diff --git a/package-lock.json b/package-lock.json index 06bc5841..14e003e6 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,62 +9,62 @@ "version": "1.4.14", "license": "AGPL-3.0-only", "dependencies": { - "@tanstack/react-virtual": "^3.13.18", - "@tiptap/extension-color": "^3.20.4", - "@tiptap/extension-image": "^3.20.4", - "@tiptap/extension-link": "^3.20.4", - "@tiptap/extension-placeholder": "^3.20.4", - "@tiptap/extension-text-align": "^3.20.4", - "@tiptap/extension-text-style": "^3.20.4", - "@tiptap/extension-underline": "^3.20.4", - "@tiptap/pm": "^3.20.4", - "@tiptap/react": "^3.20.4", - "@tiptap/starter-kit": "^3.20.4", - "asn1js": "^3.0.7", + "@tanstack/react-virtual": "^3.13.24", + "@tiptap/extension-color": "^3.22.4", + "@tiptap/extension-image": "^3.22.4", + "@tiptap/extension-link": "^3.22.4", + "@tiptap/extension-placeholder": "^3.22.4", + "@tiptap/extension-text-align": "^3.22.4", + "@tiptap/extension-text-style": "^3.22.4", + "@tiptap/extension-underline": "^3.22.4", + "@tiptap/pm": "^3.22.4", + "@tiptap/react": "^3.22.4", + "@tiptap/starter-kit": "^3.22.4", + "asn1js": "^3.0.10", "clsx": "^2.1.1", "date-fns": "^4.1.0", - "dompurify": "^3.3.3", + "dompurify": "^3.4.1", "jszip": "^3.10.1", - "lucide-react": "^0.575.0", - "next": "^16.1.5", - "next-intl": "^4.5.8", + "lucide-react": "^1.8.0", + "next": "^16.2.4", + "next-intl": "^4.9.1", "otpauth": "^9.5.0", - "pkijs": "^3.3.3", + "pkijs": "^3.4.0", "postal-mime": "^2.7.4", "pvtsutils": "^1.3.6", "qrcode": "^1.5.4", - "react": "^19.2.1", - "react-dom": "^19.2.1", + "react": "^19.2.5", + "react-dom": "^19.2.5", "sonner": "^2.0.7", "tailwind-merge": "^3.4.0", "webcrypto-liner": "^1.4.3", - "zustand": "^5.0.9" + "zustand": "^5.0.12" }, "devDependencies": { - "@eslint/js": "^9.39.3", - "@playwright/test": "^1.58.2", - "@tailwindcss/postcss": "^4", + "@eslint/js": "^9.39.4", + "@playwright/test": "^1.59.1", + "@tailwindcss/postcss": "^4.2.4", "@testing-library/dom": "^10.4.1", "@testing-library/jest-dom": "^6.9.1", "@testing-library/react": "^16.3.1", - "@types/node": "^25.2.3", + "@types/node": "^25.6.0", "@types/qrcode": "^1.5.6", "@types/react": "^19.2.7", "@types/react-dom": "^19.2.3", - "@typescript-eslint/eslint-plugin": "^8.49.0", - "@typescript-eslint/parser": "^8.49.0", - "@vitejs/plugin-react": "^5.1.2", - "@vitest/ui": "^4.0.16", - "eslint": "^9.39.2", + "@typescript-eslint/eslint-plugin": "^8.59.0", + "@typescript-eslint/parser": "^8.59.0", + "@vitejs/plugin-react": "^6.0.1", + "@vitest/ui": "^4.1.5", + "eslint": "^9.39.4", "eslint-plugin-react": "^7.37.5", - "eslint-plugin-react-hooks": "^7.0.1", + "eslint-plugin-react-hooks": "^7.1.1", "fake-indexeddb": "^6.2.5", - "globals": "^17.0.0", + "globals": "^17.5.0", "husky": "^9.1.7", "jsdom": "^28.1.0", - "tailwindcss": "^4.1.17", + "tailwindcss": "^4.2.4", "typescript": "^5.9.3", - "vitest": "^4.0.16" + "vitest": "^4.1.5" } }, "node_modules/@acemir/cssom": { @@ -301,16 +301,6 @@ "@babel/core": "^7.0.0" } }, - "node_modules/@babel/helper-plugin-utils": { - "version": "7.28.6", - "resolved": "https://registry.npmjs.org/@babel/helper-plugin-utils/-/helper-plugin-utils-7.28.6.tgz", - "integrity": "sha512-S9gzZ/bz83GRysI7gAD4wPT/AI3uCnY+9xn+Mx/KPs2JwHJIz1W8PZkg2cqyt3RNOBM8ejcXhV6y8Og7ly/Dug==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=6.9.0" - } - }, "node_modules/@babel/helper-string-parser": { "version": "7.27.1", "resolved": "https://registry.npmjs.org/@babel/helper-string-parser/-/helper-string-parser-7.27.1.tgz", @@ -371,38 +361,6 @@ "node": ">=6.0.0" } }, - "node_modules/@babel/plugin-transform-react-jsx-self": { - "version": "7.27.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-react-jsx-self/-/plugin-transform-react-jsx-self-7.27.1.tgz", - "integrity": "sha512-6UzkCs+ejGdZ5mFFC/OCUrv028ab2fp1znZmCZjAOBKiBK2jXD1O+BPSfX8X2qjJ75fZBMSnQn3Rq2mrBJK2mw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/helper-plugin-utils": "^7.27.1" - }, - "engines": { - "node": ">=6.9.0" - }, - "peerDependencies": { - "@babel/core": "^7.0.0-0" - } - }, - "node_modules/@babel/plugin-transform-react-jsx-source": { - "version": "7.27.1", - "resolved": "https://registry.npmjs.org/@babel/plugin-transform-react-jsx-source/-/plugin-transform-react-jsx-source-7.27.1.tgz", - "integrity": "sha512-zbwoTsBruTeKB9hSq73ha66iFeJHuaFkUbwvqElnygoNbj/jHRsSeokowZFN3CZ64IvEqcmmkVe89OPXc7ldAw==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/helper-plugin-utils": "^7.27.1" - }, - "engines": { - "node": ">=6.9.0" - }, - "peerDependencies": { - "@babel/core": "^7.0.0-0" - } - }, "node_modules/@babel/runtime": { "version": "7.28.6", "resolved": "https://registry.npmjs.org/@babel/runtime/-/runtime-7.28.6.tgz", @@ -606,10 +564,33 @@ "node": ">=20.19.0" } }, + "node_modules/@emnapi/core": { + "version": "1.9.2", + "resolved": "https://registry.npmjs.org/@emnapi/core/-/core-1.9.2.tgz", + "integrity": "sha512-UC+ZhH3XtczQYfOlu3lNEkdW/p4dsJ1r/bP7H8+rhao3TTTMO1ATq/4DdIi23XuGoFY+Cz0JmCbdVl0hz9jZcA==", + "dev": true, + "license": "MIT", + "optional": true, + "dependencies": { + "@emnapi/wasi-threads": "1.2.1", + "tslib": "^2.4.0" + } + }, "node_modules/@emnapi/runtime": { - "version": "1.8.1", - "resolved": "https://registry.npmjs.org/@emnapi/runtime/-/runtime-1.8.1.tgz", - "integrity": "sha512-mehfKSMWjjNol8659Z8KxEMrdSJDDot5SXMq00dM8BN4o+CLNXQ0xH2V7EchNHV4RmbZLmmPdEaXZc5H2FXmDg==", + "version": "1.9.2", + "resolved": "https://registry.npmjs.org/@emnapi/runtime/-/runtime-1.9.2.tgz", + "integrity": "sha512-3U4+MIWHImeyu1wnmVygh5WlgfYDtyf0k8AbLhMFxOipihf6nrWC4syIm/SwEeec0mNSafiiNnMJwbza/Is6Lw==", + "license": "MIT", + "optional": true, + "dependencies": { + "tslib": "^2.4.0" + } + }, + "node_modules/@emnapi/wasi-threads": { + "version": "1.2.1", + "resolved": "https://registry.npmjs.org/@emnapi/wasi-threads/-/wasi-threads-1.2.1.tgz", + "integrity": "sha512-uTII7OYF+/Mes/MrcIOYp5yOtSMLBWSIoLPpcgwipoiKbli6k322tcoFsxoIIxPDqW01SQGAgko4EzZi2BNv2w==", + "dev": true, "license": "MIT", "optional": true, "dependencies": { @@ -629,6 +610,7 @@ "os": [ "aix" ], + "peer": true, "engines": { "node": ">=18" } @@ -646,6 +628,7 @@ "os": [ "android" ], + "peer": true, "engines": { "node": ">=18" } @@ -663,6 +646,7 @@ "os": [ "android" ], + "peer": true, "engines": { "node": ">=18" } @@ -680,6 +664,7 @@ "os": [ "android" ], + "peer": true, "engines": { "node": ">=18" } @@ -697,6 +682,7 @@ "os": [ "darwin" ], + "peer": true, "engines": { "node": ">=18" } @@ -714,6 +700,7 @@ "os": [ "darwin" ], + "peer": true, "engines": { "node": ">=18" } @@ -731,6 +718,7 @@ "os": [ "freebsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -748,6 +736,7 @@ "os": [ "freebsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -765,6 +754,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -782,6 +772,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -799,6 +790,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -816,6 +808,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -833,6 +826,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -850,6 +844,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -867,6 +862,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -884,6 +880,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -901,6 +898,7 @@ "os": [ "linux" ], + "peer": true, "engines": { "node": ">=18" } @@ -918,6 +916,7 @@ "os": [ "netbsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -935,6 +934,7 @@ "os": [ "netbsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -952,6 +952,7 @@ "os": [ "openbsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -969,6 +970,7 @@ "os": [ "openbsd" ], + "peer": true, "engines": { "node": ">=18" } @@ -986,6 +988,7 @@ "os": [ "openharmony" ], + "peer": true, "engines": { "node": ">=18" } @@ -1003,6 +1006,7 @@ "os": [ "sunos" ], + "peer": true, "engines": { "node": ">=18" } @@ -1020,6 +1024,7 @@ "os": [ "win32" ], + "peer": true, "engines": { "node": ">=18" } @@ -1037,6 +1042,7 @@ "os": [ "win32" ], + "peer": true, "engines": { "node": ">=18" } @@ -1054,6 +1060,7 @@ "os": [ "win32" ], + "peer": true, "engines": { "node": ">=18" } @@ -1088,24 +1095,24 @@ } }, "node_modules/@eslint/config-array": { - "version": "0.21.1", - "resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.21.1.tgz", - "integrity": "sha512-aw1gNayWpdI/jSYVgzN5pL0cfzU02GT3NBpeT/DXbx1/1x7ZKxFPd9bwrzygx/qiwIQiJ1sw/zD8qY/kRvlGHA==", + "version": "0.21.2", + "resolved": "https://registry.npmjs.org/@eslint/config-array/-/config-array-0.21.2.tgz", + "integrity": "sha512-nJl2KGTlrf9GjLimgIru+V/mzgSK0ABCDQRvxw5BjURL7WfH5uoWmizbH7QB6MmnMBd8cIC9uceWnezL1VZWWw==", "dev": true, "license": "Apache-2.0", "dependencies": { "@eslint/object-schema": "^2.1.7", "debug": "^4.3.1", - "minimatch": "^3.1.2" + "minimatch": "^3.1.5" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" } }, "node_modules/@eslint/config-array/node_modules/brace-expansion": { - "version": "1.1.12", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.12.tgz", - "integrity": "sha512-9T9UjW3r0UW5c1Q7GTwllptXwhvYmEzFhzMfZ9H7FQWt+uZePjZPjBP/W1ZEyZ1twGWom5/56TF4lPcqjnDHcg==", + "version": "1.1.14", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.14.tgz", + "integrity": "sha512-MWPGfDxnyzKU7rNOW9SP/c50vi3xrmrua/+6hfPbCS2ABNWfx24vPidzvC7krjU/RTo235sV776ymlsMtGKj8g==", "dev": true, "license": "MIT", "dependencies": { @@ -1153,20 +1160,20 @@ } }, "node_modules/@eslint/eslintrc": { - "version": "3.3.3", - "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.3.3.tgz", - "integrity": "sha512-Kr+LPIUVKz2qkx1HAMH8q1q6azbqBAsXJUxBl/ODDuVPX45Z9DfwB8tPjTi6nNZ8BuM3nbJxC5zCAg5elnBUTQ==", + "version": "3.3.5", + "resolved": "https://registry.npmjs.org/@eslint/eslintrc/-/eslintrc-3.3.5.tgz", + "integrity": "sha512-4IlJx0X0qftVsN5E+/vGujTRIFtwuLbNsVUe7TO6zYPDR1O6nFwvwhIKEKSrl6dZchmYBITazxKoUYOjdtjlRg==", "dev": true, "license": "MIT", "dependencies": { - "ajv": "^6.12.4", + "ajv": "^6.14.0", "debug": "^4.3.2", "espree": "^10.0.1", "globals": "^14.0.0", "ignore": "^5.2.0", "import-fresh": "^3.2.1", "js-yaml": "^4.1.1", - "minimatch": "^3.1.2", + "minimatch": "^3.1.5", "strip-json-comments": "^3.1.1" }, "engines": { @@ -1177,9 +1184,9 @@ } }, "node_modules/@eslint/eslintrc/node_modules/brace-expansion": { - "version": "1.1.12", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.12.tgz", - "integrity": "sha512-9T9UjW3r0UW5c1Q7GTwllptXwhvYmEzFhzMfZ9H7FQWt+uZePjZPjBP/W1ZEyZ1twGWom5/56TF4lPcqjnDHcg==", + "version": "1.1.14", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-1.1.14.tgz", + "integrity": "sha512-MWPGfDxnyzKU7rNOW9SP/c50vi3xrmrua/+6hfPbCS2ABNWfx24vPidzvC7krjU/RTo235sV776ymlsMtGKj8g==", "dev": true, "license": "MIT", "dependencies": { @@ -1224,9 +1231,9 @@ } }, "node_modules/@eslint/js": { - "version": "9.39.3", - "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.39.3.tgz", - "integrity": "sha512-1B1VkCq6FuUNlQvlBYb+1jDu/gV297TIs/OeiaSR9l1H27SVW55ONE1e1Vp16NqP683+xEGzxYtv4XCiDPaQiw==", + "version": "9.39.4", + "resolved": "https://registry.npmjs.org/@eslint/js/-/js-9.39.4.tgz", + "integrity": "sha512-nE7DEIchvtiFTwBw4Lfbu59PG+kCofhjsKaCWzxTpt4lfRjRMqG6uMBzKXuEcyXhOHoUp9riAm7/aWYGhXZ9cw==", "dev": true, "license": "MIT", "engines": { @@ -1306,56 +1313,34 @@ "license": "MIT", "optional": true }, - "node_modules/@formatjs/ecma402-abstract": { - "version": "3.1.1", - "resolved": "https://registry.npmjs.org/@formatjs/ecma402-abstract/-/ecma402-abstract-3.1.1.tgz", - "integrity": "sha512-jhZbTwda+2tcNrs4kKvxrPLPjx8QsBCLCUgrrJ/S+G9YrGHWLhAyFMMBHJBnBoOwuLHd7L14FgYudviKaxkO2Q==", - "license": "MIT", - "dependencies": { - "@formatjs/fast-memoize": "3.1.0", - "@formatjs/intl-localematcher": "0.8.1", - "decimal.js": "^10.6.0", - "tslib": "^2.8.1" - } - }, "node_modules/@formatjs/fast-memoize": { - "version": "3.1.0", - "resolved": "https://registry.npmjs.org/@formatjs/fast-memoize/-/fast-memoize-3.1.0.tgz", - "integrity": "sha512-b5mvSWCI+XVKiz5WhnBCY3RJ4ZwfjAidU0yVlKa3d3MSgKmH1hC3tBGEAtYyN5mqL7N0G5x0BOUYyO8CEupWgg==", - "license": "MIT", - "dependencies": { - "tslib": "^2.8.1" - } + "version": "3.1.2", + "resolved": "https://registry.npmjs.org/@formatjs/fast-memoize/-/fast-memoize-3.1.2.tgz", + "integrity": "sha512-vPnriihkfK0lzoQGaXq+qXH23VsYyansRTkTgo2aTG0k1NjLFyZimFVdfj4C9JkSE5dm7CEngcQ5TTc1yAyBfQ==", + "license": "MIT" }, "node_modules/@formatjs/icu-messageformat-parser": { - "version": "3.5.1", - "resolved": "https://registry.npmjs.org/@formatjs/icu-messageformat-parser/-/icu-messageformat-parser-3.5.1.tgz", - "integrity": "sha512-sSDmSvmmoVQ92XqWb499KrIhv/vLisJU8ITFrx7T7NZHUmMY7EL9xgRowAosaljhqnj/5iufG24QrdzB6X3ItA==", + "version": "3.5.4", + "resolved": "https://registry.npmjs.org/@formatjs/icu-messageformat-parser/-/icu-messageformat-parser-3.5.4.tgz", + "integrity": "sha512-JVY39ROgLt+pIYngo6piyj4OVfZmXs/2FkC4wLS+ql1Eig/sGJKB7YwDO/5bkJFkfwaFAeIpgEiJc8hiYxNalw==", "license": "MIT", "dependencies": { - "@formatjs/ecma402-abstract": "3.1.1", - "@formatjs/icu-skeleton-parser": "2.1.1", - "tslib": "^2.8.1" + "@formatjs/icu-skeleton-parser": "2.1.4" } }, "node_modules/@formatjs/icu-skeleton-parser": { - "version": "2.1.1", - "resolved": "https://registry.npmjs.org/@formatjs/icu-skeleton-parser/-/icu-skeleton-parser-2.1.1.tgz", - "integrity": "sha512-PSFABlcNefjI6yyk8f7nyX1DC7NHmq6WaCHZLySEXBrXuLOB2f935YsnzuPjlz+ibhb9yWTdPeVX1OVcj24w2Q==", - "license": "MIT", - "dependencies": { - "@formatjs/ecma402-abstract": "3.1.1", - "tslib": "^2.8.1" - } + "version": "2.1.4", + "resolved": "https://registry.npmjs.org/@formatjs/icu-skeleton-parser/-/icu-skeleton-parser-2.1.4.tgz", + "integrity": "sha512-8bSFZbrlvGX11ywMZxtgkPBt5Q8/etyts7j7j+GWpOVK1g43zwMIH3LZxk43HAtEP7L/jtZ+OZaMiFTOiBj9CA==", + "license": "MIT" }, "node_modules/@formatjs/intl-localematcher": { - "version": "0.8.1", - "resolved": "https://registry.npmjs.org/@formatjs/intl-localematcher/-/intl-localematcher-0.8.1.tgz", - "integrity": "sha512-xwEuwQFdtSq1UKtQnyTZWC+eHdv7Uygoa+H2k/9uzBVQjDyp9r20LNDNKedWXll7FssT3GRHvqsdJGYSUWqYFA==", + "version": "0.8.3", + "resolved": "https://registry.npmjs.org/@formatjs/intl-localematcher/-/intl-localematcher-0.8.3.tgz", + "integrity": "sha512-pHUjWb9NuhnMs8+PxQdzBtZRFJHlGhrURGAbm6Ltwl82BFajeuiIR3jblSa7ia3r62rXe/0YtVpUG3xWr5bFCA==", "license": "MIT", "dependencies": { - "@formatjs/fast-memoize": "3.1.0", - "tslib": "^2.8.1" + "@formatjs/fast-memoize": "3.1.2" } }, "node_modules/@humanfs/core": { @@ -1926,16 +1911,35 @@ "@jridgewell/sourcemap-codec": "^1.4.14" } }, + "node_modules/@napi-rs/wasm-runtime": { + "version": "1.1.4", + "resolved": "https://registry.npmjs.org/@napi-rs/wasm-runtime/-/wasm-runtime-1.1.4.tgz", + "integrity": "sha512-3NQNNgA1YSlJb/kMH1ildASP9HW7/7kYnRI2szWJaofaS1hWmbGI4H+d3+22aGzXXN9IJ+n+GiFVcGipJP18ow==", + "dev": true, + "license": "MIT", + "optional": true, + "dependencies": { + "@tybys/wasm-util": "^0.10.1" + }, + "funding": { + "type": "github", + "url": "https://github.com/sponsors/Brooooooklyn" + }, + "peerDependencies": { + "@emnapi/core": "^1.7.1", + "@emnapi/runtime": "^1.7.1" + } + }, "node_modules/@next/env": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/env/-/env-16.1.6.tgz", - "integrity": "sha512-N1ySLuZjnAtN3kFnwhAwPvZah8RJxKasD7x1f8shFqhncnWZn4JMfg37diLNuoHsLAlrDfM3g4mawVdtAG8XLQ==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/env/-/env-16.2.4.tgz", + "integrity": "sha512-dKkkOzOSwFYe5RX6y26fZgkSpVAlIOJKQHIiydQcrWH6y/97+RceSOAdjZ14Qa3zLduVUy0TXcn+EiM6t4rPgw==", "license": "MIT" }, "node_modules/@next/swc-darwin-arm64": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-darwin-arm64/-/swc-darwin-arm64-16.1.6.tgz", - "integrity": "sha512-wTzYulosJr/6nFnqGW7FrG3jfUUlEf8UjGA0/pyypJl42ExdVgC6xJgcXQ+V8QFn6niSG2Pb8+MIG1mZr2vczw==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-darwin-arm64/-/swc-darwin-arm64-16.2.4.tgz", + "integrity": "sha512-OXTFFox5EKN1Ym08vfrz+OXxmCcEjT4SFMbNRsWZE99dMqt2Kcusl5MqPXcW232RYkMLQTy0hqgAMEsfEd/l2A==", "cpu": [ "arm64" ], @@ -1949,9 +1953,9 @@ } }, "node_modules/@next/swc-darwin-x64": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-darwin-x64/-/swc-darwin-x64-16.1.6.tgz", - "integrity": "sha512-BLFPYPDO+MNJsiDWbeVzqvYd4NyuRrEYVB5k2N3JfWncuHAy2IVwMAOlVQDFjj+krkWzhY2apvmekMkfQR0CUQ==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-darwin-x64/-/swc-darwin-x64-16.2.4.tgz", + "integrity": "sha512-XhpVnUfmYWvD3YrXu55XdcAkQtOnvaI6wtQa8fuF5fGoKoxIUZ0kWPtcOfqJEWngFF/lOS9l3+O9CcownhiQxQ==", "cpu": [ "x64" ], @@ -1965,9 +1969,9 @@ } }, "node_modules/@next/swc-linux-arm64-gnu": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-linux-arm64-gnu/-/swc-linux-arm64-gnu-16.1.6.tgz", - "integrity": "sha512-OJYkCd5pj/QloBvoEcJ2XiMnlJkRv9idWA/j0ugSuA34gMT6f5b7vOiCQHVRpvStoZUknhl6/UxOXL4OwtdaBw==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-linux-arm64-gnu/-/swc-linux-arm64-gnu-16.2.4.tgz", + "integrity": "sha512-Mx/tjlNA3G8kg14QvuGAJ4xBwPk1tUHq56JxZ8CXnZwz1Etz714soCEzGQQzVMz4bEnGPowzkV6Xrp6wAkEWOQ==", "cpu": [ "arm64" ], @@ -1981,9 +1985,9 @@ } }, "node_modules/@next/swc-linux-arm64-musl": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-linux-arm64-musl/-/swc-linux-arm64-musl-16.1.6.tgz", - "integrity": "sha512-S4J2v+8tT3NIO9u2q+S0G5KdvNDjXfAv06OhfOzNDaBn5rw84DGXWndOEB7d5/x852A20sW1M56vhC/tRVbccQ==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-linux-arm64-musl/-/swc-linux-arm64-musl-16.2.4.tgz", + "integrity": "sha512-iVMMp14514u7Nup2umQS03nT/bN9HurK8ufylC3FZNykrwjtx7V1A7+4kvhbDSCeonTVqV3Txnv0Lu+m2oDXNg==", "cpu": [ "arm64" ], @@ -1997,9 +2001,9 @@ } }, "node_modules/@next/swc-linux-x64-gnu": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-16.1.6.tgz", - "integrity": "sha512-2eEBDkFlMMNQnkTyPBhQOAyn2qMxyG2eE7GPH2WIDGEpEILcBPI/jdSv4t6xupSP+ot/jkfrCShLAa7+ZUPcJQ==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-linux-x64-gnu/-/swc-linux-x64-gnu-16.2.4.tgz", + "integrity": "sha512-EZOvm1aQWgnI/N/xcWOlnS3RQBk0VtVav5Zo7n4p0A7UKyTDx047k8opDbXgBpHl4CulRqRfbw3QrX2w5UOXMQ==", "cpu": [ "x64" ], @@ -2013,9 +2017,9 @@ } }, "node_modules/@next/swc-linux-x64-musl": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-linux-x64-musl/-/swc-linux-x64-musl-16.1.6.tgz", - "integrity": "sha512-oicJwRlyOoZXVlxmIMaTq7f8pN9QNbdes0q2FXfRsPhfCi8n8JmOZJm5oo1pwDaFbnnD421rVU409M3evFbIqg==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-linux-x64-musl/-/swc-linux-x64-musl-16.2.4.tgz", + "integrity": "sha512-h9FxsngCm9cTBf71AR4fGznDEDx1hS7+kSEiIRjq5kO1oXWm07DxVGZjCvk0SGx7TSjlUqhI8oOyz7NfwAdPoA==", "cpu": [ "x64" ], @@ -2029,9 +2033,9 @@ } }, "node_modules/@next/swc-win32-arm64-msvc": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-win32-arm64-msvc/-/swc-win32-arm64-msvc-16.1.6.tgz", - "integrity": "sha512-gQmm8izDTPgs+DCWH22kcDmuUp7NyiJgEl18bcr8irXA5N2m2O+JQIr6f3ct42GOs9c0h8QF3L5SzIxcYAAXXw==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-win32-arm64-msvc/-/swc-win32-arm64-msvc-16.2.4.tgz", + "integrity": "sha512-3NdJV5OXMSOeJYijX+bjaLge3mJBlh4ybydbT4GFoB/2hAojWHtMhl3CYlYoMrjPuodp0nzFVi4Tj2+WaMg+Ow==", "cpu": [ "arm64" ], @@ -2045,9 +2049,9 @@ } }, "node_modules/@next/swc-win32-x64-msvc": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/@next/swc-win32-x64-msvc/-/swc-win32-x64-msvc-16.1.6.tgz", - "integrity": "sha512-NRfO39AIrzBnixKbjuo2YiYhB6o9d8v/ymU9m/Xk8cyVk+k7XylniXkHwjs4s70wedVffc6bQNbufk5v0xEm0A==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/@next/swc-win32-x64-msvc/-/swc-win32-x64-msvc-16.2.4.tgz", + "integrity": "sha512-kMVGgsqhO5YTYODD9IPGGhA6iprWidQckK3LmPeW08PIFENRmgfb4MjXHO+p//d+ts2rpjvK5gXWzXSMrPl9cw==", "cpu": [ "x64" ], @@ -2072,6 +2076,16 @@ "url": "https://paulmillr.com/funding/" } }, + "node_modules/@oxc-project/types": { + "version": "0.126.0", + "resolved": "https://registry.npmjs.org/@oxc-project/types/-/types-0.126.0.tgz", + "integrity": "sha512-oGfVtjAgwQVVpfBrbtk4e1XDyWHRFta6BS3GWVzrF8xYBT2VGQAk39yJS/wFSMrZqoiCU4oghT3Ch0HaHGIHcQ==", + "dev": true, + "license": "MIT", + "funding": { + "url": "https://github.com/sponsors/Boshen" + } + }, "node_modules/@parcel/watcher": { "version": "2.5.6", "resolved": "https://registry.npmjs.org/@parcel/watcher/-/watcher-2.5.6.tgz", @@ -2391,13 +2405,13 @@ } }, "node_modules/@playwright/test": { - "version": "1.58.2", - "resolved": "https://registry.npmjs.org/@playwright/test/-/test-1.58.2.tgz", - "integrity": "sha512-akea+6bHYBBfA9uQqSYmlJXn61cTa+jbO87xVLCWbTqbWadRVmhxlXATaOjOgcBaWU4ePo0wB41KMFv3o35IXA==", + "version": "1.59.1", + "resolved": "https://registry.npmjs.org/@playwright/test/-/test-1.59.1.tgz", + "integrity": "sha512-PG6q63nQg5c9rIi4/Z5lR5IVF7yU5MqmKaPOe0HSc0O2cX1fPi96sUQu5j7eo4gKCkB2AnNGoWt7y4/Xx3Kcqg==", "devOptional": true, "license": "Apache-2.0", "dependencies": { - "playwright": "1.58.2" + "playwright": "1.59.1" }, "bin": { "playwright": "cli.js" @@ -2413,37 +2427,10 @@ "dev": true, "license": "MIT" }, - "node_modules/@remirror/core-constants": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/@remirror/core-constants/-/core-constants-3.0.0.tgz", - "integrity": "sha512-42aWfPrimMfDKDi4YegyS7x+/0tlzaqwPQCULLanv3DMIlu96KTJR0fM5isWX2UViOqlGnX6YFgqWepcX+XMNg==", - "license": "MIT" - }, - "node_modules/@rolldown/pluginutils": { - "version": "1.0.0-rc.3", - "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-rc.3.tgz", - "integrity": "sha512-eybk3TjzzzV97Dlj5c+XrBFW57eTNhzod66y9HrBlzJ6NsCrWCp/2kaPS3K9wJmurBC0Tdw4yPjXKZqlznim3Q==", - "dev": true, - "license": "MIT" - }, - "node_modules/@rollup/rollup-android-arm-eabi": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-android-arm-eabi/-/rollup-android-arm-eabi-4.59.0.tgz", - "integrity": "sha512-upnNBkA6ZH2VKGcBj9Fyl9IGNPULcjXRlg0LLeaioQWueH30p6IXtJEbKAgvyv+mJaMxSm1l6xwDXYjpEMiLMg==", - "cpu": [ - "arm" - ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "android" - ] - }, - "node_modules/@rollup/rollup-android-arm64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-android-arm64/-/rollup-android-arm64-4.59.0.tgz", - "integrity": "sha512-hZ+Zxj3SySm4A/DylsDKZAeVg0mvi++0PYVceVyX7hemkw7OreKdCvW2oQ3T1FMZvCaQXqOTHb8qmBShoqk69Q==", + "node_modules/@rolldown/binding-android-arm64": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-android-arm64/-/binding-android-arm64-1.0.0-rc.16.tgz", + "integrity": "sha512-rhY3k7Bsae9qQfOtph2Pm2jZEA+s8Gmjoz4hhmx70K9iMQ/ddeae+xhRQcM5IuVx5ry1+bGfkvMn7D6MJggVSA==", "cpu": [ "arm64" ], @@ -2452,12 +2439,15 @@ "optional": true, "os": [ "android" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-darwin-arm64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-arm64/-/rollup-darwin-arm64-4.59.0.tgz", - "integrity": "sha512-W2Psnbh1J8ZJw0xKAd8zdNgF9HRLkdWwwdWqubSVk0pUuQkoHnv7rx4GiF9rT4t5DIZGAsConRE3AxCdJ4m8rg==", + "node_modules/@rolldown/binding-darwin-arm64": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-darwin-arm64/-/binding-darwin-arm64-1.0.0-rc.16.tgz", + "integrity": "sha512-rNz0yK078yrNn3DrdgN+PKiMOW8HfQ92jQiXxwX8yW899ayV00MLVdaCNeVBhG/TbH3ouYVObo8/yrkiectkcQ==", "cpu": [ "arm64" ], @@ -2466,12 +2456,15 @@ "optional": true, "os": [ "darwin" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-darwin-x64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-darwin-x64/-/rollup-darwin-x64-4.59.0.tgz", - "integrity": "sha512-ZW2KkwlS4lwTv7ZVsYDiARfFCnSGhzYPdiOU4IM2fDbL+QGlyAbjgSFuqNRbSthybLbIJ915UtZBtmuLrQAT/w==", + "node_modules/@rolldown/binding-darwin-x64": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-darwin-x64/-/binding-darwin-x64-1.0.0-rc.16.tgz", + "integrity": "sha512-r/OmdR00HmD4i79Z//xO06uEPOq5hRXdhw7nzkxQxwSavs3PSHa1ijntdpOiZ2mzOQ3fVVu8C1M19FoNM+dMUQ==", "cpu": [ "x64" ], @@ -2480,26 +2473,15 @@ "optional": true, "os": [ "darwin" - ] - }, - "node_modules/@rollup/rollup-freebsd-arm64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-freebsd-arm64/-/rollup-freebsd-arm64-4.59.0.tgz", - "integrity": "sha512-EsKaJ5ytAu9jI3lonzn3BgG8iRBjV4LxZexygcQbpiU0wU0ATxhNVEpXKfUa0pS05gTcSDMKpn3Sx+QB9RlTTA==", - "cpu": [ - "arm64" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "freebsd" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-freebsd-x64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-freebsd-x64/-/rollup-freebsd-x64-4.59.0.tgz", - "integrity": "sha512-d3DuZi2KzTMjImrxoHIAODUZYoUUMsuUiY4SRRcJy6NJoZ6iIqWnJu9IScV9jXysyGMVuW+KNzZvBLOcpdl3Vg==", + "node_modules/@rolldown/binding-freebsd-x64": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-freebsd-x64/-/binding-freebsd-x64-1.0.0-rc.16.tgz", + "integrity": "sha512-KcRE5w8h0OnjUatG8pldyD14/CQ5Phs1oxfR+3pKDjboHRo9+MkqQaiIZlZRpsxC15paeXme/I127tUa9TXJ6g==", "cpu": [ "x64" ], @@ -2508,12 +2490,15 @@ "optional": true, "os": [ "freebsd" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-arm-gnueabihf": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm-gnueabihf/-/rollup-linux-arm-gnueabihf-4.59.0.tgz", - "integrity": "sha512-t4ONHboXi/3E0rT6OZl1pKbl2Vgxf9vJfWgmUoCEVQVxhW6Cw/c8I6hbbu7DAvgp82RKiH7TpLwxnJeKv2pbsw==", + "node_modules/@rolldown/binding-linux-arm-gnueabihf": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-arm-gnueabihf/-/binding-linux-arm-gnueabihf-1.0.0-rc.16.tgz", + "integrity": "sha512-bT0guA1bpxEJ/ZhTRniQf7rNF8ybvXOuWbNIeLABaV5NGjx4EtOWBTSRGWFU9ZWVkPOZ+HNFP8RMcBokBiZ0Kg==", "cpu": [ "arm" ], @@ -2522,26 +2507,15 @@ "optional": true, "os": [ "linux" - ] - }, - "node_modules/@rollup/rollup-linux-arm-musleabihf": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm-musleabihf/-/rollup-linux-arm-musleabihf-4.59.0.tgz", - "integrity": "sha512-CikFT7aYPA2ufMD086cVORBYGHffBo4K8MQ4uPS/ZnY54GKj36i196u8U+aDVT2LX4eSMbyHtyOh7D7Zvk2VvA==", - "cpu": [ - "arm" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-arm64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm64-gnu/-/rollup-linux-arm64-gnu-4.59.0.tgz", - "integrity": "sha512-jYgUGk5aLd1nUb1CtQ8E+t5JhLc9x5WdBKew9ZgAXg7DBk0ZHErLHdXM24rfX+bKrFe+Xp5YuJo54I5HFjGDAA==", + "node_modules/@rolldown/binding-linux-arm64-gnu": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-arm64-gnu/-/binding-linux-arm64-gnu-1.0.0-rc.16.tgz", + "integrity": "sha512-+tHktCHWV8BDQSjemUqm/Jl/TPk3QObCTIjmdDy/nlupcujZghmKK2962LYrqFpWu+ai01AN/REOH3NEpqvYQg==", "cpu": [ "arm64" ], @@ -2550,12 +2524,15 @@ "optional": true, "os": [ "linux" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-arm64-musl": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-arm64-musl/-/rollup-linux-arm64-musl-4.59.0.tgz", - "integrity": "sha512-peZRVEdnFWZ5Bh2KeumKG9ty7aCXzzEsHShOZEFiCQlDEepP1dpUl/SrUNXNg13UmZl+gzVDPsiCwnV1uI0RUA==", + "node_modules/@rolldown/binding-linux-arm64-musl": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-arm64-musl/-/binding-linux-arm64-musl-1.0.0-rc.16.tgz", + "integrity": "sha512-3fPzdREH806oRLxpTWW1Gt4tQHs0TitZFOECB2xzCFLPKnSOy90gwA7P29cksYilFO6XVRY1kzga0cL2nRjKPg==", "cpu": [ "arm64" ], @@ -2564,40 +2541,15 @@ "optional": true, "os": [ "linux" - ] - }, - "node_modules/@rollup/rollup-linux-loong64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-loong64-gnu/-/rollup-linux-loong64-gnu-4.59.0.tgz", - "integrity": "sha512-gbUSW/97f7+r4gHy3Jlup8zDG190AuodsWnNiXErp9mT90iCy9NKKU0Xwx5k8VlRAIV2uU9CsMnEFg/xXaOfXg==", - "cpu": [ - "loong64" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-loong64-musl": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-loong64-musl/-/rollup-linux-loong64-musl-4.59.0.tgz", - "integrity": "sha512-yTRONe79E+o0FWFijasoTjtzG9EBedFXJMl888NBEDCDV9I2wGbFFfJQQe63OijbFCUZqxpHz1GzpbtSFikJ4Q==", - "cpu": [ - "loong64" - ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] - }, - "node_modules/@rollup/rollup-linux-ppc64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-ppc64-gnu/-/rollup-linux-ppc64-gnu-4.59.0.tgz", - "integrity": "sha512-sw1o3tfyk12k3OEpRddF68a1unZ5VCN7zoTNtSn2KndUE+ea3m3ROOKRCZxEpmT9nsGnogpFP9x6mnLTCaoLkA==", + "node_modules/@rolldown/binding-linux-ppc64-gnu": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-ppc64-gnu/-/binding-linux-ppc64-gnu-1.0.0-rc.16.tgz", + "integrity": "sha512-EKwI1tSrLs7YVw+JPJT/G2dJQ1jl9qlTTTEG0V2Ok/RdOenRfBw2PQdLPyjhIu58ocdBfP7vIRN/pvMsPxs/AQ==", "cpu": [ "ppc64" ], @@ -2606,54 +2558,15 @@ "optional": true, "os": [ "linux" - ] - }, - "node_modules/@rollup/rollup-linux-ppc64-musl": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-ppc64-musl/-/rollup-linux-ppc64-musl-4.59.0.tgz", - "integrity": "sha512-+2kLtQ4xT3AiIxkzFVFXfsmlZiG5FXYW7ZyIIvGA7Bdeuh9Z0aN4hVyXS/G1E9bTP/vqszNIN/pUKCk/BTHsKA==", - "cpu": [ - "ppc64" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-riscv64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-riscv64-gnu/-/rollup-linux-riscv64-gnu-4.59.0.tgz", - "integrity": "sha512-NDYMpsXYJJaj+I7UdwIuHHNxXZ/b/N2hR15NyH3m2qAtb/hHPA4g4SuuvrdxetTdndfj9b1WOmy73kcPRoERUg==", - "cpu": [ - "riscv64" - ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] - }, - "node_modules/@rollup/rollup-linux-riscv64-musl": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-riscv64-musl/-/rollup-linux-riscv64-musl-4.59.0.tgz", - "integrity": "sha512-nLckB8WOqHIf1bhymk+oHxvM9D3tyPndZH8i8+35p/1YiVoVswPid2yLzgX7ZJP0KQvnkhM4H6QZ5m0LzbyIAg==", - "cpu": [ - "riscv64" - ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "linux" - ] - }, - "node_modules/@rollup/rollup-linux-s390x-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-s390x-gnu/-/rollup-linux-s390x-gnu-4.59.0.tgz", - "integrity": "sha512-oF87Ie3uAIvORFBpwnCvUzdeYUqi2wY6jRFWJAy1qus/udHFYIkplYRW+wo+GRUP4sKzYdmE1Y3+rY5Gc4ZO+w==", + "node_modules/@rolldown/binding-linux-s390x-gnu": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-s390x-gnu/-/binding-linux-s390x-gnu-1.0.0-rc.16.tgz", + "integrity": "sha512-Uknladnb3Sxqu6SEcqBldQyJUpk8NleooZEc0MbRBJ4inEhRYWZX0NJu12vNf2mqAq7gsofAxHrGghiUYjhaLQ==", "cpu": [ "s390x" ], @@ -2662,12 +2575,15 @@ "optional": true, "os": [ "linux" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-x64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-x64-gnu/-/rollup-linux-x64-gnu-4.59.0.tgz", - "integrity": "sha512-3AHmtQq/ppNuUspKAlvA8HtLybkDflkMuLK4DPo77DfthRb71V84/c4MlWJXixZz4uruIH4uaa07IqoAkG64fg==", + "node_modules/@rolldown/binding-linux-x64-gnu": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-x64-gnu/-/binding-linux-x64-gnu-1.0.0-rc.16.tgz", + "integrity": "sha512-FIb8+uG49sZBtLTn+zt1AJ20TqVcqWeSIyoVt0or7uAWesgKaHbiBh6OpA/k9v0LTt+PTrb1Lao133kP4uVxkg==", "cpu": [ "x64" ], @@ -2676,12 +2592,15 @@ "optional": true, "os": [ "linux" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-linux-x64-musl": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-linux-x64-musl/-/rollup-linux-x64-musl-4.59.0.tgz", - "integrity": "sha512-2UdiwS/9cTAx7qIUZB/fWtToJwvt0Vbo0zmnYt7ED35KPg13Q0ym1g442THLC7VyI6JfYTP4PiSOWyoMdV2/xg==", + "node_modules/@rolldown/binding-linux-x64-musl": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-linux-x64-musl/-/binding-linux-x64-musl-1.0.0-rc.16.tgz", + "integrity": "sha512-RuERhF9/EgWxZEXYWCOaViUWHIboceK4/ivdtQ3R0T44NjLkIIlGIAVAuCddFxsZ7vnRHtNQUrt2vR2n2slB2w==", "cpu": [ "x64" ], @@ -2690,26 +2609,15 @@ "optional": true, "os": [ "linux" - ] - }, - "node_modules/@rollup/rollup-openbsd-x64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-openbsd-x64/-/rollup-openbsd-x64-4.59.0.tgz", - "integrity": "sha512-M3bLRAVk6GOwFlPTIxVBSYKUaqfLrn8l0psKinkCFxl4lQvOSz8ZrKDz2gxcBwHFpci0B6rttydI4IpS4IS/jQ==", - "cpu": [ - "x64" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "openbsd" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-openharmony-arm64": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-openharmony-arm64/-/rollup-openharmony-arm64-4.59.0.tgz", - "integrity": "sha512-tt9KBJqaqp5i5HUZzoafHZX8b5Q2Fe7UjYERADll83O4fGqJ49O1FsL6LpdzVFQcpwvnyd0i+K/VSwu/o/nWlA==", + "node_modules/@rolldown/binding-openharmony-arm64": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-openharmony-arm64/-/binding-openharmony-arm64-1.0.0-rc.16.tgz", + "integrity": "sha512-mXcXnvd9GpazCxeUCCnZ2+YF7nut+ZOEbE4GtaiPtyY6AkhZWbK70y1KK3j+RDhjVq5+U8FySkKRb/+w0EeUwA==", "cpu": [ "arm64" ], @@ -2718,12 +2626,34 @@ "optional": true, "os": [ "openharmony" - ] + ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-win32-arm64-msvc": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-arm64-msvc/-/rollup-win32-arm64-msvc-4.59.0.tgz", - "integrity": "sha512-V5B6mG7OrGTwnxaNUzZTDTjDS7F75PO1ae6MJYdiMu60sq0CqN5CVeVsbhPxalupvTX8gXVSU9gq+Rx1/hvu6A==", + "node_modules/@rolldown/binding-wasm32-wasi": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-wasm32-wasi/-/binding-wasm32-wasi-1.0.0-rc.16.tgz", + "integrity": "sha512-3Q2KQxnC8IJOLqXmUMoYwyIPZU9hzRbnHaoV3Euz+VVnjZKcY8ktnNP8T9R4/GGQtb27C/UYKABxesKWb8lsvQ==", + "cpu": [ + "wasm32" + ], + "dev": true, + "license": "MIT", + "optional": true, + "dependencies": { + "@emnapi/core": "1.9.2", + "@emnapi/runtime": "1.9.2", + "@napi-rs/wasm-runtime": "^1.1.4" + }, + "engines": { + "node": "^20.19.0 || >=22.12.0" + } + }, + "node_modules/@rolldown/binding-win32-arm64-msvc": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-win32-arm64-msvc/-/binding-win32-arm64-msvc-1.0.0-rc.16.tgz", + "integrity": "sha512-tj7XRemQcOcFwv7qhpUxMTBbI5mWMlE4c1Omhg5+h8GuLXzyj8HviYgR+bB2DMDgRqUE+jiDleqSCRjx4aYk/Q==", "cpu": [ "arm64" ], @@ -2732,26 +2662,15 @@ "optional": true, "os": [ "win32" - ] - }, - "node_modules/@rollup/rollup-win32-ia32-msvc": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-ia32-msvc/-/rollup-win32-ia32-msvc-4.59.0.tgz", - "integrity": "sha512-UKFMHPuM9R0iBegwzKF4y0C4J9u8C6MEJgFuXTBerMk7EJ92GFVFYBfOZaSGLu6COf7FxpQNqhNS4c4icUPqxA==", - "cpu": [ - "ia32" ], - "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "win32" - ] + "engines": { + "node": "^20.19.0 || >=22.12.0" + } }, - "node_modules/@rollup/rollup-win32-x64-gnu": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-x64-gnu/-/rollup-win32-x64-gnu-4.59.0.tgz", - "integrity": "sha512-laBkYlSS1n2L8fSo1thDNGrCTQMmxjYY5G0WFWjFFYZkKPjsMBsgJfGf4TLxXrF6RyhI60L8TMOjBMvXiTcxeA==", + "node_modules/@rolldown/binding-win32-x64-msvc": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/binding-win32-x64-msvc/-/binding-win32-x64-msvc-1.0.0-rc.16.tgz", + "integrity": "sha512-PH5DRZT+F4f2PTXRXR8uJxnBq2po/xFtddyabTJVJs/ZYVHqXPEgNIr35IHTEa6bpa0Q8Awg+ymkTaGnKITw4g==", "cpu": [ "x64" ], @@ -2760,21 +2679,17 @@ "optional": true, "os": [ "win32" - ] - }, - "node_modules/@rollup/rollup-win32-x64-msvc": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/@rollup/rollup-win32-x64-msvc/-/rollup-win32-x64-msvc-4.59.0.tgz", - "integrity": "sha512-2HRCml6OztYXyJXAvdDXPKcawukWY2GpR5/nxKp4iBgiO3wcoEGkAaqctIbZcNB6KlUQBIqt8VYkNSj2397EfA==", - "cpu": [ - "x64" ], + "engines": { + "node": "^20.19.0 || >=22.12.0" + } + }, + "node_modules/@rolldown/pluginutils": { + "version": "1.0.0-rc.7", + "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-rc.7.tgz", + "integrity": "sha512-qujRfC8sFVInYSPPMLQByRh7zhwkGFS4+tyMQ83srV1qrxL4g8E2tyxVVyxd0+8QeBM1mIk9KbWxkegRr76XzA==", "dev": true, - "license": "MIT", - "optional": true, - "os": [ - "win32" - ] + "license": "MIT" }, "node_modules/@schummar/icu-type-parser": { "version": "1.21.5", @@ -3012,49 +2927,49 @@ } }, "node_modules/@tailwindcss/node": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/node/-/node-4.2.1.tgz", - "integrity": "sha512-jlx6sLk4EOwO6hHe1oCGm1Q4AN/s0rSrTTPBGPM0/RQ6Uylwq17FuU8IeJJKEjtc6K6O07zsvP+gDO6MMWo7pg==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/node/-/node-4.2.4.tgz", + "integrity": "sha512-Ai7+yQPxz3ddrDQzFfBKdHEVBg0w3Zl83jnjuwxnZOsnH9pGn93QHQtpU0p/8rYWxvbFZHneni6p1BSLK4DkGA==", "dev": true, "license": "MIT", "dependencies": { "@jridgewell/remapping": "^2.3.5", "enhanced-resolve": "^5.19.0", "jiti": "^2.6.1", - "lightningcss": "1.31.1", + "lightningcss": "1.32.0", "magic-string": "^0.30.21", "source-map-js": "^1.2.1", - "tailwindcss": "4.2.1" + "tailwindcss": "4.2.4" } }, "node_modules/@tailwindcss/oxide": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide/-/oxide-4.2.1.tgz", - "integrity": "sha512-yv9jeEFWnjKCI6/T3Oq50yQEOqmpmpfzG1hcZsAOaXFQPfzWprWrlHSdGPEF3WQTi8zu8ohC9Mh9J470nT5pUw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide/-/oxide-4.2.4.tgz", + "integrity": "sha512-9El/iI069DKDSXwTvB9J4BwdO5JhRrOweGaK25taBAvBXyXqJAX+Jqdvs8r8gKpsI/1m0LeJLyQYTf/WLrBT1Q==", "dev": true, "license": "MIT", "engines": { "node": ">= 20" }, "optionalDependencies": { - "@tailwindcss/oxide-android-arm64": "4.2.1", - "@tailwindcss/oxide-darwin-arm64": "4.2.1", - "@tailwindcss/oxide-darwin-x64": "4.2.1", - "@tailwindcss/oxide-freebsd-x64": "4.2.1", - "@tailwindcss/oxide-linux-arm-gnueabihf": "4.2.1", - "@tailwindcss/oxide-linux-arm64-gnu": "4.2.1", - "@tailwindcss/oxide-linux-arm64-musl": "4.2.1", - "@tailwindcss/oxide-linux-x64-gnu": "4.2.1", - "@tailwindcss/oxide-linux-x64-musl": "4.2.1", - "@tailwindcss/oxide-wasm32-wasi": "4.2.1", - "@tailwindcss/oxide-win32-arm64-msvc": "4.2.1", - "@tailwindcss/oxide-win32-x64-msvc": "4.2.1" + "@tailwindcss/oxide-android-arm64": "4.2.4", + "@tailwindcss/oxide-darwin-arm64": "4.2.4", + "@tailwindcss/oxide-darwin-x64": "4.2.4", + "@tailwindcss/oxide-freebsd-x64": "4.2.4", + "@tailwindcss/oxide-linux-arm-gnueabihf": "4.2.4", + "@tailwindcss/oxide-linux-arm64-gnu": "4.2.4", + "@tailwindcss/oxide-linux-arm64-musl": "4.2.4", + "@tailwindcss/oxide-linux-x64-gnu": "4.2.4", + "@tailwindcss/oxide-linux-x64-musl": "4.2.4", + "@tailwindcss/oxide-wasm32-wasi": "4.2.4", + "@tailwindcss/oxide-win32-arm64-msvc": "4.2.4", + "@tailwindcss/oxide-win32-x64-msvc": "4.2.4" } }, "node_modules/@tailwindcss/oxide-android-arm64": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-android-arm64/-/oxide-android-arm64-4.2.1.tgz", - "integrity": "sha512-eZ7G1Zm5EC8OOKaesIKuw77jw++QJ2lL9N+dDpdQiAB/c/B2wDh0QPFHbkBVrXnwNugvrbJFk1gK2SsVjwWReg==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-android-arm64/-/oxide-android-arm64-4.2.4.tgz", + "integrity": "sha512-e7MOr1SAn9U8KlZzPi1ZXGZHeC5anY36qjNwmZv9pOJ8E4Q6jmD1vyEHkQFmNOIN7twGPEMXRHmitN4zCMN03g==", "cpu": [ "arm64" ], @@ -3069,9 +2984,9 @@ } }, "node_modules/@tailwindcss/oxide-darwin-arm64": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-arm64/-/oxide-darwin-arm64-4.2.1.tgz", - "integrity": "sha512-q/LHkOstoJ7pI1J0q6djesLzRvQSIfEto148ppAd+BVQK0JYjQIFSK3JgYZJa+Yzi0DDa52ZsQx2rqytBnf8Hw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-arm64/-/oxide-darwin-arm64-4.2.4.tgz", + "integrity": "sha512-tSC/Kbqpz/5/o/C2sG7QvOxAKqyd10bq+ypZNf+9Fi2TvbVbv1zNpcEptcsU7DPROaSbVgUXmrzKhurFvo5eDg==", "cpu": [ "arm64" ], @@ -3086,9 +3001,9 @@ } }, "node_modules/@tailwindcss/oxide-darwin-x64": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-x64/-/oxide-darwin-x64-4.2.1.tgz", - "integrity": "sha512-/f/ozlaXGY6QLbpvd/kFTro2l18f7dHKpB+ieXz+Cijl4Mt9AI2rTrpq7V+t04nK+j9XBQHnSMdeQRhbGyt6fw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-darwin-x64/-/oxide-darwin-x64-4.2.4.tgz", + "integrity": "sha512-yPyUXn3yO/ufR6+Kzv0t4fCg2qNr90jxXc5QqBpjlPNd0NqyDXcmQb/6weunH/MEDXW5dhyEi+agTDiqa3WsGg==", "cpu": [ "x64" ], @@ -3103,9 +3018,9 @@ } }, "node_modules/@tailwindcss/oxide-freebsd-x64": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-freebsd-x64/-/oxide-freebsd-x64-4.2.1.tgz", - "integrity": "sha512-5e/AkgYJT/cpbkys/OU2Ei2jdETCLlifwm7ogMC7/hksI2fC3iiq6OcXwjibcIjPung0kRtR3TxEITkqgn0TcA==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-freebsd-x64/-/oxide-freebsd-x64-4.2.4.tgz", + "integrity": "sha512-BoMIB4vMQtZsXdGLVc2z+P9DbETkiopogfWZKbWwM8b/1Vinbs4YcUwo+kM/KeLkX3Ygrf4/PsRndKaYhS8Eiw==", "cpu": [ "x64" ], @@ -3120,9 +3035,9 @@ } }, "node_modules/@tailwindcss/oxide-linux-arm-gnueabihf": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm-gnueabihf/-/oxide-linux-arm-gnueabihf-4.2.1.tgz", - "integrity": "sha512-Uny1EcVTTmerCKt/1ZuKTkb0x8ZaiuYucg2/kImO5A5Y/kBz41/+j0gxUZl+hTF3xkWpDmHX+TaWhOtba2Fyuw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm-gnueabihf/-/oxide-linux-arm-gnueabihf-4.2.4.tgz", + "integrity": "sha512-7pIHBLTHYRAlS7V22JNuTh33yLH4VElwKtB3bwchK/UaKUPpQ0lPQiOWcbm4V3WP2I6fNIJ23vABIvoy2izdwA==", "cpu": [ "arm" ], @@ -3137,9 +3052,9 @@ } }, "node_modules/@tailwindcss/oxide-linux-arm64-gnu": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-gnu/-/oxide-linux-arm64-gnu-4.2.1.tgz", - "integrity": "sha512-CTrwomI+c7n6aSSQlsPL0roRiNMDQ/YzMD9EjcR+H4f0I1SQ8QqIuPnsVp7QgMkC1Qi8rtkekLkOFjo7OlEFRQ==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-gnu/-/oxide-linux-arm64-gnu-4.2.4.tgz", + "integrity": "sha512-+E4wxJ0ZGOzSH325reXTWB48l42i93kQqMvDyz5gqfRzRZ7faNhnmvlV4EPGJU3QJM/3Ab5jhJ5pCRUsKn6OQw==", "cpu": [ "arm64" ], @@ -3154,9 +3069,9 @@ } }, "node_modules/@tailwindcss/oxide-linux-arm64-musl": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-musl/-/oxide-linux-arm64-musl-4.2.1.tgz", - "integrity": "sha512-WZA0CHRL/SP1TRbA5mp9htsppSEkWuQ4KsSUumYQnyl8ZdT39ntwqmz4IUHGN6p4XdSlYfJwM4rRzZLShHsGAQ==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-arm64-musl/-/oxide-linux-arm64-musl-4.2.4.tgz", + "integrity": "sha512-bBADEGAbo4ASnppIziaQJelekCxdMaxisrk+fB7Thit72IBnALp9K6ffA2G4ruj90G9XRS2VQ6q2bCKbfFV82g==", "cpu": [ "arm64" ], @@ -3171,9 +3086,9 @@ } }, "node_modules/@tailwindcss/oxide-linux-x64-gnu": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-gnu/-/oxide-linux-x64-gnu-4.2.1.tgz", - "integrity": "sha512-qMFzxI2YlBOLW5PhblzuSWlWfwLHaneBE0xHzLrBgNtqN6mWfs+qYbhryGSXQjFYB1Dzf5w+LN5qbUTPhW7Y5g==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-gnu/-/oxide-linux-x64-gnu-4.2.4.tgz", + "integrity": "sha512-7Mx25E4WTfnht0TVRTyC00j3i0M+EeFe7wguMDTlX4mRxafznw0CA8WJkFjWYH5BlgELd1kSjuU2JiPnNZbJDA==", "cpu": [ "x64" ], @@ -3188,9 +3103,9 @@ } }, "node_modules/@tailwindcss/oxide-linux-x64-musl": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-musl/-/oxide-linux-x64-musl-4.2.1.tgz", - "integrity": "sha512-5r1X2FKnCMUPlXTWRYpHdPYUY6a1Ar/t7P24OuiEdEOmms5lyqjDRvVY1yy9Rmioh+AunQ0rWiOTPE8F9A3v5g==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-linux-x64-musl/-/oxide-linux-x64-musl-4.2.4.tgz", + "integrity": "sha512-2wwJRF7nyhOR0hhHoChc04xngV3iS+akccHTGtz965FwF0up4b2lOdo6kI1EbDaEXKgvcrFBYcYQQ/rrnWFVfA==", "cpu": [ "x64" ], @@ -3205,9 +3120,9 @@ } }, "node_modules/@tailwindcss/oxide-wasm32-wasi": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-wasm32-wasi/-/oxide-wasm32-wasi-4.2.1.tgz", - "integrity": "sha512-MGFB5cVPvshR85MTJkEvqDUnuNoysrsRxd6vnk1Lf2tbiqNlXpHYZqkqOQalydienEWOHHFyyuTSYRsLfxFJ2Q==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-wasm32-wasi/-/oxide-wasm32-wasi-4.2.4.tgz", + "integrity": "sha512-FQsqApeor8Fo6gUEklzmaa9994orJZZDBAlQpK2Mq+DslRKFJeD6AjHpBQ0kZFQohVr8o85PPh8eOy86VlSCmw==", "bundleDependencies": [ "@napi-rs/wasm-runtime", "@emnapi/core", @@ -3234,74 +3149,10 @@ "node": ">=14.0.0" } }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/core": { - "version": "1.8.1", - "dev": true, - "inBundle": true, - "license": "MIT", - "optional": true, - "dependencies": { - "@emnapi/wasi-threads": "1.1.0", - "tslib": "^2.4.0" - } - }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/runtime": { - "version": "1.8.1", - "dev": true, - "inBundle": true, - "license": "MIT", - "optional": true, - "dependencies": { - "tslib": "^2.4.0" - } - }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@emnapi/wasi-threads": { - "version": "1.1.0", - "dev": true, - "inBundle": true, - "license": "MIT", - "optional": true, - "dependencies": { - "tslib": "^2.4.0" - } - }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@napi-rs/wasm-runtime": { - "version": "1.1.1", - "dev": true, - "inBundle": true, - "license": "MIT", - "optional": true, - "dependencies": { - "@emnapi/core": "^1.7.1", - "@emnapi/runtime": "^1.7.1", - "@tybys/wasm-util": "^0.10.1" - }, - "funding": { - "type": "github", - "url": "https://github.com/sponsors/Brooooooklyn" - } - }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/@tybys/wasm-util": { - "version": "0.10.1", - "dev": true, - "inBundle": true, - "license": "MIT", - "optional": true, - "dependencies": { - "tslib": "^2.4.0" - } - }, - "node_modules/@tailwindcss/oxide-wasm32-wasi/node_modules/tslib": { - "version": "2.8.1", - "dev": true, - "inBundle": true, - "license": "0BSD", - "optional": true - }, "node_modules/@tailwindcss/oxide-win32-arm64-msvc": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-arm64-msvc/-/oxide-win32-arm64-msvc-4.2.1.tgz", - "integrity": "sha512-YlUEHRHBGnCMh4Nj4GnqQyBtsshUPdiNroZj8VPkvTZSoHsilRCwXcVKnG9kyi0ZFAS/3u+qKHBdDc81SADTRA==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-arm64-msvc/-/oxide-win32-arm64-msvc-4.2.4.tgz", + "integrity": "sha512-L9BXqxC4ToVgwMFqj3pmZRqyHEztulpUJzCxUtLjobMCzTPsGt1Fa9enKbOpY2iIyVtaHNeNvAK8ERP/64sqGQ==", "cpu": [ "arm64" ], @@ -3316,9 +3167,9 @@ } }, "node_modules/@tailwindcss/oxide-win32-x64-msvc": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-x64-msvc/-/oxide-win32-x64-msvc-4.2.1.tgz", - "integrity": "sha512-rbO34G5sMWWyrN/idLeVxAZgAKWrn5LiR3/I90Q9MkA67s6T1oB0xtTe+0heoBvHSpbU9Mk7i6uwJnpo4u21XQ==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/oxide-win32-x64-msvc/-/oxide-win32-x64-msvc-4.2.4.tgz", + "integrity": "sha512-ESlKG0EpVJQwRjXDDa9rLvhEAh0mhP1sF7sap9dNZT0yyl9SAG6T7gdP09EH0vIv0UNTlo6jPWyujD6559fZvw==", "cpu": [ "x64" ], @@ -3333,26 +3184,26 @@ } }, "node_modules/@tailwindcss/postcss": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/@tailwindcss/postcss/-/postcss-4.2.1.tgz", - "integrity": "sha512-OEwGIBnXnj7zJeonOh6ZG9woofIjGrd2BORfvE5p9USYKDCZoQmfqLcfNiRWoJlRWLdNPn2IgVZuWAOM4iTYMw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/@tailwindcss/postcss/-/postcss-4.2.4.tgz", + "integrity": "sha512-wgAVj6nUWAolAu8YFvzT2cTBIElWHkjZwFYovF+xsqKsW2ADxM/X2opxj5NsF/qVccAOjRNe8X2IdPzMsWyHTg==", "dev": true, "license": "MIT", "dependencies": { "@alloc/quick-lru": "^5.2.0", - "@tailwindcss/node": "4.2.1", - "@tailwindcss/oxide": "4.2.1", + "@tailwindcss/node": "4.2.4", + "@tailwindcss/oxide": "4.2.4", "postcss": "^8.5.6", - "tailwindcss": "4.2.1" + "tailwindcss": "4.2.4" } }, "node_modules/@tanstack/react-virtual": { - "version": "3.13.19", - "resolved": "https://registry.npmjs.org/@tanstack/react-virtual/-/react-virtual-3.13.19.tgz", - "integrity": "sha512-KzwmU1IbE0IvCZSm6OXkS+kRdrgW2c2P3Ho3NC+zZXWK6oObv/L+lcV/2VuJ+snVESRlMJ+w/fg4WXI/JzoNGQ==", + "version": "3.13.24", + "resolved": "https://registry.npmjs.org/@tanstack/react-virtual/-/react-virtual-3.13.24.tgz", + "integrity": "sha512-aIJvz5OSkhNIhZIpYivrxrPTKYsjW9Uzy+sP/mx0S3sev2HyvPb7xmjbYvokzEpfgYHy/HjzJ2zFAETuUfgCpg==", "license": "MIT", "dependencies": { - "@tanstack/virtual-core": "3.13.19" + "@tanstack/virtual-core": "3.14.0" }, "funding": { "type": "github", @@ -3364,9 +3215,9 @@ } }, "node_modules/@tanstack/virtual-core": { - "version": "3.13.19", - "resolved": "https://registry.npmjs.org/@tanstack/virtual-core/-/virtual-core-3.13.19.tgz", - "integrity": "sha512-/BMP7kNhzKOd7wnDeB8NrIRNLwkf5AhCYCvtfZV2GXWbBieFm/el0n6LOAXlTi6ZwHICSNnQcIxRCWHrLzDY+g==", + "version": "3.14.0", + "resolved": "https://registry.npmjs.org/@tanstack/virtual-core/-/virtual-core-3.14.0.tgz", + "integrity": "sha512-JLANqGy/D6k4Ujmh8Tr25lGimuOXNiaVyXaCAZS0W+1390sADdGnyUdSWNIfd49gebtIxGMij4IktRVzrdr12Q==", "license": "MIT", "funding": { "type": "github", @@ -3449,48 +3300,48 @@ } }, "node_modules/@tiptap/core": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/core/-/core-3.20.4.tgz", - "integrity": "sha512-3i/DG89TFY/b34T5P+j35UcjYuB5d3+9K8u6qID+iUqNPiza015HPIZLuPfE5elNwVdV3EXIoPo0LLeBLgXXAg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/core/-/core-3.22.4.tgz", + "integrity": "sha512-vGIGm/HpqLg8EAAQXQ+koV+/S828OEpzocfWcPOwo1u2QUVf9dQG47Yy6JJ8zFFaJwfv4dBcOXli+7BrJwsxDQ==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/pm": "^3.20.4" + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-blockquote": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-blockquote/-/extension-blockquote-3.20.4.tgz", - "integrity": "sha512-9sskyyhYj2oKat//lyZVXCp9YrPt4oJAZnGHYWXS0xlskjsLElrfKKlM4vpbhGss3VrhQRoEGqWLnIaJYPF1zw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-blockquote/-/extension-blockquote-3.22.4.tgz", + "integrity": "sha512-7/61kNPbGFhMgM//zMknD0pSb69rGdRIkpulXOWS1JBrFHkH6hjZDfrOETNzgKkO+NlmzVl9rXSTv0xauS3lzA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-bold": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-bold/-/extension-bold-3.20.4.tgz", - "integrity": "sha512-Md7/mNAeJCY+VLJc8JRGI+8XkVPKiOGB1NgqQPdh3aYtxXQDChQOZoJEQl6TuudDxZ85bLZB67NjZlx3jo8/0g==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-bold/-/extension-bold-3.22.4.tgz", + "integrity": "sha512-jIaPKfNOQu2lhpbLDvtwlQqM+mjF+Kk+auHpzYjBnsuwUli1Cl5ZOau7RH+rru/SQvZe1DtpQlANujDywugZAA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-bubble-menu": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-bubble-menu/-/extension-bubble-menu-3.20.4.tgz", - "integrity": "sha512-EXywPlI8wjPcAb8ozymgVhjtMjFrnhtoyNTy8ZcObdpUi5CdO9j892Y7aPbKe5hLhlDpvJk7rMfir4FFKEmfng==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-bubble-menu/-/extension-bubble-menu-3.22.4.tgz", + "integrity": "sha512-v4pux5Ql3THAEjaLMY4ldtdy/Xy2qU7PJLBkq8ugLp8qicaKC+tpqxp6sGif4vLIjz7Ap5hurRbTNbXzszyyHA==", "license": "MIT", "optional": true, "dependencies": { @@ -3501,93 +3352,93 @@ "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-bullet-list": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-bullet-list/-/extension-bullet-list-3.20.4.tgz", - "integrity": "sha512-1RTGrur1EKoxfnLZ3M6xeNj8GITAz74jH2DHGcjLsd2Xr7Q7BozGaIq6GkkvKguMwbI1zCOxTHFCpUETXAIQQA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-bullet-list/-/extension-bullet-list-3.22.4.tgz", + "integrity": "sha512-TB+d3fGcTixYjO7coKqTr1mGTJuqr8hjDCPUFgzuvKyJnBhqWITmBzQ/8CLq4rr6mihgGURbD3N+xkQuPAKFiw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extension-list": "^3.20.4" + "@tiptap/extension-list": "3.22.4" } }, "node_modules/@tiptap/extension-code": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-code/-/extension-code-3.20.4.tgz", - "integrity": "sha512-7j8Hi964bH1SZ9oLdZC1fkqWz27mliSDV7M8lmL/M14+Qw42D/VOAKS4Aw9OCFtHMlTsjLR6qsoVxL8Lpkt6NA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-code/-/extension-code-3.22.4.tgz", + "integrity": "sha512-cnbxmVhAcc7X3G81QUYEmKP0ve2hRmvAiFXBuuv9RUtQlBiRnzmhHoJOMgkX0CsMR7+8kMRpTfeDUYq2xp5s5w==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-code-block": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-code-block/-/extension-code-block-3.20.4.tgz", - "integrity": "sha512-Zlw3FrXTy01+o1yISeX/LC+iJeHA+ym602bMXGmtA6lyl7QSOSO7WExweJ6xeJGhbCjldwT5al6fkRAs8iGJZg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-code-block/-/extension-code-block-3.22.4.tgz", + "integrity": "sha512-MEurzNXfMET3rhjpoPJYUgMfxTdTqbzT9+ToFrqNGAHocdXVm6m1hhO2frVC7fEtHPnxXKsn0Z3NUbCRkRTLuA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-color": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-color/-/extension-color-3.20.4.tgz", - "integrity": "sha512-+OT9wWEJnqoWmzfqPYt0oWm8LZcH+D44Z3jA2TNzBj4tLGQ2YPxN2SyS12AlRi7MuguVT7utFy7qDXrfir8eUA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-color/-/extension-color-3.22.4.tgz", + "integrity": "sha512-1vDuVsrOETshe4j4nZhWalbKYcWfNybRCe30h829ExX06XwFryUYLb/LgTIaGCr9beWZUldsK+vOkBWdDTGMTw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extension-text-style": "^3.20.4" + "@tiptap/extension-text-style": "3.22.4" } }, "node_modules/@tiptap/extension-document": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-document/-/extension-document-3.20.4.tgz", - "integrity": "sha512-zF1CIFVLt8MfSpWWnPwtGyxPOsT0xYM2qJKcXf2yZcTG37wDKmUi6heG53vGigIavbQlLaAFvs+1mNdOu2x/0A==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-document/-/extension-document-3.22.4.tgz", + "integrity": "sha512-XQKla1+703FqQJC48tPDVgt9ucGiFbIEmQdOg5L5o07z9a6/NzuaZAc+1zJ7NxcUZzy+z6wBn1PrVMTiqiSXlw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-dropcursor": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-dropcursor/-/extension-dropcursor-3.20.4.tgz", - "integrity": "sha512-TgMwvZ8myXYdmd6bUV7qkpZXv7ZUiSmX/8eo+iPEzYo2CnDLAGvDKgC50nfq/g87SDvfBgPuAiBfFvsMQQWaTw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-dropcursor/-/extension-dropcursor-3.22.4.tgz", + "integrity": "sha512-N9/yMDC35jJp0V/naL0+6gi4gUDUIcPpWEzFdCDWUSYBA8mt41c1kI1ZU7UTKYIBzTClenhYHRc2XKZxxx0+LQ==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extensions": "^3.20.4" + "@tiptap/extensions": "3.22.4" } }, "node_modules/@tiptap/extension-floating-menu": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-floating-menu/-/extension-floating-menu-3.20.4.tgz", - "integrity": "sha512-AaPTFhoO8DBIElJyd/RTVJjkctvJuL+GHURX0npbtTxXq5HXbebVwf2ARNR7jMd/GThsmBaNJiGxZg4A2oeDqQ==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-floating-menu/-/extension-floating-menu-3.22.4.tgz", + "integrity": "sha512-DFuyYxgaZPgxum5z1yvJPbfYCvDdO8geXsdyqt0qYYdiat3aGE4ncJhiLRIFDhSHBhaZg5eCgu/YPYAN6jZnrA==", "license": "MIT", "optional": true, "funding": { @@ -3596,93 +3447,93 @@ }, "peerDependencies": { "@floating-ui/dom": "^1.0.0", - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-gapcursor": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-gapcursor/-/extension-gapcursor-3.20.4.tgz", - "integrity": "sha512-JJ6f1iQ1e0s4kISgq55U3UYGwWV/N9f0PYMtB6e3L+SBQjXnywaLK0g6vfN6IvTCC2vdIuqeSOX8VlSO97sJLw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-gapcursor/-/extension-gapcursor-3.22.4.tgz", + "integrity": "sha512-UYBEUj3SFpKINIE7AdzcyeS3xICK+ee+YLBbuqNXyHStYChjJOohzJehqiqhjR16A88KQQ+ZjgyDcItKGygSog==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extensions": "^3.20.4" + "@tiptap/extensions": "3.22.4" } }, "node_modules/@tiptap/extension-hard-break": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-hard-break/-/extension-hard-break-3.20.4.tgz", - "integrity": "sha512-gJbq58d8zB1gzyqVEopowej5CpW4/Fpg6oGJvlZxaCukqd0gJRWGC89K+jE62YA1Td4sfcKrekKvN7jm2y/ZUg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-hard-break/-/extension-hard-break-3.22.4.tgz", + "integrity": "sha512-xq+a4dE7T6VwApCkh/yU3p30gn3F8g8Arb9CyEZm58/WIJUIGvHSTjDdHmvU16+kiWSBg+wOOsaFHhYjJjxcKA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-heading": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-heading/-/extension-heading-3.20.4.tgz", - "integrity": "sha512-xsnkmTGggJc5P2iCwS1lv8KFG31xC/GNPJKoi/3UH67j/lKDhA3AdtshsLeyv2FKtTtYDb8oV0IqzHB1MM6a7w==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-heading/-/extension-heading-3.22.4.tgz", + "integrity": "sha512-TUaj5f0Ir5qy9HKKt2ocnwfXKpZDYeHgbbP9gshKFzdq5PLe1RbIgkjfy6bnoI865cYjmPYWRjcT7XsKyIcb9Q==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-horizontal-rule": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-horizontal-rule/-/extension-horizontal-rule-3.20.4.tgz", - "integrity": "sha512-y6joCi49haAA0bo3EGUY+dWUMHH1GPUc84hxrBY/0pMs+Bn+kQ1+DQJErZDTWGJrlHPWU/yekBZT72SNdp0DNA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-horizontal-rule/-/extension-horizontal-rule-3.22.4.tgz", + "integrity": "sha512-cCI1HekGQwhY/MbgaKQ0R/7HcH5ZM1oFAyI/J72QGLC0XnF403S/OXoHMuBWr1mCu8hNiQWCzeNRJUty0iytNw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-image": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-image/-/extension-image-3.20.4.tgz", - "integrity": "sha512-57w2TevHQljTh6Xiry9duIm7NNOQAUSTwtwRn4GGLoKwHR8qXTxzp513ASrFOgR2kgs2TP471Au6RHf947P+jg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-image/-/extension-image-3.22.4.tgz", + "integrity": "sha512-ZDc+fLaratTQ4IgnKcJJwfUgUgpcHjbZSBi6UQAILJwkflMy1Zxj8mpbma5P934nLSI+uDnR5ret6ZZLNITKhA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-italic": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-italic/-/extension-italic-3.20.4.tgz", - "integrity": "sha512-4ZqiWr7cmqPFux8tj1ZLiYytyWf343IvQemNX6AvVWvscrJcrfj3YX4Le2BA0RW3A3M6RpLQXXozuF8vxYFDeQ==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-italic/-/extension-italic-3.22.4.tgz", + "integrity": "sha512-fVSDx5AYXgDI3v2zZIqb7V8EewthwM2NJ/ZCX+XaxRsqNEpnjVhgHs7UlvDqK1wj2OJ6zmUNjPtVlAFRxwT+HQ==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-link": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-link/-/extension-link-3.20.4.tgz", - "integrity": "sha512-JNDSkWrVdb8NSvbQXwHWvK5tCMbTWwOHFOweknQZ1JPK4dei9FJVofYQaHyW4bJBdcCjds3NZSnXE8DM9iAWmg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-link/-/extension-link-3.22.4.tgz", + "integrity": "sha512-uoP3yus02uwGPVzW2QaEPJWVIrUb/r5nKm6c8DiJv9fNSX1+gykZZMg42c6GwRFLZ/vyfWjVCbAE03VMUqafgA==", "license": "MIT", "dependencies": { "linkifyjs": "^4.3.2" @@ -3692,190 +3543,184 @@ "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-list": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-list/-/extension-list-3.20.4.tgz", - "integrity": "sha512-X+5plTKhOioNcQ4KsAFJJSb/3+zR8Xhdpow4HzXtoV1KcbdDey1fhZdpsfkbrzCL0s6/wAgwZuAchCK7HujurQ==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-list/-/extension-list-3.22.4.tgz", + "integrity": "sha512-Xe8UFvvHmyp/c/TJsFwlwU9CWACYbBirNsluJ3U1+H8BTu1wqdrT/AXR5uIXeyCl5kiWKgX5q71eHWbYFOrqrg==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/extension-list-item": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-list-item/-/extension-list-item-3.20.4.tgz", - "integrity": "sha512-QoTc5RACXaZF+vIIBBxjGO7D0oWFUDgBKJCpvUZ0CoGGKosnfe4a9I5THFyLj4201cf0oUqgf1oZhTqETGxlVw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-list-item/-/extension-list-item-3.22.4.tgz", + "integrity": "sha512-H659KXTvggSypIDWSOJBZ37jh9pKjQriDDvYPYvOZCdfij0D0hsDXN/wXoypArneUkoBdgruHfTtMkFOaQlgkw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extension-list": "^3.20.4" + "@tiptap/extension-list": "3.22.4" } }, "node_modules/@tiptap/extension-list-keymap": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-list-keymap/-/extension-list-keymap-3.20.4.tgz", - "integrity": "sha512-RIqXM649+8IP7p/KVfaGlJiwjCylm1m6OPlaoM3K8O7oEOGRQzNeexexECCD2jsXRxew4E+vBNMD2orXqJmu8A==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-list-keymap/-/extension-list-keymap-3.22.4.tgz", + "integrity": "sha512-t/zhker4oIS78AIGYDdFFfZC6zSBlszfD7z/zqFLGCg5PHNNgkZK5hKj6Vyix6D2SapRn/ajnx+8mhbKIUH5eA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extension-list": "^3.20.4" + "@tiptap/extension-list": "3.22.4" } }, "node_modules/@tiptap/extension-ordered-list": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-ordered-list/-/extension-ordered-list-3.20.4.tgz", - "integrity": "sha512-3budNL8BgBon3TcXZ4hjT0YpFvx1Ka3uSIECKDxHgES+OQcR+6cagxSb60gFEccf3Dr0PIwcVTY6g14lC1qKRQ==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-ordered-list/-/extension-ordered-list-3.22.4.tgz", + "integrity": "sha512-w77hPVf7pcHt97vfrybg/l0t5CimCd4y75OJKuHuo3CfgM5xbUP/gaPNMDyLLe7MYole/UHi/XvG3XjgzqTzAw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extension-list": "^3.20.4" + "@tiptap/extension-list": "3.22.4" } }, "node_modules/@tiptap/extension-paragraph": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-paragraph/-/extension-paragraph-3.20.4.tgz", - "integrity": "sha512-lm6fOScWuZAF/Sfp97igUwFd3L1QHIVLAWP5NVdh0DTLrEIt4rMBmsww+yOpMQRhvz2uTgMbMXynrimhzi/QVw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-paragraph/-/extension-paragraph-3.22.4.tgz", + "integrity": "sha512-de6dFkIhigiENESY6rNJ3yTVS/337ybfP30dNPudTwGe9oAu9ZCS+04j6QCvXSjhlI3ULiv7wiSHqrP26Gd+Hw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-placeholder": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-placeholder/-/extension-placeholder-3.20.4.tgz", - "integrity": "sha512-GB0KWtqm83YHG8cnqBLijvUBm+xvLfQHDfFRRH2fb3EzH3eIsM9jKRC31ADT27RSV1zVpHMFGcP3/pWpdrN1Lw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-placeholder/-/extension-placeholder-3.22.4.tgz", + "integrity": "sha512-Z3wtWL+KufwkC7CkJge5enAxx4q8C3oOYixme02snY9zfjX3V/1pjAmEfP4wxScgM5GIuTEJ83B9Yz3wRzPA6Q==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/extensions": "^3.20.4" + "@tiptap/extensions": "3.22.4" } }, "node_modules/@tiptap/extension-strike": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-strike/-/extension-strike-3.20.4.tgz", - "integrity": "sha512-It1Px9uDGTsVqyyg6cy7DigLoenljpQwqdI0jssM7QclZrHnsrye9fZxBBiiuCzzV1305MxKgHvratkHwqmVNA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-strike/-/extension-strike-3.22.4.tgz", + "integrity": "sha512-aRHWQj42HiailXSC9LkKYM3jWMcSeGwOjbqM4PiuxQZmHVDRFmeHkfJItOdn2cSHaO0vuEVK+TvrWUWsBFi3pg==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-text": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-text/-/extension-text-3.20.4.tgz", - "integrity": "sha512-jchJcBZixDEO2J66Zx5dchsI2mA6IYsROqF8P1poxL4ienH7RVQRCTsBNnSfIeOtREKKWeOU/tEs5fcpvvGwIQ==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-text/-/extension-text-3.22.4.tgz", + "integrity": "sha512-mM69uUW5cSxIhyEpWXi/YcfyupcJMDLCPEfYi62awH0iOP/LRoCv/nHjJq4Hyj/KxRJbe8HKwIUnqaCUf7m5Pg==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-text-align": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-text-align/-/extension-text-align-3.20.4.tgz", - "integrity": "sha512-6ZuRyClIyCimXu+S5LQ54DueEsYg5VOVOmubOVbG+WAjM9svn9Z8gv2sNDah2yEqXrX06B02zYcSyMiD7CHbfA==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-text-align/-/extension-text-align-3.22.4.tgz", + "integrity": "sha512-W7TnXWSyfDXSatGXp5y/CahE8G4btrQPb0/sy+eG+42FxdzYsqvh1ys3OE9j2XSuTrZ1q/tZA/NLPUkc7vw6Kw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-text-style": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-text-style/-/extension-text-style-3.20.4.tgz", - "integrity": "sha512-PvW0Ja7ahWpo4bRuR8YCCVv4PH8lXjzhzlBAa4bMbsumOg+GbhX8Su7fwqd+IIPrHqfPXz9HTBMApSfzP6/08A==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-text-style/-/extension-text-style-3.22.4.tgz", + "integrity": "sha512-24DVBdySNKq3ovY+v9ERVxAyHStDa6ftUlyoHuZv0YXQ2amjUNOmqQtGEHBIULpCbBb1jZ+atHhv9MBZ0Ia9Pw==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extension-underline": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extension-underline/-/extension-underline-3.20.4.tgz", - "integrity": "sha512-0OjMc3FDujX16G+jhvqcY/mLot8SrNtDu8ggUwNLAfiI/QIvMVgk7giFD71DATC/4Nb8i/iwAEegTD8MxBIXCg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extension-underline/-/extension-underline-3.22.4.tgz", + "integrity": "sha512-08kGdbhIrA6h10GWXqOkqIveaBj5tmxclK208/nUIAlonI9hPd739vu7fmVtpnmqCnSSNpoRtU4u6Gj5at0ZpA==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4" + "@tiptap/core": "3.22.4" } }, "node_modules/@tiptap/extensions": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/extensions/-/extensions-3.20.4.tgz", - "integrity": "sha512-8p6hVT65DjuQjtEdlH6ewX9SOJHlVQAOee3sWIJQmeJNRnZNvqPIBLleebUqDiljNTpxBv6s6QWkSTKgf3btwg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/extensions/-/extensions-3.22.4.tgz", + "integrity": "sha512-fOe8VptJvLPs32bNdUYo8SRyljwqKNQVXWW056VoXIc5en/59OdJlJQVeHI0jRRciH3MtrqODi/gfJR0VHNZ8A==", "license": "MIT", "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4" } }, "node_modules/@tiptap/pm": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/pm/-/pm-3.20.4.tgz", - "integrity": "sha512-rCHYSBToilBEuI6PtjziHDdRkABH/XqwJ7dG4Amn/SD3yGiZKYCiEApQlTUS2zZeo8DsLeuqqqB4vEOeD4OEPg==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/pm/-/pm-3.22.4.tgz", + "integrity": "sha512-hj8Qka6WcHRllHUdeSjDnq2XaisUo4KsoGJc1WcFpoa1Yd+OeD861zUMnV7DFVGdZRy45Obht0CUYJpXQ4yA4w==", "license": "MIT", "dependencies": { "prosemirror-changeset": "^2.3.0", - "prosemirror-collab": "^1.3.1", "prosemirror-commands": "^1.6.2", "prosemirror-dropcursor": "^1.8.1", "prosemirror-gapcursor": "^1.3.2", "prosemirror-history": "^1.4.1", - "prosemirror-inputrules": "^1.4.0", "prosemirror-keymap": "^1.2.2", - "prosemirror-markdown": "^1.13.1", - "prosemirror-menu": "^1.2.4", "prosemirror-model": "^1.24.1", - "prosemirror-schema-basic": "^1.2.3", "prosemirror-schema-list": "^1.5.0", "prosemirror-state": "^1.4.3", "prosemirror-tables": "^1.6.4", - "prosemirror-trailing-node": "^3.0.0", "prosemirror-transform": "^1.10.2", "prosemirror-view": "^1.38.1" }, @@ -3885,9 +3730,9 @@ } }, "node_modules/@tiptap/react": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/react/-/react-3.20.4.tgz", - "integrity": "sha512-1B8iWsHWwb5TeyVaUs8BRPzwWo4PsLQcl03urHaz0zTJ8DauopqvxzV3+lem1OkzRHn7wnrapDvwmIGoROCaQw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/react/-/react-3.22.4.tgz", + "integrity": "sha512-XIQZPwLakR1t8+Q1UeCpr+kUHDWxpJzGy9r2xUi3mpPd6Wh8dtNltScBkUlCcr0sqc6J1GF6Is02JJVQGmCZMA==", "license": "MIT", "dependencies": { "@types/use-sync-external-store": "^0.0.6", @@ -3899,12 +3744,12 @@ "url": "https://github.com/sponsors/ueberdosis" }, "optionalDependencies": { - "@tiptap/extension-bubble-menu": "^3.20.4", - "@tiptap/extension-floating-menu": "^3.20.4" + "@tiptap/extension-bubble-menu": "^3.22.4", + "@tiptap/extension-floating-menu": "^3.22.4" }, "peerDependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/pm": "^3.20.4", + "@tiptap/core": "3.22.4", + "@tiptap/pm": "3.22.4", "@types/react": "^17.0.0 || ^18.0.0 || ^19.0.0", "@types/react-dom": "^17.0.0 || ^18.0.0 || ^19.0.0", "react": "^17.0.0 || ^18.0.0 || ^19.0.0", @@ -3912,41 +3757,52 @@ } }, "node_modules/@tiptap/starter-kit": { - "version": "3.20.4", - "resolved": "https://registry.npmjs.org/@tiptap/starter-kit/-/starter-kit-3.20.4.tgz", - "integrity": "sha512-WcyK6hsTl8eBsQhQ+d9Sq8fYZKOYdL+D45MyH3hz583elXqJlW3h3JPFYb0o87gddGxn8Mm57OA/gA1zEdeDMw==", + "version": "3.22.4", + "resolved": "https://registry.npmjs.org/@tiptap/starter-kit/-/starter-kit-3.22.4.tgz", + "integrity": "sha512-qWjw+vfdin1rzMRpRU4cC5tLTwMJtUpXeQukv+6mOqqvhptuwuZBjUHImVEJaSPoHXS7+1ut+nTnrLyWyEuE5Q==", "license": "MIT", "dependencies": { - "@tiptap/core": "^3.20.4", - "@tiptap/extension-blockquote": "^3.20.4", - "@tiptap/extension-bold": "^3.20.4", - "@tiptap/extension-bullet-list": "^3.20.4", - "@tiptap/extension-code": "^3.20.4", - "@tiptap/extension-code-block": "^3.20.4", - "@tiptap/extension-document": "^3.20.4", - "@tiptap/extension-dropcursor": "^3.20.4", - "@tiptap/extension-gapcursor": "^3.20.4", - "@tiptap/extension-hard-break": "^3.20.4", - "@tiptap/extension-heading": "^3.20.4", - "@tiptap/extension-horizontal-rule": "^3.20.4", - "@tiptap/extension-italic": "^3.20.4", - "@tiptap/extension-link": "^3.20.4", - "@tiptap/extension-list": "^3.20.4", - "@tiptap/extension-list-item": "^3.20.4", - "@tiptap/extension-list-keymap": "^3.20.4", - "@tiptap/extension-ordered-list": "^3.20.4", - "@tiptap/extension-paragraph": "^3.20.4", - "@tiptap/extension-strike": "^3.20.4", - "@tiptap/extension-text": "^3.20.4", - "@tiptap/extension-underline": "^3.20.4", - "@tiptap/extensions": "^3.20.4", - "@tiptap/pm": "^3.20.4" + "@tiptap/core": "^3.22.4", + "@tiptap/extension-blockquote": "^3.22.4", + "@tiptap/extension-bold": "^3.22.4", + "@tiptap/extension-bullet-list": "^3.22.4", + "@tiptap/extension-code": "^3.22.4", + "@tiptap/extension-code-block": "^3.22.4", + "@tiptap/extension-document": "^3.22.4", + "@tiptap/extension-dropcursor": "^3.22.4", + "@tiptap/extension-gapcursor": "^3.22.4", + "@tiptap/extension-hard-break": "^3.22.4", + "@tiptap/extension-heading": "^3.22.4", + "@tiptap/extension-horizontal-rule": "^3.22.4", + "@tiptap/extension-italic": "^3.22.4", + "@tiptap/extension-link": "^3.22.4", + "@tiptap/extension-list": "^3.22.4", + "@tiptap/extension-list-item": "^3.22.4", + "@tiptap/extension-list-keymap": "^3.22.4", + "@tiptap/extension-ordered-list": "^3.22.4", + "@tiptap/extension-paragraph": "^3.22.4", + "@tiptap/extension-strike": "^3.22.4", + "@tiptap/extension-text": "^3.22.4", + "@tiptap/extension-underline": "^3.22.4", + "@tiptap/extensions": "^3.22.4", + "@tiptap/pm": "^3.22.4" }, "funding": { "type": "github", "url": "https://github.com/sponsors/ueberdosis" } }, + "node_modules/@tybys/wasm-util": { + "version": "0.10.1", + "resolved": "https://registry.npmjs.org/@tybys/wasm-util/-/wasm-util-0.10.1.tgz", + "integrity": "sha512-9tTaPJLSiejZKx+Bmog4uSubteqTvFrVrURwkmHixBo0G4seD0zUxp98E1DzUBJxLQ3NPwXrGKDiVjwx/DpPsg==", + "dev": true, + "license": "MIT", + "optional": true, + "dependencies": { + "tslib": "^2.4.0" + } + }, "node_modules/@types/aria-query": { "version": "5.0.4", "resolved": "https://registry.npmjs.org/@types/aria-query/-/aria-query-5.0.4.tgz", @@ -3954,51 +3810,6 @@ "dev": true, "license": "MIT" }, - "node_modules/@types/babel__core": { - "version": "7.20.5", - "resolved": "https://registry.npmjs.org/@types/babel__core/-/babel__core-7.20.5.tgz", - "integrity": "sha512-qoQprZvz5wQFJwMDqeseRXWv3rqMvhgpbXFfVyWhbx9X47POIA6i/+dXefEmZKoAgOaTdaIgNSMqMIU61yRyzA==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/parser": "^7.20.7", - "@babel/types": "^7.20.7", - "@types/babel__generator": "*", - "@types/babel__template": "*", - "@types/babel__traverse": "*" - } - }, - "node_modules/@types/babel__generator": { - "version": "7.27.0", - "resolved": "https://registry.npmjs.org/@types/babel__generator/-/babel__generator-7.27.0.tgz", - "integrity": "sha512-ufFd2Xi92OAVPYsy+P4n7/U7e68fex0+Ee8gSG9KX7eo084CWiQ4sdxktvdl0bOPupXtVJPY19zk6EwWqUQ8lg==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/types": "^7.0.0" - } - }, - "node_modules/@types/babel__template": { - "version": "7.4.4", - "resolved": "https://registry.npmjs.org/@types/babel__template/-/babel__template-7.4.4.tgz", - "integrity": "sha512-h/NUaSyG5EyxBIp8YRxo4RMe2/qQgvyowRwVMzhYhBCONbW8PUsg4lkFMrhgZhUe5z3L3MiLDuvyJ/CaPa2A8A==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/parser": "^7.1.0", - "@babel/types": "^7.0.0" - } - }, - "node_modules/@types/babel__traverse": { - "version": "7.28.0", - "resolved": "https://registry.npmjs.org/@types/babel__traverse/-/babel__traverse-7.28.0.tgz", - "integrity": "sha512-8PvcXf70gTDZBgt9ptxJ8elBeBjcLOAcOtoO/mPJjtji1+CdGbHgm77om1GrsPxsiE+uXIpNSK64UYaIwQXd4Q==", - "dev": true, - "license": "MIT", - "dependencies": { - "@babel/types": "^7.28.2" - } - }, "node_modules/@types/chai": { "version": "5.2.3", "resolved": "https://registry.npmjs.org/@types/chai/-/chai-5.2.3.tgz", @@ -4031,36 +3842,14 @@ "dev": true, "license": "MIT" }, - "node_modules/@types/linkify-it": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/@types/linkify-it/-/linkify-it-5.0.0.tgz", - "integrity": "sha512-sVDA58zAw4eWAffKOaQH5/5j3XeayukzDk+ewSsnv3p4yJEZHCCzMDiZM8e0OUrRvmpGZ85jf4yDHkHsgBNr9Q==", - "license": "MIT" - }, - "node_modules/@types/markdown-it": { - "version": "14.1.2", - "resolved": "https://registry.npmjs.org/@types/markdown-it/-/markdown-it-14.1.2.tgz", - "integrity": "sha512-promo4eFwuiW+TfGxhi+0x3czqTYJkG8qB17ZUJiVF10Xm7NLVRSLUsfRTU/6h1e24VvRnXCx+hG7li58lkzog==", - "license": "MIT", - "dependencies": { - "@types/linkify-it": "^5", - "@types/mdurl": "^2" - } - }, - "node_modules/@types/mdurl": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/@types/mdurl/-/mdurl-2.0.0.tgz", - "integrity": "sha512-RGdgjQUZba5p6QEFAVx2OGb8rQDL/cPRG7GiedRzMcJ1tYnUANBncjbSB1NRGwbvjcPeikRABz2nshyPk1bhWg==", - "license": "MIT" - }, "node_modules/@types/node": { - "version": "25.3.3", - "resolved": "https://registry.npmjs.org/@types/node/-/node-25.3.3.tgz", - "integrity": "sha512-DpzbrH7wIcBaJibpKo9nnSQL0MTRdnWttGyE5haGwK86xgMOkFLp7vEyfQPGLOJh5wNYiJ3V9PmUMDhV9u8kkQ==", + "version": "25.6.0", + "resolved": "https://registry.npmjs.org/@types/node/-/node-25.6.0.tgz", + "integrity": "sha512-+qIYRKdNYJwY3vRCZMdJbPLJAtGjQBudzZzdzwQYkEPQd+PJGixUL5QfvCLDaULoLv+RhT3LDkwEfKaAkgSmNQ==", "dev": true, "license": "MIT", "dependencies": { - "undici-types": "~7.18.0" + "undici-types": "~7.19.0" } }, "node_modules/@types/qrcode": { @@ -4105,20 +3894,20 @@ "license": "MIT" }, "node_modules/@typescript-eslint/eslint-plugin": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-8.56.1.tgz", - "integrity": "sha512-Jz9ZztpB37dNC+HU2HI28Bs9QXpzCz+y/twHOwhyrIRdbuVDxSytJNDl6z/aAKlaRIwC7y8wJdkBv7FxYGgi0A==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-8.59.0.tgz", + "integrity": "sha512-HyAZtpdkgZwpq8Sz3FSUvCR4c+ScbuWa9AksK2Jweub7w4M3yTz4O11AqVJzLYjy/B9ZWPyc81I+mOdJU/bDQw==", "dev": true, "license": "MIT", "dependencies": { "@eslint-community/regexpp": "^4.12.2", - "@typescript-eslint/scope-manager": "8.56.1", - "@typescript-eslint/type-utils": "8.56.1", - "@typescript-eslint/utils": "8.56.1", - "@typescript-eslint/visitor-keys": "8.56.1", + "@typescript-eslint/scope-manager": "8.59.0", + "@typescript-eslint/type-utils": "8.59.0", + "@typescript-eslint/utils": "8.59.0", + "@typescript-eslint/visitor-keys": "8.59.0", "ignore": "^7.0.5", "natural-compare": "^1.4.0", - "ts-api-utils": "^2.4.0" + "ts-api-utils": "^2.5.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -4128,22 +3917,22 @@ "url": "https://opencollective.com/typescript-eslint" }, "peerDependencies": { - "@typescript-eslint/parser": "^8.56.1", + "@typescript-eslint/parser": "^8.59.0", "eslint": "^8.57.0 || ^9.0.0 || ^10.0.0", - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/parser": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/parser/-/parser-8.56.1.tgz", - "integrity": "sha512-klQbnPAAiGYFyI02+znpBRLyjL4/BrBd0nyWkdC0s/6xFLkXYQ8OoRrSkqacS1ddVxf/LDyODIKbQ5TgKAf/Fg==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/parser/-/parser-8.59.0.tgz", + "integrity": "sha512-TI1XGwKbDpo9tRW8UDIXCOeLk55qe9ZFGs8MTKU6/M08HWTw52DD/IYhfQtOEhEdPhLMT26Ka/x7p70nd3dzDg==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/scope-manager": "8.56.1", - "@typescript-eslint/types": "8.56.1", - "@typescript-eslint/typescript-estree": "8.56.1", - "@typescript-eslint/visitor-keys": "8.56.1", + "@typescript-eslint/scope-manager": "8.59.0", + "@typescript-eslint/types": "8.59.0", + "@typescript-eslint/typescript-estree": "8.59.0", + "@typescript-eslint/visitor-keys": "8.59.0", "debug": "^4.4.3" }, "engines": { @@ -4155,18 +3944,18 @@ }, "peerDependencies": { "eslint": "^8.57.0 || ^9.0.0 || ^10.0.0", - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/project-service": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/project-service/-/project-service-8.56.1.tgz", - "integrity": "sha512-TAdqQTzHNNvlVFfR+hu2PDJrURiwKsUvxFn1M0h95BB8ah5jejas08jUWG4dBA68jDMI988IvtfdAI53JzEHOQ==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/project-service/-/project-service-8.59.0.tgz", + "integrity": "sha512-Lw5ITrR5s5TbC19YSvlr63ZfLaJoU6vtKTHyB0GQOpX0W7d5/Ir6vUahWi/8Sps/nOukZQ0IB3SmlxZnjaKVnw==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/tsconfig-utils": "^8.56.1", - "@typescript-eslint/types": "^8.56.1", + "@typescript-eslint/tsconfig-utils": "^8.59.0", + "@typescript-eslint/types": "^8.59.0", "debug": "^4.4.3" }, "engines": { @@ -4177,18 +3966,18 @@ "url": "https://opencollective.com/typescript-eslint" }, "peerDependencies": { - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/scope-manager": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.56.1.tgz", - "integrity": "sha512-YAi4VDKcIZp0O4tz/haYKhmIDZFEUPOreKbfdAN3SzUDMcPhJ8QI99xQXqX+HoUVq8cs85eRKnD+rne2UAnj2w==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.59.0.tgz", + "integrity": "sha512-UzR16Ut8IpA3Mc4DbgAShlPPkVm8xXMWafXxB0BocaVRHs8ZGakAxGRskF7FId3sdk9lgGD73GSFaWmWFDE4dg==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.56.1", - "@typescript-eslint/visitor-keys": "8.56.1" + "@typescript-eslint/types": "8.59.0", + "@typescript-eslint/visitor-keys": "8.59.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -4199,9 +3988,9 @@ } }, "node_modules/@typescript-eslint/tsconfig-utils": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/tsconfig-utils/-/tsconfig-utils-8.56.1.tgz", - "integrity": "sha512-qOtCYzKEeyr3aR9f28mPJqBty7+DBqsdd63eO0yyDwc6vgThj2UjWfJIcsFeSucYydqcuudMOprZ+x1SpF3ZuQ==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/tsconfig-utils/-/tsconfig-utils-8.59.0.tgz", + "integrity": "sha512-91Sbl3s4Kb3SybliIY6muFBmHVv+pYXfybC4Oolp3dvk8BvIE3wOPc+403CWIT7mJNkfQRGtdqghzs2+Z91Tqg==", "dev": true, "license": "MIT", "engines": { @@ -4212,21 +4001,21 @@ "url": "https://opencollective.com/typescript-eslint" }, "peerDependencies": { - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/type-utils": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/type-utils/-/type-utils-8.56.1.tgz", - "integrity": "sha512-yB/7dxi7MgTtGhZdaHCemf7PuwrHMenHjmzgUW1aJpO+bBU43OycnM3Wn+DdvDO/8zzA9HlhaJ0AUGuvri4oGg==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/type-utils/-/type-utils-8.59.0.tgz", + "integrity": "sha512-3TRiZaQSltGqGeNrJzzr1+8YcEobKH9rHnqIp/1psfKFmhRQDNMGP5hBufanYTGznwShzVLs3Mz+gDN7HkWfXg==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.56.1", - "@typescript-eslint/typescript-estree": "8.56.1", - "@typescript-eslint/utils": "8.56.1", + "@typescript-eslint/types": "8.59.0", + "@typescript-eslint/typescript-estree": "8.59.0", + "@typescript-eslint/utils": "8.59.0", "debug": "^4.4.3", - "ts-api-utils": "^2.4.0" + "ts-api-utils": "^2.5.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -4237,13 +4026,13 @@ }, "peerDependencies": { "eslint": "^8.57.0 || ^9.0.0 || ^10.0.0", - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/types": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.56.1.tgz", - "integrity": "sha512-dbMkdIUkIkchgGDIv7KLUpa0Mda4IYjo4IAMJUZ+3xNoUXxMsk9YtKpTHSChRS85o+H9ftm51gsK1dZReY9CVw==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.59.0.tgz", + "integrity": "sha512-nLzdsT1gdOgFxxxwrlNVUBzSNBEEHJ86bblmk4QAS6stfig7rcJzWKqCyxFy3YRRHXDWEkb2NralA1nOYkkm/A==", "dev": true, "license": "MIT", "engines": { @@ -4255,21 +4044,21 @@ } }, "node_modules/@typescript-eslint/typescript-estree": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.56.1.tgz", - "integrity": "sha512-qzUL1qgalIvKWAf9C1HpvBjif+Vm6rcT5wZd4VoMb9+Km3iS3Cv9DY6dMRMDtPnwRAFyAi7YXJpTIEXLvdfPxg==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.59.0.tgz", + "integrity": "sha512-O9Re9P1BmBLFJyikRbQpLku/QA3/AueZNO9WePLBwQrvkixTmDe8u76B6CYUAITRl/rHawggEqUGn5QIkVRLMw==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/project-service": "8.56.1", - "@typescript-eslint/tsconfig-utils": "8.56.1", - "@typescript-eslint/types": "8.56.1", - "@typescript-eslint/visitor-keys": "8.56.1", + "@typescript-eslint/project-service": "8.59.0", + "@typescript-eslint/tsconfig-utils": "8.59.0", + "@typescript-eslint/types": "8.59.0", + "@typescript-eslint/visitor-keys": "8.59.0", "debug": "^4.4.3", "minimatch": "^10.2.2", "semver": "^7.7.3", "tinyglobby": "^0.2.15", - "ts-api-utils": "^2.4.0" + "ts-api-utils": "^2.5.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -4279,20 +4068,20 @@ "url": "https://opencollective.com/typescript-eslint" }, "peerDependencies": { - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/utils": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.56.1.tgz", - "integrity": "sha512-HPAVNIME3tABJ61siYlHzSWCGtOoeP2RTIaHXFMPqjrQKCGB9OgUVdiNgH7TJS2JNIQ5qQ4RsAUDuGaGme/KOA==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.59.0.tgz", + "integrity": "sha512-I1R/K7V07XsMJ12Oaxg/O9GfrysGTmCRhvZJBv0RE0NcULMzjqVpR5kRRQjHsz3J/bElU7HwCO7zkqL+MSUz+g==", "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.9.1", - "@typescript-eslint/scope-manager": "8.56.1", - "@typescript-eslint/types": "8.56.1", - "@typescript-eslint/typescript-estree": "8.56.1" + "@typescript-eslint/scope-manager": "8.59.0", + "@typescript-eslint/types": "8.59.0", + "@typescript-eslint/typescript-estree": "8.59.0" }, "engines": { "node": "^18.18.0 || ^20.9.0 || >=21.1.0" @@ -4303,17 +4092,17 @@ }, "peerDependencies": { "eslint": "^8.57.0 || ^9.0.0 || ^10.0.0", - "typescript": ">=4.8.4 <6.0.0" + "typescript": ">=4.8.4 <6.1.0" } }, "node_modules/@typescript-eslint/visitor-keys": { - "version": "8.56.1", - "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.56.1.tgz", - "integrity": "sha512-KiROIzYdEV85YygXw6BI/Dx4fnBlFQu6Mq4QE4MOH9fFnhohw6wX/OAvDY2/C+ut0I3RSPKenvZJIVYqJNkhEw==", + "version": "8.59.0", + "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.59.0.tgz", + "integrity": "sha512-/uejZt4dSere1bx12WLlPfv8GktzcaDtuJ7s42/HEZ5zGj9oxRaD4bj7qwSunXkf+pbAhFt2zjpHYUiT5lHf0Q==", "dev": true, "license": "MIT", "dependencies": { - "@typescript-eslint/types": "8.56.1", + "@typescript-eslint/types": "8.59.0", "eslint-visitor-keys": "^5.0.0" }, "engines": { @@ -4338,52 +4127,57 @@ } }, "node_modules/@vitejs/plugin-react": { - "version": "5.1.4", - "resolved": "https://registry.npmjs.org/@vitejs/plugin-react/-/plugin-react-5.1.4.tgz", - "integrity": "sha512-VIcFLdRi/VYRU8OL/puL7QXMYafHmqOnwTZY50U1JPlCNj30PxCMx65c494b1K9be9hX83KVt0+gTEwTWLqToA==", + "version": "6.0.1", + "resolved": "https://registry.npmjs.org/@vitejs/plugin-react/-/plugin-react-6.0.1.tgz", + "integrity": "sha512-l9X/E3cDb+xY3SWzlG1MOGt2usfEHGMNIaegaUGFsLkb3RCn/k8/TOXBcab+OndDI4TBtktT8/9BwwW8Vi9KUQ==", "dev": true, "license": "MIT", "dependencies": { - "@babel/core": "^7.29.0", - "@babel/plugin-transform-react-jsx-self": "^7.27.1", - "@babel/plugin-transform-react-jsx-source": "^7.27.1", - "@rolldown/pluginutils": "1.0.0-rc.3", - "@types/babel__core": "^7.20.5", - "react-refresh": "^0.18.0" + "@rolldown/pluginutils": "1.0.0-rc.7" }, "engines": { "node": "^20.19.0 || >=22.12.0" }, "peerDependencies": { - "vite": "^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" + "@rolldown/plugin-babel": "^0.1.7 || ^0.2.0", + "babel-plugin-react-compiler": "^1.0.0", + "vite": "^8.0.0" + }, + "peerDependenciesMeta": { + "@rolldown/plugin-babel": { + "optional": true + }, + "babel-plugin-react-compiler": { + "optional": true + } } }, "node_modules/@vitest/expect": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/expect/-/expect-4.0.18.tgz", - "integrity": "sha512-8sCWUyckXXYvx4opfzVY03EOiYVxyNrHS5QxX3DAIi5dpJAAkyJezHCP77VMX4HKA2LDT/Jpfo8i2r5BE3GnQQ==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/expect/-/expect-4.1.5.tgz", + "integrity": "sha512-PWBaRY5JoKuRnHlUHfpV/KohFylaDZTupcXN1H9vYryNLOnitSw60Mw9IAE2r67NbwwzBw/Cc/8q9BK3kIX8Kw==", "dev": true, "license": "MIT", "dependencies": { - "@standard-schema/spec": "^1.0.0", + "@standard-schema/spec": "^1.1.0", "@types/chai": "^5.2.2", - "@vitest/spy": "4.0.18", - "@vitest/utils": "4.0.18", - "chai": "^6.2.1", - "tinyrainbow": "^3.0.3" + "@vitest/spy": "4.1.5", + "@vitest/utils": "4.1.5", + "chai": "^6.2.2", + "tinyrainbow": "^3.1.0" }, "funding": { "url": "https://opencollective.com/vitest" } }, "node_modules/@vitest/mocker": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/mocker/-/mocker-4.0.18.tgz", - "integrity": "sha512-HhVd0MDnzzsgevnOWCBj5Otnzobjy5wLBe4EdeeFGv8luMsGcYqDuFRMcttKWZA5vVO8RFjexVovXvAM4JoJDQ==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/mocker/-/mocker-4.1.5.tgz", + "integrity": "sha512-/x2EmFC4mT4NNzqvC3fmesuV97w5FC903KPmey4gsnJiMQ3Be1IlDKVaDaG8iqaLFHqJ2FVEkxZk5VmeLjIItw==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/spy": "4.0.18", + "@vitest/spy": "4.1.5", "estree-walker": "^3.0.3", "magic-string": "^0.30.21" }, @@ -4392,7 +4186,7 @@ }, "peerDependencies": { "msw": "^2.4.9", - "vite": "^6.0.0 || ^7.0.0-0" + "vite": "^6.0.0 || ^7.0.0 || ^8.0.0" }, "peerDependenciesMeta": { "msw": { @@ -4404,26 +4198,26 @@ } }, "node_modules/@vitest/pretty-format": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/pretty-format/-/pretty-format-4.0.18.tgz", - "integrity": "sha512-P24GK3GulZWC5tz87ux0m8OADrQIUVDPIjjj65vBXYG17ZeU3qD7r+MNZ1RNv4l8CGU2vtTRqixrOi9fYk/yKw==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/pretty-format/-/pretty-format-4.1.5.tgz", + "integrity": "sha512-7I3q6l5qr03dVfMX2wCo9FxwSJbPdwKjy2uu/YPpU3wfHvIL4QHwVRp57OfGrDFeUJ8/8QdfBKIV12FTtLn00g==", "dev": true, "license": "MIT", "dependencies": { - "tinyrainbow": "^3.0.3" + "tinyrainbow": "^3.1.0" }, "funding": { "url": "https://opencollective.com/vitest" } }, "node_modules/@vitest/runner": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/runner/-/runner-4.0.18.tgz", - "integrity": "sha512-rpk9y12PGa22Jg6g5M3UVVnTS7+zycIGk9ZNGN+m6tZHKQb7jrP7/77WfZy13Y/EUDd52NDsLRQhYKtv7XfPQw==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/runner/-/runner-4.1.5.tgz", + "integrity": "sha512-2D+o7Pr82IEO46YPpoA/YU0neeyr6FTerQb5Ro7BUnBuv6NQtT/kmVnczngiMEBhzgqz2UZYl5gArejsyERDSQ==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/utils": "4.0.18", + "@vitest/utils": "4.1.5", "pathe": "^2.0.3" }, "funding": { @@ -4431,13 +4225,14 @@ } }, "node_modules/@vitest/snapshot": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/snapshot/-/snapshot-4.0.18.tgz", - "integrity": "sha512-PCiV0rcl7jKQjbgYqjtakly6T1uwv/5BQ9SwBLekVg/EaYeQFPiXcgrC2Y7vDMA8dM1SUEAEV82kgSQIlXNMvA==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/snapshot/-/snapshot-4.1.5.tgz", + "integrity": "sha512-zypXEt4KH/XgKGPUz4eC2AvErYx0My5hfL8oDb1HzGFpEk1P62bxSohdyOmvz+d9UJwanI68MKwr2EquOaOgMQ==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/pretty-format": "4.0.18", + "@vitest/pretty-format": "4.1.5", + "@vitest/utils": "4.1.5", "magic-string": "^0.30.21", "pathe": "^2.0.3" }, @@ -4446,9 +4241,9 @@ } }, "node_modules/@vitest/spy": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/spy/-/spy-4.0.18.tgz", - "integrity": "sha512-cbQt3PTSD7P2OARdVW3qWER5EGq7PHlvE+QfzSC0lbwO+xnt7+XH06ZzFjFRgzUX//JmpxrCu92VdwvEPlWSNw==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/spy/-/spy-4.1.5.tgz", + "integrity": "sha512-2lNOsh6+R2Idnf1TCZqSwYlKN2E/iDlD8sgU59kYVl+OMDmvldO1VDk39smRfpUNwYpNRVn3w4YfuC7KfbBnkQ==", "dev": true, "license": "MIT", "funding": { @@ -4456,36 +4251,37 @@ } }, "node_modules/@vitest/ui": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/ui/-/ui-4.0.18.tgz", - "integrity": "sha512-CGJ25bc8fRi8Lod/3GHSvXRKi7nBo3kxh0ApW4yCjmrWmRmlT53B5E08XRSZRliygG0aVNxLrBEqPYdz/KcCtQ==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/ui/-/ui-4.1.5.tgz", + "integrity": "sha512-3Z9HNFiV0IF1fk0JPiK+7kE1GcaIPefQQIBYur6PM5yFIq6agys3uqP/0t966e1wXfmjbRCHDe7qW236Xjwnag==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/utils": "4.0.18", + "@vitest/utils": "4.1.5", "fflate": "^0.8.2", - "flatted": "^3.3.3", + "flatted": "^3.4.2", "pathe": "^2.0.3", "sirv": "^3.0.2", "tinyglobby": "^0.2.15", - "tinyrainbow": "^3.0.3" + "tinyrainbow": "^3.1.0" }, "funding": { "url": "https://opencollective.com/vitest" }, "peerDependencies": { - "vitest": "4.0.18" + "vitest": "4.1.5" } }, "node_modules/@vitest/utils": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/@vitest/utils/-/utils-4.0.18.tgz", - "integrity": "sha512-msMRKLMVLWygpK3u2Hybgi4MNjcYJvwTb0Ru09+fOyCXIgT5raYP041DRRdiJiI3k/2U6SEbAETB3YtBrUkCFA==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/@vitest/utils/-/utils-4.1.5.tgz", + "integrity": "sha512-76wdkrmfXfqGjueGgnb45ITPyUi1ycZ4IHgC2bhPDUfWHklY/q3MdLOAB+TF1e6xfl8NxNY0ZYaPCFNWSsw3Ug==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/pretty-format": "4.0.18", - "tinyrainbow": "^3.0.3" + "@vitest/pretty-format": "4.1.5", + "convert-source-map": "^2.0.0", + "tinyrainbow": "^3.1.0" }, "funding": { "url": "https://opencollective.com/vitest" @@ -4569,6 +4365,7 @@ "version": "2.0.1", "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz", "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q==", + "dev": true, "license": "Python-2.0" }, "node_modules/aria-query": { @@ -4726,13 +4523,13 @@ "license": "MIT" }, "node_modules/asn1js": { - "version": "3.0.7", - "resolved": "https://registry.npmjs.org/asn1js/-/asn1js-3.0.7.tgz", - "integrity": "sha512-uLvq6KJu04qoQM6gvBfKFjlh6Gl0vOKQuR5cJMDHQkmwfMOQeN3F3SHCv9SNYSL+CRoHvOGFfllDlVz03GQjvQ==", + "version": "3.0.10", + "resolved": "https://registry.npmjs.org/asn1js/-/asn1js-3.0.10.tgz", + "integrity": "sha512-S2s3aOytiKdFRdulw2qPE51MzjzVOisppcVv7jVFR+Kw0kxwvFrDcYA0h7Ndqbmj0HkMIXYWaoj7fli8kgx1eg==", "license": "BSD-3-Clause", "dependencies": { "pvtsutils": "^1.3.6", - "pvutils": "^1.1.3", + "pvutils": "^1.1.5", "tslib": "^2.8.1" }, "engines": { @@ -4811,9 +4608,9 @@ "license": "MIT" }, "node_modules/brace-expansion": { - "version": "5.0.4", - "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.4.tgz", - "integrity": "sha512-h+DEnpVvxmfVefa4jFbCf5HdH5YMDXRsmKflpf1pILZWRFlTbJpxeU55nJl4Smt5HQaGzg1o6RHFPJaOqnmBDg==", + "version": "5.0.5", + "resolved": "https://registry.npmjs.org/brace-expansion/-/brace-expansion-5.0.5.tgz", + "integrity": "sha512-VZznLgtwhn+Mact9tfiwx64fA9erHH/MCXEUfB/0bX/6Fz6ny5EGTXYltMocqg4xFAQZtnO3DHWWXi8RiuN7cQ==", "dev": true, "license": "MIT", "dependencies": { @@ -5073,12 +4870,6 @@ "integrity": "sha512-ZQBvi1DcpJ4GDqanjucZ2Hj3wEO5pZDS89BWbkcrvdxksJorwUDDZamX9ldFkp9aw2lmBDLgkObEA4DWNJ9FYQ==", "license": "MIT" }, - "node_modules/crelt": { - "version": "1.0.6", - "resolved": "https://registry.npmjs.org/crelt/-/crelt-1.0.6.tgz", - "integrity": "sha512-VQ2MBenTq1fWZUH9DJNGti7kKv6EeAuYr3cLwxUWhIu1baTaXh4Ib5W2CqHVqib4/MqbYGJqiL3Zb8GJZr3l4g==", - "license": "MIT" - }, "node_modules/cross-spawn": { "version": "7.0.6", "resolved": "https://registry.npmjs.org/cross-spawn/-/cross-spawn-7.0.6.tgz", @@ -5256,6 +5047,7 @@ "version": "10.6.0", "resolved": "https://registry.npmjs.org/decimal.js/-/decimal.js-10.6.0.tgz", "integrity": "sha512-YpgQiITW3JXGntzdUmyUR1V812Hn8T1YVXhCu+wO3OpS4eU9l4YdD3qjyiKdV6mvV29zapkMeD390UVEf2lkUg==", + "dev": true, "license": "MIT" }, "node_modules/deep-is": { @@ -5357,9 +5149,9 @@ "license": "MIT" }, "node_modules/dompurify": { - "version": "3.3.3", - "resolved": "https://registry.npmjs.org/dompurify/-/dompurify-3.3.3.tgz", - "integrity": "sha512-Oj6pzI2+RqBfFG+qOaOLbFXLQ90ARpcGG6UePL82bJLtdsa6CYJD7nmiU8MW9nQNOtCHV3lZ/Bzq1X0QYbBZCA==", + "version": "3.4.1", + "resolved": "https://registry.npmjs.org/dompurify/-/dompurify-3.4.1.tgz", + "integrity": "sha512-JahakDAIg1gyOm7dlgWSDjV4n7Ip2PKR55NIT6jrMfIgLFgWo81vdr1/QGqWtFNRqXP9UV71oVePtjqS2ebnPw==", "license": "(MPL-2.0 OR Apache-2.0)", "optionalDependencies": { "@types/trusted-types": "^2.0.7" @@ -5409,9 +5201,9 @@ "license": "MIT" }, "node_modules/enhanced-resolve": { - "version": "5.20.0", - "resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-5.20.0.tgz", - "integrity": "sha512-/ce7+jQ1PQ6rVXwe+jKEg5hW5ciicHwIQUagZkp6IufBoY3YDgdTTY1azVs0qoRgVmvsNB+rbjLJxDAeHHtwsQ==", + "version": "5.20.1", + "resolved": "https://registry.npmjs.org/enhanced-resolve/-/enhanced-resolve-5.20.1.tgz", + "integrity": "sha512-Qohcme7V1inbAfvjItgw0EaxVX5q2rdVEZHRBrEQdRZTssLDGsL8Lwrznl8oQ/6kuTJONLaDcGjkNP247XEhcA==", "dev": true, "license": "MIT", "dependencies": { @@ -5553,9 +5345,9 @@ } }, "node_modules/es-module-lexer": { - "version": "1.7.0", - "resolved": "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-1.7.0.tgz", - "integrity": "sha512-jEQoCwk8hyb2AZziIOLhDqpm5+2ww5uIE6lkO/6jcOCusfk6LhMHpXXfBLXTZ7Ydyt0j4VoUQv6uGNYbdW+kBA==", + "version": "2.0.0", + "resolved": "https://registry.npmjs.org/es-module-lexer/-/es-module-lexer-2.0.0.tgz", + "integrity": "sha512-5POEcUuZybH7IdmGsD8wlf0AI55wMecM9rVBTI/qEAy2c1kTOm3DjFYjrBdI2K3BaJjJYfYFeRtM0t9ssnRuxw==", "dev": true, "license": "MIT" }, @@ -5626,6 +5418,8 @@ "dev": true, "hasInstallScript": true, "license": "MIT", + "optional": true, + "peer": true, "bin": { "esbuild": "bin/esbuild" }, @@ -5675,6 +5469,7 @@ "version": "4.0.0", "resolved": "https://registry.npmjs.org/escape-string-regexp/-/escape-string-regexp-4.0.0.tgz", "integrity": "sha512-TtpcNJ3XAzx3Gq8sWRzJaVajRs0uVxA2YAkdb1jm2YkPz4G6egUFAyA3n5vtEIZefPk5Wa4UXbKuS5fKkJWdgA==", + "dev": true, "license": "MIT", "engines": { "node": ">=10" @@ -5684,25 +5479,25 @@ } }, "node_modules/eslint": { - "version": "9.39.3", - "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.39.3.tgz", - "integrity": "sha512-VmQ+sifHUbI/IcSopBCF/HO3YiHQx/AVd3UVyYL6weuwW+HvON9VYn5l6Zl1WZzPWXPNZrSQpxwkkZ/VuvJZzg==", + "version": "9.39.4", + "resolved": "https://registry.npmjs.org/eslint/-/eslint-9.39.4.tgz", + "integrity": "sha512-XoMjdBOwe/esVgEvLmNsD3IRHkm7fbKIUGvrleloJXUZgDHig2IPWNniv+GwjyJXzuNqVjlr5+4yVUZjycJwfQ==", "dev": true, "license": "MIT", "dependencies": { "@eslint-community/eslint-utils": "^4.8.0", "@eslint-community/regexpp": "^4.12.1", - "@eslint/config-array": "^0.21.1", + "@eslint/config-array": "^0.21.2", "@eslint/config-helpers": "^0.4.2", "@eslint/core": "^0.17.0", - "@eslint/eslintrc": "^3.3.1", - "@eslint/js": "9.39.3", + "@eslint/eslintrc": "^3.3.5", + "@eslint/js": "9.39.4", "@eslint/plugin-kit": "^0.4.1", "@humanfs/node": "^0.16.6", "@humanwhocodes/module-importer": "^1.0.1", "@humanwhocodes/retry": "^0.4.2", "@types/estree": "^1.0.6", - "ajv": "^6.12.4", + "ajv": "^6.14.0", "chalk": "^4.0.0", "cross-spawn": "^7.0.6", "debug": "^4.3.2", @@ -5721,7 +5516,7 @@ "is-glob": "^4.0.0", "json-stable-stringify-without-jsonify": "^1.0.1", "lodash.merge": "^4.6.2", - "minimatch": "^3.1.2", + "minimatch": "^3.1.5", "natural-compare": "^1.4.0", "optionator": "^0.9.3" }, @@ -5777,9 +5572,9 @@ } }, "node_modules/eslint-plugin-react-hooks": { - "version": "7.0.1", - "resolved": "https://registry.npmjs.org/eslint-plugin-react-hooks/-/eslint-plugin-react-hooks-7.0.1.tgz", - "integrity": "sha512-O0d0m04evaNzEPoSW+59Mezf8Qt0InfgGIBJnpC0h3NH/WjUAR7BIKUfysC6todmtiZ/A0oUVS8Gce0WhBrHsA==", + "version": "7.1.1", + "resolved": "https://registry.npmjs.org/eslint-plugin-react-hooks/-/eslint-plugin-react-hooks-7.1.1.tgz", + "integrity": "sha512-f2I7Gw6JbvCexzIInuSbZpfdQ44D7iqdWX01FKLvrPgqxoE7oMj8clOfto8U6vYiz4yd5oKu39rRSVOe1zRu0g==", "dev": true, "license": "MIT", "dependencies": { @@ -5793,7 +5588,7 @@ "node": ">=18" }, "peerDependencies": { - "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0-0 || ^9.0.0" + "eslint": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0-0 || ^9.0.0 || ^10.0.0" } }, "node_modules/eslint-plugin-react/node_modules/brace-expansion": { @@ -6298,9 +6093,9 @@ } }, "node_modules/globals": { - "version": "17.4.0", - "resolved": "https://registry.npmjs.org/globals/-/globals-17.4.0.tgz", - "integrity": "sha512-hjrNztw/VajQwOLsMNT1cbJiH2muO3OROCHnbehc8eY5JyD2gqz4AcMHPqgaOR59DjgUjYAYLeH699g/eWi2jw==", + "version": "17.5.0", + "resolved": "https://registry.npmjs.org/globals/-/globals-17.5.0.tgz", + "integrity": "sha512-qoV+HK2yFl/366t2/Cb3+xxPUo5BuMynomoDmiaZBIdbs+0pYbjfZU+twLhGKp4uCZ/+NbtpVepH5bGCxRyy2g==", "dev": true, "license": "MIT", "engines": { @@ -6537,9 +6332,9 @@ } }, "node_modules/icu-minify": { - "version": "4.8.3", - "resolved": "https://registry.npmjs.org/icu-minify/-/icu-minify-4.8.3.tgz", - "integrity": "sha512-65Av7FLosNk7bPbmQx5z5XG2Y3T2GFppcjiXh4z1idHeVgQxlDpAmkGoYI0eFzAvrOnjpWTL5FmPDhsdfRMPEA==", + "version": "4.9.1", + "resolved": "https://registry.npmjs.org/icu-minify/-/icu-minify-4.9.1.tgz", + "integrity": "sha512-6NkfF9GHHFouqnz+wuiLjCWQiyxoEyJ5liUv4Jxxo/8wyhV7MY0L0iTEGDAVEa4aAD58WqTxFMa20S5nyMjwNw==", "funding": [ { "type": "individual", @@ -6626,15 +6421,13 @@ } }, "node_modules/intl-messageformat": { - "version": "11.1.2", - "resolved": "https://registry.npmjs.org/intl-messageformat/-/intl-messageformat-11.1.2.tgz", - "integrity": "sha512-ucSrQmZGAxfiBHfBRXW/k7UC8MaGFlEj4Ry1tKiDcmgwQm1y3EDl40u+4VNHYomxJQMJi9NEI3riDRlth96jKg==", + "version": "11.2.1", + "resolved": "https://registry.npmjs.org/intl-messageformat/-/intl-messageformat-11.2.1.tgz", + "integrity": "sha512-1gAVEUt3wEPvTqML4Fsw9klZV5j0vszQxayP/fi6gUroAc8AUHiNaisBKLWxybL1AdWq1mP07YV1q8v4N92ilQ==", "license": "BSD-3-Clause", "dependencies": { - "@formatjs/ecma402-abstract": "3.1.1", - "@formatjs/fast-memoize": "3.1.0", - "@formatjs/icu-messageformat-parser": "3.5.1", - "tslib": "^2.8.1" + "@formatjs/fast-memoize": "3.1.2", + "@formatjs/icu-messageformat-parser": "3.5.4" } }, "node_modules/is-array-buffer": { @@ -7245,9 +7038,9 @@ } }, "node_modules/lightningcss": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss/-/lightningcss-1.31.1.tgz", - "integrity": "sha512-l51N2r93WmGUye3WuFoN5k10zyvrVs0qfKBhyC5ogUQ6Ew6JUSswh78mbSO+IU3nTWsyOArqPCcShdQSadghBQ==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss/-/lightningcss-1.32.0.tgz", + "integrity": "sha512-NXYBzinNrblfraPGyrbPoD19C1h9lfI/1mzgWYvXUTe414Gz/X1FD2XBZSZM7rRTrMA8JL3OtAaGifrIKhQ5yQ==", "dev": true, "license": "MPL-2.0", "dependencies": { @@ -7261,23 +7054,23 @@ "url": "https://opencollective.com/parcel" }, "optionalDependencies": { - "lightningcss-android-arm64": "1.31.1", - "lightningcss-darwin-arm64": "1.31.1", - "lightningcss-darwin-x64": "1.31.1", - "lightningcss-freebsd-x64": "1.31.1", - "lightningcss-linux-arm-gnueabihf": "1.31.1", - "lightningcss-linux-arm64-gnu": "1.31.1", - "lightningcss-linux-arm64-musl": "1.31.1", - "lightningcss-linux-x64-gnu": "1.31.1", - "lightningcss-linux-x64-musl": "1.31.1", - "lightningcss-win32-arm64-msvc": "1.31.1", - "lightningcss-win32-x64-msvc": "1.31.1" + "lightningcss-android-arm64": "1.32.0", + "lightningcss-darwin-arm64": "1.32.0", + "lightningcss-darwin-x64": "1.32.0", + "lightningcss-freebsd-x64": "1.32.0", + "lightningcss-linux-arm-gnueabihf": "1.32.0", + "lightningcss-linux-arm64-gnu": "1.32.0", + "lightningcss-linux-arm64-musl": "1.32.0", + "lightningcss-linux-x64-gnu": "1.32.0", + "lightningcss-linux-x64-musl": "1.32.0", + "lightningcss-win32-arm64-msvc": "1.32.0", + "lightningcss-win32-x64-msvc": "1.32.0" } }, "node_modules/lightningcss-android-arm64": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-android-arm64/-/lightningcss-android-arm64-1.31.1.tgz", - "integrity": "sha512-HXJF3x8w9nQ4jbXRiNppBCqeZPIAfUo8zE/kOEGbW5NZvGc/K7nMxbhIr+YlFlHW5mpbg/YFPdbnCh1wAXCKFg==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-android-arm64/-/lightningcss-android-arm64-1.32.0.tgz", + "integrity": "sha512-YK7/ClTt4kAK0vo6w3X+Pnm0D2cf2vPHbhOXdoNti1Ga0al1P4TBZhwjATvjNwLEBCnKvjJc2jQgHXH0NEwlAg==", "cpu": [ "arm64" ], @@ -7296,9 +7089,9 @@ } }, "node_modules/lightningcss-darwin-arm64": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-darwin-arm64/-/lightningcss-darwin-arm64-1.31.1.tgz", - "integrity": "sha512-02uTEqf3vIfNMq3h/z2cJfcOXnQ0GRwQrkmPafhueLb2h7mqEidiCzkE4gBMEH65abHRiQvhdcQ+aP0D0g67sg==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-darwin-arm64/-/lightningcss-darwin-arm64-1.32.0.tgz", + "integrity": "sha512-RzeG9Ju5bag2Bv1/lwlVJvBE3q6TtXskdZLLCyfg5pt+HLz9BqlICO7LZM7VHNTTn/5PRhHFBSjk5lc4cmscPQ==", "cpu": [ "arm64" ], @@ -7317,9 +7110,9 @@ } }, "node_modules/lightningcss-darwin-x64": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-darwin-x64/-/lightningcss-darwin-x64-1.31.1.tgz", - "integrity": "sha512-1ObhyoCY+tGxtsz1lSx5NXCj3nirk0Y0kB/g8B8DT+sSx4G9djitg9ejFnjb3gJNWo7qXH4DIy2SUHvpoFwfTA==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-darwin-x64/-/lightningcss-darwin-x64-1.32.0.tgz", + "integrity": "sha512-U+QsBp2m/s2wqpUYT/6wnlagdZbtZdndSmut/NJqlCcMLTWp5muCrID+K5UJ6jqD2BFshejCYXniPDbNh73V8w==", "cpu": [ "x64" ], @@ -7338,9 +7131,9 @@ } }, "node_modules/lightningcss-freebsd-x64": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-freebsd-x64/-/lightningcss-freebsd-x64-1.31.1.tgz", - "integrity": "sha512-1RINmQKAItO6ISxYgPwszQE1BrsVU5aB45ho6O42mu96UiZBxEXsuQ7cJW4zs4CEodPUioj/QrXW1r9pLUM74A==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-freebsd-x64/-/lightningcss-freebsd-x64-1.32.0.tgz", + "integrity": "sha512-JCTigedEksZk3tHTTthnMdVfGf61Fky8Ji2E4YjUTEQX14xiy/lTzXnu1vwiZe3bYe0q+SpsSH/CTeDXK6WHig==", "cpu": [ "x64" ], @@ -7359,9 +7152,9 @@ } }, "node_modules/lightningcss-linux-arm-gnueabihf": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-linux-arm-gnueabihf/-/lightningcss-linux-arm-gnueabihf-1.31.1.tgz", - "integrity": "sha512-OOCm2//MZJ87CdDK62rZIu+aw9gBv4azMJuA8/KB74wmfS3lnC4yoPHm0uXZ/dvNNHmnZnB8XLAZzObeG0nS1g==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-linux-arm-gnueabihf/-/lightningcss-linux-arm-gnueabihf-1.32.0.tgz", + "integrity": "sha512-x6rnnpRa2GL0zQOkt6rts3YDPzduLpWvwAF6EMhXFVZXD4tPrBkEFqzGowzCsIWsPjqSK+tyNEODUBXeeVHSkw==", "cpu": [ "arm" ], @@ -7380,9 +7173,9 @@ } }, "node_modules/lightningcss-linux-arm64-gnu": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-gnu/-/lightningcss-linux-arm64-gnu-1.31.1.tgz", - "integrity": "sha512-WKyLWztD71rTnou4xAD5kQT+982wvca7E6QoLpoawZ1gP9JM0GJj4Tp5jMUh9B3AitHbRZ2/H3W5xQmdEOUlLg==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-gnu/-/lightningcss-linux-arm64-gnu-1.32.0.tgz", + "integrity": "sha512-0nnMyoyOLRJXfbMOilaSRcLH3Jw5z9HDNGfT/gwCPgaDjnx0i8w7vBzFLFR1f6CMLKF8gVbebmkUN3fa/kQJpQ==", "cpu": [ "arm64" ], @@ -7401,9 +7194,9 @@ } }, "node_modules/lightningcss-linux-arm64-musl": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-musl/-/lightningcss-linux-arm64-musl-1.31.1.tgz", - "integrity": "sha512-mVZ7Pg2zIbe3XlNbZJdjs86YViQFoJSpc41CbVmKBPiGmC4YrfeOyz65ms2qpAobVd7WQsbW4PdsSJEMymyIMg==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-linux-arm64-musl/-/lightningcss-linux-arm64-musl-1.32.0.tgz", + "integrity": "sha512-UpQkoenr4UJEzgVIYpI80lDFvRmPVg6oqboNHfoH4CQIfNA+HOrZ7Mo7KZP02dC6LjghPQJeBsvXhJod/wnIBg==", "cpu": [ "arm64" ], @@ -7422,9 +7215,9 @@ } }, "node_modules/lightningcss-linux-x64-gnu": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-gnu/-/lightningcss-linux-x64-gnu-1.31.1.tgz", - "integrity": "sha512-xGlFWRMl+0KvUhgySdIaReQdB4FNudfUTARn7q0hh/V67PVGCs3ADFjw+6++kG1RNd0zdGRlEKa+T13/tQjPMA==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-gnu/-/lightningcss-linux-x64-gnu-1.32.0.tgz", + "integrity": "sha512-V7Qr52IhZmdKPVr+Vtw8o+WLsQJYCTd8loIfpDaMRWGUZfBOYEJeyJIkqGIDMZPwPx24pUMfwSxxI8phr/MbOA==", "cpu": [ "x64" ], @@ -7443,9 +7236,9 @@ } }, "node_modules/lightningcss-linux-x64-musl": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-musl/-/lightningcss-linux-x64-musl-1.31.1.tgz", - "integrity": "sha512-eowF8PrKHw9LpoZii5tdZwnBcYDxRw2rRCyvAXLi34iyeYfqCQNA9rmUM0ce62NlPhCvof1+9ivRaTY6pSKDaA==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-linux-x64-musl/-/lightningcss-linux-x64-musl-1.32.0.tgz", + "integrity": "sha512-bYcLp+Vb0awsiXg/80uCRezCYHNg1/l3mt0gzHnWV9XP1W5sKa5/TCdGWaR/zBM2PeF/HbsQv/j2URNOiVuxWg==", "cpu": [ "x64" ], @@ -7464,9 +7257,9 @@ } }, "node_modules/lightningcss-win32-arm64-msvc": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-win32-arm64-msvc/-/lightningcss-win32-arm64-msvc-1.31.1.tgz", - "integrity": "sha512-aJReEbSEQzx1uBlQizAOBSjcmr9dCdL3XuC/6HLXAxmtErsj2ICo5yYggg1qOODQMtnjNQv2UHb9NpOuFtYe4w==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-win32-arm64-msvc/-/lightningcss-win32-arm64-msvc-1.32.0.tgz", + "integrity": "sha512-8SbC8BR40pS6baCM8sbtYDSwEVQd4JlFTOlaD3gWGHfThTcABnNDBda6eTZeqbofalIJhFx0qKzgHJmcPTnGdw==", "cpu": [ "arm64" ], @@ -7485,9 +7278,9 @@ } }, "node_modules/lightningcss-win32-x64-msvc": { - "version": "1.31.1", - "resolved": "https://registry.npmjs.org/lightningcss-win32-x64-msvc/-/lightningcss-win32-x64-msvc-1.31.1.tgz", - "integrity": "sha512-I9aiFrbd7oYHwlnQDqr1Roz+fTz61oDDJX7n9tYF9FJymH1cIN1DtKw3iYt6b8WZgEjoNwVSncwF4wx/ZedMhw==", + "version": "1.32.0", + "resolved": "https://registry.npmjs.org/lightningcss-win32-x64-msvc/-/lightningcss-win32-x64-msvc-1.32.0.tgz", + "integrity": "sha512-Amq9B/SoZYdDi1kFrojnoqPLxYhQ4Wo5XiL8EVJrVsB8ARoC1PWW6VGtT0WKCemjy8aC+louJnjS7U18x3b06Q==", "cpu": [ "x64" ], @@ -7505,15 +7298,6 @@ "url": "https://opencollective.com/parcel" } }, - "node_modules/linkify-it": { - "version": "5.0.0", - "resolved": "https://registry.npmjs.org/linkify-it/-/linkify-it-5.0.0.tgz", - "integrity": "sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==", - "license": "MIT", - "dependencies": { - "uc.micro": "^2.0.0" - } - }, "node_modules/linkifyjs": { "version": "4.3.2", "resolved": "https://registry.npmjs.org/linkifyjs/-/linkifyjs-4.3.2.tgz", @@ -7567,9 +7351,9 @@ } }, "node_modules/lucide-react": { - "version": "0.575.0", - "resolved": "https://registry.npmjs.org/lucide-react/-/lucide-react-0.575.0.tgz", - "integrity": "sha512-VuXgKZrk0uiDlWjGGXmKV6MSk9Yy4l10qgVvzGn2AWBx1Ylt0iBexKOAoA6I7JO3m+M9oeovJd3yYENfkUbOeg==", + "version": "1.8.0", + "resolved": "https://registry.npmjs.org/lucide-react/-/lucide-react-1.8.0.tgz", + "integrity": "sha512-WuvlsjngSk7TnTBJ1hsCy3ql9V9VOdcPkd3PKcSmM34vJD8KG6molxz7m7zbYFgICwsanQWmJ13JlYs4Zp7Arw==", "license": "ISC", "peerDependencies": { "react": "^16.5.1 || ^17.0.0 || ^18.0.0 || ^19.0.0" @@ -7595,35 +7379,6 @@ "@jridgewell/sourcemap-codec": "^1.5.5" } }, - "node_modules/markdown-it": { - "version": "14.1.1", - "resolved": "https://registry.npmjs.org/markdown-it/-/markdown-it-14.1.1.tgz", - "integrity": "sha512-BuU2qnTti9YKgK5N+IeMubp14ZUKUUw7yeJbkjtosvHiP0AZ5c8IAgEMk79D0eC8F23r4Ac/q8cAIFdm2FtyoA==", - "license": "MIT", - "dependencies": { - "argparse": "^2.0.1", - "entities": "^4.4.0", - "linkify-it": "^5.0.0", - "mdurl": "^2.0.0", - "punycode.js": "^2.3.1", - "uc.micro": "^2.1.0" - }, - "bin": { - "markdown-it": "bin/markdown-it.mjs" - } - }, - "node_modules/markdown-it/node_modules/entities": { - "version": "4.5.0", - "resolved": "https://registry.npmjs.org/entities/-/entities-4.5.0.tgz", - "integrity": "sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==", - "license": "BSD-2-Clause", - "engines": { - "node": ">=0.12" - }, - "funding": { - "url": "https://github.com/fb55/entities?sponsor=1" - } - }, "node_modules/math-intrinsics": { "version": "1.1.0", "resolved": "https://registry.npmjs.org/math-intrinsics/-/math-intrinsics-1.1.0.tgz", @@ -7641,12 +7396,6 @@ "dev": true, "license": "CC0-1.0" }, - "node_modules/mdurl": { - "version": "2.0.0", - "resolved": "https://registry.npmjs.org/mdurl/-/mdurl-2.0.0.tgz", - "integrity": "sha512-Lf+9+2r+Tdp5wXDXC4PcIBjTDtq4UKjCPMQhKIuzpJNW0b96kVqSwW0bT7FhRSfmAiFYgP+SCRvdrDozfh0U5w==", - "license": "MIT" - }, "node_modules/min-indent": { "version": "1.0.1", "resolved": "https://registry.npmjs.org/min-indent/-/min-indent-1.0.1.tgz", @@ -7670,13 +7419,13 @@ "license": "MIT" }, "node_modules/minimatch": { - "version": "10.2.4", - "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.2.4.tgz", - "integrity": "sha512-oRjTw/97aTBN0RHbYCdtF1MQfvusSIBQM0IZEgzl6426+8jSC0nF1a/GmnVLpfB9yyr6g6FTqWqiZVbxrtaCIg==", + "version": "10.2.5", + "resolved": "https://registry.npmjs.org/minimatch/-/minimatch-10.2.5.tgz", + "integrity": "sha512-MULkVLfKGYDFYejP07QOurDLLQpcjk7Fw+7jXS2R2czRQzR56yHRveU5NDJEOviH+hETZKSkIk5c+T23GjFUMg==", "dev": true, "license": "BlueOak-1.0.0", "dependencies": { - "brace-expansion": "^5.0.2" + "brace-expansion": "^5.0.5" }, "engines": { "node": "18 || 20 || >=22" @@ -7737,14 +7486,14 @@ } }, "node_modules/next": { - "version": "16.1.6", - "resolved": "https://registry.npmjs.org/next/-/next-16.1.6.tgz", - "integrity": "sha512-hkyRkcu5x/41KoqnROkfTm2pZVbKxvbZRuNvKXLRXxs3VfyO0WhY50TQS40EuKO9SW3rBj/sF3WbVwDACeMZyw==", + "version": "16.2.4", + "resolved": "https://registry.npmjs.org/next/-/next-16.2.4.tgz", + "integrity": "sha512-kPvz56wF5frc+FxlHI5qnklCzbq53HTwORaWBGdT0vNoKh1Aya9XC8aPauH4NJxqtzbWsS5mAbctm4cr+EkQ2Q==", "license": "MIT", "dependencies": { - "@next/env": "16.1.6", + "@next/env": "16.2.4", "@swc/helpers": "0.5.15", - "baseline-browser-mapping": "^2.8.3", + "baseline-browser-mapping": "^2.9.19", "caniuse-lite": "^1.0.30001579", "postcss": "8.4.31", "styled-jsx": "5.1.6" @@ -7756,15 +7505,15 @@ "node": ">=20.9.0" }, "optionalDependencies": { - "@next/swc-darwin-arm64": "16.1.6", - "@next/swc-darwin-x64": "16.1.6", - "@next/swc-linux-arm64-gnu": "16.1.6", - "@next/swc-linux-arm64-musl": "16.1.6", - "@next/swc-linux-x64-gnu": "16.1.6", - "@next/swc-linux-x64-musl": "16.1.6", - "@next/swc-win32-arm64-msvc": "16.1.6", - "@next/swc-win32-x64-msvc": "16.1.6", - "sharp": "^0.34.4" + "@next/swc-darwin-arm64": "16.2.4", + "@next/swc-darwin-x64": "16.2.4", + "@next/swc-linux-arm64-gnu": "16.2.4", + "@next/swc-linux-arm64-musl": "16.2.4", + "@next/swc-linux-x64-gnu": "16.2.4", + "@next/swc-linux-x64-musl": "16.2.4", + "@next/swc-win32-arm64-msvc": "16.2.4", + "@next/swc-win32-x64-msvc": "16.2.4", + "sharp": "^0.34.5" }, "peerDependencies": { "@opentelemetry/api": "^1.1.0", @@ -7790,9 +7539,9 @@ } }, "node_modules/next-intl": { - "version": "4.8.3", - "resolved": "https://registry.npmjs.org/next-intl/-/next-intl-4.8.3.tgz", - "integrity": "sha512-PvdBDWg+Leh7BR7GJUQbCDVVaBRn37GwDBWc9sv0rVQOJDQ5JU1rVzx9EEGuOGYo0DHAl70++9LQ7HxTawdL7w==", + "version": "4.9.1", + "resolved": "https://registry.npmjs.org/next-intl/-/next-intl-4.9.1.tgz", + "integrity": "sha512-N7ga0CjtYcdxNvaKNIi6eJ2mmatlHK5hp8rt0YO2Omoc1m0gean242/Ukdj6+gJNiReBVcYIjK0HZeNx7CV1ug==", "funding": [ { "type": "individual", @@ -7804,16 +7553,15 @@ "@formatjs/intl-localematcher": "^0.8.1", "@parcel/watcher": "^2.4.1", "@swc/core": "^1.15.2", - "icu-minify": "^4.8.3", + "icu-minify": "^4.9.1", "negotiator": "^1.0.0", - "next-intl-swc-plugin-extractor": "^4.8.3", + "next-intl-swc-plugin-extractor": "^4.9.1", "po-parser": "^2.1.1", - "use-intl": "^4.8.3" + "use-intl": "^4.9.1" }, "peerDependencies": { "next": "^12.0.0 || ^13.0.0 || ^14.0.0 || ^15.0.0 || ^16.0.0", - "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || >=19.0.0-rc <19.0.0 || ^19.0.0", - "typescript": "^5.0.0" + "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || >=19.0.0-rc <19.0.0 || ^19.0.0" }, "peerDependenciesMeta": { "typescript": { @@ -7822,9 +7570,9 @@ } }, "node_modules/next-intl-swc-plugin-extractor": { - "version": "4.8.3", - "resolved": "https://registry.npmjs.org/next-intl-swc-plugin-extractor/-/next-intl-swc-plugin-extractor-4.8.3.tgz", - "integrity": "sha512-YcaT+R9z69XkGhpDarVFWUprrCMbxgIQYPUaXoE6LGVnLjGdo8hu3gL6bramDVjNKViYY8a/pXPy7Bna0mXORg==", + "version": "4.9.1", + "resolved": "https://registry.npmjs.org/next-intl-swc-plugin-extractor/-/next-intl-swc-plugin-extractor-4.9.1.tgz", + "integrity": "sha512-8whJJ6oxJz8JqkHarggmmuEDyXgC7nEnaPhZD91CJwEWW4xp0AST3Mw17YxvHyP2vAF3taWfFbs1maD+WWtz3w==", "license": "MIT" }, "node_modules/next-intl/node_modules/@swc/core": { @@ -8244,9 +7992,9 @@ } }, "node_modules/pkijs": { - "version": "3.3.3", - "resolved": "https://registry.npmjs.org/pkijs/-/pkijs-3.3.3.tgz", - "integrity": "sha512-+KD8hJtqQMYoTuL1bbGOqxb4z+nZkTAwVdNtWwe8Tc2xNbEmdJYIYoc6Qt0uF55e6YW6KuTHw1DjQ18gMhzepw==", + "version": "3.4.0", + "resolved": "https://registry.npmjs.org/pkijs/-/pkijs-3.4.0.tgz", + "integrity": "sha512-emEcLuomt2j03vxD54giVB4SxTjnsqkU692xZOZXHDVoYyypEm+b3jpiTcc+Cf+myooc+/Ly0z01jqeNHVgJGw==", "license": "BSD-3-Clause", "dependencies": { "@noble/hashes": "1.4.0", @@ -8273,13 +8021,13 @@ } }, "node_modules/playwright": { - "version": "1.58.2", - "resolved": "https://registry.npmjs.org/playwright/-/playwright-1.58.2.tgz", - "integrity": "sha512-vA30H8Nvkq/cPBnNw4Q8TWz1EJyqgpuinBcHET0YVJVFldr8JDNiU9LaWAE1KqSkRYazuaBhTpB5ZzShOezQ6A==", + "version": "1.59.1", + "resolved": "https://registry.npmjs.org/playwright/-/playwright-1.59.1.tgz", + "integrity": "sha512-C8oWjPR3F81yljW9o5OxcWzfh6avkVwDD2VYdwIGqTkl+OGFISgypqzfu7dOe4QNLL2aqcWBmI3PMtLIK233lw==", "devOptional": true, "license": "Apache-2.0", "dependencies": { - "playwright-core": "1.58.2" + "playwright-core": "1.59.1" }, "bin": { "playwright": "cli.js" @@ -8292,9 +8040,9 @@ } }, "node_modules/playwright-core": { - "version": "1.58.2", - "resolved": "https://registry.npmjs.org/playwright-core/-/playwright-core-1.58.2.tgz", - "integrity": "sha512-yZkEtftgwS8CsfYo7nm0KE8jsvm6i/PTgVtB8DL726wNf6H2IMsDuxCpJj59KDaxCtSnrWan2AeDqM7JBaultg==", + "version": "1.59.1", + "resolved": "https://registry.npmjs.org/playwright-core/-/playwright-core-1.59.1.tgz", + "integrity": "sha512-HBV/RJg81z5BiiZ9yPzIiClYV/QMsDCKUyogwH9p3MCP6IYjUFu/MActgYAvK0oWyV9NlwM3GLBjADyWgydVyg==", "devOptional": true, "license": "Apache-2.0", "bin": { @@ -8336,9 +8084,9 @@ "license": "MIT-0" }, "node_modules/postcss": { - "version": "8.5.6", - "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.5.6.tgz", - "integrity": "sha512-3Ybi1tAuwAP9s0r1UQ2J4n5Y0G05bJkpUIO0/bI9MhwmD70S5aTWbXGBwxHrelT+XM1k6dM0pk+SwNkpTRN7Pg==", + "version": "8.5.10", + "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.5.10.tgz", + "integrity": "sha512-pMMHxBOZKFU6HgAZ4eyGnwXF/EvPGGqUr0MnZ5+99485wwW41kW91A4LOGxSHhgugZmSChL5AlElNdwlNgcnLQ==", "dev": true, "funding": [ { @@ -8436,15 +8184,6 @@ "prosemirror-transform": "^1.0.0" } }, - "node_modules/prosemirror-collab": { - "version": "1.3.1", - "resolved": "https://registry.npmjs.org/prosemirror-collab/-/prosemirror-collab-1.3.1.tgz", - "integrity": "sha512-4SnynYR9TTYaQVXd/ieUvsVV4PDMBzrq2xPUWutHivDuOshZXqQ5rGbZM84HEaXKbLdItse7weMGOUdDVcLKEQ==", - "license": "MIT", - "dependencies": { - "prosemirror-state": "^1.0.0" - } - }, "node_modules/prosemirror-commands": { "version": "1.7.1", "resolved": "https://registry.npmjs.org/prosemirror-commands/-/prosemirror-commands-1.7.1.tgz", @@ -8491,16 +8230,6 @@ "rope-sequence": "^1.3.0" } }, - "node_modules/prosemirror-inputrules": { - "version": "1.5.1", - "resolved": "https://registry.npmjs.org/prosemirror-inputrules/-/prosemirror-inputrules-1.5.1.tgz", - "integrity": "sha512-7wj4uMjKaXWAQ1CDgxNzNtR9AlsuwzHfdFH1ygEHA2KHF2DOEaXl1CJfNPAKCg9qNEh4rum975QLaCiQPyY6Fw==", - "license": "MIT", - "dependencies": { - "prosemirror-state": "^1.0.0", - "prosemirror-transform": "^1.0.0" - } - }, "node_modules/prosemirror-keymap": { "version": "1.2.3", "resolved": "https://registry.npmjs.org/prosemirror-keymap/-/prosemirror-keymap-1.2.3.tgz", @@ -8511,29 +8240,6 @@ "w3c-keyname": "^2.2.0" } }, - "node_modules/prosemirror-markdown": { - "version": "1.13.4", - "resolved": "https://registry.npmjs.org/prosemirror-markdown/-/prosemirror-markdown-1.13.4.tgz", - "integrity": "sha512-D98dm4cQ3Hs6EmjK500TdAOew4Z03EV71ajEFiWra3Upr7diytJsjF4mPV2dW+eK5uNectiRj0xFxYI9NLXDbw==", - "license": "MIT", - "dependencies": { - "@types/markdown-it": "^14.0.0", - "markdown-it": "^14.0.0", - "prosemirror-model": "^1.25.0" - } - }, - "node_modules/prosemirror-menu": { - "version": "1.3.0", - "resolved": "https://registry.npmjs.org/prosemirror-menu/-/prosemirror-menu-1.3.0.tgz", - "integrity": "sha512-TImyPXCHPcDsSka2/lwJ6WjTASr4re/qWq1yoTTuLOqfXucwF6VcRa2LWCkM/EyTD1UO3CUwiH8qURJoWJRxwg==", - "license": "MIT", - "dependencies": { - "crelt": "^1.0.0", - "prosemirror-commands": "^1.0.0", - "prosemirror-history": "^1.0.0", - "prosemirror-state": "^1.0.0" - } - }, "node_modules/prosemirror-model": { "version": "1.25.4", "resolved": "https://registry.npmjs.org/prosemirror-model/-/prosemirror-model-1.25.4.tgz", @@ -8543,15 +8249,6 @@ "orderedmap": "^2.0.0" } }, - "node_modules/prosemirror-schema-basic": { - "version": "1.2.4", - "resolved": "https://registry.npmjs.org/prosemirror-schema-basic/-/prosemirror-schema-basic-1.2.4.tgz", - "integrity": "sha512-ELxP4TlX3yr2v5rM7Sb70SqStq5NvI15c0j9j/gjsrO5vaw+fnnpovCLEGIcpeGfifkuqJwl4fon6b+KdrODYQ==", - "license": "MIT", - "dependencies": { - "prosemirror-model": "^1.25.0" - } - }, "node_modules/prosemirror-schema-list": { "version": "1.5.1", "resolved": "https://registry.npmjs.org/prosemirror-schema-list/-/prosemirror-schema-list-1.5.1.tgz", @@ -8587,21 +8284,6 @@ "prosemirror-view": "^1.41.4" } }, - "node_modules/prosemirror-trailing-node": { - "version": "3.0.0", - "resolved": "https://registry.npmjs.org/prosemirror-trailing-node/-/prosemirror-trailing-node-3.0.0.tgz", - "integrity": "sha512-xiun5/3q0w5eRnGYfNlW1uU9W6x5MoFKWwq/0TIRgt09lv7Hcser2QYV8t4muXbEr+Fwo0geYn79Xs4GKywrRQ==", - "license": "MIT", - "dependencies": { - "@remirror/core-constants": "3.0.0", - "escape-string-regexp": "^4.0.0" - }, - "peerDependencies": { - "prosemirror-model": "^1.22.1", - "prosemirror-state": "^1.4.2", - "prosemirror-view": "^1.33.8" - } - }, "node_modules/prosemirror-transform": { "version": "1.11.0", "resolved": "https://registry.npmjs.org/prosemirror-transform/-/prosemirror-transform-1.11.0.tgz", @@ -8632,15 +8314,6 @@ "node": ">=6" } }, - "node_modules/punycode.js": { - "version": "2.3.1", - "resolved": "https://registry.npmjs.org/punycode.js/-/punycode.js-2.3.1.tgz", - "integrity": "sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==", - "license": "MIT", - "engines": { - "node": ">=6" - } - }, "node_modules/pvtsutils": { "version": "1.3.6", "resolved": "https://registry.npmjs.org/pvtsutils/-/pvtsutils-1.3.6.tgz", @@ -8677,24 +8350,24 @@ } }, "node_modules/react": { - "version": "19.2.4", - "resolved": "https://registry.npmjs.org/react/-/react-19.2.4.tgz", - "integrity": "sha512-9nfp2hYpCwOjAN+8TZFGhtWEwgvWHXqESH8qT89AT/lWklpLON22Lc8pEtnpsZz7VmawabSU0gCjnj8aC0euHQ==", + "version": "19.2.5", + "resolved": "https://registry.npmjs.org/react/-/react-19.2.5.tgz", + "integrity": "sha512-llUJLzz1zTUBrskt2pwZgLq59AemifIftw4aB7JxOqf1HY2FDaGDxgwpAPVzHU1kdWabH7FauP4i1oEeer2WCA==", "license": "MIT", "engines": { "node": ">=0.10.0" } }, "node_modules/react-dom": { - "version": "19.2.4", - "resolved": "https://registry.npmjs.org/react-dom/-/react-dom-19.2.4.tgz", - "integrity": "sha512-AXJdLo8kgMbimY95O2aKQqsz2iWi9jMgKJhRBAxECE4IFxfcazB2LmzloIoibJI3C12IlY20+KFaLv+71bUJeQ==", + "version": "19.2.5", + "resolved": "https://registry.npmjs.org/react-dom/-/react-dom-19.2.5.tgz", + "integrity": "sha512-J5bAZz+DXMMwW/wV3xzKke59Af6CHY7G4uYLN1OvBcKEsWOs4pQExj86BBKamxl/Ik5bx9whOrvBlSDfWzgSag==", "license": "MIT", "dependencies": { "scheduler": "^0.27.0" }, "peerDependencies": { - "react": "^19.2.4" + "react": "^19.2.5" } }, "node_modules/react-is": { @@ -8704,16 +8377,6 @@ "dev": true, "license": "MIT" }, - "node_modules/react-refresh": { - "version": "0.18.0", - "resolved": "https://registry.npmjs.org/react-refresh/-/react-refresh-0.18.0.tgz", - "integrity": "sha512-QgT5//D3jfjJb6Gsjxv0Slpj23ip+HtOpnNgnb2S5zU3CB26G/IDPGoy4RJB42wzFE46DRsstbW6tKHoKbhAxw==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=0.10.0" - } - }, "node_modules/readable-stream": { "version": "2.3.8", "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-2.3.8.tgz", @@ -8828,51 +8491,47 @@ "node": ">=4" } }, - "node_modules/rollup": { - "version": "4.59.0", - "resolved": "https://registry.npmjs.org/rollup/-/rollup-4.59.0.tgz", - "integrity": "sha512-2oMpl67a3zCH9H79LeMcbDhXW/UmWG/y2zuqnF2jQq5uq9TbM9TVyXvA4+t+ne2IIkBdrLpAaRQAvo7YI/Yyeg==", + "node_modules/rolldown": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/rolldown/-/rolldown-1.0.0-rc.16.tgz", + "integrity": "sha512-rzi5WqKzEZw3SooTt7cgm4eqIoujPIyGcJNGFL7iPEuajQw7vxMHUkXylu4/vhCkJGXsgRmxqMKXUpT6FEgl0g==", "dev": true, "license": "MIT", "dependencies": { - "@types/estree": "1.0.8" + "@oxc-project/types": "=0.126.0", + "@rolldown/pluginutils": "1.0.0-rc.16" }, "bin": { - "rollup": "dist/bin/rollup" + "rolldown": "bin/cli.mjs" }, "engines": { - "node": ">=18.0.0", - "npm": ">=8.0.0" + "node": "^20.19.0 || >=22.12.0" }, "optionalDependencies": { - "@rollup/rollup-android-arm-eabi": "4.59.0", - "@rollup/rollup-android-arm64": "4.59.0", - "@rollup/rollup-darwin-arm64": "4.59.0", - "@rollup/rollup-darwin-x64": "4.59.0", - "@rollup/rollup-freebsd-arm64": "4.59.0", - "@rollup/rollup-freebsd-x64": "4.59.0", - "@rollup/rollup-linux-arm-gnueabihf": "4.59.0", - "@rollup/rollup-linux-arm-musleabihf": "4.59.0", - "@rollup/rollup-linux-arm64-gnu": "4.59.0", - "@rollup/rollup-linux-arm64-musl": "4.59.0", - "@rollup/rollup-linux-loong64-gnu": "4.59.0", - "@rollup/rollup-linux-loong64-musl": "4.59.0", - "@rollup/rollup-linux-ppc64-gnu": "4.59.0", - "@rollup/rollup-linux-ppc64-musl": "4.59.0", - "@rollup/rollup-linux-riscv64-gnu": "4.59.0", - "@rollup/rollup-linux-riscv64-musl": "4.59.0", - "@rollup/rollup-linux-s390x-gnu": "4.59.0", - "@rollup/rollup-linux-x64-gnu": "4.59.0", - "@rollup/rollup-linux-x64-musl": "4.59.0", - "@rollup/rollup-openbsd-x64": "4.59.0", - "@rollup/rollup-openharmony-arm64": "4.59.0", - "@rollup/rollup-win32-arm64-msvc": "4.59.0", - "@rollup/rollup-win32-ia32-msvc": "4.59.0", - "@rollup/rollup-win32-x64-gnu": "4.59.0", - "@rollup/rollup-win32-x64-msvc": "4.59.0", - "fsevents": "~2.3.2" + "@rolldown/binding-android-arm64": "1.0.0-rc.16", + "@rolldown/binding-darwin-arm64": "1.0.0-rc.16", + "@rolldown/binding-darwin-x64": "1.0.0-rc.16", + "@rolldown/binding-freebsd-x64": "1.0.0-rc.16", + "@rolldown/binding-linux-arm-gnueabihf": "1.0.0-rc.16", + "@rolldown/binding-linux-arm64-gnu": "1.0.0-rc.16", + "@rolldown/binding-linux-arm64-musl": "1.0.0-rc.16", + "@rolldown/binding-linux-ppc64-gnu": "1.0.0-rc.16", + "@rolldown/binding-linux-s390x-gnu": "1.0.0-rc.16", + "@rolldown/binding-linux-x64-gnu": "1.0.0-rc.16", + "@rolldown/binding-linux-x64-musl": "1.0.0-rc.16", + "@rolldown/binding-openharmony-arm64": "1.0.0-rc.16", + "@rolldown/binding-wasm32-wasi": "1.0.0-rc.16", + "@rolldown/binding-win32-arm64-msvc": "1.0.0-rc.16", + "@rolldown/binding-win32-x64-msvc": "1.0.0-rc.16" } }, + "node_modules/rolldown/node_modules/@rolldown/pluginutils": { + "version": "1.0.0-rc.16", + "resolved": "https://registry.npmjs.org/@rolldown/pluginutils/-/pluginutils-1.0.0-rc.16.tgz", + "integrity": "sha512-45+YtqxLYKDWQouLKCrpIZhke+nXxhsw+qAHVzHDVwttyBlHNBVs2K25rDXrZzhpTp9w1FlAlvweV1H++fdZoA==", + "dev": true, + "license": "MIT" + }, "node_modules/rope-sequence": { "version": "1.3.4", "resolved": "https://registry.npmjs.org/rope-sequence/-/rope-sequence-1.3.4.tgz", @@ -9226,9 +8885,9 @@ "license": "MIT" }, "node_modules/std-env": { - "version": "3.10.0", - "resolved": "https://registry.npmjs.org/std-env/-/std-env-3.10.0.tgz", - "integrity": "sha512-5GS12FdOZNliM5mAOxFRg7Ir0pWz8MdpYm6AY6VPkGpbA7ZzmbzNcBJQ0GPvvyWgcY7QAhCgf9Uy89I03faLkg==", + "version": "4.1.0", + "resolved": "https://registry.npmjs.org/std-env/-/std-env-4.1.0.tgz", + "integrity": "sha512-Rq7ybcX2RuC55r9oaPVEW7/xu3tj8u4GeBYHBWCychFtzMIr86A7e3PPEBPT37sHStKX3+TiX/Fr/ACmJLVlLQ==", "dev": true, "license": "MIT" }, @@ -9472,16 +9131,16 @@ } }, "node_modules/tailwindcss": { - "version": "4.2.1", - "resolved": "https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.1.tgz", - "integrity": "sha512-/tBrSQ36vCleJkAOsy9kbNTgaxvGbyOamC30PRePTQe/o1MFwEKHQk4Cn7BNGaPtjp+PuUrByJehM1hgxfq4sw==", + "version": "4.2.4", + "resolved": "https://registry.npmjs.org/tailwindcss/-/tailwindcss-4.2.4.tgz", + "integrity": "sha512-HhKppgO81FQof5m6TEnuBWCZGgfRAWbaeOaGT00KOy/Pf/j6oUihdvBpA7ltCeAvZpFhW3j0PTclkxsd4IXYDA==", "dev": true, "license": "MIT" }, "node_modules/tapable": { - "version": "2.3.0", - "resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.0.tgz", - "integrity": "sha512-g9ljZiwki/LfxmQADO3dEY1CbpmXT5Hm2fJ+QaGKwSXUylMybePR7/67YW7jOrrvjEgL1Fmz5kzyAjWVWLlucg==", + "version": "2.3.3", + "resolved": "https://registry.npmjs.org/tapable/-/tapable-2.3.3.tgz", + "integrity": "sha512-uxc/zpqFg6x7C8vOE7lh6Lbda8eEL9zmVm/PLeTPBRhh1xCgdWaQ+J1CUieGpIfm2HdtsUpRv+HshiasBMcc6A==", "dev": true, "license": "MIT", "engines": { @@ -9500,9 +9159,9 @@ "license": "MIT" }, "node_modules/tinyexec": { - "version": "1.0.2", - "resolved": "https://registry.npmjs.org/tinyexec/-/tinyexec-1.0.2.tgz", - "integrity": "sha512-W/KYk+NFhkmsYpuHq5JykngiOCnxeVL8v8dFnqxSD8qEEdRfXk1SDM6JzNqcERbcGYj9tMrDQBYV9cjgnunFIg==", + "version": "1.1.1", + "resolved": "https://registry.npmjs.org/tinyexec/-/tinyexec-1.1.1.tgz", + "integrity": "sha512-VKS/ZaQhhkKFMANmAOhhXVoIfBXblQxGX1myCQ2faQrfmobMftXeJPcZGp0gS07ocvGJWDLZGyOZDadDBqYIJg==", "dev": true, "license": "MIT", "engines": { @@ -9510,14 +9169,14 @@ } }, "node_modules/tinyglobby": { - "version": "0.2.15", - "resolved": "https://registry.npmjs.org/tinyglobby/-/tinyglobby-0.2.15.tgz", - "integrity": "sha512-j2Zq4NyQYG5XMST4cbs02Ak8iJUdxRM0XI5QyxXuZOzKOINmWurp3smXu3y5wDcJrptwpSjgXHzIQxR0omXljQ==", + "version": "0.2.16", + "resolved": "https://registry.npmjs.org/tinyglobby/-/tinyglobby-0.2.16.tgz", + "integrity": "sha512-pn99VhoACYR8nFHhxqix+uvsbXineAasWm5ojXoN8xEwK5Kd3/TrhNn1wByuD52UxWRLy8pu+kRMniEi6Eq9Zg==", "dev": true, "license": "MIT", "dependencies": { "fdir": "^6.5.0", - "picomatch": "^4.0.3" + "picomatch": "^4.0.4" }, "engines": { "node": ">=12.0.0" @@ -9545,9 +9204,9 @@ } }, "node_modules/tinyrainbow": { - "version": "3.0.3", - "resolved": "https://registry.npmjs.org/tinyrainbow/-/tinyrainbow-3.0.3.tgz", - "integrity": "sha512-PSkbLUoxOFRzJYjjxHJt9xro7D+iilgMX/C9lawzVuYiIdcihh9DXmVibBe8lmcFrRi/VzlPjBxbN7rH24q8/Q==", + "version": "3.1.0", + "resolved": "https://registry.npmjs.org/tinyrainbow/-/tinyrainbow-3.1.0.tgz", + "integrity": "sha512-Bf+ILmBgretUrdJxzXM0SgXLZ3XfiaUuOj/IKQHuTXip+05Xn+uyEYdVg0kYDipTBcLrCVyUzAPz7QmArb0mmw==", "dev": true, "license": "MIT", "engines": { @@ -9611,9 +9270,9 @@ } }, "node_modules/ts-api-utils": { - "version": "2.4.0", - "resolved": "https://registry.npmjs.org/ts-api-utils/-/ts-api-utils-2.4.0.tgz", - "integrity": "sha512-3TaVTaAv2gTiMB35i3FiGJaRfwb3Pyn/j3m/bfAvGe8FB7CF6u+LMYqYlDh7reQf7UNvoTvdfAqHGmPGOSsPmA==", + "version": "2.5.0", + "resolved": "https://registry.npmjs.org/ts-api-utils/-/ts-api-utils-2.5.0.tgz", + "integrity": "sha512-OJ/ibxhPlqrMM0UiNHJ/0CKQkoKF243/AEmplt3qpRgkW8VG7IfOS41h7V8TjITqdByHzrjcS/2si+y4lIh8NA==", "dev": true, "license": "MIT", "engines": { @@ -9724,7 +9383,7 @@ "version": "5.9.3", "resolved": "https://registry.npmjs.org/typescript/-/typescript-5.9.3.tgz", "integrity": "sha512-jl1vZzPDinLr9eUt3J/t7V6FgNEw9QjvBPdysz9KfQDD41fQrC2Y4vKQdiaUpFT4bXlb1RHhLpp8wtm6M5TgSw==", - "devOptional": true, + "dev": true, "license": "Apache-2.0", "bin": { "tsc": "bin/tsc", @@ -9734,12 +9393,6 @@ "node": ">=14.17" } }, - "node_modules/uc.micro": { - "version": "2.1.0", - "resolved": "https://registry.npmjs.org/uc.micro/-/uc.micro-2.1.0.tgz", - "integrity": "sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==", - "license": "MIT" - }, "node_modules/unbox-primitive": { "version": "1.1.0", "resolved": "https://registry.npmjs.org/unbox-primitive/-/unbox-primitive-1.1.0.tgz", @@ -9770,9 +9423,9 @@ } }, "node_modules/undici-types": { - "version": "7.18.2", - "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-7.18.2.tgz", - "integrity": "sha512-AsuCzffGHJybSaRrmr5eHr81mwJU3kjw6M+uprWvCXiNeN9SOGwQ3Jn8jb8m3Z6izVgknn1R0FTCEAP2QrLY/w==", + "version": "7.19.2", + "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-7.19.2.tgz", + "integrity": "sha512-qYVnV5OEm2AW8cJMCpdV20CDyaN3g0AjDlOGf1OW4iaDEx8MwdtChUp4zu4H0VP3nDRF/8RKWH+IPp9uW0YGZg==", "dev": true, "license": "MIT" }, @@ -9818,9 +9471,9 @@ } }, "node_modules/use-intl": { - "version": "4.8.3", - "resolved": "https://registry.npmjs.org/use-intl/-/use-intl-4.8.3.tgz", - "integrity": "sha512-nLxlC/RH+le6g3amA508Itnn/00mE+J22ui21QhOWo5V9hCEC43+WtnRAITbJW0ztVZphev5X9gvOf2/Dk9PLA==", + "version": "4.9.1", + "resolved": "https://registry.npmjs.org/use-intl/-/use-intl-4.9.1.tgz", + "integrity": "sha512-iGVV/xFYlhe3btafRlL8RPLD2Jsuet4yqn9DR6LWWbMhULsJnXgLonDkzDmsAIBIwFtk02oJuX/Ox2vwHKF+UQ==", "funding": [ { "type": "individual", @@ -9831,7 +9484,7 @@ "dependencies": { "@formatjs/fast-memoize": "^3.1.0", "@schummar/icu-type-parser": "1.21.5", - "icu-minify": "^4.8.3", + "icu-minify": "^4.9.1", "intl-messageformat": "^11.1.0" }, "peerDependencies": { @@ -9854,18 +9507,17 @@ "license": "MIT" }, "node_modules/vite": { - "version": "7.3.1", - "resolved": "https://registry.npmjs.org/vite/-/vite-7.3.1.tgz", - "integrity": "sha512-w+N7Hifpc3gRjZ63vYBXA56dvvRlNWRczTdmCBBa+CotUzAPf5b7YMdMR/8CQoeYE5LX3W4wj6RYTgonm1b9DA==", + "version": "8.0.9", + "resolved": "https://registry.npmjs.org/vite/-/vite-8.0.9.tgz", + "integrity": "sha512-t7g7GVRpMXjNpa67HaVWI/8BWtdVIQPCL2WoozXXA7LBGEFK4AkkKkHx2hAQf5x1GZSlcmEDPkVLSGahxnEEZw==", "dev": true, "license": "MIT", "dependencies": { - "esbuild": "^0.27.0", - "fdir": "^6.5.0", - "picomatch": "^4.0.3", - "postcss": "^8.5.6", - "rollup": "^4.43.0", - "tinyglobby": "^0.2.15" + "lightningcss": "^1.32.0", + "picomatch": "^4.0.4", + "postcss": "^8.5.10", + "rolldown": "1.0.0-rc.16", + "tinyglobby": "^0.2.16" }, "bin": { "vite": "bin/vite.js" @@ -9881,9 +9533,10 @@ }, "peerDependencies": { "@types/node": "^20.19.0 || >=22.12.0", + "@vitejs/devtools": "^0.1.0", + "esbuild": "^0.27.0 || ^0.28.0", "jiti": ">=1.21.0", "less": "^4.0.0", - "lightningcss": "^1.21.0", "sass": "^1.70.0", "sass-embedded": "^1.70.0", "stylus": ">=0.54.8", @@ -9896,15 +9549,18 @@ "@types/node": { "optional": true }, + "@vitejs/devtools": { + "optional": true + }, + "esbuild": { + "optional": true + }, "jiti": { "optional": true }, "less": { "optional": true }, - "lightningcss": { - "optional": true - }, "sass": { "optional": true }, @@ -9928,24 +9584,6 @@ } } }, - "node_modules/vite/node_modules/fdir": { - "version": "6.5.0", - "resolved": "https://registry.npmjs.org/fdir/-/fdir-6.5.0.tgz", - "integrity": "sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg==", - "dev": true, - "license": "MIT", - "engines": { - "node": ">=12.0.0" - }, - "peerDependencies": { - "picomatch": "^3 || ^4" - }, - "peerDependenciesMeta": { - "picomatch": { - "optional": true - } - } - }, "node_modules/vite/node_modules/fsevents": { "version": "2.3.3", "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.3.3.tgz", @@ -9962,31 +9600,31 @@ } }, "node_modules/vitest": { - "version": "4.0.18", - "resolved": "https://registry.npmjs.org/vitest/-/vitest-4.0.18.tgz", - "integrity": "sha512-hOQuK7h0FGKgBAas7v0mSAsnvrIgAvWmRFjmzpJ7SwFHH3g1k2u37JtYwOwmEKhK6ZO3v9ggDBBm0La1LCK4uQ==", + "version": "4.1.5", + "resolved": "https://registry.npmjs.org/vitest/-/vitest-4.1.5.tgz", + "integrity": "sha512-9Xx1v3/ih3m9hN+SbfkUyy0JAs72ap3r7joc87XL6jwF0jGg6mFBvQ1SrwaX+h8BlkX6Hz9shdd1uo6AF+ZGpg==", "dev": true, "license": "MIT", "dependencies": { - "@vitest/expect": "4.0.18", - "@vitest/mocker": "4.0.18", - "@vitest/pretty-format": "4.0.18", - "@vitest/runner": "4.0.18", - "@vitest/snapshot": "4.0.18", - "@vitest/spy": "4.0.18", - "@vitest/utils": "4.0.18", - "es-module-lexer": "^1.7.0", - "expect-type": "^1.2.2", + "@vitest/expect": "4.1.5", + "@vitest/mocker": "4.1.5", + "@vitest/pretty-format": "4.1.5", + "@vitest/runner": "4.1.5", + "@vitest/snapshot": "4.1.5", + "@vitest/spy": "4.1.5", + "@vitest/utils": "4.1.5", + "es-module-lexer": "^2.0.0", + "expect-type": "^1.3.0", "magic-string": "^0.30.21", "obug": "^2.1.1", "pathe": "^2.0.3", "picomatch": "^4.0.3", - "std-env": "^3.10.0", + "std-env": "^4.0.0-rc.1", "tinybench": "^2.9.0", "tinyexec": "^1.0.2", "tinyglobby": "^0.2.15", - "tinyrainbow": "^3.0.3", - "vite": "^6.0.0 || ^7.0.0", + "tinyrainbow": "^3.1.0", + "vite": "^6.0.0 || ^7.0.0 || ^8.0.0", "why-is-node-running": "^2.3.0" }, "bin": { @@ -10002,12 +9640,15 @@ "@edge-runtime/vm": "*", "@opentelemetry/api": "^1.9.0", "@types/node": "^20.0.0 || ^22.0.0 || >=24.0.0", - "@vitest/browser-playwright": "4.0.18", - "@vitest/browser-preview": "4.0.18", - "@vitest/browser-webdriverio": "4.0.18", - "@vitest/ui": "4.0.18", + "@vitest/browser-playwright": "4.1.5", + "@vitest/browser-preview": "4.1.5", + "@vitest/browser-webdriverio": "4.1.5", + "@vitest/coverage-istanbul": "4.1.5", + "@vitest/coverage-v8": "4.1.5", + "@vitest/ui": "4.1.5", "happy-dom": "*", - "jsdom": "*" + "jsdom": "*", + "vite": "^6.0.0 || ^7.0.0 || ^8.0.0" }, "peerDependenciesMeta": { "@edge-runtime/vm": { @@ -10028,6 +9669,12 @@ "@vitest/browser-webdriverio": { "optional": true }, + "@vitest/coverage-istanbul": { + "optional": true + }, + "@vitest/coverage-v8": { + "optional": true + }, "@vitest/ui": { "optional": true }, @@ -10036,6 +9683,9 @@ }, "jsdom": { "optional": true + }, + "vite": { + "optional": false } } }, @@ -10431,9 +10081,9 @@ } }, "node_modules/zustand": { - "version": "5.0.11", - "resolved": "https://registry.npmjs.org/zustand/-/zustand-5.0.11.tgz", - "integrity": "sha512-fdZY+dk7zn/vbWNCYmzZULHRrss0jx5pPFiOuMZ/5HJN6Yv3u+1Wswy/4MpZEkEGhtNH+pwxZB8OKgUBPzYAGg==", + "version": "5.0.12", + "resolved": "https://registry.npmjs.org/zustand/-/zustand-5.0.12.tgz", + "integrity": "sha512-i77ae3aZq4dhMlRhJVCYgMLKuSiZAaUPAct2AksxQ+gOtimhGMdXljRT21P5BNpeT4kXlLIckvkPM029OljD7g==", "license": "MIT", "engines": { "node": ">=12.20.0" diff --git a/package.json b/package.json index 8c2fb66d..21175fb1 100644 --- a/package.json +++ b/package.json @@ -32,62 +32,62 @@ "typecheck": "tsc --noEmit" }, "dependencies": { - "@tanstack/react-virtual": "^3.13.18", - "@tiptap/extension-color": "^3.20.4", - "@tiptap/extension-image": "^3.20.4", - "@tiptap/extension-link": "^3.20.4", - "@tiptap/extension-placeholder": "^3.20.4", - "@tiptap/extension-text-align": "^3.20.4", - "@tiptap/extension-text-style": "^3.20.4", - "@tiptap/extension-underline": "^3.20.4", - "@tiptap/pm": "^3.20.4", - "@tiptap/react": "^3.20.4", - "@tiptap/starter-kit": "^3.20.4", - "asn1js": "^3.0.7", + "@tanstack/react-virtual": "^3.13.24", + "@tiptap/extension-color": "^3.22.4", + "@tiptap/extension-image": "^3.22.4", + "@tiptap/extension-link": "^3.22.4", + "@tiptap/extension-placeholder": "^3.22.4", + "@tiptap/extension-text-align": "^3.22.4", + "@tiptap/extension-text-style": "^3.22.4", + "@tiptap/extension-underline": "^3.22.4", + "@tiptap/pm": "^3.22.4", + "@tiptap/react": "^3.22.4", + "@tiptap/starter-kit": "^3.22.4", + "asn1js": "^3.0.10", "clsx": "^2.1.1", "date-fns": "^4.1.0", - "dompurify": "^3.3.3", + "dompurify": "^3.4.1", "jszip": "^3.10.1", - "lucide-react": "^0.575.0", - "next": "^16.1.5", - "next-intl": "^4.5.8", + "lucide-react": "^1.8.0", + "next": "^16.2.4", + "next-intl": "^4.9.1", "otpauth": "^9.5.0", - "pkijs": "^3.3.3", + "pkijs": "^3.4.0", "postal-mime": "^2.7.4", "pvtsutils": "^1.3.6", "qrcode": "^1.5.4", - "react": "^19.2.1", - "react-dom": "^19.2.1", + "react": "^19.2.5", + "react-dom": "^19.2.5", "sonner": "^2.0.7", "tailwind-merge": "^3.4.0", "webcrypto-liner": "^1.4.3", - "zustand": "^5.0.9" + "zustand": "^5.0.12" }, "devDependencies": { - "@eslint/js": "^9.39.3", - "@playwright/test": "^1.58.2", - "@tailwindcss/postcss": "^4", + "@eslint/js": "^9.39.4", + "@playwright/test": "^1.59.1", + "@tailwindcss/postcss": "^4.2.4", "@testing-library/dom": "^10.4.1", "@testing-library/jest-dom": "^6.9.1", "@testing-library/react": "^16.3.1", - "@types/node": "^25.2.3", + "@types/node": "^25.6.0", "@types/qrcode": "^1.5.6", "@types/react": "^19.2.7", "@types/react-dom": "^19.2.3", - "@typescript-eslint/eslint-plugin": "^8.49.0", - "@typescript-eslint/parser": "^8.49.0", - "@vitejs/plugin-react": "^5.1.2", - "@vitest/ui": "^4.0.16", - "eslint": "^9.39.2", + "@typescript-eslint/eslint-plugin": "^8.59.0", + "@typescript-eslint/parser": "^8.59.0", + "@vitejs/plugin-react": "^6.0.1", + "@vitest/ui": "^4.1.5", + "eslint": "^9.39.4", "eslint-plugin-react": "^7.37.5", - "eslint-plugin-react-hooks": "^7.0.1", + "eslint-plugin-react-hooks": "^7.1.1", "fake-indexeddb": "^6.2.5", - "globals": "^17.0.0", + "globals": "^17.5.0", "husky": "^9.1.7", "jsdom": "^28.1.0", - "tailwindcss": "^4.1.17", + "tailwindcss": "^4.2.4", "typescript": "^5.9.3", - "vitest": "^4.0.16" + "vitest": "^4.1.5" }, "overrides": { "elliptic": { diff --git a/specifications/auth/rfc5280.txt b/specifications/auth/rfc5280.txt deleted file mode 100644 index 34d56992..00000000 --- a/specifications/auth/rfc5280.txt +++ /dev/null @@ -1,8459 +0,0 @@ - - - - - - -Network Working Group D. Cooper -Request for Comments: 5280 NIST -Obsoletes: 3280, 4325, 4630 S. Santesson -Category: Standards Track Microsoft - S. Farrell - Trinity College Dublin - S. Boeyen - Entrust - R. Housley - Vigil Security - W. Polk - NIST - May 2008 - - - Internet X.509 Public Key Infrastructure Certificate - and Certificate Revocation List (CRL) Profile - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This memo profiles the X.509 v3 certificate and X.509 v2 certificate - revocation list (CRL) for use in the Internet. An overview of this - approach and model is provided as an introduction. The X.509 v3 - certificate format is described in detail, with additional - information regarding the format and semantics of Internet name - forms. Standard certificate extensions are described and two - Internet-specific extensions are defined. A set of required - certificate extensions is specified. The X.509 v2 CRL format is - described in detail along with standard and Internet-specific - extensions. An algorithm for X.509 certification path validation is - described. An ASN.1 module and examples are provided in the - appendices. - - - - - - - - - - - -Cooper, et al. Standards Track [Page 1] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -Table of Contents - - 1. Introduction ....................................................4 - 2. Requirements and Assumptions ....................................6 - 2.1. Communication and Topology .................................7 - 2.2. Acceptability Criteria .....................................7 - 2.3. User Expectations ..........................................7 - 2.4. Administrator Expectations .................................8 - 3. Overview of Approach ............................................8 - 3.1. X.509 Version 3 Certificate ................................9 - 3.2. Certification Paths and Trust .............................10 - 3.3. Revocation ................................................13 - 3.4. Operational Protocols .....................................14 - 3.5. Management Protocols ......................................14 - 4. Certificate and Certificate Extensions Profile .................16 - 4.1. Basic Certificate Fields ..................................16 - 4.1.1. Certificate Fields .................................17 - 4.1.1.1. tbsCertificate ............................18 - 4.1.1.2. signatureAlgorithm ........................18 - 4.1.1.3. signatureValue ............................18 - 4.1.2. TBSCertificate .....................................18 - 4.1.2.1. Version ...................................19 - 4.1.2.2. Serial Number .............................19 - 4.1.2.3. Signature .................................19 - 4.1.2.4. Issuer ....................................20 - 4.1.2.5. Validity ..................................22 - 4.1.2.5.1. UTCTime ........................23 - 4.1.2.5.2. GeneralizedTime ................23 - 4.1.2.6. Subject ...................................23 - 4.1.2.7. Subject Public Key Info ...................25 - 4.1.2.8. Unique Identifiers ........................25 - 4.1.2.9. Extensions ................................26 - 4.2. Certificate Extensions ....................................26 - 4.2.1. Standard Extensions ................................27 - 4.2.1.1. Authority Key Identifier ..................27 - 4.2.1.2. Subject Key Identifier ....................28 - 4.2.1.3. Key Usage .................................29 - 4.2.1.4. Certificate Policies ......................32 - 4.2.1.5. Policy Mappings ...........................35 - 4.2.1.6. Subject Alternative Name ..................35 - 4.2.1.7. Issuer Alternative Name ...................38 - 4.2.1.8. Subject Directory Attributes ..............39 - 4.2.1.9. Basic Constraints .........................39 - 4.2.1.10. Name Constraints .........................40 - 4.2.1.11. Policy Constraints .......................43 - 4.2.1.12. Extended Key Usage .......................44 - 4.2.1.13. CRL Distribution Points ..................45 - 4.2.1.14. Inhibit anyPolicy ........................48 - - - -Cooper, et al. Standards Track [Page 2] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 4.2.1.15. Freshest CRL (a.k.a. Delta CRL - Distribution Point) ......................48 - 4.2.2. Private Internet Extensions ........................49 - 4.2.2.1. Authority Information Access ..............49 - 4.2.2.2. Subject Information Access ................51 - 5. CRL and CRL Extensions Profile .................................54 - 5.1. CRL Fields ................................................55 - 5.1.1. CertificateList Fields .............................56 - 5.1.1.1. tbsCertList ...............................56 - 5.1.1.2. signatureAlgorithm ........................57 - 5.1.1.3. signatureValue ............................57 - 5.1.2. Certificate List "To Be Signed" ....................58 - 5.1.2.1. Version ...................................58 - 5.1.2.2. Signature .................................58 - 5.1.2.3. Issuer Name ...............................58 - 5.1.2.4. This Update ...............................58 - 5.1.2.5. Next Update ...............................59 - 5.1.2.6. Revoked Certificates ......................59 - 5.1.2.7. Extensions ................................60 - 5.2. CRL Extensions ............................................60 - 5.2.1. Authority Key Identifier ...........................60 - 5.2.2. Issuer Alternative Name ............................60 - 5.2.3. CRL Number .........................................61 - 5.2.4. Delta CRL Indicator ................................62 - 5.2.5. Issuing Distribution Point .........................65 - 5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution - Point) .............................................67 - 5.2.7. Authority Information Access .......................67 - 5.3. CRL Entry Extensions ......................................69 - 5.3.1. Reason Code ........................................69 - 5.3.2. Invalidity Date ....................................70 - 5.3.3. Certificate Issuer .................................70 - 6. Certification Path Validation ..................................71 - 6.1. Basic Path Validation .....................................72 - 6.1.1. Inputs .............................................75 - 6.1.2. Initialization .....................................77 - 6.1.3. Basic Certificate Processing .......................80 - 6.1.4. Preparation for Certificate i+1 ....................84 - 6.1.5. Wrap-Up Procedure ..................................87 - 6.1.6. Outputs ............................................89 - 6.2. Using the Path Validation Algorithm .......................89 - 6.3. CRL Validation ............................................90 - 6.3.1. Revocation Inputs ..................................91 - 6.3.2. Initialization and Revocation State Variables ......91 - 6.3.3. CRL Processing .....................................92 - 7. Processing Rules for Internationalized Names ...................95 - 7.1. Internationalized Names in Distinguished Names ............96 - 7.2. Internationalized Domain Names in GeneralName .............97 - - - -Cooper, et al. Standards Track [Page 3] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 7.3. Internationalized Domain Names in Distinguished Names .....98 - 7.4. Internationalized Resource Identifiers ....................98 - 7.5. Internationalized Electronic Mail Addresses ..............100 - 8. Security Considerations .......................................100 - 9. IANA Considerations ...........................................105 - 10. Acknowledgments ..............................................105 - 11. References ...................................................105 - 11.1. Normative References ....................................105 - 11.2. Informative References ..................................107 - Appendix A. Pseudo-ASN.1 Structures and OIDs ....................110 - A.1. Explicitly Tagged Module, 1988 Syntax ....................110 - A.2. Implicitly Tagged Module, 1988 Syntax ....................125 - Appendix B. ASN.1 Notes ..........................................133 - Appendix C. Examples .............................................136 - C.1. RSA Self-Signed Certificate ..............................137 - C.2. End Entity Certificate Using RSA .........................140 - C.3. End Entity Certificate Using DSA .........................143 - C.4. Certificate Revocation List ..............................147 - -1. Introduction - - This specification is one part of a family of standards for the X.509 - Public Key Infrastructure (PKI) for the Internet. - - This specification profiles the format and semantics of certificates - and certificate revocation lists (CRLs) for the Internet PKI. - Procedures are described for processing of certification paths in the - Internet environment. Finally, ASN.1 modules are provided in the - appendices for all data structures defined or referenced. - - Section 2 describes Internet PKI requirements and the assumptions - that affect the scope of this document. Section 3 presents an - architectural model and describes its relationship to previous IETF - and ISO/IEC/ITU-T standards. In particular, this document's - relationship with the IETF PEM specifications and the ISO/IEC/ITU-T - X.509 documents is described. - - Section 4 profiles the X.509 version 3 certificate, and Section 5 - profiles the X.509 version 2 CRL. The profiles include the - identification of ISO/IEC/ITU-T and ANSI extensions that may be - useful in the Internet PKI. The profiles are presented in the 1988 - Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1 - syntax used in the most recent ISO/IEC/ITU-T standards. - - Section 6 includes certification path validation procedures. These - procedures are based upon the ISO/IEC/ITU-T definition. - Implementations are REQUIRED to derive the same results but are not - required to use the specified procedures. - - - -Cooper, et al. Standards Track [Page 4] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Procedures for identification and encoding of public key materials - and digital signatures are defined in [RFC3279], [RFC4055], and - [RFC4491]. Implementations of this specification are not required to - use any particular cryptographic algorithms. However, conforming - implementations that use the algorithms identified in [RFC3279], - [RFC4055], and [RFC4491] MUST identify and encode the public key - materials and digital signatures as described in those - specifications. - - Finally, three appendices are provided to aid implementers. Appendix - A contains all ASN.1 structures defined or referenced within this - specification. As above, the material is presented in the 1988 - ASN.1. Appendix B contains notes on less familiar features of the - ASN.1 notation used within this specification. Appendix C contains - examples of conforming certificates and a conforming CRL. - - This specification obsoletes [RFC3280]. Differences from RFC 3280 - are summarized below: - - * Enhanced support for internationalized names is specified in - Section 7, with rules for encoding and comparing - Internationalized Domain Names, Internationalized Resource - Identifiers (IRIs), and distinguished names. These rules are - aligned with comparison rules established in current RFCs, - including [RFC3490], [RFC3987], and [RFC4518]. - - * Sections 4.1.2.4 and 4.1.2.6 incorporate the conditions for - continued use of legacy text encoding schemes that were - specified in [RFC4630]. Where in use by an established PKI, - transition to UTF8String could cause denial of service based on - name chaining failures or incorrect processing of name - constraints. - - * Section 4.2.1.4 in RFC 3280, which specified the - privateKeyUsagePeriod certificate extension but deprecated its - use, was removed. Use of this ISO standard extension is neither - deprecated nor recommended for use in the Internet PKI. - - * Section 4.2.1.5 recommends marking the policy mappings extension - as critical. RFC 3280 required that the policy mappings - extension be marked as non-critical. - - * Section 4.2.1.11 requires marking the policy constraints - extension as critical. RFC 3280 permitted the policy - constraints extension to be marked as critical or non-critical. - - * The Authority Information Access (AIA) CRL extension, as - specified in [RFC4325], was added as Section 5.2.7. - - - -Cooper, et al. Standards Track [Page 5] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - * Sections 5.2 and 5.3 clarify the rules for handling unrecognized - CRL extensions and CRL entry extensions, respectively. - - * Section 5.3.2 in RFC 3280, which specified the - holdInstructionCode CRL entry extension, was removed. - - * The path validation algorithm specified in Section 6 no longer - tracks the criticality of the certificate policies extensions in - a chain of certificates. In RFC 3280, this information was - returned to a relying party. - - * The Security Considerations section addresses the risk of - circular dependencies arising from the use of https or similar - schemes in the CRL distribution points, authority information - access, or subject information access extensions. - - * The Security Considerations section addresses risks associated - with name ambiguity. - - * The Security Considerations section references RFC 4210 for - procedures to signal changes in CA operations. - - The ASN.1 modules in Appendix A are unchanged from RFC 3280, except - that ub-emailaddress-length was changed from 128 to 255 in order to - align with PKCS #9 [RFC2985]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. Requirements and Assumptions - - The goal of this specification is to develop a profile to facilitate - the use of X.509 certificates within Internet applications for those - communities wishing to make use of X.509 technology. Such - applications may include WWW, electronic mail, user authentication, - and IPsec. In order to relieve some of the obstacles to using X.509 - certificates, this document defines a profile to promote the - development of certificate management systems, development of - application tools, and interoperability determined by policy. - - Some communities will need to supplement, or possibly replace, this - profile in order to meet the requirements of specialized application - domains or environments with additional authorization, assurance, or - operational requirements. However, for basic applications, common - representations of frequently used attributes are defined so that - - - - - -Cooper, et al. Standards Track [Page 6] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - application developers can obtain necessary information without - regard to the issuer of a particular certificate or certificate - revocation list (CRL). - - A certificate user should review the certificate policy generated by - the certification authority (CA) before relying on the authentication - or non-repudiation services associated with the public key in a - particular certificate. To this end, this standard does not - prescribe legally binding rules or duties. - - As supplemental authorization and attribute management tools emerge, - such as attribute certificates, it may be appropriate to limit the - authenticated attributes that are included in a certificate. These - other management tools may provide more appropriate methods of - conveying many authenticated attributes. - -2.1. Communication and Topology - - The users of certificates will operate in a wide range of - environments with respect to their communication topology, especially - users of secure electronic mail. This profile supports users without - high bandwidth, real-time IP connectivity, or high connection - availability. In addition, the profile allows for the presence of - firewall or other filtered communication. - - This profile does not assume the deployment of an X.500 directory - system [X.500] or a Lightweight Directory Access Protocol (LDAP) - directory system [RFC4510]. The profile does not prohibit the use of - an X.500 directory or an LDAP directory; however, any means of - distributing certificates and certificate revocation lists (CRLs) may - be used. - -2.2. Acceptability Criteria - - The goal of the Internet Public Key Infrastructure (PKI) is to meet - the needs of deterministic, automated identification, authentication, - access control, and authorization functions. Support for these - services determines the attributes contained in the certificate as - well as the ancillary control information in the certificate such as - policy data and certification path constraints. - -2.3. User Expectations - - Users of the Internet PKI are people and processes who use client - software and are the subjects named in certificates. These uses - include readers and writers of electronic mail, the clients for WWW - browsers, WWW servers, and the key manager for IPsec within a router. - This profile recognizes the limitations of the platforms these users - - - -Cooper, et al. Standards Track [Page 7] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - employ and the limitations in sophistication and attentiveness of the - users themselves. This manifests itself in minimal user - configuration responsibility (e.g., trusted CA keys, rules), explicit - platform usage constraints within the certificate, certification path - constraints that shield the user from many malicious actions, and - applications that sensibly automate validation functions. - -2.4. Administrator Expectations - - As with user expectations, the Internet PKI profile is structured to - support the individuals who generally operate CAs. Providing - administrators with unbounded choices increases the chances that a - subtle CA administrator mistake will result in broad compromise. - Also, unbounded choices greatly complicate the software that process - and validate the certificates created by the CA. - -3. Overview of Approach - - Following is a simplified view of the architectural model assumed by - the Public-Key Infrastructure using X.509 (PKIX) specifications. - - The components in this model are: - - end entity: user of PKI certificates and/or end user system that is - the subject of a certificate; - - CA: certification authority; - - RA: registration authority, i.e., an optional system to which - a CA delegates certain management functions; - - CRL issuer: a system that generates and signs CRLs; and - - repository: a system or collection of distributed systems that stores - certificates and CRLs and serves as a means of - distributing these certificates and CRLs to end entities. - - CAs are responsible for indicating the revocation status of the - certificates that they issue. Revocation status information may be - provided using the Online Certificate Status Protocol (OCSP) - [RFC2560], certificate revocation lists (CRLs), or some other - mechanism. In general, when revocation status information is - provided using CRLs, the CA is also the CRL issuer. However, a CA - may delegate the responsibility for issuing CRLs to a different - entity. - - Note that an Attribute Authority (AA) might also choose to delegate - the publication of CRLs to a CRL issuer. - - - -Cooper, et al. Standards Track [Page 8] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - +---+ - | C | +------------+ - | e | <-------------------->| End entity | - | r | Operational +------------+ - | t | transactions ^ - | i | and management | Management - | f | transactions | transactions PKI - | i | | users - | c | v - | a | ======================= +--+------------+ ============== - | t | ^ ^ - | e | | | PKI - | | v | management - | & | +------+ | entities - | | <---------------------| RA |<----+ | - | C | Publish certificate +------+ | | - | R | | | - | L | | | - | | v v - | R | +------------+ - | e | <------------------------------| CA | - | p | Publish certificate +------------+ - | o | Publish CRL ^ ^ - | s | | | Management - | i | +------------+ | | transactions - | t | <--------------| CRL Issuer |<----+ | - | o | Publish CRL +------------+ v - | r | +------+ - | y | | CA | - +---+ +------+ - - Figure 1. PKI Entities - -3.1. X.509 Version 3 Certificate - - Users of a public key require confidence that the associated private - key is owned by the correct remote subject (person or system) with - which an encryption or digital signature mechanism will be used. - This confidence is obtained through the use of public key - certificates, which are data structures that bind public key values - to subjects. The binding is asserted by having a trusted CA - digitally sign each certificate. The CA may base this assertion upon - technical means (a.k.a., proof of possession through a challenge- - response protocol), presentation of the private key, or on an - assertion by the subject. A certificate has a limited valid - lifetime, which is indicated in its signed contents. Because a - certificate's signature and timeliness can be independently checked - by a certificate-using client, certificates can be distributed via - - - -Cooper, et al. Standards Track [Page 9] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - untrusted communications and server systems, and can be cached in - unsecured storage in certificate-using systems. - - ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first - published in 1988 as part of the X.500 directory recommendations, - defines a standard certificate format [X.509]. The certificate - format in the 1988 standard is called the version 1 (v1) format. - When X.500 was revised in 1993, two more fields were added, resulting - in the version 2 (v2) format. - - The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993, - include specifications for a public key infrastructure based on X.509 - v1 certificates [RFC1422]. The experience gained in attempts to - deploy RFC 1422 made it clear that the v1 and v2 certificate formats - were deficient in several respects. Most importantly, more fields - were needed to carry information that PEM design and implementation - experience had proven necessary. In response to these new - requirements, the ISO/IEC, ITU-T, and ANSI X9 developed the X.509 - version 3 (v3) certificate format. The v3 format extends the v2 - format by adding provision for additional extension fields. - Particular extension field types may be specified in standards or may - be defined and registered by any organization or community. In June - 1996, standardization of the basic v3 format was completed [X.509]. - - ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions - for use in the v3 extensions field [X.509][X9.55]. These extensions - can convey such data as additional subject identification - information, key attribute information, policy information, and - certification path constraints. - - However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very - broad in their applicability. In order to develop interoperable - implementations of X.509 v3 systems for Internet use, it is necessary - to specify a profile for use of the X.509 v3 extensions tailored for - the Internet. It is one goal of this document to specify a profile - for Internet WWW, electronic mail, and IPsec applications. - Environments with additional requirements may build on this profile - or may replace it. - -3.2. Certification Paths and Trust - - A user of a security service requiring knowledge of a public key - generally needs to obtain and validate a certificate containing the - required public key. If the public key user does not already hold an - assured copy of the public key of the CA that signed the certificate, - the CA's name, and related information (such as the validity period - or name constraints), then it might need an additional certificate to - obtain that public key. In general, a chain of multiple certificates - - - -Cooper, et al. Standards Track [Page 10] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - may be needed, comprising a certificate of the public key owner (the - end entity) signed by one CA, and zero or more additional - certificates of CAs signed by other CAs. Such chains, called - certification paths, are required because a public key user is only - initialized with a limited number of assured CA public keys. - - There are different ways in which CAs might be configured in order - for public key users to be able to find certification paths. For - PEM, RFC 1422 defined a rigid hierarchical structure of CAs. There - are three types of PEM certification authority: - - (a) Internet Policy Registration Authority (IPRA): This - authority, operated under the auspices of the Internet - Society, acts as the root of the PEM certification hierarchy - at level 1. It issues certificates only for the next level - of authorities, PCAs. All certification paths start with the - IPRA. - - (b) Policy Certification Authorities (PCAs): PCAs are at level 2 - of the hierarchy, each PCA being certified by the IPRA. A - PCA shall establish and publish a statement of its policy - with respect to certifying users or subordinate certification - authorities. Distinct PCAs aim to satisfy different user - needs. For example, one PCA (an organizational PCA) might - support the general electronic mail needs of commercial - organizations, and another PCA (a high-assurance PCA) might - have a more stringent policy designed for satisfying legally - binding digital signature requirements. - - (c) Certification Authorities (CAs): CAs are at level 3 of the - hierarchy and can also be at lower levels. Those at level 3 - are certified by PCAs. CAs represent, for example, - particular organizations, particular organizational units - (e.g., departments, groups, sections), or particular - geographical areas. - - RFC 1422 furthermore has a name subordination rule, which requires - that a CA can only issue certificates for entities whose names are - subordinate (in the X.500 naming tree) to the name of the CA itself. - The trust associated with a PEM certification path is implied by the - PCA name. The name subordination rule ensures that CAs below the PCA - are sensibly constrained as to the set of subordinate entities they - can certify (e.g., a CA for an organization can only certify entities - in that organization's name tree). Certificate user systems are able - to mechanically check that the name subordination rule has been - followed. - - - - - -Cooper, et al. Standards Track [Page 11] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - RFC 1422 uses the X.509 v1 certificate format. The limitations of - X.509 v1 required imposition of several structural restrictions to - clearly associate policy information or restrict the utility of - certificates. These restrictions included: - - (a) a pure top-down hierarchy, with all certification paths - starting from IPRA; - - (b) a naming subordination rule restricting the names of a CA's - subjects; and - - (c) use of the PCA concept, which requires knowledge of - individual PCAs to be built into certificate chain - verification logic. Knowledge of individual PCAs was - required to determine if a chain could be accepted. - - With X.509 v3, most of the requirements addressed by RFC 1422 can be - addressed using certificate extensions, without a need to restrict - the CA structures used. In particular, the certificate extensions - relating to certificate policies obviate the need for PCAs and the - constraint extensions obviate the need for the name subordination - rule. As a result, this document supports a more flexible - architecture, including: - - (a) Certification paths start with a public key of a CA in a - user's own domain, or with the public key of the top of a - hierarchy. Starting with the public key of a CA in a user's - own domain has certain advantages. In some environments, the - local domain is the most trusted. - - (b) Name constraints may be imposed through explicit inclusion of - a name constraints extension in a certificate, but are not - required. - - (c) Policy extensions and policy mappings replace the PCA - concept, which permits a greater degree of automation. The - application can determine if the certification path is - acceptable based on the contents of the certificates instead - of a priori knowledge of PCAs. This permits automation of - certification path processing. - - X.509 v3 also includes an extension that identifies the subject of a - certificate as being either a CA or an end entity, reducing the - reliance on out-of-band information demanded in PEM. - - This specification covers two classes of certificates: CA - certificates and end entity certificates. CA certificates may be - further divided into three classes: cross-certificates, self-issued - - - -Cooper, et al. Standards Track [Page 12] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - certificates, and self-signed certificates. Cross-certificates are - CA certificates in which the issuer and subject are different - entities. Cross-certificates describe a trust relationship between - the two CAs. Self-issued certificates are CA certificates in which - the issuer and subject are the same entity. Self-issued certificates - are generated to support changes in policy or operations. Self- - signed certificates are self-issued certificates where the digital - signature may be verified by the public key bound into the - certificate. Self-signed certificates are used to convey a public - key for use to begin certification paths. End entity certificates - are issued to subjects that are not authorized to issue certificates. - -3.3. Revocation - - When a certificate is issued, it is expected to be in use for its - entire validity period. However, various circumstances may cause a - certificate to become invalid prior to the expiration of the validity - period. Such circumstances include change of name, change of - association between subject and CA (e.g., an employee terminates - employment with an organization), and compromise or suspected - compromise of the corresponding private key. Under such - circumstances, the CA needs to revoke the certificate. - - X.509 defines one method of certificate revocation. This method - involves each CA periodically issuing a signed data structure called - a certificate revocation list (CRL). A CRL is a time-stamped list - identifying revoked certificates that is signed by a CA or CRL issuer - and made freely available in a public repository. Each revoked - certificate is identified in a CRL by its certificate serial number. - When a certificate-using system uses a certificate (e.g., for - verifying a remote user's digital signature), that system not only - checks the certificate signature and validity but also acquires a - suitably recent CRL and checks that the certificate serial number is - not on that CRL. The meaning of "suitably recent" may vary with - local policy, but it usually means the most recently issued CRL. A - new CRL is issued on a regular periodic basis (e.g., hourly, daily, - or weekly). An entry is added to the CRL as part of the next update - following notification of revocation. An entry MUST NOT be removed - from the CRL until it appears on one regularly scheduled CRL issued - beyond the revoked certificate's validity period. - - An advantage of this revocation method is that CRLs may be - distributed by exactly the same means as certificates themselves, - namely, via untrusted servers and untrusted communications. - - One limitation of the CRL revocation method, using untrusted - communications and servers, is that the time granularity of - revocation is limited to the CRL issue period. For example, if a - - - -Cooper, et al. Standards Track [Page 13] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - revocation is reported now, that revocation will not be reliably - notified to certificate-using systems until all currently issued CRLs - are scheduled to be updated -- this may be up to one hour, one day, - or one week depending on the frequency that CRLs are issued. - - As with the X.509 v3 certificate format, in order to facilitate - interoperable implementations from multiple vendors, the X.509 v2 CRL - format needs to be profiled for Internet use. It is one goal of this - document to specify that profile. However, this profile does not - require the issuance of CRLs. Message formats and protocols - supporting on-line revocation notification are defined in other PKIX - specifications. On-line methods of revocation notification may be - applicable in some environments as an alternative to the X.509 CRL. - On-line revocation checking may significantly reduce the latency - between a revocation report and the distribution of the information - to relying parties. Once the CA accepts a revocation report as - authentic and valid, any query to the on-line service will correctly - reflect the certificate validation impacts of the revocation. - However, these methods impose new security requirements: the - certificate validator needs to trust the on-line validation service - while the repository does not need to be trusted. - -3.4. Operational Protocols - - Operational protocols are required to deliver certificates and CRLs - (or status information) to certificate-using client systems. - Provisions are needed for a variety of different means of certificate - and CRL delivery, including distribution procedures based on LDAP, - HTTP, FTP, and X.500. Operational protocols supporting these - functions are defined in other PKIX specifications. These - specifications may include definitions of message formats and - procedures for supporting all of the above operational environments, - including definitions of or references to appropriate MIME content - types. - -3.5. Management Protocols - - Management protocols are required to support on-line interactions - between PKI user and management entities. For example, a management - protocol might be used between a CA and a client system with which a - key pair is associated, or between two CAs that cross-certify each - other. The set of functions that potentially need to be supported by - management protocols include: - - (a) registration: This is the process whereby a user first makes - itself known to a CA (directly, or through an RA), prior to - that CA issuing a certificate or certificates for that user. - - - - -Cooper, et al. Standards Track [Page 14] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (b) initialization: Before a client system can operate securely, - it is necessary to install key materials that have the - appropriate relationship with keys stored elsewhere in the - infrastructure. For example, the client needs to be securely - initialized with the public key and other assured information - of the trusted CA(s), to be used in validating certificate - paths. - - Furthermore, a client typically needs to be initialized with - its own key pair(s). - - (c) certification: This is the process in which a CA issues a - certificate for a user's public key, and returns that - certificate to the user's client system and/or posts that - certificate in a repository. - - (d) key pair recovery: As an option, user client key materials - (e.g., a user's private key used for encryption purposes) may - be backed up by a CA or a key backup system. If a user needs - to recover these backed-up key materials (e.g., as a result - of a forgotten password or a lost key chain file), an on-line - protocol exchange may be needed to support such recovery. - - (e) key pair update: All key pairs need to be updated regularly, - i.e., replaced with a new key pair, and new certificates - issued. - - (f) revocation request: An authorized person advises a CA of an - abnormal situation requiring certificate revocation. - - (g) cross-certification: Two CAs exchange information used in - establishing a cross-certificate. A cross-certificate is a - certificate issued by one CA to another CA that contains a CA - signature key used for issuing certificates. - - Note that on-line protocols are not the only way of implementing the - above functions. For all functions, there are off-line methods of - achieving the same result, and this specification does not mandate - use of on-line protocols. For example, when hardware tokens are - used, many of the functions may be achieved as part of the physical - token delivery. Furthermore, some of the above functions may be - combined into one protocol exchange. In particular, two or more of - the registration, initialization, and certification functions can be - combined into one protocol exchange. - - - - - - - -Cooper, et al. Standards Track [Page 15] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - The PKIX series of specifications defines a set of standard message - formats supporting the above functions. The protocols for conveying - these messages in different environments (e.g., email, file transfer, - and WWW) are described in those specifications. - -4. Certificate and Certificate Extensions Profile - - This section presents a profile for public key certificates that will - foster interoperability and a reusable PKI. This section is based - upon the X.509 v3 certificate format and the standard certificate - extensions defined in [X.509]. The ISO/IEC and ITU-T documents use - the 1997 version of ASN.1; while this document uses the 1988 ASN.1 - syntax, the encoded certificate and standard extensions are - equivalent. This section also defines private extensions required to - support a PKI for the Internet community. - - Certificates may be used in a wide range of applications and - environments covering a broad spectrum of interoperability goals and - a broader spectrum of operational and assurance requirements. The - goal of this document is to establish a common baseline for generic - applications requiring broad interoperability and limited special - purpose requirements. In particular, the emphasis will be on - supporting the use of X.509 v3 certificates for informal Internet - electronic mail, IPsec, and WWW applications. - -4.1. Basic Certificate Fields - - The X.509 v3 certificate basic syntax is as follows. For signature - calculation, the data that is to be signed is encoded using the ASN.1 - distinguished encoding rules (DER) [X.690]. ASN.1 DER encoding is a - tag, length, value encoding system for each element. - - Certificate ::= SEQUENCE { - tbsCertificate TBSCertificate, - signatureAlgorithm AlgorithmIdentifier, - signatureValue BIT STRING } - - TBSCertificate ::= SEQUENCE { - version [0] EXPLICIT Version DEFAULT v1, - serialNumber CertificateSerialNumber, - signature AlgorithmIdentifier, - issuer Name, - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo, - issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - - - - -Cooper, et al. Standards Track [Page 16] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - extensions [3] EXPLICIT Extensions OPTIONAL - -- If present, version MUST be v3 - } - - Version ::= INTEGER { v1(0), v2(1), v3(2) } - - CertificateSerialNumber ::= INTEGER - - Validity ::= SEQUENCE { - notBefore Time, - notAfter Time } - - Time ::= CHOICE { - utcTime UTCTime, - generalTime GeneralizedTime } - - UniqueIdentifier ::= BIT STRING - - SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING } - - Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension - - Extension ::= SEQUENCE { - extnID OBJECT IDENTIFIER, - critical BOOLEAN DEFAULT FALSE, - extnValue OCTET STRING - -- contains the DER encoding of an ASN.1 value - -- corresponding to the extension type identified - -- by extnID - } - - The following items describe the X.509 v3 certificate for use in the - Internet. - -4.1.1. Certificate Fields - - The Certificate is a SEQUENCE of three required fields. The fields - are described in detail in the following subsections. - - - - - - - - - -Cooper, et al. Standards Track [Page 17] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -4.1.1.1. tbsCertificate - - The field contains the names of the subject and issuer, a public key - associated with the subject, a validity period, and other associated - information. The fields are described in detail in Section 4.1.2; - the tbsCertificate usually includes extensions, which are described - in Section 4.2. - -4.1.1.2. signatureAlgorithm - - The signatureAlgorithm field contains the identifier for the - cryptographic algorithm used by the CA to sign this certificate. - [RFC3279], [RFC4055], and [RFC4491] list supported signature - algorithms, but other signature algorithms MAY also be supported. - - An algorithm identifier is defined by the following ASN.1 structure: - - AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL } - - The algorithm identifier is used to identify a cryptographic - algorithm. The OBJECT IDENTIFIER component identifies the algorithm - (such as DSA with SHA-1). The contents of the optional parameters - field will vary according to the algorithm identified. - - This field MUST contain the same algorithm identifier as the - signature field in the sequence tbsCertificate (Section 4.1.2.3). - -4.1.1.3. signatureValue - - The signatureValue field contains a digital signature computed upon - the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded - tbsCertificate is used as the input to the signature function. This - signature value is encoded as a BIT STRING and included in the - signature field. The details of this process are specified for each - of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491]. - - By generating this signature, a CA certifies the validity of the - information in the tbsCertificate field. In particular, the CA - certifies the binding between the public key material and the subject - of the certificate. - -4.1.2. TBSCertificate - - The sequence TBSCertificate contains information associated with the - subject of the certificate and the CA that issued it. Every - TBSCertificate contains the names of the subject and issuer, a public - - - -Cooper, et al. Standards Track [Page 18] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - key associated with the subject, a validity period, a version number, - and a serial number; some MAY contain optional unique identifier - fields. The remainder of this section describes the syntax and - semantics of these fields. A TBSCertificate usually includes - extensions. Extensions for the Internet PKI are described in Section - 4.2. - -4.1.2.1. Version - - This field describes the version of the encoded certificate. When - extensions are used, as expected in this profile, version MUST be 3 - (value is 2). If no extensions are present, but a UniqueIdentifier - is present, the version SHOULD be 2 (value is 1); however, the - version MAY be 3. If only basic fields are present, the version - SHOULD be 1 (the value is omitted from the certificate as the default - value); however, the version MAY be 2 or 3. - - Implementations SHOULD be prepared to accept any version certificate. - At a minimum, conforming implementations MUST recognize version 3 - certificates. - - Generation of version 2 certificates is not expected by - implementations based on this profile. - -4.1.2.2. Serial Number - - The serial number MUST be a positive integer assigned by the CA to - each certificate. It MUST be unique for each certificate issued by a - given CA (i.e., the issuer name and serial number identify a unique - certificate). CAs MUST force the serialNumber to be a non-negative - integer. - - Given the uniqueness requirements above, serial numbers can be - expected to contain long integers. Certificate users MUST be able to - handle serialNumber values up to 20 octets. Conforming CAs MUST NOT - use serialNumber values longer than 20 octets. - - Note: Non-conforming CAs may issue certificates with serial numbers - that are negative or zero. Certificate users SHOULD be prepared to - gracefully handle such certificates. - -4.1.2.3. Signature - - This field contains the algorithm identifier for the algorithm used - by the CA to sign the certificate. - - This field MUST contain the same algorithm identifier as the - signatureAlgorithm field in the sequence Certificate (Section - - - -Cooper, et al. Standards Track [Page 19] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 4.1.1.2). The contents of the optional parameters field will vary - according to the algorithm identified. [RFC3279], [RFC4055], and - [RFC4491] list supported signature algorithms, but other signature - algorithms MAY also be supported. - -4.1.2.4. Issuer - - The issuer field identifies the entity that has signed and issued the - certificate. The issuer field MUST contain a non-empty distinguished - name (DN). The issuer field is defined as the X.501 type Name - [X.501]. Name is defined by the following ASN.1 structures: - - Name ::= CHOICE { -- only one possibility for now -- - rdnSequence RDNSequence } - - RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - - RelativeDistinguishedName ::= - SET SIZE (1..MAX) OF AttributeTypeAndValue - - AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - - AttributeType ::= OBJECT IDENTIFIER - - AttributeValue ::= ANY -- DEFINED BY AttributeType - - DirectoryString ::= CHOICE { - teletexString TeletexString (SIZE (1..MAX)), - printableString PrintableString (SIZE (1..MAX)), - universalString UniversalString (SIZE (1..MAX)), - utf8String UTF8String (SIZE (1..MAX)), - bmpString BMPString (SIZE (1..MAX)) } - - The Name describes a hierarchical name composed of attributes, such - as country name, and corresponding values, such as US. The type of - the component AttributeValue is determined by the AttributeType; in - general it will be a DirectoryString. - - The DirectoryString type is defined as a choice of PrintableString, - TeletexString, BMPString, UTF8String, and UniversalString. CAs - conforming to this profile MUST use either the PrintableString or - UTF8String encoding of DirectoryString, with two exceptions. When - CAs have previously issued certificates with issuer fields with - attributes encoded using TeletexString, BMPString, or - UniversalString, then the CA MAY continue to use these encodings of - the DirectoryString to preserve backward compatibility. Also, new - - - -Cooper, et al. Standards Track [Page 20] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - CAs that are added to a domain where existing CAs issue certificates - with issuer fields with attributes encoded using TeletexString, - BMPString, or UniversalString MAY encode attributes that they share - with the existing CAs using the same encodings as the existing CAs - use. - - As noted above, distinguished names are composed of attributes. This - specification does not restrict the set of attribute types that may - appear in names. However, conforming implementations MUST be - prepared to receive certificates with issuer names containing the set - of attribute types defined below. This specification RECOMMENDS - support for additional attribute types. - - Standard sets of attributes have been defined in the X.500 series of - specifications [X.520]. Implementations of this specification MUST - be prepared to receive the following standard attribute types in - issuer and subject (Section 4.1.2.6) names: - - * country, - * organization, - * organizational unit, - * distinguished name qualifier, - * state or province name, - * common name (e.g., "Susan Housley"), and - * serial number. - - In addition, implementations of this specification SHOULD be prepared - to receive the following standard attribute types in issuer and - subject names: - - * locality, - * title, - * surname, - * given name, - * initials, - * pseudonym, and - * generation qualifier (e.g., "Jr.", "3rd", or "IV"). - - The syntax and associated object identifiers (OIDs) for these - attribute types are provided in the ASN.1 modules in Appendix A. - - In addition, implementations of this specification MUST be prepared - to receive the domainComponent attribute, as defined in [RFC4519]. - The Domain Name System (DNS) provides a hierarchical resource - labeling system. This attribute provides a convenient mechanism for - organizations that wish to use DNs that parallel their DNS names. - This is not a replacement for the dNSName component of the - alternative name extensions. Implementations are not required to - - - -Cooper, et al. Standards Track [Page 21] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - convert such names into DNS names. The syntax and associated OID for - this attribute type are provided in the ASN.1 modules in Appendix A. - Rules for encoding internationalized domain names for use with the - domainComponent attribute type are specified in Section 7.3. - - Certificate users MUST be prepared to process the issuer - distinguished name and subject distinguished name (Section 4.1.2.6) - fields to perform name chaining for certification path validation - (Section 6). Name chaining is performed by matching the issuer - distinguished name in one certificate with the subject name in a CA - certificate. Rules for comparing distinguished names are specified - in Section 7.1. If the names in the issuer and subject field in a - certificate match according to the rules specified in Section 7.1, - then the certificate is self-issued. - -4.1.2.5. Validity - - The certificate validity period is the time interval during which the - CA warrants that it will maintain information about the status of the - certificate. The field is represented as a SEQUENCE of two dates: - the date on which the certificate validity period begins (notBefore) - and the date on which the certificate validity period ends - (notAfter). Both notBefore and notAfter may be encoded as UTCTime or - GeneralizedTime. - - CAs conforming to this profile MUST always encode certificate - validity dates through the year 2049 as UTCTime; certificate validity - dates in 2050 or later MUST be encoded as GeneralizedTime. - Conforming applications MUST be able to process validity dates that - are encoded in either UTCTime or GeneralizedTime. - - The validity period for a certificate is the period of time from - notBefore through notAfter, inclusive. - - In some situations, devices are given certificates for which no good - expiration date can be assigned. For example, a device could be - issued a certificate that binds its model and serial number to its - public key; such a certificate is intended to be used for the entire - lifetime of the device. - - To indicate that a certificate has no well-defined expiration date, - the notAfter SHOULD be assigned the GeneralizedTime value of - 99991231235959Z. - - When the issuer will not be able to maintain status information until - the notAfter date (including when the notAfter date is - 99991231235959Z), the issuer MUST ensure that no valid certification - path exists for the certificate after maintenance of status - - - -Cooper, et al. Standards Track [Page 22] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - information is terminated. This may be accomplished by expiration or - revocation of all CA certificates containing the public key used to - verify the signature on the certificate and discontinuing use of the - public key used to verify the signature on the certificate as a trust - anchor. - -4.1.2.5.1. UTCTime - - The universal time type, UTCTime, is a standard ASN.1 type intended - for representation of dates and time. UTCTime specifies the year - through the two low-order digits and time is specified to the - precision of one minute or one second. UTCTime includes either Z - (for Zulu, or Greenwich Mean Time) or a time differential. - - For the purposes of this profile, UTCTime values MUST be expressed in - Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are - YYMMDDHHMMSSZ), even where the number of seconds is zero. Conforming - systems MUST interpret the year field (YY) as follows: - - Where YY is greater than or equal to 50, the year SHALL be - interpreted as 19YY; and - - Where YY is less than 50, the year SHALL be interpreted as 20YY. - -4.1.2.5.2. GeneralizedTime - - The generalized time type, GeneralizedTime, is a standard ASN.1 type - for variable precision representation of time. Optionally, the - GeneralizedTime field can include a representation of the time - differential between local and Greenwich Mean Time. - - For the purposes of this profile, GeneralizedTime values MUST be - expressed in Greenwich Mean Time (Zulu) and MUST include seconds - (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds - is zero. GeneralizedTime values MUST NOT include fractional seconds. - -4.1.2.6. Subject - - The subject field identifies the entity associated with the public - key stored in the subject public key field. The subject name MAY be - carried in the subject field and/or the subjectAltName extension. If - the subject is a CA (e.g., the basic constraints extension, as - discussed in Section 4.2.1.9, is present and the value of cA is - TRUE), then the subject field MUST be populated with a non-empty - distinguished name matching the contents of the issuer field (Section - 4.1.2.4) in all certificates issued by the subject CA. If the - subject is a CRL issuer (e.g., the key usage extension, as discussed - in Section 4.2.1.3, is present and the value of cRLSign is TRUE), - - - -Cooper, et al. Standards Track [Page 23] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - then the subject field MUST be populated with a non-empty - distinguished name matching the contents of the issuer field (Section - 5.1.2.3) in all CRLs issued by the subject CRL issuer. If subject - naming information is present only in the subjectAltName extension - (e.g., a key bound only to an email address or URI), then the subject - name MUST be an empty sequence and the subjectAltName extension MUST - be critical. - - Where it is non-empty, the subject field MUST contain an X.500 - distinguished name (DN). The DN MUST be unique for each subject - entity certified by the one CA as defined by the issuer field. A CA - MAY issue more than one certificate with the same DN to the same - subject entity. - - The subject field is defined as the X.501 type Name. Implementation - requirements for this field are those defined for the issuer field - (Section 4.1.2.4). Implementations of this specification MUST be - prepared to receive subject names containing the attribute types - required for the issuer field. Implementations of this specification - SHOULD be prepared to receive subject names containing the - recommended attribute types for the issuer field. The syntax and - associated object identifiers (OIDs) for these attribute types are - provided in the ASN.1 modules in Appendix A. Implementations of this - specification MAY use the comparison rules in Section 7.1 to process - unfamiliar attribute types (i.e., for name chaining) whose attribute - values use one of the encoding options from DirectoryString. Binary - comparison should be used when unfamiliar attribute types include - attribute values with encoding options other than those found in - DirectoryString. This allows implementations to process certificates - with unfamiliar attributes in the subject name. - - When encoding attribute values of type DirectoryString, conforming - CAs MUST use PrintableString or UTF8String encoding, with the - following exceptions: - - (a) When the subject of the certificate is a CA, the subject - field MUST be encoded in the same way as it is encoded in the - issuer field (Section 4.1.2.4) in all certificates issued by - the subject CA. Thus, if the subject CA encodes attributes - in the issuer fields of certificates that it issues using the - TeletexString, BMPString, or UniversalString encodings, then - the subject field of certificates issued to that CA MUST use - the same encoding. - - (b) When the subject of the certificate is a CRL issuer, the - subject field MUST be encoded in the same way as it is - encoded in the issuer field (Section 5.1.2.3) in all CRLs - issued by the subject CRL issuer. - - - -Cooper, et al. Standards Track [Page 24] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (c) TeletexString, BMPString, and UniversalString are included - for backward compatibility, and SHOULD NOT be used for - certificates for new subjects. However, these types MAY be - used in certificates where the name was previously - established, including cases in which a new certificate is - being issued to an existing subject or a certificate is being - issued to a new subject where the attributes being encoded - have been previously established in certificates issued to - other subjects. Certificate users SHOULD be prepared to - receive certificates with these types. - - Legacy implementations exist where an electronic mail address is - embedded in the subject distinguished name as an emailAddress - attribute [RFC2985]. The attribute value for emailAddress is of type - IA5String to permit inclusion of the character '@', which is not part - of the PrintableString character set. emailAddress attribute values - are not case-sensitive (e.g., "subscriber@example.com" is the same as - "SUBSCRIBER@EXAMPLE.COM"). - - Conforming implementations generating new certificates with - electronic mail addresses MUST use the rfc822Name in the subject - alternative name extension (Section 4.2.1.6) to describe such - identities. Simultaneous inclusion of the emailAddress attribute in - the subject distinguished name to support legacy implementations is - deprecated but permitted. - -4.1.2.7. Subject Public Key Info - - This field is used to carry the public key and identify the algorithm - with which the key is used (e.g., RSA, DSA, or Diffie-Hellman). The - algorithm is identified using the AlgorithmIdentifier structure - specified in Section 4.1.1.2. The object identifiers for the - supported algorithms and the methods for encoding the public key - materials (public key and parameters) are specified in [RFC3279], - [RFC4055], and [RFC4491]. - -4.1.2.8. Unique Identifiers - - These fields MUST only appear if the version is 2 or 3 (Section - 4.1.2.1). These fields MUST NOT appear if the version is 1. The - subject and issuer unique identifiers are present in the certificate - to handle the possibility of reuse of subject and/or issuer names - over time. This profile RECOMMENDS that names not be reused for - different entities and that Internet certificates not make use of - unique identifiers. CAs conforming to this profile MUST NOT generate - certificates with unique identifiers. Applications conforming to - - - - - -Cooper, et al. Standards Track [Page 25] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - this profile SHOULD be capable of parsing certificates that include - unique identifiers, but there are no processing requirements - associated with the unique identifiers. - -4.1.2.9. Extensions - - This field MUST only appear if the version is 3 (Section 4.1.2.1). - If present, this field is a SEQUENCE of one or more certificate - extensions. The format and content of certificate extensions in the - Internet PKI are defined in Section 4.2. - -4.2. Certificate Extensions - - The extensions defined for X.509 v3 certificates provide methods for - associating additional attributes with users or public keys and for - managing relationships between CAs. The X.509 v3 certificate format - also allows communities to define private extensions to carry - information unique to those communities. Each extension in a - certificate is designated as either critical or non-critical. A - certificate-using system MUST reject the certificate if it encounters - a critical extension it does not recognize or a critical extension - that contains information that it cannot process. A non-critical - extension MAY be ignored if it is not recognized, but MUST be - processed if it is recognized. The following sections present - recommended extensions used within Internet certificates and standard - locations for information. Communities may elect to use additional - extensions; however, caution ought to be exercised in adopting any - critical extensions in certificates that might prevent use in a - general context. - - Each extension includes an OID and an ASN.1 structure. When an - extension appears in a certificate, the OID appears as the field - extnID and the corresponding ASN.1 DER encoded structure is the value - of the octet string extnValue. A certificate MUST NOT include more - than one instance of a particular extension. For example, a - certificate may contain only one authority key identifier extension - (Section 4.2.1.1). An extension includes the boolean critical, with - a default value of FALSE. The text for each extension specifies the - acceptable values for the critical field for CAs conforming to this - profile. - - Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and - 4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section - 4.2.1.3), and certificate policies (Section 4.2.1.4) extensions. If - the CA issues certificates with an empty sequence for the subject - field, the CA MUST support the subject alternative name extension - (Section 4.2.1.6). Support for the remaining extensions is OPTIONAL. - Conforming CAs MAY support extensions that are not identified within - - - -Cooper, et al. Standards Track [Page 26] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - this specification; certificate issuers are cautioned that marking - such extensions as critical may inhibit interoperability. - - At a minimum, applications conforming to this profile MUST recognize - the following extensions: key usage (Section 4.2.1.3), certificate - policies (Section 4.2.1.4), subject alternative name (Section - 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints - (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended - key usage (Section 4.2.1.12), and inhibit anyPolicy (Section - 4.2.1.14). - - In addition, applications conforming to this profile SHOULD recognize - the authority and subject key identifier (Sections 4.2.1.1 and - 4.2.1.2) and policy mappings (Section 4.2.1.5) extensions. - -4.2.1. Standard Extensions - - This section identifies standard certificate extensions defined in - [X.509] for use in the Internet PKI. Each extension is associated - with an OID defined in [X.509]. These OIDs are members of the id-ce - arc, which is defined by the following: - - id-ce OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 29 } - -4.2.1.1. Authority Key Identifier - - The authority key identifier extension provides a means of - identifying the public key corresponding to the private key used to - sign a certificate. This extension is used where an issuer has - multiple signing keys (either due to multiple concurrent key pairs or - due to changeover). The identification MAY be based on either the - key identifier (the subject key identifier in the issuer's - certificate) or the issuer name and serial number. - - The keyIdentifier field of the authorityKeyIdentifier extension MUST - be included in all certificates generated by conforming CAs to - facilitate certification path construction. There is one exception; - where a CA distributes its public key in the form of a "self-signed" - certificate, the authority key identifier MAY be omitted. The - signature on a self-signed certificate is generated with the private - key associated with the certificate's subject public key. (This - proves that the issuer possesses both the public and private keys.) - In this case, the subject and authority key identifiers would be - identical, but only the subject key identifier is needed for - certification path building. - - The value of the keyIdentifier field SHOULD be derived from the - public key used to verify the certificate's signature or a method - - - -Cooper, et al. Standards Track [Page 27] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - that generates unique values. Two common methods for generating key - identifiers from the public key are described in Section 4.2.1.2. - Where a key identifier has not been previously established, this - specification RECOMMENDS use of one of these methods for generating - keyIdentifiers or use of a similar method that uses a different hash - algorithm. Where a key identifier has been previously established, - the CA SHOULD use the previously established identifier. - - This profile RECOMMENDS support for the key identifier method by all - certificate users. - - Conforming CAs MUST mark this extension as non-critical. - - id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } - - AuthorityKeyIdentifier ::= SEQUENCE { - keyIdentifier [0] KeyIdentifier OPTIONAL, - authorityCertIssuer [1] GeneralNames OPTIONAL, - authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } - - KeyIdentifier ::= OCTET STRING - -4.2.1.2. Subject Key Identifier - - The subject key identifier extension provides a means of identifying - certificates that contain a particular public key. - - To facilitate certification path construction, this extension MUST - appear in all conforming CA certificates, that is, all certificates - including the basic constraints extension (Section 4.2.1.9) where the - value of cA is TRUE. In conforming CA certificates, the value of the - subject key identifier MUST be the value placed in the key identifier - field of the authority key identifier extension (Section 4.2.1.1) of - certificates issued by the subject of this certificate. Applications - are not required to verify that key identifiers match when performing - certification path validation. - - For CA certificates, subject key identifiers SHOULD be derived from - the public key or a method that generates unique values. Two common - methods for generating key identifiers from the public key are: - - (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the - value of the BIT STRING subjectPublicKey (excluding the tag, - length, and number of unused bits). - - - - - - - -Cooper, et al. Standards Track [Page 28] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (2) The keyIdentifier is composed of a four-bit type field with - the value 0100 followed by the least significant 60 bits of - the SHA-1 hash of the value of the BIT STRING - subjectPublicKey (excluding the tag, length, and number of - unused bits). - - Other methods of generating unique numbers are also acceptable. - - For end entity certificates, the subject key identifier extension - provides a means for identifying certificates containing the - particular public key used in an application. Where an end entity - has obtained multiple certificates, especially from multiple CAs, the - subject key identifier provides a means to quickly identify the set - of certificates containing a particular public key. To assist - applications in identifying the appropriate end entity certificate, - this extension SHOULD be included in all end entity certificates. - - For end entity certificates, subject key identifiers SHOULD be - derived from the public key. Two common methods for generating key - identifiers from the public key are identified above. - - Where a key identifier has not been previously established, this - specification RECOMMENDS use of one of these methods for generating - keyIdentifiers or use of a similar method that uses a different hash - algorithm. Where a key identifier has been previously established, - the CA SHOULD use the previously established identifier. - - Conforming CAs MUST mark this extension as non-critical. - - id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } - - SubjectKeyIdentifier ::= KeyIdentifier - -4.2.1.3. Key Usage - - The key usage extension defines the purpose (e.g., encipherment, - signature, certificate signing) of the key contained in the - certificate. The usage restriction might be employed when a key that - could be used for more than one operation is to be restricted. For - example, when an RSA key should be used only to verify signatures on - objects other than public key certificates and CRLs, the - digitalSignature and/or nonRepudiation bits would be asserted. - Likewise, when an RSA key should be used only for key management, the - keyEncipherment bit would be asserted. - - - - - - - -Cooper, et al. Standards Track [Page 29] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Conforming CAs MUST include this extension in certificates that - contain public keys that are used to validate digital signatures on - other public key certificates or CRLs. When present, conforming CAs - SHOULD mark this extension as critical. - - id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } - - KeyUsage ::= BIT STRING { - digitalSignature (0), - nonRepudiation (1), -- recent editions of X.509 have - -- renamed this bit to contentCommitment - keyEncipherment (2), - dataEncipherment (3), - keyAgreement (4), - keyCertSign (5), - cRLSign (6), - encipherOnly (7), - decipherOnly (8) } - - Bits in the KeyUsage type are used as follows: - - The digitalSignature bit is asserted when the subject public key - is used for verifying digital signatures, other than signatures on - certificates (bit 5) and CRLs (bit 6), such as those used in an - entity authentication service, a data origin authentication - service, and/or an integrity service. - - The nonRepudiation bit is asserted when the subject public key is - used to verify digital signatures, other than signatures on - certificates (bit 5) and CRLs (bit 6), used to provide a non- - repudiation service that protects against the signing entity - falsely denying some action. In the case of later conflict, a - reliable third party may determine the authenticity of the signed - data. (Note that recent editions of X.509 have renamed the - nonRepudiation bit to contentCommitment.) - - The keyEncipherment bit is asserted when the subject public key is - used for enciphering private or secret keys, i.e., for key - transport. For example, this bit shall be set when an RSA public - key is to be used for encrypting a symmetric content-decryption - key or an asymmetric private key. - - The dataEncipherment bit is asserted when the subject public key - is used for directly enciphering raw user data without the use of - an intermediate symmetric cipher. Note that the use of this bit - is extremely uncommon; almost all applications use key transport - or key agreement to establish a symmetric key. - - - - -Cooper, et al. Standards Track [Page 30] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - The keyAgreement bit is asserted when the subject public key is - used for key agreement. For example, when a Diffie-Hellman key is - to be used for key management, then this bit is set. - - The keyCertSign bit is asserted when the subject public key is - used for verifying signatures on public key certificates. If the - keyCertSign bit is asserted, then the cA bit in the basic - constraints extension (Section 4.2.1.9) MUST also be asserted. - - The cRLSign bit is asserted when the subject public key is used - for verifying signatures on certificate revocation lists (e.g., - CRLs, delta CRLs, or ARLs). - - The meaning of the encipherOnly bit is undefined in the absence of - the keyAgreement bit. When the encipherOnly bit is asserted and - the keyAgreement bit is also set, the subject public key may be - used only for enciphering data while performing key agreement. - - The meaning of the decipherOnly bit is undefined in the absence of - the keyAgreement bit. When the decipherOnly bit is asserted and - the keyAgreement bit is also set, the subject public key may be - used only for deciphering data while performing key agreement. - - If the keyUsage extension is present, then the subject public key - MUST NOT be used to verify signatures on certificates or CRLs unless - the corresponding keyCertSign or cRLSign bit is set. If the subject - public key is only to be used for verifying signatures on - certificates and/or CRLs, then the digitalSignature and - nonRepudiation bits SHOULD NOT be set. However, the digitalSignature - and/or nonRepudiation bits MAY be set in addition to the keyCertSign - and/or cRLSign bits if the subject public key is to be used to verify - signatures on certificates and/or CRLs as well as other objects. - - Combining the nonRepudiation bit in the keyUsage certificate - extension with other keyUsage bits may have security implications - depending on the context in which the certificate is to be used. - Further distinctions between the digitalSignature and nonRepudiation - bits may be provided in specific certificate policies. - - This profile does not restrict the combinations of bits that may be - set in an instantiation of the keyUsage extension. However, - appropriate values for keyUsage extensions for particular algorithms - are specified in [RFC3279], [RFC4055], and [RFC4491]. When the - keyUsage extension appears in a certificate, at least one of the bits - MUST be set to 1. - - - - - - -Cooper, et al. Standards Track [Page 31] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -4.2.1.4. Certificate Policies - - The certificate policies extension contains a sequence of one or more - policy information terms, each of which consists of an object - identifier (OID) and optional qualifiers. Optional qualifiers, which - MAY be present, are not expected to change the definition of the - policy. A certificate policy OID MUST NOT appear more than once in a - certificate policies extension. - - In an end entity certificate, these policy information terms indicate - the policy under which the certificate has been issued and the - purposes for which the certificate may be used. In a CA certificate, - these policy information terms limit the set of policies for - certification paths that include this certificate. When a CA does - not wish to limit the set of policies for certification paths that - include this certificate, it MAY assert the special policy anyPolicy, - with a value of { 2 5 29 32 0 }. - - Applications with specific policy requirements are expected to have a - list of those policies that they will accept and to compare the - policy OIDs in the certificate to that list. If this extension is - critical, the path validation software MUST be able to interpret this - extension (including the optional qualifier), or MUST reject the - certificate. - - To promote interoperability, this profile RECOMMENDS that policy - information terms consist of only an OID. Where an OID alone is - insufficient, this profile strongly recommends that the use of - qualifiers be limited to those identified in this section. When - qualifiers are used with the special policy anyPolicy, they MUST be - limited to the qualifiers identified in this section. Only those - qualifiers returned as a result of path validation are considered. - - This specification defines two policy qualifier types for use by - certificate policy writers and certificate issuers. The qualifier - types are the CPS Pointer and User Notice qualifiers. - - The CPS Pointer qualifier contains a pointer to a Certification - Practice Statement (CPS) published by the CA. The pointer is in the - form of a URI. Processing requirements for this qualifier are a - local matter. No action is mandated by this specification regardless - of the criticality value asserted for the extension. - - User notice is intended for display to a relying party when a - certificate is used. Only user notices returned as a result of path - validation are intended for display to the user. If a notice is - - - - - -Cooper, et al. Standards Track [Page 32] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - duplicated, only one copy need be displayed. To prevent such - duplication, this qualifier SHOULD only be present in end entity - certificates and CA certificates issued to other organizations. - - The user notice has two optional fields: the noticeRef field and the - explicitText field. Conforming CAs SHOULD NOT use the noticeRef - option. - - The noticeRef field, if used, names an organization and - identifies, by number, a particular textual statement prepared by - that organization. For example, it might identify the - organization "CertsRUs" and notice number 1. In a typical - implementation, the application software will have a notice file - containing the current set of notices for CertsRUs; the - application will extract the notice text from the file and display - it. Messages MAY be multilingual, allowing the software to select - the particular language message for its own environment. - - An explicitText field includes the textual statement directly in - the certificate. The explicitText field is a string with a - maximum size of 200 characters. Conforming CAs SHOULD use the - UTF8String encoding for explicitText, but MAY use IA5String. - Conforming CAs MUST NOT encode explicitText as VisibleString or - BMPString. The explicitText string SHOULD NOT include any control - characters (e.g., U+0000 to U+001F and U+007F to U+009F). When - the UTF8String encoding is used, all character sequences SHOULD be - normalized according to Unicode normalization form C (NFC) [NFC]. - - If both the noticeRef and explicitText options are included in the - one qualifier and if the application software can locate the notice - text indicated by the noticeRef option, then that text SHOULD be - displayed; otherwise, the explicitText string SHOULD be displayed. - - Note: While the explicitText has a maximum size of 200 characters, - some non-conforming CAs exceed this limit. Therefore, certificate - users SHOULD gracefully handle explicitText with more than 200 - characters. - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 33] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } - - anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } - - certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation - - PolicyInformation ::= SEQUENCE { - policyIdentifier CertPolicyId, - policyQualifiers SEQUENCE SIZE (1..MAX) OF - PolicyQualifierInfo OPTIONAL } - - CertPolicyId ::= OBJECT IDENTIFIER - - PolicyQualifierInfo ::= SEQUENCE { - policyQualifierId PolicyQualifierId, - qualifier ANY DEFINED BY policyQualifierId } - - -- policyQualifierIds for Internet policy qualifiers - - id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } - id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } - id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } - - PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) - - Qualifier ::= CHOICE { - cPSuri CPSuri, - userNotice UserNotice } - - CPSuri ::= IA5String - - UserNotice ::= SEQUENCE { - noticeRef NoticeReference OPTIONAL, - explicitText DisplayText OPTIONAL } - - NoticeReference ::= SEQUENCE { - organization DisplayText, - noticeNumbers SEQUENCE OF INTEGER } - - DisplayText ::= CHOICE { - ia5String IA5String (SIZE (1..200)), - visibleString VisibleString (SIZE (1..200)), - bmpString BMPString (SIZE (1..200)), - utf8String UTF8String (SIZE (1..200)) } - - - - - - - -Cooper, et al. Standards Track [Page 34] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -4.2.1.5. Policy Mappings - - This extension is used in CA certificates. It lists one or more - pairs of OIDs; each pair includes an issuerDomainPolicy and a - subjectDomainPolicy. The pairing indicates the issuing CA considers - its issuerDomainPolicy equivalent to the subject CA's - subjectDomainPolicy. - - The issuing CA's users might accept an issuerDomainPolicy for certain - applications. The policy mapping defines the list of policies - associated with the subject CA that may be accepted as comparable to - the issuerDomainPolicy. - - Each issuerDomainPolicy named in the policy mappings extension SHOULD - also be asserted in a certificate policies extension in the same - certificate. Policies MUST NOT be mapped either to or from the - special value anyPolicy (Section 4.2.1.4). - - In general, certificate policies that appear in the - issuerDomainPolicy field of the policy mappings extension are not - considered acceptable policies for inclusion in subsequent - certificates in the certification path. In some circumstances, a CA - may wish to map from one policy (p1) to another (p2), but still wants - the issuerDomainPolicy (p1) to be considered acceptable for inclusion - in subsequent certificates. This may occur, for example, if the CA - is in the process of transitioning from the use of policy p1 to the - use of policy p2 and has valid certificates that were issued under - each of the policies. A CA may indicate this by including two policy - mappings in the CA certificates that it issues. Each policy mapping - would have an issuerDomainPolicy of p1; one policy mapping would have - a subjectDomainPolicy of p1 and the other would have a - subjectDomainPolicy of p2. - - This extension MAY be supported by CAs and/or applications. - Conforming CAs SHOULD mark this extension as critical. - - id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } - - PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - issuerDomainPolicy CertPolicyId, - subjectDomainPolicy CertPolicyId } - -4.2.1.6. Subject Alternative Name - - The subject alternative name extension allows identities to be bound - to the subject of the certificate. These identities may be included - in addition to or in place of the identity in the subject field of - the certificate. Defined options include an Internet electronic mail - - - -Cooper, et al. Standards Track [Page 35] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - address, a DNS name, an IP address, and a Uniform Resource Identifier - (URI). Other options exist, including completely local definitions. - Multiple name forms, and multiple instances of each name form, MAY be - included. Whenever such identities are to be bound into a - certificate, the subject alternative name (or issuer alternative - name) extension MUST be used; however, a DNS name MAY also be - represented in the subject field using the domainComponent attribute - as described in Section 4.1.2.4. Note that where such names are - represented in the subject field implementations are not required to - convert them into DNS names. - - Because the subject alternative name is considered to be definitively - bound to the public key, all parts of the subject alternative name - MUST be verified by the CA. - - Further, if the only subject identity included in the certificate is - an alternative name form (e.g., an electronic mail address), then the - subject distinguished name MUST be empty (an empty sequence), and the - subjectAltName extension MUST be present. If the subject field - contains an empty sequence, then the issuing CA MUST include a - subjectAltName extension that is marked as critical. When including - the subjectAltName extension in a certificate that has a non-empty - subject distinguished name, conforming CAs SHOULD mark the - subjectAltName extension as non-critical. - - When the subjectAltName extension contains an Internet mail address, - the address MUST be stored in the rfc822Name. The format of an - rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821]. - A Mailbox has the form "Local-part@Domain". Note that a Mailbox has - no phrase (such as a common name) before it, has no comment (text - surrounded in parentheses) after it, and is not surrounded by "<" and - ">". Rules for encoding Internet mail addresses that include - internationalized domain names are specified in Section 7.5. - - When the subjectAltName extension contains an iPAddress, the address - MUST be stored in the octet string in "network byte order", as - specified in [RFC791]. The least significant bit (LSB) of each octet - is the LSB of the corresponding byte in the network address. For IP - version 4, as specified in [RFC791], the octet string MUST contain - exactly four octets. For IP version 6, as specified in - [RFC2460], the octet string MUST contain exactly sixteen octets. - - When the subjectAltName extension contains a domain name system - label, the domain name MUST be stored in the dNSName (an IA5String). - The name MUST be in the "preferred name syntax", as specified by - Section 3.5 of [RFC1034] and as modified by Section 2.1 of - [RFC1123]. Note that while uppercase and lowercase letters are - allowed in domain names, no significance is attached to the case. In - - - -Cooper, et al. Standards Track [Page 36] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - addition, while the string " " is a legal domain name, subjectAltName - extensions with a dNSName of " " MUST NOT be used. Finally, the use - of the DNS representation for Internet mail addresses - (subscriber.example.com instead of subscriber@example.com) MUST NOT - be used; such identities are to be encoded as rfc822Name. Rules for - encoding internationalized domain names are specified in Section 7.2. - - When the subjectAltName extension contains a URI, the name MUST be - stored in the uniformResourceIdentifier (an IA5String). The name - MUST NOT be a relative URI, and it MUST follow the URI syntax and - encoding rules specified in [RFC3986]. The name MUST include both a - scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that - include an authority ([RFC3986], Section 3.2) MUST include a fully - qualified domain name or IP address as the host. Rules for encoding - Internationalized Resource Identifiers (IRIs) are specified in - Section 7.4. - - As specified in [RFC3986], the scheme name is not case-sensitive - (e.g., "http" is equivalent to "HTTP"). The host part, if present, - is also not case-sensitive, but other components of the scheme- - specific-part may be case-sensitive. Rules for comparing URIs are - specified in Section 7.4. - - When the subjectAltName extension contains a DN in the directoryName, - the encoding rules are the same as those specified for the issuer - field in Section 4.1.2.4. The DN MUST be unique for each subject - entity certified by the one CA as defined by the issuer field. A CA - MAY issue more than one certificate with the same DN to the same - subject entity. - - The subjectAltName MAY carry additional name types through the use of - the otherName field. The format and semantics of the name are - indicated through the OBJECT IDENTIFIER in the type-id field. The - name itself is conveyed as value field in otherName. For example, - Kerberos [RFC4120] format names can be encoded into the otherName, - using a Kerberos 5 principal name OID and a SEQUENCE of the Realm and - the PrincipalName. - - Subject alternative names MAY be constrained in the same manner as - subject distinguished names using the name constraints extension as - described in Section 4.2.1.10. - - If the subjectAltName extension is present, the sequence MUST contain - at least one entry. Unlike the subject field, conforming CAs MUST - NOT issue certificates with subjectAltNames containing empty - GeneralName fields. For example, an rfc822Name is represented as an - IA5String. While an empty string is a valid IA5String, such an - rfc822Name is not permitted by this profile. The behavior of clients - - - -Cooper, et al. Standards Track [Page 37] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - that encounter such a certificate when processing a certification - path is not defined by this profile. - - Finally, the semantics of subject alternative names that include - wildcard characters (e.g., as a placeholder for a set of names) are - not addressed by this specification. Applications with specific - requirements MAY use such names, but they must define the semantics. - - id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } - - SubjectAltName ::= GeneralNames - - GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName - - GeneralName ::= CHOICE { - otherName [0] OtherName, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] ORAddress, - directoryName [4] Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER } - - OtherName ::= SEQUENCE { - type-id OBJECT IDENTIFIER, - value [0] EXPLICIT ANY DEFINED BY type-id } - - EDIPartyName ::= SEQUENCE { - nameAssigner [0] DirectoryString OPTIONAL, - partyName [1] DirectoryString } - -4.2.1.7. Issuer Alternative Name - - As with Section 4.2.1.6, this extension is used to associate Internet - style identities with the certificate issuer. Issuer alternative - name MUST be encoded as in 4.2.1.6. Issuer alternative names are not - processed as part of the certification path validation algorithm in - Section 6. (That is, issuer alternative names are not used in name - chaining and name constraints are not enforced.) - - Where present, conforming CAs SHOULD mark this extension as non- - critical. - - id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } - - IssuerAltName ::= GeneralNames - - - -Cooper, et al. Standards Track [Page 38] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -4.2.1.8. Subject Directory Attributes - - The subject directory attributes extension is used to convey - identification attributes (e.g., nationality) of the subject. The - extension is defined as a sequence of one or more attributes. - Conforming CAs MUST mark this extension as non-critical. - - id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } - - SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute - -4.2.1.9. Basic Constraints - - The basic constraints extension identifies whether the subject of the - certificate is a CA and the maximum depth of valid certification - paths that include this certificate. - - The cA boolean indicates whether the certified public key may be used - to verify certificate signatures. If the cA boolean is not asserted, - then the keyCertSign bit in the key usage extension MUST NOT be - asserted. If the basic constraints extension is not present in a - version 3 certificate, or the extension is present but the cA boolean - is not asserted, then the certified public key MUST NOT be used to - verify certificate signatures. - - The pathLenConstraint field is meaningful only if the cA boolean is - asserted and the key usage extension, if present, asserts the - keyCertSign bit (Section 4.2.1.3). In this case, it gives the - maximum number of non-self-issued intermediate certificates that may - follow this certificate in a valid certification path. (Note: The - last certificate in the certification path is not an intermediate - certificate, and is not included in this limit. Usually, the last - certificate is an end entity certificate, but it can be a CA - certificate.) A pathLenConstraint of zero indicates that no non- - self-issued intermediate CA certificates may follow in a valid - certification path. Where it appears, the pathLenConstraint field - MUST be greater than or equal to zero. Where pathLenConstraint does - not appear, no limit is imposed. - - Conforming CAs MUST include this extension in all CA certificates - that contain public keys used to validate digital signatures on - certificates and MUST mark the extension as critical in such - certificates. This extension MAY appear as a critical or non- - critical extension in CA certificates that contain public keys used - exclusively for purposes other than validating digital signatures on - certificates. Such CA certificates include ones that contain public - keys used exclusively for validating digital signatures on CRLs and - ones that contain key management public keys used with certificate - - - -Cooper, et al. Standards Track [Page 39] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - enrollment protocols. This extension MAY appear as a critical or - non-critical extension in end entity certificates. - - CAs MUST NOT include the pathLenConstraint field unless the cA - boolean is asserted and the key usage extension asserts the - keyCertSign bit. - - id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } - - BasicConstraints ::= SEQUENCE { - cA BOOLEAN DEFAULT FALSE, - pathLenConstraint INTEGER (0..MAX) OPTIONAL } - -4.2.1.10. Name Constraints - - The name constraints extension, which MUST be used only in a CA - certificate, indicates a name space within which all subject names in - subsequent certificates in a certification path MUST be located. - Restrictions apply to the subject distinguished name and apply to - subject alternative names. Restrictions apply only when the - specified name form is present. If no name of the type is in the - certificate, the certificate is acceptable. - - Name constraints are not applied to self-issued certificates (unless - the certificate is the final certificate in the path). (This could - prevent CAs that use name constraints from employing self-issued - certificates to implement key rollover.) - - Restrictions are defined in terms of permitted or excluded name - subtrees. Any name matching a restriction in the excludedSubtrees - field is invalid regardless of information appearing in the - permittedSubtrees. Conforming CAs MUST mark this extension as - critical and SHOULD NOT impose name constraints on the x400Address, - ediPartyName, or registeredID name forms. Conforming CAs MUST NOT - issue certificates where name constraints is an empty sequence. That - is, either the permittedSubtrees field or the excludedSubtrees MUST - be present. - - Applications conforming to this profile MUST be able to process name - constraints that are imposed on the directoryName name form and - SHOULD be able to process name constraints that are imposed on the - rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name - forms. If a name constraints extension that is marked as critical - imposes constraints on a particular name form, and an instance of - that name form appears in the subject field or subjectAltName - extension of a subsequent certificate, then the application MUST - either process the constraint or reject the certificate. - - - - -Cooper, et al. Standards Track [Page 40] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Within this profile, the minimum and maximum fields are not used with - any name forms, thus, the minimum MUST be zero, and maximum MUST be - absent. However, if an application encounters a critical name - constraints extension that specifies other values for minimum or - maximum for a name form that appears in a subsequent certificate, the - application MUST either process these fields or reject the - certificate. - - For URIs, the constraint applies to the host part of the name. The - constraint MUST be specified as a fully qualified domain name and MAY - specify a host or a domain. Examples would be "host.example.com" and - ".example.com". When the constraint begins with a period, it MAY be - expanded with one or more labels. That is, the constraint - ".example.com" is satisfied by both host.example.com and - my.host.example.com. However, the constraint ".example.com" is not - satisfied by "example.com". When the constraint does not begin with - a period, it specifies a host. If a constraint is applied to the - uniformResourceIdentifier name form and a subsequent certificate - includes a subjectAltName extension with a uniformResourceIdentifier - that does not include an authority component with a host name - specified as a fully qualified domain name (e.g., if the URI either - does not include an authority component or includes an authority - component in which the host name is specified as an IP address), then - the application MUST reject the certificate. - - A name constraint for Internet mail addresses MAY specify a - particular mailbox, all addresses at a particular host, or all - mailboxes in a domain. To indicate a particular mailbox, the - constraint is the complete mail address. For example, - "root@example.com" indicates the root mailbox on the host - "example.com". To indicate all Internet mail addresses on a - particular host, the constraint is specified as the host name. For - example, the constraint "example.com" is satisfied by any mail - address at the host "example.com". To specify any address within a - domain, the constraint is specified with a leading period (as with - URIs). For example, ".example.com" indicates all the Internet mail - addresses in the domain "example.com", but not Internet mail - addresses on the host "example.com". - - DNS name restrictions are expressed as host.example.com. Any DNS - name that can be constructed by simply adding zero or more labels to - the left-hand side of the name satisfies the name constraint. For - example, www.host.example.com would satisfy the constraint but - host1.example.com would not. - - Legacy implementations exist where an electronic mail address is - embedded in the subject distinguished name in an attribute of type - emailAddress (Section 4.1.2.6). When constraints are imposed on the - - - -Cooper, et al. Standards Track [Page 41] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - rfc822Name name form, but the certificate does not include a subject - alternative name, the rfc822Name constraint MUST be applied to the - attribute of type emailAddress in the subject distinguished name. - The ASN.1 syntax for emailAddress and the corresponding OID are - supplied in Appendix A. - - Restrictions of the form directoryName MUST be applied to the subject - field in the certificate (when the certificate includes a non-empty - subject field) and to any names of type directoryName in the - subjectAltName extension. Restrictions of the form x400Address MUST - be applied to any names of type x400Address in the subjectAltName - extension. - - When applying restrictions of the form directoryName, an - implementation MUST compare DN attributes. At a minimum, - implementations MUST perform the DN comparison rules specified in - Section 7.1. CAs issuing certificates with a restriction of the form - directoryName SHOULD NOT rely on implementation of the full ISO DN - name comparison algorithm. This implies name restrictions MUST be - stated identically to the encoding used in the subject field or - subjectAltName extension. - - The syntax of iPAddress MUST be as described in Section 4.2.1.6 with - the following additions specifically for name constraints. For IPv4 - addresses, the iPAddress field of GeneralName MUST contain eight (8) - octets, encoded in the style of RFC 4632 (CIDR) to represent an - address range [RFC4632]. For IPv6 addresses, the iPAddress field - MUST contain 32 octets similarly encoded. For example, a name - constraint for "class C" subnet 192.0.2.0 is represented as the - octets C0 00 02 00 FF FF FF 00, representing the CIDR notation - 192.0.2.0/24 (mask 255.255.255.0). - - Additional rules for encoding and processing name constraints are - specified in Section 7. - - The syntax and semantics for name constraints for otherName, - ediPartyName, and registeredID are not defined by this specification, - however, syntax and semantics for name constraints for other name - forms may be specified in other documents. - - id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } - - NameConstraints ::= SEQUENCE { - permittedSubtrees [0] GeneralSubtrees OPTIONAL, - excludedSubtrees [1] GeneralSubtrees OPTIONAL } - - GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree - - - - -Cooper, et al. Standards Track [Page 42] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - GeneralSubtree ::= SEQUENCE { - base GeneralName, - minimum [0] BaseDistance DEFAULT 0, - maximum [1] BaseDistance OPTIONAL } - - BaseDistance ::= INTEGER (0..MAX) - -4.2.1.11. Policy Constraints - - The policy constraints extension can be used in certificates issued - to CAs. The policy constraints extension constrains path validation - in two ways. It can be used to prohibit policy mapping or require - that each certificate in a path contain an acceptable policy - identifier. - - If the inhibitPolicyMapping field is present, the value indicates the - number of additional certificates that may appear in the path before - policy mapping is no longer permitted. For example, a value of one - indicates that policy mapping may be processed in certificates issued - by the subject of this certificate, but not in additional - certificates in the path. - - If the requireExplicitPolicy field is present, the value of - requireExplicitPolicy indicates the number of additional certificates - that may appear in the path before an explicit policy is required for - the entire path. When an explicit policy is required, it is - necessary for all certificates in the path to contain an acceptable - policy identifier in the certificate policies extension. An - acceptable policy identifier is the identifier of a policy required - by the user of the certification path or the identifier of a policy - that has been declared equivalent through policy mapping. - - Conforming applications MUST be able to process the - requireExplicitPolicy field and SHOULD be able to process the - inhibitPolicyMapping field. Applications that support the - inhibitPolicyMapping field MUST also implement support for the - policyMappings extension. If the policyConstraints extension is - marked as critical and the inhibitPolicyMapping field is present, - applications that do not implement support for the - inhibitPolicyMapping field MUST reject the certificate. - - Conforming CAs MUST NOT issue certificates where policy constraints - is an empty sequence. That is, either the inhibitPolicyMapping field - or the requireExplicitPolicy field MUST be present. The behavior of - clients that encounter an empty policy constraints field is not - addressed in this profile. - - Conforming CAs MUST mark this extension as critical. - - - -Cooper, et al. Standards Track [Page 43] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } - - PolicyConstraints ::= SEQUENCE { - requireExplicitPolicy [0] SkipCerts OPTIONAL, - inhibitPolicyMapping [1] SkipCerts OPTIONAL } - - SkipCerts ::= INTEGER (0..MAX) - -4.2.1.12. Extended Key Usage - - This extension indicates one or more purposes for which the certified - public key may be used, in addition to or in place of the basic - purposes indicated in the key usage extension. In general, this - extension will appear only in end entity certificates. This - extension is defined as follows: - - id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 } - - ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId - - KeyPurposeId ::= OBJECT IDENTIFIER - - Key purposes may be defined by any organization with a need. Object - identifiers used to identify key purposes MUST be assigned in - accordance with IANA or ITU-T Recommendation X.660 [X.660]. - - This extension MAY, at the option of the certificate issuer, be - either critical or non-critical. - - If the extension is present, then the certificate MUST only be used - for one of the purposes indicated. If multiple purposes are - indicated the application need not recognize all purposes indicated, - as long as the intended purpose is present. Certificate using - applications MAY require that the extended key usage extension be - present and that a particular purpose be indicated in order for the - certificate to be acceptable to that application. - - If a CA includes extended key usages to satisfy such applications, - but does not wish to restrict usages of the key, the CA can include - the special KeyPurposeId anyExtendedKeyUsage in addition to the - particular key purposes required by the applications. Conforming CAs - SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage - KeyPurposeId is present. Applications that require the presence of a - particular purpose MAY reject certificates that include the - anyExtendedKeyUsage OID but not the particular OID expected for the - application. - - - - - -Cooper, et al. Standards Track [Page 44] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - If a certificate contains both a key usage extension and an extended - key usage extension, then both extensions MUST be processed - independently and the certificate MUST only be used for a purpose - consistent with both extensions. If there is no purpose consistent - with both extensions, then the certificate MUST NOT be used for any - purpose. - - The following key usage purposes are defined: - - anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } - - id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } - - id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } - -- TLS WWW server authentication - -- Key usage bits that may be consistent: digitalSignature, - -- keyEncipherment or keyAgreement - - id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } - -- TLS WWW client authentication - -- Key usage bits that may be consistent: digitalSignature - -- and/or keyAgreement - - id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } - -- Signing of downloadable executable code - -- Key usage bits that may be consistent: digitalSignature - - id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } - -- Email protection - -- Key usage bits that may be consistent: digitalSignature, - -- nonRepudiation, and/or (keyEncipherment or keyAgreement) - - id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } - -- Binding the hash of an object to a time - -- Key usage bits that may be consistent: digitalSignature - -- and/or nonRepudiation - - id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } - -- Signing OCSP responses - -- Key usage bits that may be consistent: digitalSignature - -- and/or nonRepudiation - -4.2.1.13. CRL Distribution Points - - The CRL distribution points extension identifies how CRL information - is obtained. The extension SHOULD be non-critical, but this profile - RECOMMENDS support for this extension by CAs and applications. - Further discussion of CRL management is contained in Section 5. - - - -Cooper, et al. Standards Track [Page 45] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - The cRLDistributionPoints extension is a SEQUENCE of - DistributionPoint. A DistributionPoint consists of three fields, - each of which is optional: distributionPoint, reasons, and cRLIssuer. - While each of these fields is optional, a DistributionPoint MUST NOT - consist of only the reasons field; either distributionPoint or - cRLIssuer MUST be present. If the certificate issuer is not the CRL - issuer, then the cRLIssuer field MUST be present and contain the Name - of the CRL issuer. If the certificate issuer is also the CRL issuer, - then conforming CAs MUST omit the cRLIssuer field and MUST include - the distributionPoint field. - - When the distributionPoint field is present, it contains either a - SEQUENCE of general names or a single value, nameRelativeToCRLIssuer. - If the DistributionPointName contains multiple values, each name - describes a different mechanism to obtain the same CRL. For example, - the same CRL could be available for retrieval through both LDAP and - HTTP. - - If the distributionPoint field contains a directoryName, the entry - for that directoryName contains the current CRL for the associated - reasons and the CRL is issued by the associated cRLIssuer. The CRL - may be stored in either the certificateRevocationList or - authorityRevocationList attribute. The CRL is to be obtained by the - application from whatever directory server is locally configured. - The protocol the application uses to access the directory (e.g., DAP - or LDAP) is a local matter. - - If the DistributionPointName contains a general name of type URI, the - following semantics MUST be assumed: the URI is a pointer to the - current CRL for the associated reasons and will be issued by the - associated cRLIssuer. When the HTTP or FTP URI scheme is used, the - URI MUST point to a single DER encoded CRL as specified in - [RFC2585]. HTTP server implementations accessed via the URI SHOULD - specify the media type application/pkix-crl in the content-type - header field of the response. When the LDAP URI scheme [RFC4516] is - used, the URI MUST include a field containing the distinguished - name of the entry holding the CRL, MUST include a single - that contains an appropriate attribute description for the attribute - that holds the CRL [RFC4523], and SHOULD include a - (e.g., ). Omitting the (e.g., - ) has - the effect of relying on whatever a priori knowledge the client might - have to contact an appropriate server. When present, - DistributionPointName SHOULD include at least one LDAP or HTTP URI. - - If the DistributionPointName contains the single value - nameRelativeToCRLIssuer, the value provides a distinguished name - - - -Cooper, et al. Standards Track [Page 46] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - fragment. The fragment is appended to the X.500 distinguished name - of the CRL issuer to obtain the distribution point name. If the - cRLIssuer field in the DistributionPoint is present, then the name - fragment is appended to the distinguished name that it contains; - otherwise, the name fragment is appended to the certificate issuer - distinguished name. Conforming CAs SHOULD NOT use - nameRelativeToCRLIssuer to specify distribution point names. The - DistributionPointName MUST NOT use the nameRelativeToCRLIssuer - alternative when cRLIssuer contains more than one distinguished name. - - If the DistributionPoint omits the reasons field, the CRL MUST - include revocation information for all reasons. This profile - RECOMMENDS against segmenting CRLs by reason code. When a conforming - CA includes a cRLDistributionPoints extension in a certificate, it - MUST include at least one DistributionPoint that points to a CRL that - covers the certificate for all reasons. - - The cRLIssuer identifies the entity that signs and issues the CRL. - If present, the cRLIssuer MUST only contain the distinguished name - (DN) from the issuer field of the CRL to which the DistributionPoint - is pointing. The encoding of the name in the cRLIssuer field MUST be - exactly the same as the encoding in issuer field of the CRL. If the - cRLIssuer field is included and the DN in that field does not - correspond to an X.500 or LDAP directory entry where CRL is located, - then conforming CAs MUST include the distributionPoint field. - - id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= { id-ce 31 } - - CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint - - DistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - reasons [1] ReasonFlags OPTIONAL, - cRLIssuer [2] GeneralNames OPTIONAL } - - DistributionPointName ::= CHOICE { - fullName [0] GeneralNames, - nameRelativeToCRLIssuer [1] RelativeDistinguishedName } - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 47] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - ReasonFlags ::= BIT STRING { - unused (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - privilegeWithdrawn (7), - aACompromise (8) } - -4.2.1.14. Inhibit anyPolicy - - The inhibit anyPolicy extension can be used in certificates issued to - CAs. The inhibit anyPolicy extension indicates that the special - anyPolicy OID, with the value { 2 5 29 32 0 }, is not considered an - explicit match for other certificate policies except when it appears - in an intermediate self-issued CA certificate. The value indicates - the number of additional non-self-issued certificates that may appear - in the path before anyPolicy is no longer permitted. For example, a - value of one indicates that anyPolicy may be processed in - certificates issued by the subject of this certificate, but not in - additional certificates in the path. - - Conforming CAs MUST mark this extension as critical. - - id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } - - InhibitAnyPolicy ::= SkipCerts - - SkipCerts ::= INTEGER (0..MAX) - -4.2.1.15. Freshest CRL (a.k.a. Delta CRL Distribution Point) - - The freshest CRL extension identifies how delta CRL information is - obtained. The extension MUST be marked as non-critical by conforming - CAs. Further discussion of CRL management is contained in Section 5. - - The same syntax is used for this extension and the - cRLDistributionPoints extension, and is described in Section - 4.2.1.13. The same conventions apply to both extensions. - - id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - - FreshestCRL ::= CRLDistributionPoints - - - - - - -Cooper, et al. Standards Track [Page 48] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -4.2.2. Private Internet Extensions - - This section defines two extensions for use in the Internet Public - Key Infrastructure. These extensions may be used to direct - applications to on-line information about the issuer or the subject. - Each extension contains a sequence of access methods and access - locations. The access method is an object identifier that indicates - the type of information that is available. The access location is a - GeneralName that implicitly specifies the location and format of the - information and the method for obtaining the information. - - Object identifiers are defined for the private extensions. The - object identifiers associated with the private extensions are defined - under the arc id-pe within the arc id-pkix. Any future extensions - defined for the Internet PKI are also expected to be defined under - the arc id-pe. - - id-pkix OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) } - - id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } - -4.2.2.1. Authority Information Access - - The authority information access extension indicates how to access - information and services for the issuer of the certificate in which - the extension appears. Information and services may include on-line - validation services and CA policy data. (The location of CRLs is not - specified in this extension; that information is provided by the - cRLDistributionPoints extension.) This extension may be included in - end entity or CA certificates. Conforming CAs MUST mark this - extension as non-critical. - - id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } - - AuthorityInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - - AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - - id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - - id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } - - id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } - - - -Cooper, et al. Standards Track [Page 49] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Each entry in the sequence AuthorityInfoAccessSyntax describes the - format and location of additional information provided by the issuer - of the certificate in which this extension appears. The type and - format of the information are specified by the accessMethod field; - the accessLocation field specifies the location of the information. - The retrieval mechanism may be implied by the accessMethod or - specified by accessLocation. - - This profile defines two accessMethod OIDs: id-ad-caIssuers and - id-ad-ocsp. - - In a public key certificate, the id-ad-caIssuers OID is used when the - additional information lists certificates that were issued to the CA - that issued the certificate containing this extension. The - referenced CA issuers description is intended to aid certificate - users in the selection of a certification path that terminates at a - point trusted by the certificate user. - - When id-ad-caIssuers appears as accessMethod, the accessLocation - field describes the referenced description server and the access - protocol to obtain the referenced description. The accessLocation - field is defined as a GeneralName, which can take several forms. - - When the accessLocation is a directoryName, the information is to be - obtained by the application from whatever directory server is locally - configured. The entry for the directoryName contains CA certificates - in the crossCertificatePair and/or cACertificate attributes as - specified in [RFC4523]. The protocol that application uses to access - the directory (e.g., DAP or LDAP) is a local matter. - - Where the information is available via LDAP, the accessLocation - SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST - include a field containing the distinguished name of the entry - holding the certificates, MUST include an field that - lists appropriate attribute descriptions for the attributes that hold - the DER encoded certificates or cross-certificate pairs [RFC4523], - and SHOULD include a (e.g., ). - Omitting the (e.g., ) has the effect of relying on whatever a priori - knowledge the client might have to contact an appropriate server. - - Where the information is available via HTTP or FTP, accessLocation - MUST be a uniformResourceIdentifier and the URI MUST point to either - a single DER encoded certificate as specified in [RFC2585] or a - collection of certificates in a BER or DER encoded "certs-only" CMS - message as specified in [RFC2797]. - - - - -Cooper, et al. Standards Track [Page 50] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Conforming applications that support HTTP or FTP for accessing - certificates MUST be able to accept individual DER encoded - certificates and SHOULD be able to accept "certs-only" CMS messages. - - HTTP server implementations accessed via the URI SHOULD specify the - media type application/pkix-cert [RFC2585] in the content-type header - field of the response for a single DER encoded certificate and SHOULD - specify the media type application/pkcs7-mime [RFC2797] in the - content-type header field of the response for "certs-only" CMS - messages. For FTP, the name of a file that contains a single DER - encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the - name of a file that contains a "certs-only" CMS message SHOULD have a - suffix of ".p7c" [RFC2797]. Consuming clients may use the media type - or file extension as a hint to the content, but should not depend - solely on the presence of the correct media type or file extension in - the server response. - - The semantics of other id-ad-caIssuers accessLocation name forms are - not defined. - - An authorityInfoAccess extension may include multiple instances of - the id-ad-caIssuers accessMethod. The different instances may - specify different methods for accessing the same information or may - point to different information. When the id-ad-caIssuers - accessMethod is used, at least one instance SHOULD specify an - accessLocation that is an HTTP [RFC2616] or LDAP [RFC4516] URI. - - The id-ad-ocsp OID is used when revocation information for the - certificate containing this extension is available using the Online - Certificate Status Protocol (OCSP) [RFC2560]. - - When id-ad-ocsp appears as accessMethod, the accessLocation field is - the location of the OCSP responder, using the conventions defined in - [RFC2560]. - - Additional access descriptors may be defined in other PKIX - specifications. - -4.2.2.2. Subject Information Access - - The subject information access extension indicates how to access - information and services for the subject of the certificate in which - the extension appears. When the subject is a CA, information and - services may include certificate validation services and CA policy - data. When the subject is an end entity, the information describes - the type of services offered and how to access them. In this case, - the contents of this extension are defined in the protocol - - - - -Cooper, et al. Standards Track [Page 51] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - specifications for the supported services. This extension may be - included in end entity or CA certificates. Conforming CAs MUST mark - this extension as non-critical. - - id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } - - SubjectInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - - AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - - Each entry in the sequence SubjectInfoAccessSyntax describes the - format and location of additional information provided by the subject - of the certificate in which this extension appears. The type and - format of the information are specified by the accessMethod field; - the accessLocation field specifies the location of the information. - The retrieval mechanism may be implied by the accessMethod or - specified by accessLocation. - - This profile defines one access method to be used when the subject is - a CA and one access method to be used when the subject is an end - entity. Additional access methods may be defined in the future in - the protocol specifications for other services. - - The id-ad-caRepository OID is used when the subject is a CA that - publishes certificates it issues in a repository. The accessLocation - field is defined as a GeneralName, which can take several forms. - - When the accessLocation is a directoryName, the information is to be - obtained by the application from whatever directory server is locally - configured. When the extension is used to point to CA certificates, - the entry for the directoryName contains CA certificates in the - crossCertificatePair and/or cACertificate attributes as specified in - [RFC4523]. The protocol the application uses to access the directory - (e.g., DAP or LDAP) is a local matter. - - Where the information is available via LDAP, the accessLocation - SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST - include a field containing the distinguished name of the entry - holding the certificates, MUST include an field that - lists appropriate attribute descriptions for the attributes that hold - the DER encoded certificates or cross-certificate pairs [RFC4523], - and SHOULD include a (e.g., ). - - - - - -Cooper, et al. Standards Track [Page 52] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Omitting the (e.g., ) has the effect of relying on whatever a priori - knowledge the client might have to contact an appropriate server. - - Where the information is available via HTTP or FTP, accessLocation - MUST be a uniformResourceIdentifier and the URI MUST point to either - a single DER encoded certificate as specified in [RFC2585] or a - collection of certificates in a BER or DER encoded "certs-only" CMS - message as specified in [RFC2797]. - - Conforming applications that support HTTP or FTP for accessing - certificates MUST be able to accept individual DER encoded - certificates and SHOULD be able to accept "certs-only" CMS messages. - - HTTP server implementations accessed via the URI SHOULD specify the - media type application/pkix-cert [RFC2585] in the content-type header - field of the response for a single DER encoded certificate and SHOULD - specify the media type application/pkcs7-mime [RFC2797] in the - content-type header field of the response for "certs-only" CMS - messages. For FTP, the name of a file that contains a single DER - encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the - name of a file that contains a "certs-only" CMS message SHOULD have a - suffix of ".p7c" [RFC2797]. Consuming clients may use the media type - or file extension as a hint to the content, but should not depend - solely on the presence of the correct media type or file extension in - the server response. - - The semantics of other id-ad-caRepository accessLocation name forms - are not defined. - - A subjectInfoAccess extension may include multiple instances of the - id-ad-caRepository accessMethod. The different instances may specify - different methods for accessing the same information or may point to - different information. When the id-ad-caRepository accessMethod is - used, at least one instance SHOULD specify an accessLocation that is - an HTTP [RFC2616] or LDAP [RFC4516] URI. - - The id-ad-timeStamping OID is used when the subject offers - timestamping services using the Time Stamp Protocol defined in - [RFC3161]. Where the timestamping services are available via HTTP or - FTP, accessLocation MUST be a uniformResourceIdentifier. Where the - timestamping services are available via electronic mail, - accessLocation MUST be an rfc822Name. Where timestamping services - are available using TCP/IP, the dNSName or iPAddress name forms may - be used. The semantics of other name forms of accessLocation (when - accessMethod is id-ad-timeStamping) are not defined by this - specification. - - - - -Cooper, et al. Standards Track [Page 53] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Additional access descriptors may be defined in other PKIX - specifications. - - id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - - id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } - - id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } - -5. CRL and CRL Extensions Profile - - As discussed above, one goal of this X.509 v2 CRL profile is to - foster the creation of an interoperable and reusable Internet PKI. - To achieve this goal, guidelines for the use of extensions are - specified, and some assumptions are made about the nature of - information included in the CRL. - - CRLs may be used in a wide range of applications and environments - covering a broad spectrum of interoperability goals and an even - broader spectrum of operational and assurance requirements. This - profile establishes a common baseline for generic applications - requiring broad interoperability. The profile defines a set of - information that can be expected in every CRL. Also, the profile - defines common locations within the CRL for frequently used - attributes as well as common representations for these attributes. - - CRL issuers issue CRLs. The CRL issuer is either the CA or an entity - that has been authorized by the CA to issue CRLs. CAs publish CRLs - to provide status information about the certificates they issued. - However, a CA may delegate this responsibility to another trusted - authority. - - Each CRL has a particular scope. The CRL scope is the set of - certificates that could appear on a given CRL. For example, the - scope could be "all certificates issued by CA X", "all CA - certificates issued by CA X", "all certificates issued by CA X that - have been revoked for reasons of key compromise and CA compromise", - or a set of certificates based on arbitrary local information, such - as "all certificates issued to the NIST employees located in - Boulder". - - A complete CRL lists all unexpired certificates, within its scope, - that have been revoked for one of the revocation reasons covered by - the CRL scope. A full and complete CRL lists all unexpired - certificates issued by a CA that have been revoked for any reason. - (Note that since CAs and CRL issuers are identified by name, the - scope of a CRL is not affected by the key used to sign the CRL or the - key(s) used to sign certificates.) - - - -Cooper, et al. Standards Track [Page 54] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - If the scope of the CRL includes one or more certificates issued by - an entity other than the CRL issuer, then it is an indirect CRL. The - scope of an indirect CRL may be limited to certificates issued by a - single CA or may include certificates issued by multiple CAs. If the - issuer of the indirect CRL is a CA, then the scope of the indirect - CRL MAY also include certificates issued by the issuer of the CRL. - - The CRL issuer MAY also generate delta CRLs. A delta CRL only lists - those certificates, within its scope, whose revocation status has - changed since the issuance of a referenced complete CRL. The - referenced complete CRL is referred to as a base CRL. The scope of a - delta CRL MUST be the same as the base CRL that it references. - - This profile defines one private Internet CRL extension but does not - define any private CRL entry extensions. - - Environments with additional or special purpose requirements may - build on this profile or may replace it. - - Conforming CAs are not required to issue CRLs if other revocation or - certificate status mechanisms are provided. When CRLs are issued, - the CRLs MUST be version 2 CRLs, include the date by which the next - CRL will be issued in the nextUpdate field (Section 5.1.2.5), include - the CRL number extension (Section 5.2.3), and include the authority - key identifier extension (Section 5.2.1). Conforming applications - that support CRLs are REQUIRED to process both version 1 and version - 2 complete CRLs that provide revocation information for all - certificates issued by one CA. Conforming applications are not - required to support processing of delta CRLs, indirect CRLs, or CRLs - with a scope other than all certificates issued by one CA. - -5.1. CRL Fields - - The X.509 v2 CRL syntax is as follows. For signature calculation, - the data that is to be signed is ASN.1 DER encoded. ASN.1 DER - encoding is a tag, length, value encoding system for each element. - - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 55] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - CertificateList ::= SEQUENCE { - tbsCertList TBSCertList, - signatureAlgorithm AlgorithmIdentifier, - signatureValue BIT STRING } - - TBSCertList ::= SEQUENCE { - version Version OPTIONAL, - -- if present, MUST be v2 - signature AlgorithmIdentifier, - issuer Name, - thisUpdate Time, - nextUpdate Time OPTIONAL, - revokedCertificates SEQUENCE OF SEQUENCE { - userCertificate CertificateSerialNumber, - revocationDate Time, - crlEntryExtensions Extensions OPTIONAL - -- if present, version MUST be v2 - } OPTIONAL, - crlExtensions [0] EXPLICIT Extensions OPTIONAL - -- if present, version MUST be v2 - } - - -- Version, Time, CertificateSerialNumber, and Extensions - -- are all defined in the ASN.1 in Section 4.1 - - -- AlgorithmIdentifier is defined in Section 4.1.1.2 - - The following items describe the use of the X.509 v2 CRL in the - Internet PKI. - -5.1.1. CertificateList Fields - - The CertificateList is a SEQUENCE of three required fields. The - fields are described in detail in the following subsections. - -5.1.1.1. tbsCertList - - The first field in the sequence is the tbsCertList. This field is - itself a sequence containing the name of the issuer, issue date, - issue date of the next list, the optional list of revoked - certificates, and optional CRL extensions. When there are no revoked - certificates, the revoked certificates list is absent. When one or - more certificates are revoked, each entry on the revoked certificate - list is defined by a sequence of user certificate serial number, - revocation date, and optional CRL entry extensions. - - - - - - -Cooper, et al. Standards Track [Page 56] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.1.1.2. signatureAlgorithm - - The signatureAlgorithm field contains the algorithm identifier for - the algorithm used by the CRL issuer to sign the CertificateList. - The field is of type AlgorithmIdentifier, which is defined in Section - 4.1.1.2. [RFC3279], [RFC4055], and [RFC4491] list supported - algorithms for this specification, but other signature algorithms MAY - also be supported. - - This field MUST contain the same algorithm identifier as the - signature field in the sequence tbsCertList (Section 5.1.2.2). - -5.1.1.3. signatureValue - - The signatureValue field contains a digital signature computed upon - the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList - is used as the input to the signature function. This signature value - is encoded as a BIT STRING and included in the CRL signatureValue - field. The details of this process are specified for each of the - supported algorithms in [RFC3279], [RFC4055], and [RFC4491]. - - CAs that are also CRL issuers MAY use one private key to digitally - sign certificates and CRLs, or MAY use separate private keys to - digitally sign certificates and CRLs. When separate private keys are - employed, each of the public keys associated with these private keys - is placed in a separate certificate, one with the keyCertSign bit set - in the key usage extension, and one with the cRLSign bit set in the - key usage extension (Section 4.2.1.3). When separate private keys - are employed, certificates issued by the CA contain one authority key - identifier, and the corresponding CRLs contain a different authority - key identifier. The use of separate CA certificates for validation - of certificate signatures and CRL signatures can offer improved - security characteristics; however, it imposes a burden on - applications, and it might limit interoperability. Many applications - construct a certification path, and then validate the certification - path (Section 6). CRL checking in turn requires a separate - certification path to be constructed and validated for the CA's CRL - signature validation certificate. Applications that perform CRL - checking MUST support certification path validation when certificates - and CRLs are digitally signed with the same CA private key. These - applications SHOULD support certification path validation when - certificates and CRLs are digitally signed with different CA private - keys. - - - - - - - - -Cooper, et al. Standards Track [Page 57] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.1.2. Certificate List "To Be Signed" - - The certificate list to be signed, or TBSCertList, is a sequence of - required and optional fields. The required fields identify the CRL - issuer, the algorithm used to sign the CRL, and the date and time the - CRL was issued. - - Optional fields include the date and time by which the CRL issuer - will issue the next CRL, lists of revoked certificates, and CRL - extensions. The revoked certificate list is optional to support the - case where a CA has not revoked any unexpired certificates that it - has issued. This profile requires conforming CRL issuers to include - the nextUpdate field and the CRL number and authority key identifier - CRL extensions in all CRLs issued. - -5.1.2.1. Version - - This optional field describes the version of the encoded CRL. When - extensions are used, as required by this profile, this field MUST be - present and MUST specify version 2 (the integer value is 1). - -5.1.2.2. Signature - - This field contains the algorithm identifier for the algorithm used - to sign the CRL. [RFC3279], [RFC4055], and [RFC4491] list OIDs for - the most popular signature algorithms used in the Internet PKI. - - This field MUST contain the same algorithm identifier as the - signatureAlgorithm field in the sequence CertificateList (Section - 5.1.1.2). - -5.1.2.3. Issuer Name - - The issuer name identifies the entity that has signed and issued the - CRL. The issuer identity is carried in the issuer field. - Alternative name forms may also appear in the issuerAltName extension - (Section 5.2.2). The issuer field MUST contain a non-empty X.500 - distinguished name (DN). The issuer field is defined as the X.501 - type Name, and MUST follow the encoding rules for the issuer name - field in the certificate (Section 4.1.2.4). - -5.1.2.4. This Update - - This field indicates the issue date of this CRL. thisUpdate may be - encoded as UTCTime or GeneralizedTime. - - CRL issuers conforming to this profile MUST encode thisUpdate as - UTCTime for dates through the year 2049. CRL issuers conforming to - - - -Cooper, et al. Standards Track [Page 58] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - this profile MUST encode thisUpdate as GeneralizedTime for dates in - the year 2050 or later. Conforming applications MUST be able to - process dates that are encoded in either UTCTime or GeneralizedTime. - - Where encoded as UTCTime, thisUpdate MUST be specified and - interpreted as defined in Section 4.1.2.5.1. Where encoded as - GeneralizedTime, thisUpdate MUST be specified and interpreted as - defined in Section 4.1.2.5.2. - -5.1.2.5. Next Update - - This field indicates the date by which the next CRL will be issued. - The next CRL could be issued before the indicated date, but it will - not be issued any later than the indicated date. CRL issuers SHOULD - issue CRLs with a nextUpdate time equal to or later than all previous - CRLs. nextUpdate may be encoded as UTCTime or GeneralizedTime. - - Conforming CRL issuers MUST include the nextUpdate field in all CRLs. - Note that the ASN.1 syntax of TBSCertList describes this field as - OPTIONAL, which is consistent with the ASN.1 structure defined in - [X.509]. The behavior of clients processing CRLs that omit - nextUpdate is not specified by this profile. - - CRL issuers conforming to this profile MUST encode nextUpdate as - UTCTime for dates through the year 2049. CRL issuers conforming to - this profile MUST encode nextUpdate as GeneralizedTime for dates in - the year 2050 or later. Conforming applications MUST be able to - process dates that are encoded in either UTCTime or GeneralizedTime. - - Where encoded as UTCTime, nextUpdate MUST be specified and - interpreted as defined in Section 4.1.2.5.1. Where encoded as - GeneralizedTime, nextUpdate MUST be specified and interpreted as - defined in Section 4.1.2.5.2. - -5.1.2.6. Revoked Certificates - - When there are no revoked certificates, the revoked certificates list - MUST be absent. Otherwise, revoked certificates are listed by their - serial numbers. Certificates revoked by the CA are uniquely - identified by the certificate serial number. The date on which the - revocation occurred is specified. The time for revocationDate MUST - be expressed as described in Section 5.1.2.4. Additional information - may be supplied in CRL entry extensions; CRL entry extensions are - discussed in Section 5.3. - - - - - - - -Cooper, et al. Standards Track [Page 59] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.1.2.7. Extensions - - This field may only appear if the version is 2 (Section 5.1.2.1). If - present, this field is a sequence of one or more CRL extensions. CRL - extensions are discussed in Section 5.2. - -5.2. CRL Extensions - - The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2 - CRLs [X.509] [X9.55] provide methods for associating additional - attributes with CRLs. The X.509 v2 CRL format also allows - communities to define private extensions to carry information unique - to those communities. Each extension in a CRL may be designated as - critical or non-critical. If a CRL contains a critical extension - that the application cannot process, then the application MUST NOT - use that CRL to determine the status of certificates. However, - applications may ignore unrecognized non-critical extensions. The - following subsections present those extensions used within Internet - CRLs. Communities may elect to include extensions in CRLs that are - not defined in this specification. However, caution should be - exercised in adopting any critical extensions in CRLs that might be - used in a general context. - - Conforming CRL issuers are REQUIRED to include the authority key - identifier (Section 5.2.1) and the CRL number (Section 5.2.3) - extensions in all CRLs issued. - -5.2.1. Authority Key Identifier - - The authority key identifier extension provides a means of - identifying the public key corresponding to the private key used to - sign a CRL. The identification can be based on either the key - identifier (the subject key identifier in the CRL signer's - certificate) or the issuer name and serial number. This extension is - especially useful where an issuer has more than one signing key, - either due to multiple concurrent key pairs or due to changeover. - - Conforming CRL issuers MUST use the key identifier method, and MUST - include this extension in all CRLs issued. - - The syntax for this CRL extension is defined in Section 4.2.1.1. - -5.2.2. Issuer Alternative Name - - The issuer alternative name extension allows additional identities to - be associated with the issuer of the CRL. Defined options include an - electronic mail address (rfc822Name), a DNS name, an IP address, and - a URI. Multiple instances of a name form and multiple name forms may - - - -Cooper, et al. Standards Track [Page 60] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - be included. Whenever such identities are used, the issuer - alternative name extension MUST be used; however, a DNS name MAY be - represented in the issuer field using the domainComponent attribute - as described in Section 4.1.2.4. - - Conforming CRL issuers SHOULD mark the issuerAltName extension as - non-critical. - - The OID and syntax for this CRL extension are defined in Section - 4.2.1.7. - -5.2.3. CRL Number - - The CRL number is a non-critical CRL extension that conveys a - monotonically increasing sequence number for a given CRL scope and - CRL issuer. This extension allows users to easily determine when a - particular CRL supersedes another CRL. CRL numbers also support the - identification of complementary complete CRLs and delta CRLs. CRL - issuers conforming to this profile MUST include this extension in all - CRLs and MUST mark this extension as non-critical. - - If a CRL issuer generates delta CRLs in addition to complete CRLs for - a given scope, the complete CRLs and delta CRLs MUST share one - numbering sequence. If a delta CRL and a complete CRL that cover the - same scope are issued at the same time, they MUST have the same CRL - number and provide the same revocation information. That is, the - combination of the delta CRL and an acceptable complete CRL MUST - provide the same revocation information as the simultaneously issued - complete CRL. - - If a CRL issuer generates two CRLs (two complete CRLs, two delta - CRLs, or a complete CRL and a delta CRL) for the same scope at - different times, the two CRLs MUST NOT have the same CRL number. - That is, if the this update field (Section 5.1.2.4) in the two CRLs - are not identical, the CRL numbers MUST be different. - - Given the requirements above, CRL numbers can be expected to contain - long integers. CRL verifiers MUST be able to handle CRLNumber values - up to 20 octets. Conforming CRL issuers MUST NOT use CRLNumber - values longer than 20 octets. - - id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } - - CRLNumber ::= INTEGER (0..MAX) - - - - - - - -Cooper, et al. Standards Track [Page 61] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.2.4. Delta CRL Indicator - - The delta CRL indicator is a critical CRL extension that identifies a - CRL as being a delta CRL. Delta CRLs contain updates to revocation - information previously distributed, rather than all the information - that would appear in a complete CRL. The use of delta CRLs can - significantly reduce network load and processing time in some - environments. Delta CRLs are generally smaller than the CRLs they - update, so applications that obtain delta CRLs consume less network - bandwidth than applications that obtain the corresponding complete - CRLs. Applications that store revocation information in a format - other than the CRL structure can add new revocation information to - the local database without reprocessing information. - - The delta CRL indicator extension contains the single value of type - BaseCRLNumber. The CRL number identifies the CRL, complete for a - given scope, that was used as the starting point in the generation of - this delta CRL. A conforming CRL issuer MUST publish the referenced - base CRL as a complete CRL. The delta CRL contains all updates to - the revocation status for that same scope. The combination of a - delta CRL plus the referenced base CRL is equivalent to a complete - CRL, for the applicable scope, at the time of publication of the - delta CRL. - - When a conforming CRL issuer generates a delta CRL, the delta CRL - MUST include a critical delta CRL indicator extension. - - When a delta CRL is issued, it MUST cover the same set of reasons and - the same set of certificates that were covered by the base CRL it - references. That is, the scope of the delta CRL MUST be the same as - the scope of the complete CRL referenced as the base. The referenced - base CRL and the delta CRL MUST omit the issuing distribution point - extension or contain identical issuing distribution point extensions. - Further, the CRL issuer MUST use the same private key to sign the - delta CRL and any complete CRL that it can be used to update. - - An application that supports delta CRLs can construct a CRL that is - complete for a given scope by combining a delta CRL for that scope - with either an issued CRL that is complete for that scope or a - locally constructed CRL that is complete for that scope. - - When a delta CRL is combined with a complete CRL or a locally - constructed CRL, the resulting locally constructed CRL has the CRL - number specified in the CRL number extension found in the delta CRL - used in its construction. In addition, the resulting locally - constructed CRL has the thisUpdate and nextUpdate times specified in - - - - - -Cooper, et al. Standards Track [Page 62] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - the corresponding fields of the delta CRL used in its construction. - In addition, the locally constructed CRL inherits the issuing - distribution point from the delta CRL. - - A complete CRL and a delta CRL MAY be combined if the following four - conditions are satisfied: - - (a) The complete CRL and delta CRL have the same issuer. - - (b) The complete CRL and delta CRL have the same scope. The two - CRLs have the same scope if either of the following - conditions are met: - - (1) The issuingDistributionPoint extension is omitted from - both the complete CRL and the delta CRL. - - (2) The issuingDistributionPoint extension is present in both - the complete CRL and the delta CRL, and the values for - each of the fields in the extensions are the same in both - CRLs. - - (c) The CRL number of the complete CRL is equal to or greater - than the BaseCRLNumber specified in the delta CRL. That is, - the complete CRL contains (at a minimum) all the revocation - information held by the referenced base CRL. - - (d) The CRL number of the complete CRL is less than the CRL - number of the delta CRL. That is, the delta CRL follows the - complete CRL in the numbering sequence. - - CRL issuers MUST ensure that the combination of a delta CRL and any - appropriate complete CRL accurately reflects the current revocation - status. The CRL issuer MUST include an entry in the delta CRL for - each certificate within the scope of the delta CRL whose status has - changed since the generation of the referenced base CRL: - - (a) If the certificate is revoked for a reason included in the - scope of the CRL, list the certificate as revoked. - - (b) If the certificate is valid and was listed on the referenced - base CRL or any subsequent CRL with reason code - certificateHold, and the reason code certificateHold is - included in the scope of the CRL, list the certificate with - the reason code removeFromCRL. - - - - - - - -Cooper, et al. Standards Track [Page 63] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (c) If the certificate is revoked for a reason outside the scope - of the CRL, but the certificate was listed on the referenced - base CRL or any subsequent CRL with a reason code included in - the scope of this CRL, list the certificate as revoked but - omit the reason code. - - (d) If the certificate is revoked for a reason outside the scope - of the CRL and the certificate was neither listed on the - referenced base CRL nor any subsequent CRL with a reason code - included in the scope of this CRL, do not list the - certificate on this CRL. - - The status of a certificate is considered to have changed if it is - revoked (for any revocation reason, including certificateHold), if it - is released from hold, or if its revocation reason changes. - - It is appropriate to list a certificate with reason code - removeFromCRL on a delta CRL even if the certificate was not on hold - in the referenced base CRL. If the certificate was placed on hold in - any CRL issued after the base but before this delta CRL and then - released from hold, it MUST be listed on the delta CRL with - revocation reason removeFromCRL. - - A CRL issuer MAY optionally list a certificate on a delta CRL with - reason code removeFromCRL if the notAfter time specified in the - certificate precedes the thisUpdate time specified in the delta CRL - and the certificate was listed on the referenced base CRL or in any - CRL issued after the base but before this delta CRL. - - If a certificate revocation notice first appears on a delta CRL, then - it is possible for the certificate validity period to expire before - the next complete CRL for the same scope is issued. In this case, - the revocation notice MUST be included in all subsequent delta CRLs - until the revocation notice is included on at least one explicitly - issued complete CRL for this scope. - - An application that supports delta CRLs MUST be able to construct a - current complete CRL by combining a previously issued complete CRL - and the most current delta CRL. An application that supports delta - CRLs MAY also be able to construct a current complete CRL by - combining a previously locally constructed complete CRL and the - current delta CRL. A delta CRL is considered to be the current one - if the current time is between the times contained in the thisUpdate - and nextUpdate fields. Under some circumstances, the CRL issuer may - publish one or more delta CRLs before the time indicated by the - nextUpdate field. If more than one current delta CRL for a given - scope is encountered, the application SHOULD consider the one with - the latest value in thisUpdate to be the most current one. - - - -Cooper, et al. Standards Track [Page 64] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } - - BaseCRLNumber ::= CRLNumber - -5.2.5. Issuing Distribution Point - - The issuing distribution point is a critical CRL extension that - identifies the CRL distribution point and scope for a particular CRL, - and it indicates whether the CRL covers revocation for end entity - certificates only, CA certificates only, attribute certificates only, - or a limited set of reason codes. Although the extension is - critical, conforming implementations are not required to support this - extension. However, implementations that do not support this - extension MUST either treat the status of any certificate not listed - on this CRL as unknown or locate another CRL that does not contain - any unrecognized critical extensions. - - The CRL is signed using the CRL issuer's private key. CRL - distribution points do not have their own key pairs. If the CRL is - stored in the X.500 directory, it is stored in the directory entry - corresponding to the CRL distribution point, which may be different - from the directory entry of the CRL issuer. - - The reason codes associated with a distribution point MUST be - specified in onlySomeReasons. If onlySomeReasons does not appear, - the distribution point MUST contain revocations for all reason codes. - CAs may use CRL distribution points to partition the CRL on the basis - of compromise and routine revocation. In this case, the revocations - with reason code keyCompromise (1), cACompromise (2), and - aACompromise (8) appear in one distribution point, and the - revocations with other reason codes appear in another distribution - point. - - If a CRL includes an issuingDistributionPoint extension with - onlySomeReasons present, then every certificate in the scope of the - CRL that is revoked MUST be assigned a revocation reason other than - unspecified. The assigned revocation reason is used to determine on - which CRL(s) to list the revoked certificate, however, there is no - requirement to include the reasonCode CRL entry extension in the - corresponding CRL entry. - - The syntax and semantics for the distributionPoint field are the same - as for the distributionPoint field in the cRLDistributionPoints - extension (Section 4.2.1.13). If the distributionPoint field is - present, then it MUST include at least one of names from the - corresponding distributionPoint field of the cRLDistributionPoints - - - - - -Cooper, et al. Standards Track [Page 65] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - extension of every certificate that is within the scope of this CRL. - The identical encoding MUST be used in the distributionPoint fields - of the certificate and the CRL. - - If the distributionPoint field is absent, the CRL MUST contain - entries for all revoked unexpired certificates issued by the CRL - issuer, if any, within the scope of the CRL. - - If the scope of the CRL only includes certificates issued by the CRL - issuer, then the indirectCRL boolean MUST be set to FALSE. - Otherwise, if the scope of the CRL includes certificates issued by - one or more authorities other than the CRL issuer, the indirectCRL - boolean MUST be set to TRUE. The authority responsible for each - entry is indicated by the certificate issuer CRL entry extension - (Section 5.3.3). - - If the scope of the CRL only includes end entity public key - certificates, then onlyContainsUserCerts MUST be set to TRUE. If the - scope of the CRL only includes CA certificates, then - onlyContainsCACerts MUST be set to TRUE. If either - onlyContainsUserCerts or onlyContainsCACerts is set to TRUE, then the - scope of the CRL MUST NOT include any version 1 or version 2 - certificates. Conforming CRLs issuers MUST set the - onlyContainsAttributeCerts boolean to FALSE. - - Conforming CRLs issuers MUST NOT issue CRLs where the DER encoding of - the issuing distribution point extension is an empty sequence. That - is, if onlyContainsUserCerts, onlyContainsCACerts, indirectCRL, and - onlyContainsAttributeCerts are all FALSE, then either the - distributionPoint field or the onlySomeReasons field MUST be present. - - id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } - - IssuingDistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, - onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, - onlySomeReasons [3] ReasonFlags OPTIONAL, - indirectCRL [4] BOOLEAN DEFAULT FALSE, - onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } - - -- at most one of onlyContainsUserCerts, onlyContainsCACerts, - -- and onlyContainsAttributeCerts may be set to TRUE. - - - - - - - - -Cooper, et al. Standards Track [Page 66] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.2.6. Freshest CRL (a.k.a. Delta CRL Distribution Point) - - The freshest CRL extension identifies how delta CRL information for - this complete CRL is obtained. Conforming CRL issuers MUST mark this - extension as non-critical. This extension MUST NOT appear in delta - CRLs. - - The same syntax is used for this extension as the - cRLDistributionPoints certificate extension, and is described in - Section 4.2.1.13. However, only the distribution point field is - meaningful in this context. The reasons and cRLIssuer fields MUST be - omitted from this CRL extension. - - Each distribution point name provides the location at which a delta - CRL for this complete CRL can be found. The scope of these delta - CRLs MUST be the same as the scope of this complete CRL. The - contents of this CRL extension are only used to locate delta CRLs; - the contents are not used to validate the CRL or the referenced delta - CRLs. The encoding conventions defined for distribution points in - Section 4.2.1.13 apply to this extension. - - id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - - FreshestCRL ::= CRLDistributionPoints - -5.2.7. Authority Information Access - - This section defines the use of the Authority Information Access - extension in a CRL. The syntax and semantics defined in Section - 4.2.2.1 for the certificate extension are also used for the CRL - extension. - - This CRL extension MUST be marked as non-critical. - - When present in a CRL, this extension MUST include at least one - AccessDescription specifying id-ad-caIssuers as the accessMethod. - The id-ad-caIssuers OID is used when the information available lists - certificates that can be used to verify the signature on the CRL - (i.e., certificates that have a subject name that matches the issuer - name on the CRL and that have a subject public key that corresponds - to the private key used to sign the CRL). Access method types other - than id-ad-caIssuers MUST NOT be included. At least one instance of - AccessDescription SHOULD specify an accessLocation that is an HTTP - [RFC2616] or LDAP [RFC4516] URI. - - - - - - - -Cooper, et al. Standards Track [Page 67] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Where the information is available via HTTP or FTP, accessLocation - MUST be a uniformResourceIdentifier and the URI MUST point to either - a single DER encoded certificate as specified in [RFC2585] or a - collection of certificates in a BER or DER encoded "certs-only" CMS - message as specified in [RFC2797]. - - Conforming applications that support HTTP or FTP for accessing - certificates MUST be able to accept individual DER encoded - certificates and SHOULD be able to accept "certs-only" CMS messages. - - HTTP server implementations accessed via the URI SHOULD specify the - media type application/pkix-cert [RFC2585] in the content-type header - field of the response for a single DER encoded certificate and SHOULD - specify the media type application/pkcs7-mime [RFC2797] in the - content-type header field of the response for "certs-only" CMS - messages. For FTP, the name of a file that contains a single DER - encoded certificate SHOULD have a suffix of ".cer" [RFC2585] and the - name of a file that contains a "certs-only" CMS message SHOULD have a - suffix of ".p7c" [RFC2797]. Consuming clients may use the media type - or file extension as a hint to the content, but should not depend - solely on the presence of the correct media type or file extension in - the server response. - - When the accessLocation is a directoryName, the information is to be - obtained by the application from whatever directory server is locally - configured. When one CA public key is used to validate signatures on - certificates and CRLs, the desired CA certificate is stored in the - crossCertificatePair and/or cACertificate attributes as specified in - [RFC4523]. When different public keys are used to validate - signatures on certificates and CRLs, the desired certificate is - stored in the userCertificate attribute as specified in [RFC4523]. - Thus, implementations that support the directoryName form of - accessLocation MUST be prepared to find the needed certificate in any - of these three attributes. The protocol that an application uses to - access the directory (e.g., DAP or LDAP) is a local matter. - - Where the information is available via LDAP, the accessLocation - SHOULD be a uniformResourceIdentifier. The LDAP URI [RFC4516] MUST - include a field containing the distinguished name of the entry - holding the certificates, MUST include an field that - lists appropriate attribute descriptions for the attributes that hold - the DER encoded certificates or cross-certificate pairs [RFC4523], - and SHOULD include a (e.g., ). - Omitting the (e.g., ) has the effect of relying on whatever a priori - knowledge the client might have to contact an appropriate server. - - - - -Cooper, et al. Standards Track [Page 68] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -5.3. CRL Entry Extensions - - The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for - X.509 v2 CRLs provide methods for associating additional attributes - with CRL entries [X.509] [X9.55]. The X.509 v2 CRL format also - allows communities to define private CRL entry extensions to carry - information unique to those communities. Each extension in a CRL - entry may be designated as critical or non-critical. If a CRL - contains a critical CRL entry extension that the application cannot - process, then the application MUST NOT use that CRL to determine the - status of any certificates. However, applications may ignore - unrecognized non-critical CRL entry extensions. - - The following subsections present recommended extensions used within - Internet CRL entries and standard locations for information. - Communities may elect to use additional CRL entry extensions; - however, caution should be exercised in adopting any critical CRL - entry extensions in CRLs that might be used in a general context. - - Support for the CRL entry extensions defined in this specification is - optional for conforming CRL issuers and applications. However, CRL - issuers SHOULD include reason codes (Section 5.3.1) and invalidity - dates (Section 5.3.2) whenever this information is available. - -5.3.1. Reason Code - - The reasonCode is a non-critical CRL entry extension that identifies - the reason for the certificate revocation. CRL issuers are strongly - encouraged to include meaningful reason codes in CRL entries; - however, the reason code CRL entry extension SHOULD be absent instead - of using the unspecified (0) reasonCode value. - - The removeFromCRL (8) reasonCode value may only appear in delta CRLs - and indicates that a certificate is to be removed from a CRL because - either the certificate expired or was removed from hold. All other - reason codes may appear in any CRL and indicate that the specified - certificate should be considered revoked. - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 69] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } - - -- reasonCode ::= { CRLReason } - - CRLReason ::= ENUMERATED { - unspecified (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - -- value 7 is not used - removeFromCRL (8), - privilegeWithdrawn (9), - aACompromise (10) } - -5.3.2. Invalidity Date - - The invalidity date is a non-critical CRL entry extension that - provides the date on which it is known or suspected that the private - key was compromised or that the certificate otherwise became invalid. - This date may be earlier than the revocation date in the CRL entry, - which is the date at which the CA processed the revocation. When a - revocation is first posted by a CRL issuer in a CRL, the invalidity - date may precede the date of issue of earlier CRLs, but the - revocation date SHOULD NOT precede the date of issue of earlier CRLs. - Whenever this information is available, CRL issuers are strongly - encouraged to share it with CRL users. - - The GeneralizedTime values included in this field MUST be expressed - in Greenwich Mean Time (Zulu), and MUST be specified and interpreted - as defined in Section 4.1.2.5.2. - - id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } - - InvalidityDate ::= GeneralizedTime - -5.3.3. Certificate Issuer - - This CRL entry extension identifies the certificate issuer associated - with an entry in an indirect CRL, that is, a CRL that has the - indirectCRL indicator set in its issuing distribution point - extension. When present, the certificate issuer CRL entry extension - includes one or more names from the issuer field and/or issuer - alternative name extension of the certificate that corresponds to the - CRL entry. If this extension is not present on the first entry in an - indirect CRL, the certificate issuer defaults to the CRL issuer. On - - - -Cooper, et al. Standards Track [Page 70] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - subsequent entries in an indirect CRL, if this extension is not - present, the certificate issuer for the entry is the same as that for - the preceding entry. This field is defined as follows: - - id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } - - CertificateIssuer ::= GeneralNames - - Conforming CRL issuers MUST include in this extension the - distinguished name (DN) from the issuer field of the certificate that - corresponds to this CRL entry. The encoding of the DN MUST be - identical to the encoding used in the certificate. - - CRL issuers MUST mark this extension as critical since an - implementation that ignored this extension could not correctly - attribute CRL entries to certificates. This specification RECOMMENDS - that implementations recognize this extension. - -6. Certification Path Validation - - Certification path validation procedures for the Internet PKI are - based on the algorithm supplied in [X.509]. Certification path - processing verifies the binding between the subject distinguished - name and/or subject alternative name and subject public key. The - binding is limited by constraints that are specified in the - certificates that comprise the path and inputs that are specified by - the relying party. The basic constraints and policy constraints - extensions allow the certification path processing logic to automate - the decision making process. - - This section describes an algorithm for validating certification - paths. Conforming implementations of this specification are not - required to implement this algorithm, but MUST provide functionality - equivalent to the external behavior resulting from this procedure. - Any algorithm may be used by a particular implementation so long as - it derives the correct result. - - In Section 6.1, the text describes basic path validation. Valid - paths begin with certificates issued by a trust anchor. The - algorithm requires the public key of the CA, the CA's name, and any - constraints upon the set of paths that may be validated using this - key. - - The selection of a trust anchor is a matter of policy: it could be - the top CA in a hierarchical PKI, the CA that issued the verifier's - own certificate(s), or any other CA in a network PKI. The path - - - - - -Cooper, et al. Standards Track [Page 71] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - validation procedure is the same regardless of the choice of trust - anchor. In addition, different applications may rely on different - trust anchors, or may accept paths that begin with any of a set of - trust anchors. - - Section 6.2 describes methods for using the path validation algorithm - in specific implementations. - - Section 6.3 describes the steps necessary to determine if a - certificate is revoked when CRLs are the revocation mechanism used by - the certificate issuer. - -6.1. Basic Path Validation - - This text describes an algorithm for X.509 path processing. A - conforming implementation MUST include an X.509 path processing - procedure that is functionally equivalent to the external behavior of - this algorithm. However, support for some of the certificate - extensions processed in this algorithm are OPTIONAL for compliant - implementations. Clients that do not support these extensions MAY - omit the corresponding steps in the path validation algorithm. - - For example, clients are not required to support the policy mappings - extension. Clients that do not support this extension MAY omit the - path validation steps where policy mappings are processed. Note that - clients MUST reject the certificate if it contains an unsupported - critical extension. - - While the certificate and CRL profiles specified in Sections 4 and 5 - of this document specify values for certificate and CRL fields and - extensions that are considered to be appropriate for the Internet - PKI, the algorithm presented in this section is not limited to - accepting certificates and CRLs that conform to these profiles. - Therefore, the algorithm only includes checks to verify that the - certification path is valid according to X.509 and does not include - checks to verify that the certificates and CRLs conform to this - profile. While the algorithm could be extended to include checks for - conformance to the profiles in Sections 4 and 5, this profile - RECOMMENDS against including such checks. - - The algorithm presented in this section validates the certificate - with respect to the current date and time. A conforming - implementation MAY also support validation with respect to some point - in the past. Note that mechanisms are not available for validating a - certificate with respect to a time outside the certificate validity - period. - - - - - -Cooper, et al. Standards Track [Page 72] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - The trust anchor is an input to the algorithm. There is no - requirement that the same trust anchor be used to validate all - certification paths. Different trust anchors MAY be used to validate - different paths, as discussed further in Section 6.2. - - The primary goal of path validation is to verify the binding between - a subject distinguished name or a subject alternative name and - subject public key, as represented in the target certificate, based - on the public key of the trust anchor. In most cases, the target - certificate will be an end entity certificate, but the target - certificate may be a CA certificate as long as the subject public key - is to be used for a purpose other than verifying the signature on a - public key certificate. Verifying the binding between the name and - subject public key requires obtaining a sequence of certificates that - support that binding. The procedure performed to obtain this - sequence of certificates is outside the scope of this specification. - - To meet this goal, the path validation process verifies, among other - things, that a prospective certification path (a sequence of n - certificates) satisfies the following conditions: - - (a) for all x in {1, ..., n-1}, the subject of certificate x is - the issuer of certificate x+1; - - (b) certificate 1 is issued by the trust anchor; - - (c) certificate n is the certificate to be validated (i.e., the - target certificate); and - - (d) for all x in {1, ..., n}, the certificate was valid at the - time in question. - - A certificate MUST NOT appear more than once in a prospective - certification path. - - When the trust anchor is provided in the form of a self-signed - certificate, this self-signed certificate is not included as part of - the prospective certification path. Information about trust anchors - is provided as inputs to the certification path validation algorithm - (Section 6.1.1). - - A particular certification path may not, however, be appropriate for - all applications. Therefore, an application MAY augment this - algorithm to further limit the set of valid paths. The path - validation process also determines the set of certificate policies - that are valid for this path, based on the certificate policies - extension, policy mappings extension, policy constraints extension, - and inhibit anyPolicy extension. To achieve this, the path - - - -Cooper, et al. Standards Track [Page 73] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - validation algorithm constructs a valid policy tree. If the set of - certificate policies that are valid for this path is not empty, then - the result will be a valid policy tree of depth n, otherwise the - result will be a null valid policy tree. - - A certificate is self-issued if the same DN appears in the subject - and issuer fields (the two DNs are the same if they match according - to the rules specified in Section 7.1). In general, the issuer and - subject of the certificates that make up a path are different for - each certificate. However, a CA may issue a certificate to itself to - support key rollover or changes in certificate policies. These - self-issued certificates are not counted when evaluating path length - or name constraints. - - This section presents the algorithm in four basic steps: (1) - initialization, (2) basic certificate processing, (3) preparation for - the next certificate, and (4) wrap-up. Steps (1) and (4) are - performed exactly once. Step (2) is performed for all certificates - in the path. Step (3) is performed for all certificates in the path - except the final certificate. Figure 2 provides a high-level - flowchart of this algorithm. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 74] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - +-------+ - | START | - +-------+ - | - V - +----------------+ - | Initialization | - +----------------+ - | - +<--------------------+ - | | - V | - +----------------+ | - | Process Cert | | - +----------------+ | - | | - V | - +================+ | - | IF Last Cert | | - | in Path | | - +================+ | - | | | - THEN | | ELSE | - V V | - +----------------+ +----------------+ | - | Wrap up | | Prepare for | | - +----------------+ | Next Cert | | - | +----------------+ | - V | | - +-------+ +--------------+ - | STOP | - +-------+ - - Figure 2. Certification Path Processing Flowchart - -6.1.1. Inputs - - This algorithm assumes that the following nine inputs are provided to - the path processing logic: - - (a) a prospective certification path of length n. - - (b) the current date/time. - - - - - - - - -Cooper, et al. Standards Track [Page 75] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (c) user-initial-policy-set: A set of certificate policy - identifiers naming the policies that are acceptable to the - certificate user. The user-initial-policy-set contains the - special value any-policy if the user is not concerned about - certificate policy. - - (d) trust anchor information, describing a CA that serves as a - trust anchor for the certification path. The trust anchor - information includes: - - (1) the trusted issuer name, - - (2) the trusted public key algorithm, - - (3) the trusted public key, and - - (4) optionally, the trusted public key parameters associated - with the public key. - - The trust anchor information may be provided to the path - processing procedure in the form of a self-signed certificate. - When the trust anchor information is provided in the form of a - certificate, the name in the subject field is used as the trusted - issuer name and the contents of the subjectPublicKeyInfo field is - used as the source of the trusted public key algorithm and the - trusted public key. The trust anchor information is trusted - because it was delivered to the path processing procedure by some - trustworthy out-of-band procedure. If the trusted public key - algorithm requires parameters, then the parameters are provided - along with the trusted public key. - - (e) initial-policy-mapping-inhibit, which indicates if policy - mapping is allowed in the certification path. - - (f) initial-explicit-policy, which indicates if the path must be - valid for at least one of the certificate policies in the - user-initial-policy-set. - - (g) initial-any-policy-inhibit, which indicates whether the - anyPolicy OID should be processed if it is included in a - certificate. - - (h) initial-permitted-subtrees, which indicates for each name - type (e.g., X.500 distinguished names, email addresses, or IP - addresses) a set of subtrees within which all subject names - in every certificate in the certification path MUST fall. - The initial-permitted-subtrees input includes a set for each - name type. For each name type, the set may consist of a - - - -Cooper, et al. Standards Track [Page 76] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - single subtree that includes all names of that name type or - one or more subtrees that each specifies a subset of the - names of that name type, or the set may be empty. If the set - for a name type is empty, then the certification path will be - considered invalid if any certificate in the certification - path includes a name of that name type. - - (i) initial-excluded-subtrees, which indicates for each name type - (e.g., X.500 distinguished names, email addresses, or IP - addresses) a set of subtrees within which no subject name in - any certificate in the certification path may fall. The - initial-excluded-subtrees input includes a set for each name - type. For each name type, the set may be empty or may - consist of one or more subtrees that each specifies a subset - of the names of that name type. If the set for a name type - is empty, then no names of that name type are excluded. - - Conforming implementations are not required to support the setting of - all of these inputs. For example, a conforming implementation may be - designed to validate all certification paths using a value of FALSE - for initial-any-policy-inhibit. - -6.1.2. Initialization - - This initialization phase establishes eleven state variables based - upon the nine inputs: - - (a) valid_policy_tree: A tree of certificate policies with their - optional qualifiers; each of the leaves of the tree - represents a valid policy at this stage in the certification - path validation. If valid policies exist at this stage in - the certification path validation, the depth of the tree is - equal to the number of certificates in the chain that have - been processed. If valid policies do not exist at this stage - in the certification path validation, the tree is set to - NULL. Once the tree is set to NULL, policy processing - ceases. - - Each node in the valid_policy_tree includes three data - objects: the valid policy, a set of associated policy - qualifiers, and a set of one or more expected policy values. - If the node is at depth x, the components of the node have - the following semantics: - - (1) The valid_policy is a single policy OID representing a - valid policy for the path of length x. - - - - - -Cooper, et al. Standards Track [Page 77] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (2) The qualifier_set is a set of policy qualifiers associated - with the valid policy in certificate x. - - (3) The expected_policy_set contains one or more policy OIDs - that would satisfy this policy in the certificate x+1. - - The initial value of the valid_policy_tree is a single node with - valid_policy anyPolicy, an empty qualifier_set, and an - expected_policy_set with the single value anyPolicy. This node is - considered to be at depth zero. - - Figure 3 is a graphic representation of the initial state of the - valid_policy_tree. Additional figures will use this format to - describe changes in the valid_policy_tree during path processing. - - +----------------+ - | anyPolicy | <---- valid_policy - +----------------+ - | {} | <---- qualifier_set - +----------------+ - | {anyPolicy} | <---- expected_policy_set - +----------------+ - - Figure 3. Initial Value of the valid_policy_tree State Variable - - (b) permitted_subtrees: a set of root names for each name type - (e.g., X.500 distinguished names, email addresses, or IP - addresses) defining a set of subtrees within which all - subject names in subsequent certificates in the certification - path MUST fall. This variable includes a set for each name - type, and the initial value is initial-permitted-subtrees. - - (c) excluded_subtrees: a set of root names for each name type - (e.g., X.500 distinguished names, email addresses, or IP - addresses) defining a set of subtrees within which no subject - name in subsequent certificates in the certification path may - fall. This variable includes a set for each name type, and - the initial value is initial-excluded-subtrees. - - (d) explicit_policy: an integer that indicates if a non-NULL - valid_policy_tree is required. The integer indicates the - number of non-self-issued certificates to be processed before - this requirement is imposed. Once set, this variable may be - decreased, but may not be increased. That is, if a - certificate in the path requires a non-NULL - valid_policy_tree, a later certificate cannot remove this - requirement. If initial-explicit-policy is set, then the - initial value is 0, otherwise the initial value is n+1. - - - -Cooper, et al. Standards Track [Page 78] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (e) inhibit_anyPolicy: an integer that indicates whether the - anyPolicy policy identifier is considered a match. The - integer indicates the number of non-self-issued certificates - to be processed before the anyPolicy OID, if asserted in a - certificate other than an intermediate self-issued - certificate, is ignored. Once set, this variable may be - decreased, but may not be increased. That is, if a - certificate in the path inhibits processing of anyPolicy, a - later certificate cannot permit it. If initial-any-policy- - inhibit is set, then the initial value is 0, otherwise the - initial value is n+1. - - (f) policy_mapping: an integer that indicates if policy mapping - is permitted. The integer indicates the number of non-self- - issued certificates to be processed before policy mapping is - inhibited. Once set, this variable may be decreased, but may - not be increased. That is, if a certificate in the path - specifies that policy mapping is not permitted, it cannot be - overridden by a later certificate. If initial-policy- - mapping-inhibit is set, then the initial value is 0, - otherwise the initial value is n+1. - - (g) working_public_key_algorithm: the digital signature - algorithm used to verify the signature of a certificate. The - working_public_key_algorithm is initialized from the trusted - public key algorithm provided in the trust anchor - information. - - (h) working_public_key: the public key used to verify the - signature of a certificate. The working_public_key is - initialized from the trusted public key provided in the trust - anchor information. - - (i) working_public_key_parameters: parameters associated with - the current public key that may be required to verify a - signature (depending upon the algorithm). The - working_public_key_parameters variable is initialized from - the trusted public key parameters provided in the trust - anchor information. - - (j) working_issuer_name: the issuer distinguished name expected - in the next certificate in the chain. The - working_issuer_name is initialized to the trusted issuer name - provided in the trust anchor information. - - - - - - - -Cooper, et al. Standards Track [Page 79] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (k) max_path_length: this integer is initialized to n, is - decremented for each non-self-issued certificate in the path, - and may be reduced to the value in the path length constraint - field within the basic constraints extension of a CA - certificate. - - Upon completion of the initialization steps, perform the basic - certificate processing steps specified in 6.1.3. - -6.1.3. Basic Certificate Processing - - The basic path processing actions to be performed for certificate i - (for all i in [1..n]) are listed below. - - (a) Verify the basic certificate information. The certificate - MUST satisfy each of the following: - - (1) The signature on the certificate can be verified using - working_public_key_algorithm, the working_public_key, and - the working_public_key_parameters. - - (2) The certificate validity period includes the current time. - - (3) At the current time, the certificate is not revoked. This - may be determined by obtaining the appropriate CRL - (Section 6.3), by status information, or by out-of-band - mechanisms. - - (4) The certificate issuer name is the working_issuer_name. - - (b) If certificate i is self-issued and it is not the final - certificate in the path, skip this step for certificate i. - Otherwise, verify that the subject name is within one of the - permitted_subtrees for X.500 distinguished names, and verify - that each of the alternative names in the subjectAltName - extension (critical or non-critical) is within one of the - permitted_subtrees for that name type. - - (c) If certificate i is self-issued and it is not the final - certificate in the path, skip this step for certificate i. - Otherwise, verify that the subject name is not within any of - the excluded_subtrees for X.500 distinguished names, and - verify that each of the alternative names in the - subjectAltName extension (critical or non-critical) is not - within any of the excluded_subtrees for that name type. - - - - - - -Cooper, et al. Standards Track [Page 80] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (d) If the certificate policies extension is present in the - certificate and the valid_policy_tree is not NULL, process - the policy information by performing the following steps in - order: - - (1) For each policy P not equal to anyPolicy in the - certificate policies extension, let P-OID denote the OID - for policy P and P-Q denote the qualifier set for policy - P. Perform the following steps in order: - - (i) For each node of depth i-1 in the valid_policy_tree - where P-OID is in the expected_policy_set, create a - child node as follows: set the valid_policy to P-OID, - set the qualifier_set to P-Q, and set the - expected_policy_set to - {P-OID}. - - For example, consider a valid_policy_tree with a node - of depth i-1 where the expected_policy_set is {Gold, - White}. Assume the certificate policies Gold and - Silver appear in the certificate policies extension of - certificate i. The Gold policy is matched, but the - Silver policy is not. This rule will generate a child - node of depth i for the Gold policy. The result is - shown as Figure 4. - - +-----------------+ - | Red | - +-----------------+ - | {} | - +-----------------+ node of depth i-1 - | {Gold, White} | - +-----------------+ - | - | - | - V - +-----------------+ - | Gold | - +-----------------+ - | {} | - +-----------------+ node of depth i - | {Gold} | - +-----------------+ - - Figure 4. Processing an Exact Match - - - - - -Cooper, et al. Standards Track [Page 81] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (ii) If there was no match in step (i) and the - valid_policy_tree includes a node of depth i-1 with - the valid_policy anyPolicy, generate a child node with - the following values: set the valid_policy to P-OID, - set the qualifier_set to P-Q, and set the - expected_policy_set to {P-OID}. - - For example, consider a valid_policy_tree with a node - of depth i-1 where the valid_policy is anyPolicy. - Assume the certificate policies Gold and Silver appear - in the certificate policies extension of certificate - i. The Gold policy does not have a qualifier, but the - Silver policy has the qualifier Q-Silver. If Gold and - Silver were not matched in (i) above, this rule will - generate two child nodes of depth i, one for each - policy. The result is shown as Figure 5. - - +-----------------+ - | anyPolicy | - +-----------------+ - | {} | - +-----------------+ node of depth i-1 - | {anyPolicy} | - +-----------------+ - / \ - / \ - / \ - / \ - +-----------------+ +-----------------+ - | Gold | | Silver | - +-----------------+ +-----------------+ - | {} | | {Q-Silver} | - +-----------------+ nodes of +-----------------+ - | {Gold} | depth i | {Silver} | - +-----------------+ +-----------------+ - - Figure 5. Processing Unmatched Policies when a - Leaf Node Specifies anyPolicy - - (2) If the certificate policies extension includes the policy - anyPolicy with the qualifier set AP-Q and either (a) - inhibit_anyPolicy is greater than 0 or (b) i. - - [RFC1422] Kent, S., "Privacy Enhancement for Internet Electronic - Mail: Part II: Certificate-Based Key Management", RFC - 1422, February 1993. - - [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and - Languages", BCP 18, RFC 2277, January 1998. - - [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and CRL - Profile", RFC 2459, January 1999. - - [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. - Adams, "X.509 Internet Public Key Infrastructure Online - Certificate Status Protocol - OCSP", RFC 2560, June 1999. - - [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object - Classes and Attribute Types Version 2.0", RFC 2985, - November 2000. - - [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, - "Internet X.509 Public Key Infrastructure Time-Stamp - Protocol (TSP)", RFC 3161, August 2001. - - [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and - Identifiers for the Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 3279, April 2002. - - - - - -Cooper, et al. Standards Track [Page 107] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet - X.509 Public Key Infrastructure Certificate and - Certificate Revocation List (CRL) Profile", RFC 3280, - April 2002. - - [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional - Algorithms and Identifiers for RSA Cryptography for use in - the Internet X.509 Public Key Infrastructure Certificate - and Certificate Revocation List (CRL) Profile", RFC 4055, - June 2005. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC 4120, - July 2005. - - [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, - "Internet X.509 Public Key Infrastructure Certificate - Management Protocol (CMP)", RFC 4210, September 2005. - - [RFC4325] Santesson, S. and R. Housley, "Internet X.509 Public Key - Infrastructure Authority Information Access Certificate - Revocation List (CRL) Extension", RFC 4325, December 2005. - - [RFC4491] Leontiev, S., Ed., and D. Shefanovski, Ed., "Using the - GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 - Algorithms with the Internet X.509 Public Key - Infrastructure Certificate and CRL Profile", RFC 4491, May - 2006. - - [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Technical Specification Road Map", RFC 4510, June - 2006. - - [RFC4512] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): Directory Information Models", RFC 4512, June - 2006. - - [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol - (LDAP): String Representation of Distinguished Names", RFC - 4514, June 2006. - - [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol - (LDAP): Schema for User Applications", RFC 4519, June - 2006. - - - - - - - -Cooper, et al. Standards Track [Page 108] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - [RFC4630] Housley, R. and S. Santesson, "Update to DirectoryString - Processing in the Internet X.509 Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) - Profile", RFC 4630, August 2006. - - [X.500] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, - Information technology - Open Systems Interconnection - - The Directory: Overview of concepts, models and services. - - [X.501] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005, - Information technology - Open Systems Interconnection - - The Directory: Models. - - [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, - Information technology - Open Systems Interconnection - - The Directory: Public-key and attribute certificate - frameworks. - - [X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005, - Information technology - Open Systems Interconnection - - The Directory: Selected attribute types. - - [X.660] ITU-T Recommendation X.660 (2004) | ISO/IEC 9834-1:2005, - Information technology - Open Systems Interconnection - - Procedures for the operation of OSI Registration - Authorities: General procedures, and top arcs of the ASN.1 - Object Identifier tree. - - [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002, - Information technology - Abstract Syntax Notation One - (ASN.1): Parameterization of ASN.1 specifications. - - [X9.55] ANSI X9.55-1997, Public Key Cryptography for the Financial - Services Industry: Extensions to Public Key Certificates - and Certificate Revocation Lists, January 1997. - - - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 109] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -Appendix A. Pseudo-ASN.1 Structures and OIDs - - This appendix describes data objects used by conforming PKI - components in an "ASN.1-like" syntax. This syntax is a hybrid of the - 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented - with 1993 UNIVERSAL Types UniversalString, BMPString, and UTF8String. - - The ASN.1 syntax does not permit the inclusion of type statements in - the ASN.1 module, and the 1993 ASN.1 standard does not permit use of - the new UNIVERSAL types in modules using the 1988 syntax. As a - result, this module does not conform to either version of the ASN.1 - standard. - - This appendix may be converted into 1988 ASN.1 by replacing the - definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". - -A.1. Explicitly Tagged Module, 1988 Syntax - -PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } - -DEFINITIONS EXPLICIT TAGS ::= - -BEGIN - --- EXPORTS ALL -- - --- IMPORTS NONE -- - --- UNIVERSAL Types defined in 1993 and 1998 ASN.1 --- and required by this specification - -UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING - -- UniversalString is defined in ASN.1:1993 - -BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING - -- BMPString is the subtype of UniversalString and models - -- the Basic Multilingual Plane of ISO/IEC 10646 - -UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING - -- The content of this type conforms to RFC 3629. - --- PKIX specific OIDs - -id-pkix OBJECT IDENTIFIER ::= - { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) } - - - - -Cooper, et al. Standards Track [Page 110] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- PKIX arcs - -id-pe OBJECT IDENTIFIER ::= { id-pkix 1 } - -- arc for private certificate extensions -id-qt OBJECT IDENTIFIER ::= { id-pkix 2 } - -- arc for policy qualifier types -id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } - -- arc for extended key purpose OIDS -id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } - -- arc for access descriptors - --- policyQualifierIds for Internet policy qualifiers - -id-qt-cps OBJECT IDENTIFIER ::= { id-qt 1 } - -- OID for CPS qualifier -id-qt-unotice OBJECT IDENTIFIER ::= { id-qt 2 } - -- OID for user notice qualifier - --- access descriptor definitions - -id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } -id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 } -id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 } -id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 } - --- attribute data types - -Attribute ::= SEQUENCE { - type AttributeType, - values SET OF AttributeValue } - -- at least one value is required - -AttributeType ::= OBJECT IDENTIFIER - -AttributeValue ::= ANY -- DEFINED BY AttributeType - -AttributeTypeAndValue ::= SEQUENCE { - type AttributeType, - value AttributeValue } - --- suggested naming attributes: Definition of the following --- information object set may be augmented to meet local --- requirements. Note that deleting members of the set may --- prevent interoperability with conforming implementations. --- presented in pairs: the AttributeType followed by the --- type definition for the corresponding AttributeValue - - - - - -Cooper, et al. Standards Track [Page 111] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Arc for standard naming attributes - -id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 } - --- Naming attributes of type X520name - -id-at-name AttributeType ::= { id-at 41 } -id-at-surname AttributeType ::= { id-at 4 } -id-at-givenName AttributeType ::= { id-at 42 } -id-at-initials AttributeType ::= { id-at 43 } -id-at-generationQualifier AttributeType ::= { id-at 44 } - --- Naming attributes of type X520Name: --- X520name ::= DirectoryString (SIZE (1..ub-name)) --- --- Expanded to avoid parameterized type: -X520name ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-name)), - printableString PrintableString (SIZE (1..ub-name)), - universalString UniversalString (SIZE (1..ub-name)), - utf8String UTF8String (SIZE (1..ub-name)), - bmpString BMPString (SIZE (1..ub-name)) } - --- Naming attributes of type X520CommonName - -id-at-commonName AttributeType ::= { id-at 3 } - --- Naming attributes of type X520CommonName: --- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name)) --- --- Expanded to avoid parameterized type: -X520CommonName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-common-name)), - printableString PrintableString (SIZE (1..ub-common-name)), - universalString UniversalString (SIZE (1..ub-common-name)), - utf8String UTF8String (SIZE (1..ub-common-name)), - bmpString BMPString (SIZE (1..ub-common-name)) } - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 112] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Naming attributes of type X520LocalityName - -id-at-localityName AttributeType ::= { id-at 7 } - --- Naming attributes of type X520LocalityName: --- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name)) --- --- Expanded to avoid parameterized type: -X520LocalityName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-locality-name)), - printableString PrintableString (SIZE (1..ub-locality-name)), - universalString UniversalString (SIZE (1..ub-locality-name)), - utf8String UTF8String (SIZE (1..ub-locality-name)), - bmpString BMPString (SIZE (1..ub-locality-name)) } - --- Naming attributes of type X520StateOrProvinceName - -id-at-stateOrProvinceName AttributeType ::= { id-at 8 } - --- Naming attributes of type X520StateOrProvinceName: --- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name)) --- --- Expanded to avoid parameterized type: -X520StateOrProvinceName ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-state-name)), - printableString PrintableString (SIZE (1..ub-state-name)), - universalString UniversalString (SIZE (1..ub-state-name)), - utf8String UTF8String (SIZE (1..ub-state-name)), - bmpString BMPString (SIZE (1..ub-state-name)) } - - - - - - - - - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 113] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Naming attributes of type X520OrganizationName - -id-at-organizationName AttributeType ::= { id-at 10 } - --- Naming attributes of type X520OrganizationName: --- X520OrganizationName ::= --- DirectoryName (SIZE (1..ub-organization-name)) --- --- Expanded to avoid parameterized type: -X520OrganizationName ::= CHOICE { - teletexString TeletexString - (SIZE (1..ub-organization-name)), - printableString PrintableString - (SIZE (1..ub-organization-name)), - universalString UniversalString - (SIZE (1..ub-organization-name)), - utf8String UTF8String - (SIZE (1..ub-organization-name)), - bmpString BMPString - (SIZE (1..ub-organization-name)) } - --- Naming attributes of type X520OrganizationalUnitName - -id-at-organizationalUnitName AttributeType ::= { id-at 11 } - --- Naming attributes of type X520OrganizationalUnitName: --- X520OrganizationalUnitName ::= --- DirectoryName (SIZE (1..ub-organizational-unit-name)) --- --- Expanded to avoid parameterized type: -X520OrganizationalUnitName ::= CHOICE { - teletexString TeletexString - (SIZE (1..ub-organizational-unit-name)), - printableString PrintableString - (SIZE (1..ub-organizational-unit-name)), - universalString UniversalString - (SIZE (1..ub-organizational-unit-name)), - utf8String UTF8String - (SIZE (1..ub-organizational-unit-name)), - bmpString BMPString - (SIZE (1..ub-organizational-unit-name)) } - - - - - - - - - - -Cooper, et al. Standards Track [Page 114] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Naming attributes of type X520Title - -id-at-title AttributeType ::= { id-at 12 } - --- Naming attributes of type X520Title: --- X520Title ::= DirectoryName (SIZE (1..ub-title)) --- --- Expanded to avoid parameterized type: -X520Title ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-title)), - printableString PrintableString (SIZE (1..ub-title)), - universalString UniversalString (SIZE (1..ub-title)), - utf8String UTF8String (SIZE (1..ub-title)), - bmpString BMPString (SIZE (1..ub-title)) } - --- Naming attributes of type X520dnQualifier - -id-at-dnQualifier AttributeType ::= { id-at 46 } - -X520dnQualifier ::= PrintableString - --- Naming attributes of type X520countryName (digraph from IS 3166) - -id-at-countryName AttributeType ::= { id-at 6 } - -X520countryName ::= PrintableString (SIZE (2)) - --- Naming attributes of type X520SerialNumber - -id-at-serialNumber AttributeType ::= { id-at 5 } - -X520SerialNumber ::= PrintableString (SIZE (1..ub-serial-number)) - --- Naming attributes of type X520Pseudonym - -id-at-pseudonym AttributeType ::= { id-at 65 } - --- Naming attributes of type X520Pseudonym: --- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym)) --- --- Expanded to avoid parameterized type: -X520Pseudonym ::= CHOICE { - teletexString TeletexString (SIZE (1..ub-pseudonym)), - printableString PrintableString (SIZE (1..ub-pseudonym)), - universalString UniversalString (SIZE (1..ub-pseudonym)), - utf8String UTF8String (SIZE (1..ub-pseudonym)), - bmpString BMPString (SIZE (1..ub-pseudonym)) } - - - - -Cooper, et al. Standards Track [Page 115] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Naming attributes of type DomainComponent (from RFC 4519) - -id-domainComponent AttributeType ::= { 0 9 2342 19200300 100 1 25 } - -DomainComponent ::= IA5String - --- Legacy attributes - -pkcs-9 OBJECT IDENTIFIER ::= - { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 } - -id-emailAddress AttributeType ::= { pkcs-9 1 } - -EmailAddress ::= IA5String (SIZE (1..ub-emailaddress-length)) - --- naming data types -- - -Name ::= CHOICE { -- only one possibility for now -- - rdnSequence RDNSequence } - -RDNSequence ::= SEQUENCE OF RelativeDistinguishedName - -DistinguishedName ::= RDNSequence - -RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue - --- Directory string type -- - -DirectoryString ::= CHOICE { - teletexString TeletexString (SIZE (1..MAX)), - printableString PrintableString (SIZE (1..MAX)), - universalString UniversalString (SIZE (1..MAX)), - utf8String UTF8String (SIZE (1..MAX)), - bmpString BMPString (SIZE (1..MAX)) } - --- certificate and CRL specific structures begin here - -Certificate ::= SEQUENCE { - tbsCertificate TBSCertificate, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING } - - - - - - - - - - -Cooper, et al. Standards Track [Page 116] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -TBSCertificate ::= SEQUENCE { - version [0] Version DEFAULT v1, - serialNumber CertificateSerialNumber, - signature AlgorithmIdentifier, - issuer Name, - validity Validity, - subject Name, - subjectPublicKeyInfo SubjectPublicKeyInfo, - issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, - -- If present, version MUST be v2 or v3 - extensions [3] Extensions OPTIONAL - -- If present, version MUST be v3 -- } - -Version ::= INTEGER { v1(0), v2(1), v3(2) } - -CertificateSerialNumber ::= INTEGER - -Validity ::= SEQUENCE { - notBefore Time, - notAfter Time } - -Time ::= CHOICE { - utcTime UTCTime, - generalTime GeneralizedTime } - -UniqueIdentifier ::= BIT STRING - -SubjectPublicKeyInfo ::= SEQUENCE { - algorithm AlgorithmIdentifier, - subjectPublicKey BIT STRING } - -Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension - -Extension ::= SEQUENCE { - extnID OBJECT IDENTIFIER, - critical BOOLEAN DEFAULT FALSE, - extnValue OCTET STRING - -- contains the DER encoding of an ASN.1 value - -- corresponding to the extension type identified - -- by extnID - } - - - - - - - - -Cooper, et al. Standards Track [Page 117] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- CRL structures - -CertificateList ::= SEQUENCE { - tbsCertList TBSCertList, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING } - -TBSCertList ::= SEQUENCE { - version Version OPTIONAL, - -- if present, MUST be v2 - signature AlgorithmIdentifier, - issuer Name, - thisUpdate Time, - nextUpdate Time OPTIONAL, - revokedCertificates SEQUENCE OF SEQUENCE { - userCertificate CertificateSerialNumber, - revocationDate Time, - crlEntryExtensions Extensions OPTIONAL - -- if present, version MUST be v2 - } OPTIONAL, - crlExtensions [0] Extensions OPTIONAL } - -- if present, version MUST be v2 - --- Version, Time, CertificateSerialNumber, and Extensions were --- defined earlier for use in the certificate structure - -AlgorithmIdentifier ::= SEQUENCE { - algorithm OBJECT IDENTIFIER, - parameters ANY DEFINED BY algorithm OPTIONAL } - -- contains a value of the type - -- registered for use with the - -- algorithm object identifier value - --- X.400 address syntax starts here - -ORAddress ::= SEQUENCE { - built-in-standard-attributes BuiltInStandardAttributes, - built-in-domain-defined-attributes - BuiltInDomainDefinedAttributes OPTIONAL, - -- see also teletex-domain-defined-attributes - extension-attributes ExtensionAttributes OPTIONAL } - - - - - - - - - - -Cooper, et al. Standards Track [Page 118] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- Built-in Standard Attributes - -BuiltInStandardAttributes ::= SEQUENCE { - country-name CountryName OPTIONAL, - administration-domain-name AdministrationDomainName OPTIONAL, - network-address [0] IMPLICIT NetworkAddress OPTIONAL, - -- see also extended-network-address - terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL, - private-domain-name [2] PrivateDomainName OPTIONAL, - organization-name [3] IMPLICIT OrganizationName OPTIONAL, - -- see also teletex-organization-name - numeric-user-identifier [4] IMPLICIT NumericUserIdentifier - OPTIONAL, - personal-name [5] IMPLICIT PersonalName OPTIONAL, - -- see also teletex-personal-name - organizational-unit-names [6] IMPLICIT OrganizationalUnitNames - OPTIONAL } - -- see also teletex-organizational-unit-names - -CountryName ::= [APPLICATION 1] CHOICE { - x121-dcc-code NumericString - (SIZE (ub-country-name-numeric-length)), - iso-3166-alpha2-code PrintableString - (SIZE (ub-country-name-alpha-length)) } - -AdministrationDomainName ::= [APPLICATION 2] CHOICE { - numeric NumericString (SIZE (0..ub-domain-name-length)), - printable PrintableString (SIZE (0..ub-domain-name-length)) } - -NetworkAddress ::= X121Address -- see also extended-network-address - -X121Address ::= NumericString (SIZE (1..ub-x121-address-length)) - -TerminalIdentifier ::= PrintableString (SIZE (1..ub-terminal-id-length)) - -PrivateDomainName ::= CHOICE { - numeric NumericString (SIZE (1..ub-domain-name-length)), - printable PrintableString (SIZE (1..ub-domain-name-length)) } - -OrganizationName ::= PrintableString - (SIZE (1..ub-organization-name-length)) - -- see also teletex-organization-name - -NumericUserIdentifier ::= NumericString - (SIZE (1..ub-numeric-user-id-length)) - - - - - - -Cooper, et al. Standards Track [Page 119] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -PersonalName ::= SET { - surname [0] IMPLICIT PrintableString - (SIZE (1..ub-surname-length)), - given-name [1] IMPLICIT PrintableString - (SIZE (1..ub-given-name-length)) OPTIONAL, - initials [2] IMPLICIT PrintableString - (SIZE (1..ub-initials-length)) OPTIONAL, - generation-qualifier [3] IMPLICIT PrintableString - (SIZE (1..ub-generation-qualifier-length)) - OPTIONAL } - -- see also teletex-personal-name - -OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units) - OF OrganizationalUnitName - -- see also teletex-organizational-unit-names - -OrganizationalUnitName ::= PrintableString (SIZE - (1..ub-organizational-unit-name-length)) - --- Built-in Domain-defined Attributes - -BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE - (1..ub-domain-defined-attributes) OF - BuiltInDomainDefinedAttribute - -BuiltInDomainDefinedAttribute ::= SEQUENCE { - type PrintableString (SIZE - (1..ub-domain-defined-attribute-type-length)), - value PrintableString (SIZE - (1..ub-domain-defined-attribute-value-length)) } - --- Extension Attributes - -ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF - ExtensionAttribute - -ExtensionAttribute ::= SEQUENCE { - extension-attribute-type [0] IMPLICIT INTEGER - (0..ub-extension-attributes), - extension-attribute-value [1] - ANY DEFINED BY extension-attribute-type } - --- Extension types and attribute values - -common-name INTEGER ::= 1 - -CommonName ::= PrintableString (SIZE (1..ub-common-name-length)) - - - - -Cooper, et al. Standards Track [Page 120] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -teletex-common-name INTEGER ::= 2 - -TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length)) - -teletex-organization-name INTEGER ::= 3 - -TeletexOrganizationName ::= - TeletexString (SIZE (1..ub-organization-name-length)) - -teletex-personal-name INTEGER ::= 4 - -TeletexPersonalName ::= SET { - surname [0] IMPLICIT TeletexString - (SIZE (1..ub-surname-length)), - given-name [1] IMPLICIT TeletexString - (SIZE (1..ub-given-name-length)) OPTIONAL, - initials [2] IMPLICIT TeletexString - (SIZE (1..ub-initials-length)) OPTIONAL, - generation-qualifier [3] IMPLICIT TeletexString - (SIZE (1..ub-generation-qualifier-length)) - OPTIONAL } - -teletex-organizational-unit-names INTEGER ::= 5 - -TeletexOrganizationalUnitNames ::= SEQUENCE SIZE - (1..ub-organizational-units) OF TeletexOrganizationalUnitName - -TeletexOrganizationalUnitName ::= TeletexString - (SIZE (1..ub-organizational-unit-name-length)) - -pds-name INTEGER ::= 7 - -PDSName ::= PrintableString (SIZE (1..ub-pds-name-length)) - -physical-delivery-country-name INTEGER ::= 8 - -PhysicalDeliveryCountryName ::= CHOICE { - x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), - iso-3166-alpha2-code PrintableString - (SIZE (ub-country-name-alpha-length)) } - -postal-code INTEGER ::= 9 - -PostalCode ::= CHOICE { - numeric-code NumericString (SIZE (1..ub-postal-code-length)), - printable-code PrintableString (SIZE (1..ub-postal-code-length)) } - -physical-delivery-office-name INTEGER ::= 10 - - - -Cooper, et al. Standards Track [Page 121] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -PhysicalDeliveryOfficeName ::= PDSParameter - -physical-delivery-office-number INTEGER ::= 11 - -PhysicalDeliveryOfficeNumber ::= PDSParameter - -extension-OR-address-components INTEGER ::= 12 - -ExtensionORAddressComponents ::= PDSParameter - -physical-delivery-personal-name INTEGER ::= 13 - -PhysicalDeliveryPersonalName ::= PDSParameter - -physical-delivery-organization-name INTEGER ::= 14 - -PhysicalDeliveryOrganizationName ::= PDSParameter - -extension-physical-delivery-address-components INTEGER ::= 15 - -ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter - -unformatted-postal-address INTEGER ::= 16 - -UnformattedPostalAddress ::= SET { - printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines) - OF PrintableString (SIZE (1..ub-pds-parameter-length)) OPTIONAL, - teletex-string TeletexString - (SIZE (1..ub-unformatted-address-length)) OPTIONAL } - -street-address INTEGER ::= 17 - -StreetAddress ::= PDSParameter - -post-office-box-address INTEGER ::= 18 - -PostOfficeBoxAddress ::= PDSParameter - -poste-restante-address INTEGER ::= 19 - -PosteRestanteAddress ::= PDSParameter - -unique-postal-name INTEGER ::= 20 - -UniquePostalName ::= PDSParameter - -local-postal-attributes INTEGER ::= 21 - - - - -Cooper, et al. Standards Track [Page 122] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -LocalPostalAttributes ::= PDSParameter - -PDSParameter ::= SET { - printable-string PrintableString - (SIZE(1..ub-pds-parameter-length)) OPTIONAL, - teletex-string TeletexString - (SIZE(1..ub-pds-parameter-length)) OPTIONAL } - -extended-network-address INTEGER ::= 22 - -ExtendedNetworkAddress ::= CHOICE { - e163-4-address SEQUENCE { - number [0] IMPLICIT NumericString - (SIZE (1..ub-e163-4-number-length)), - sub-address [1] IMPLICIT NumericString - (SIZE (1..ub-e163-4-sub-address-length)) - OPTIONAL }, - psap-address [0] IMPLICIT PresentationAddress } - -PresentationAddress ::= SEQUENCE { - pSelector [0] EXPLICIT OCTET STRING OPTIONAL, - sSelector [1] EXPLICIT OCTET STRING OPTIONAL, - tSelector [2] EXPLICIT OCTET STRING OPTIONAL, - nAddresses [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING } - -terminal-type INTEGER ::= 23 - -TerminalType ::= INTEGER { - telex (3), - teletex (4), - g3-facsimile (5), - g4-facsimile (6), - ia5-terminal (7), - videotex (8) } (0..ub-integer-options) - --- Extension Domain-defined Attributes - -teletex-domain-defined-attributes INTEGER ::= 6 - -TeletexDomainDefinedAttributes ::= SEQUENCE SIZE - (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute - -TeletexDomainDefinedAttribute ::= SEQUENCE { - type TeletexString - (SIZE (1..ub-domain-defined-attribute-type-length)), - value TeletexString - (SIZE (1..ub-domain-defined-attribute-value-length)) } - - - - -Cooper, et al. Standards Track [Page 123] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- specifications of Upper Bounds MUST be regarded as mandatory --- from Annex B of ITU-T X.411 Reference Definition of MTS Parameter --- Upper Bounds - --- Upper Bounds -ub-name INTEGER ::= 32768 -ub-common-name INTEGER ::= 64 -ub-locality-name INTEGER ::= 128 -ub-state-name INTEGER ::= 128 -ub-organization-name INTEGER ::= 64 -ub-organizational-unit-name INTEGER ::= 64 -ub-title INTEGER ::= 64 -ub-serial-number INTEGER ::= 64 -ub-match INTEGER ::= 128 -ub-emailaddress-length INTEGER ::= 255 -ub-common-name-length INTEGER ::= 64 -ub-country-name-alpha-length INTEGER ::= 2 -ub-country-name-numeric-length INTEGER ::= 3 -ub-domain-defined-attributes INTEGER ::= 4 -ub-domain-defined-attribute-type-length INTEGER ::= 8 -ub-domain-defined-attribute-value-length INTEGER ::= 128 -ub-domain-name-length INTEGER ::= 16 -ub-extension-attributes INTEGER ::= 256 -ub-e163-4-number-length INTEGER ::= 15 -ub-e163-4-sub-address-length INTEGER ::= 40 -ub-generation-qualifier-length INTEGER ::= 3 -ub-given-name-length INTEGER ::= 16 -ub-initials-length INTEGER ::= 5 -ub-integer-options INTEGER ::= 256 -ub-numeric-user-id-length INTEGER ::= 32 -ub-organization-name-length INTEGER ::= 64 -ub-organizational-unit-name-length INTEGER ::= 32 -ub-organizational-units INTEGER ::= 4 -ub-pds-name-length INTEGER ::= 16 -ub-pds-parameter-length INTEGER ::= 30 -ub-pds-physical-address-lines INTEGER ::= 6 -ub-postal-code-length INTEGER ::= 16 -ub-pseudonym INTEGER ::= 128 -ub-surname-length INTEGER ::= 40 -ub-terminal-id-length INTEGER ::= 24 -ub-unformatted-address-length INTEGER ::= 180 -ub-x121-address-length INTEGER ::= 16 - --- Note - upper bounds on string types, such as TeletexString, are --- measured in characters. Excepting PrintableString or IA5String, a --- significantly greater number of octets will be required to hold --- such a value. As a minimum, 16 octets, or twice the specified --- upper bound, whichever is the larger, should be allowed for - - - -Cooper, et al. Standards Track [Page 124] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- TeletexString. For UTF8String or UniversalString at least four --- times the upper bound should be allowed. - -END - -A.2. Implicitly Tagged Module, 1988 Syntax - -PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1) - security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) } - -DEFINITIONS IMPLICIT TAGS ::= - -BEGIN - --- EXPORTS ALL -- - -IMPORTS - id-pe, id-kp, id-qt-unotice, id-qt-cps, - -- delete following line if "new" types are supported -- - BMPString, UTF8String, -- end "new" types -- - ORAddress, Name, RelativeDistinguishedName, - CertificateSerialNumber, Attribute, DirectoryString - FROM PKIX1Explicit88 { iso(1) identified-organization(3) - dod(6) internet(1) security(5) mechanisms(5) pkix(7) - id-mod(0) id-pkix1-explicit(18) }; - --- ISO arc for standard certificate and CRL extensions - -id-ce OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5) 29} - --- authority key identifier OID and syntax - -id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 } - -AuthorityKeyIdentifier ::= SEQUENCE { - keyIdentifier [0] KeyIdentifier OPTIONAL, - authorityCertIssuer [1] GeneralNames OPTIONAL, - authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL } - -- authorityCertIssuer and authorityCertSerialNumber MUST both - -- be present or both be absent - -KeyIdentifier ::= OCTET STRING - - - - - - - - - -Cooper, et al. Standards Track [Page 125] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- subject key identifier OID and syntax - -id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 14 } - -SubjectKeyIdentifier ::= KeyIdentifier - --- key usage extension OID and syntax - -id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } - -KeyUsage ::= BIT STRING { - digitalSignature (0), - nonRepudiation (1), -- recent editions of X.509 have - -- renamed this bit to contentCommitment - keyEncipherment (2), - dataEncipherment (3), - keyAgreement (4), - keyCertSign (5), - cRLSign (6), - encipherOnly (7), - decipherOnly (8) } - --- private key usage period extension OID and syntax - -id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::= { id-ce 16 } - -PrivateKeyUsagePeriod ::= SEQUENCE { - notBefore [0] GeneralizedTime OPTIONAL, - notAfter [1] GeneralizedTime OPTIONAL } - -- either notBefore or notAfter MUST be present - --- certificate policies extension OID and syntax - -id-ce-certificatePolicies OBJECT IDENTIFIER ::= { id-ce 32 } - -anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } - -CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation - -PolicyInformation ::= SEQUENCE { - policyIdentifier CertPolicyId, - policyQualifiers SEQUENCE SIZE (1..MAX) OF - PolicyQualifierInfo OPTIONAL } - -CertPolicyId ::= OBJECT IDENTIFIER - - - - - - -Cooper, et al. Standards Track [Page 126] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -PolicyQualifierInfo ::= SEQUENCE { - policyQualifierId PolicyQualifierId, - qualifier ANY DEFINED BY policyQualifierId } - --- Implementations that recognize additional policy qualifiers MUST --- augment the following definition for PolicyQualifierId - -PolicyQualifierId ::= OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice ) - --- CPS pointer qualifier - -CPSuri ::= IA5String - --- user notice qualifier - -UserNotice ::= SEQUENCE { - noticeRef NoticeReference OPTIONAL, - explicitText DisplayText OPTIONAL } - -NoticeReference ::= SEQUENCE { - organization DisplayText, - noticeNumbers SEQUENCE OF INTEGER } - -DisplayText ::= CHOICE { - ia5String IA5String (SIZE (1..200)), - visibleString VisibleString (SIZE (1..200)), - bmpString BMPString (SIZE (1..200)), - utf8String UTF8String (SIZE (1..200)) } - --- policy mapping extension OID and syntax - -id-ce-policyMappings OBJECT IDENTIFIER ::= { id-ce 33 } - -PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { - issuerDomainPolicy CertPolicyId, - subjectDomainPolicy CertPolicyId } - --- subject alternative name extension OID and syntax - -id-ce-subjectAltName OBJECT IDENTIFIER ::= { id-ce 17 } - -SubjectAltName ::= GeneralNames - -GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName - - - - - - - -Cooper, et al. Standards Track [Page 127] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -GeneralName ::= CHOICE { - otherName [0] AnotherName, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] ORAddress, - directoryName [4] Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER } - --- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as --- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax - -AnotherName ::= SEQUENCE { - type-id OBJECT IDENTIFIER, - value [0] EXPLICIT ANY DEFINED BY type-id } - -EDIPartyName ::= SEQUENCE { - nameAssigner [0] DirectoryString OPTIONAL, - partyName [1] DirectoryString } - --- issuer alternative name extension OID and syntax - -id-ce-issuerAltName OBJECT IDENTIFIER ::= { id-ce 18 } - -IssuerAltName ::= GeneralNames - -id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= { id-ce 9 } - -SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute - --- basic constraints extension OID and syntax - -id-ce-basicConstraints OBJECT IDENTIFIER ::= { id-ce 19 } - -BasicConstraints ::= SEQUENCE { - cA BOOLEAN DEFAULT FALSE, - pathLenConstraint INTEGER (0..MAX) OPTIONAL } - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 128] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- name constraints extension OID and syntax - -id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 } - -NameConstraints ::= SEQUENCE { - permittedSubtrees [0] GeneralSubtrees OPTIONAL, - excludedSubtrees [1] GeneralSubtrees OPTIONAL } - -GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree - -GeneralSubtree ::= SEQUENCE { - base GeneralName, - minimum [0] BaseDistance DEFAULT 0, - maximum [1] BaseDistance OPTIONAL } - -BaseDistance ::= INTEGER (0..MAX) - --- policy constraints extension OID and syntax - -id-ce-policyConstraints OBJECT IDENTIFIER ::= { id-ce 36 } - -PolicyConstraints ::= SEQUENCE { - requireExplicitPolicy [0] SkipCerts OPTIONAL, - inhibitPolicyMapping [1] SkipCerts OPTIONAL } - -SkipCerts ::= INTEGER (0..MAX) - --- CRL distribution points extension OID and syntax - -id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 31} - -CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint - -DistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - reasons [1] ReasonFlags OPTIONAL, - cRLIssuer [2] GeneralNames OPTIONAL } - -DistributionPointName ::= CHOICE { - fullName [0] GeneralNames, - nameRelativeToCRLIssuer [1] RelativeDistinguishedName } - - - - - - - - - - -Cooper, et al. Standards Track [Page 129] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -ReasonFlags ::= BIT STRING { - unused (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - privilegeWithdrawn (7), - aACompromise (8) } - --- extended key usage extension OID and syntax - -id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37} - -ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId - -KeyPurposeId ::= OBJECT IDENTIFIER - --- permit unspecified key uses - -anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } - --- extended key purpose OIDs - -id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } -id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 } -id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 } -id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 } -id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 } -id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 } - --- inhibit any policy OID and syntax - -id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::= { id-ce 54 } - -InhibitAnyPolicy ::= SkipCerts - --- freshest (delta)CRL extension OID and syntax - -id-ce-freshestCRL OBJECT IDENTIFIER ::= { id-ce 46 } - -FreshestCRL ::= CRLDistributionPoints - - - - - - - - -Cooper, et al. Standards Track [Page 130] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- authority info access - -id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 } - -AuthorityInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - -AccessDescription ::= SEQUENCE { - accessMethod OBJECT IDENTIFIER, - accessLocation GeneralName } - --- subject info access - -id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 } - -SubjectInfoAccessSyntax ::= - SEQUENCE SIZE (1..MAX) OF AccessDescription - --- CRL number extension OID and syntax - -id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } - -CRLNumber ::= INTEGER (0..MAX) - --- issuing distribution point extension OID and syntax - -id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 } - -IssuingDistributionPoint ::= SEQUENCE { - distributionPoint [0] DistributionPointName OPTIONAL, - onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, - onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, - onlySomeReasons [3] ReasonFlags OPTIONAL, - indirectCRL [4] BOOLEAN DEFAULT FALSE, - onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } - -- at most one of onlyContainsUserCerts, onlyContainsCACerts, - -- and onlyContainsAttributeCerts may be set to TRUE. - -id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 } - -BaseCRLNumber ::= CRLNumber - - - - - - - - - - -Cooper, et al. Standards Track [Page 131] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- reason code extension OID and syntax - -id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 } - -CRLReason ::= ENUMERATED { - unspecified (0), - keyCompromise (1), - cACompromise (2), - affiliationChanged (3), - superseded (4), - cessationOfOperation (5), - certificateHold (6), - removeFromCRL (8), - privilegeWithdrawn (9), - aACompromise (10) } - --- certificate issuer CRL entry extension OID and syntax - -id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 } - -CertificateIssuer ::= GeneralNames - --- hold instruction extension OID and syntax - -id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 } - -HoldInstructionCode ::= OBJECT IDENTIFIER - --- ANSI x9 arc holdinstruction arc - -holdInstruction OBJECT IDENTIFIER ::= - {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2} - --- ANSI X9 holdinstructions - -id-holdinstruction-none OBJECT IDENTIFIER ::= - {holdInstruction 1} -- deprecated - -id-holdinstruction-callissuer OBJECT IDENTIFIER ::= {holdInstruction 2} - -id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3} - - - - - - - - - - -Cooper, et al. Standards Track [Page 132] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - --- invalidity date CRL entry extension OID and syntax - -id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 } - -InvalidityDate ::= GeneralizedTime - -END - -Appendix B. ASN.1 Notes - - CAs MUST force the serialNumber to be a non-negative integer, that - is, the sign bit in the DER encoding of the INTEGER value MUST be - zero. This can be done by adding a leading (leftmost) `00'H octet if - necessary. This removes a potential ambiguity in mapping between a - string of octets and an integer value. - - As noted in Section 4.1.2.2, serial numbers can be expected to - contain long integers. Certificate users MUST be able to handle - serialNumber values up to 20 octets in length. Conforming CAs MUST - NOT use serialNumber values longer than 20 octets. - - As noted in Section 5.2.3, CRL numbers can be expected to contain - long integers. CRL validators MUST be able to handle cRLNumber - values up to 20 octets in length. Conforming CRL issuers MUST NOT - use cRLNumber values longer than 20 octets. - - The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 - constructs. A valid ASN.1 sequence will have zero or more entries. - The SIZE (1..MAX) construct constrains the sequence to have at least - one entry. MAX indicates that the upper bound is unspecified. - Implementations are free to choose an upper bound that suits their - environment. - - The character string type PrintableString supports a very basic Latin - character set: the lowercase letters 'a' through 'z', uppercase - letters 'A' through 'Z', the digits '0' through '9', eleven special - characters ' = ( ) + , - . / : ? and space. - - Implementers should note that the at sign ('@') and underscore ('_') - characters are not supported by the ASN.1 type PrintableString. - These characters often appear in Internet addresses. Such addresses - MUST be encoded using an ASN.1 type that supports them. They are - usually encoded as IA5String in either the emailAddress attribute - within a distinguished name or the rfc822Name field of GeneralName. - Conforming implementations MUST NOT encode strings that include - either the at sign or underscore character as PrintableString. - - - - - -Cooper, et al. Standards Track [Page 133] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - The character string type TeletexString is a superset of - PrintableString. TeletexString supports a fairly standard (ASCII- - like) Latin character set: Latin characters with non-spacing accents - and Japanese characters. - - Named bit lists are BIT STRINGs where the values have been assigned - names. This specification makes use of named bit lists in the - definitions for the key usage, CRL distribution points, and freshest - CRL certificate extensions, as well as the freshest CRL and issuing - distribution point CRL extensions. When DER encoding a named bit - list, trailing zeros MUST be omitted. That is, the encoded value - ends with the last named bit that is set to one. - - The character string type UniversalString supports any of the - characters allowed by [ISO10646]. ISO 10646 is the Universal - multiple-octet coded Character Set (UCS). - - The character string type UTF8String was introduced in the 1997 - version of ASN.1, and UTF8String was added to the list of choices for - DirectoryString in the 2001 version of [X.520]. UTF8String is a - universal type and has been assigned tag number 12. The content of - UTF8String was defined by RFC 2044 and updated in RFC 2279, which was - updated in [RFC3629]. - - In anticipation of these changes, and in conformance with IETF Best - Practices codified in [RFC2277], IETF Policy on Character Sets and - Languages, this document includes UTF8String as a choice in - DirectoryString and in the userNotice certificate policy qualifier. - - For many of the attribute types defined in [X.520], the - AttributeValue uses the DirectoryString type. Of the attributes - specified in Appendix A, the name, surname, givenName, initials, - generationQualifier, commonName, localityName, stateOrProvinceName, - organizationName, organizationalUnitName, title, and pseudonym - attributes all use the DirectoryString type. X.520 uses a - parameterized type definition [X.683] of DirectoryString to specify - the syntax for each of these attributes. The parameter is used to - indicate the maximum string length allowed for the attribute. In - Appendix A, in order to avoid the use of parameterized type - definitions, the DirectoryString type is written in its expanded form - for the definition of each of these attribute types. So, the ASN.1 - in Appendix A describes the syntax for each of these attributes as - being a CHOICE of TeletexString, PrintableString, UniversalString, - UTF8String, and BMPString, with the appropriate constraints on the - string length applied to each of the types in the CHOICE, rather than - using the ASN.1 type DirectoryString to describe the syntax. - - - - - -Cooper, et al. Standards Track [Page 134] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - Implementers should note that the DER encoding of the SET OF values - requires ordering of the encodings of the values. In particular, - this issue arises with respect to distinguished names. - - Implementers should note that the DER encoding of SET or SEQUENCE - components whose value is the DEFAULT omit the component from the - encoded certificate or CRL. For example, a BasicConstraints - extension whose cA value is FALSE would omit the cA boolean from the - encoded certificate. - - Object Identifiers (OIDs) are used throughout this specification to - identify certificate policies, public key and signature algorithms, - certificate extensions, etc. There is no maximum size for OIDs. - This specification mandates support for OIDs that have arc elements - with values that are less than 2^28, that is, they MUST be between 0 - and 268,435,455, inclusive. This allows each arc element to be - represented within a single 32-bit word. Implementations MUST also - support OIDs where the length of the dotted decimal (see Section 1.4 - of [RFC4512]) string representation can be up to 100 bytes - (inclusive). Implementations MUST be able to handle OIDs with up to - 20 elements (inclusive). CAs SHOULD NOT issue certificates that - contain OIDs that exceed these requirements. Likewise, CRL issuers - SHOULD NOT issue CRLs that contain OIDs that exceed these - requirements. - - The content-specific rules for encoding GeneralName field values in - the nameConstraints extension differ from rules that apply in other - extensions. In all other certificate, CRL, and CRL entry extensions - specified in this document the encoding rules conform to the rules - for the underlying type. For example, values in the - uniformResourceIdentifier field must contain a valid URI as specified - in [RFC3986]. The content-specific rules for encoding values in the - nameConstraints extension are specified in Section 4.2.1.10, and - these rules may not conform to the rules for the underlying type. - For example, when the uniformResourceIdentifier field appears in a - nameConstraints extension, it must hold a DNS name (e.g., - "host.example.com" or ".example.com") rather than a URI. - - Implementors are warned that the X.500 standards community has - developed a series of extensibility rules. These rules determine - when an ASN.1 definition can be changed without assigning a new - Object Identifier (OID). For example, at least two extension - definitions included in [RFC2459], the predecessor to this profile - document, have different ASN.1 definitions in this specification, but - the same OID is used. If unknown elements appear within an - extension, and the extension is not marked as critical, those unknown - elements ought to be ignored, as follows: - - - - -Cooper, et al. Standards Track [Page 135] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (a) ignore all unknown bit name assignments within a bit string; - - (b) ignore all unknown named numbers in an ENUMERATED type or - INTEGER type that is being used in the enumerated style, - provided the number occurs as an optional element of a SET or - SEQUENCE; and - - (c) ignore all unknown elements in SETs, at the end of SEQUENCEs, - or in CHOICEs where the CHOICE is itself an optional element - of a SET or SEQUENCE. - - If an extension containing unexpected values is marked as critical, - the implementation MUST reject the certificate or CRL containing the - unrecognized extension. - -Appendix C. Examples - - This appendix contains four examples: three certificates and a CRL. - The first two certificates and the CRL comprise a minimal - certification path. - - Appendix C.1 contains an annotated hex dump of a "self-signed" - certificate issued by a CA whose distinguished name is - cn=Example CA,dc=example,dc=com. The certificate contains an RSA - public key, and is signed by the corresponding RSA private key. - - Appendix C.2 contains an annotated hex dump of an end entity - certificate. The end entity certificate contains an RSA public key, - and is signed by the private key corresponding to the "self-signed" - certificate in Appendix C.1. - - Appendix C.3 contains an annotated hex dump of an end entity - certificate that contains a DSA public key with parameters, and is - signed with DSA and SHA-1. This certificate is not part of the - minimal certification path. - - Appendix C.4 contains an annotated hex dump of a CRL. The CRL is - issued by the CA whose distinguished name is - cn=Example CA,dc=example,dc=com and the list of revoked certificates - includes the end entity certificate presented in Appendix C.2. - - The certificates were processed using Peter Gutmann's dumpasn1 - utility to generate the output. The source for the dumpasn1 utility - is available at . - The binaries for the certificates and CRLs are available at - http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/pkixtools. - - - - - -Cooper, et al. Standards Track [Page 136] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - In places in this appendix where a distinguished name is specified - using a string representation, the strings are formatted using the - rules specified in [RFC4514]. - -C.1. RSA Self-Signed Certificate - - This appendix contains an annotated hex dump of a 578 byte version 3 - certificate. The certificate contains the following information: - - (a) the serial number is 17; - (b) the certificate is signed with RSA and the SHA-1 hash algorithm; - (c) the issuer's distinguished name is - cn=Example CA,dc=example,dc=com; - (d) the subject's distinguished name is - cn=Example CA,dc=example,dc=com; - (e) the certificate was issued on April 30, 2004 and expired on - April 30, 2005; - (f) the certificate contains a 1024-bit RSA public key; - (g) the certificate contains a subject key identifier extension - generated using method (1) of Section 4.2.1.2; and - (h) the certificate is a CA certificate (as indicated through the - basic constraints extension). - - 0 574: SEQUENCE { - 4 423: SEQUENCE { - 8 3: [0] { - 10 1: INTEGER 2 - : } - 13 1: INTEGER 17 - 16 13: SEQUENCE { - 18 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 29 0: NULL - : } - 31 67: SEQUENCE { - 33 19: SET { - 35 17: SEQUENCE { - 37 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 49 3: IA5String 'com' - : } - : } - 54 23: SET { - 56 21: SEQUENCE { - 58 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 70 7: IA5String 'example' - : } - - - -Cooper, et al. Standards Track [Page 137] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : } - 79 19: SET { - 81 17: SEQUENCE { - 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 88 10: PrintableString 'Example CA' - : } - : } - : } - 100 30: SEQUENCE { - 102 13: UTCTime 30/04/2004 14:25:34 GMT - 117 13: UTCTime 30/04/2005 14:25:34 GMT - : } - 132 67: SEQUENCE { - 134 19: SET { - 136 17: SEQUENCE { - 138 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 150 3: IA5String 'com' - : } - : } - 155 23: SET { - 157 21: SEQUENCE { - 159 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 171 7: IA5String 'example' - : } - : } - 180 19: SET { - 182 17: SEQUENCE { - 184 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 189 10: PrintableString 'Example CA' - : } - : } - : } - 201 159: SEQUENCE { - 204 13: SEQUENCE { - 206 9: OBJECT IDENTIFIER - : rsaEncryption (1 2 840 113549 1 1 1) - 217 0: NULL - : } - 219 141: BIT STRING, encapsulates { - 223 137: SEQUENCE { - 226 129: INTEGER - : 00 C2 D7 97 6D 28 70 AA 5B CF 23 2E 80 70 39 EE - : DB 6F D5 2D D5 6A 4F 7A 34 2D F9 22 72 47 70 1D - : EF 80 E9 CA 30 8C 00 C4 9A 6E 5B 45 B4 6E A5 E6 - : 6C 94 0D FA 91 E9 40 FC 25 9D C7 B7 68 19 56 8F - : 11 70 6A D7 F1 C9 11 4F 3A 7E 3F 99 8D 6E 76 A5 - - - -Cooper, et al. Standards Track [Page 138] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : 74 5F 5E A4 55 53 E5 C7 68 36 53 C7 1D 3B 12 A6 - : 85 FE BD 6E A1 CA DF 35 50 AC 08 D7 B9 B4 7E 5C - : FE E2 A3 2C D1 23 84 AA 98 C0 9B 66 18 9A 68 47 - : E9 - 358 3: INTEGER 65537 - : } - : } - : } - 363 66: [3] { - 365 64: SEQUENCE { - 367 29: SEQUENCE { - 369 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) - 374 22: OCTET STRING, encapsulates { - 376 20: OCTET STRING - : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A 4A - : 20 84 2C 32 - : } - : } - 398 14: SEQUENCE { - 400 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) - 405 1: BOOLEAN TRUE - 408 4: OCTET STRING, encapsulates { - 410 2: BIT STRING 1 unused bits - : '0000011'B - : } - : } - 414 15: SEQUENCE { - 416 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) - 421 1: BOOLEAN TRUE - 424 5: OCTET STRING, encapsulates { - 426 3: SEQUENCE { - 428 1: BOOLEAN TRUE - : } - : } - : } - : } - : } - : } - 431 13: SEQUENCE { - 433 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 444 0: NULL - : } - 446 129: BIT STRING - : 6C F8 02 74 A6 61 E2 64 04 A6 54 0C 6C 72 13 AD - : 3C 47 FB F6 65 13 A9 85 90 33 EA 76 A3 26 D9 FC - : D1 0E 15 5F 28 B7 EF 93 BF 3C F3 E2 3E 7C B9 52 - : FC 16 6E 29 AA E1 F4 7A 6F D5 7F EF B3 95 CA F3 - - - -Cooper, et al. Standards Track [Page 139] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : 66 88 83 4E A1 35 45 84 CB BC 9B B8 C8 AD C5 5E - : 46 D9 0B 0E 8D 80 E1 33 2B DC BE 2B 92 7E 4A 43 - : A9 6A EF 8A 63 61 B3 6E 47 38 BE E8 0D A3 67 5D - : F3 FA 91 81 3C 92 BB C5 5F 25 25 EB 7C E7 D8 A1 - : } - -C.2. End Entity Certificate Using RSA - - This appendix contains an annotated hex dump of a 629-byte version 3 - certificate. The certificate contains the following information: - - (a) the serial number is 18; - (b) the certificate is signed with RSA and the SHA-1 hash algorithm; - (c) the issuer's distinguished name is - cn=Example CA,dc=example,dc=com; - (d) the subject's distinguished name is - cn=End Entity,dc=example,dc=com; - (e) the certificate was valid from September 15, 2004 through March - 15, 2005; - (f) the certificate contains a 1024-bit RSA public key; - (g) the certificate is an end entity certificate, as the basic - constraints extension is not present; - (h) the certificate contains an authority key identifier extension - matching the subject key identifier of the certificate in - appendix C.1; and - (i) the certificate includes one alternative name -- an electronic - mail address (rfc822Name) of "end.entity@example.com". - - 0 625: SEQUENCE { - 4 474: SEQUENCE { - 8 3: [0] { - 10 1: INTEGER 2 - : } - 13 1: INTEGER 18 - 16 13: SEQUENCE { - 18 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 29 0: NULL - : } - 31 67: SEQUENCE { - 33 19: SET { - 35 17: SEQUENCE { - 37 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 49 3: IA5String 'com' - : } - : } - 54 23: SET { - - - -Cooper, et al. Standards Track [Page 140] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 56 21: SEQUENCE { - 58 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 70 7: IA5String 'example' - : } - : } - 79 19: SET { - 81 17: SEQUENCE { - 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 88 10: PrintableString 'Example CA' - : } - : } - : } - 100 30: SEQUENCE { - 102 13: UTCTime 15/09/2004 11:48:21 GMT - 117 13: UTCTime 15/03/2005 11:48:21 GMT - : } - 132 67: SEQUENCE { - 134 19: SET { - 136 17: SEQUENCE { - 138 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 150 3: IA5String 'com' - : } - : } - 155 23: SET { - 157 21: SEQUENCE { - 159 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 171 7: IA5String 'example' - : } - : } - 180 19: SET { - 182 17: SEQUENCE { - 184 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 189 10: PrintableString 'End Entity' - : } - : } - : } - 201 159: SEQUENCE { - 204 13: SEQUENCE { - 206 9: OBJECT IDENTIFIER - : rsaEncryption (1 2 840 113549 1 1 1) - 217 0: NULL - : } - 219 141: BIT STRING, encapsulates { - 223 137: SEQUENCE { - 226 129: INTEGER - - - -Cooper, et al. Standards Track [Page 141] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : 00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E 4D 7F - : 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75 EC ED B6 56 - : 96 7F 88 99 85 9A F2 3E 68 77 87 EB 9E D1 9F C0 - : B4 17 DC AB 89 23 A4 1D 7E 16 23 4C 4F A8 4D F5 - : 31 B8 7C AA E3 1A 49 09 F4 4B 26 DB 27 67 30 82 - : 12 01 4A E9 1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC - : 33 36 7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2 - : 2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16 95 FF - : 23 - 358 3: INTEGER 65537 - : } - : } - : } - 363 117: [3] { - 365 115: SEQUENCE { - 367 33: SEQUENCE { - 369 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) - 374 26: OCTET STRING, encapsulates { - 376 24: SEQUENCE { - 378 22: [1] 'end.entity@example.com' - : } - : } - : } - 402 29: SEQUENCE { - 404 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) - 409 22: OCTET STRING, encapsulates { - 411 20: OCTET STRING - : 17 7B 92 30 FF 44 D6 66 E1 90 10 22 6C 16 4F C0 - : 8E 41 DD 6D - : } - : } - 433 31: SEQUENCE { - 435 3: OBJECT IDENTIFIER - : authorityKeyIdentifier (2 5 29 35) - 440 24: OCTET STRING, encapsulates { - 442 22: SEQUENCE { - 444 20: [0] - : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A - : 4A 20 84 2C 32 - : } - : } - : } - 466 14: SEQUENCE { - 468 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) - 473 1: BOOLEAN TRUE - 476 4: OCTET STRING, encapsulates { - 478 2: BIT STRING 6 unused bits - : '11'B - - - -Cooper, et al. Standards Track [Page 142] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : } - : } - : } - : } - : } - 482 13: SEQUENCE { - 484 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 495 0: NULL - : } - 497 129: BIT STRING - : 00 20 28 34 5B 68 32 01 BB 0A 36 0E AD 71 C5 95 - : 1A E1 04 CF AE AD C7 62 14 A4 1B 36 31 C0 E2 0C - : 3D D9 1E C0 00 DC 10 A0 BA 85 6F 41 CB 62 7A B7 - : 4C 63 81 26 5E D2 80 45 5E 33 E7 70 45 3B 39 3B - : 26 4A 9C 3B F2 26 36 69 08 79 BB FB 96 43 77 4B - : 61 8B A1 AB 91 64 E0 F3 37 61 3C 1A A3 A4 C9 8A - : B2 BF 73 D4 4D E4 58 E4 62 EA BC 20 74 92 86 0E - : CE 84 60 76 E9 73 BB C7 85 D3 91 45 EA 62 5D CD - : } - -C.3. End Entity Certificate Using DSA - - This appendix contains an annotated hex dump of a 914-byte version 3 - certificate. The certificate contains the following information: - - (a) the serial number is 256; - - (b) the certificate is signed with DSA and the SHA-1 hash algorithm; - - (c) the issuer's distinguished name is cn=Example DSA - CA,dc=example,dc=com; - - (d) the subject's distinguished name is cn=DSA End - Entity,dc=example,dc=com; - - (e) the certificate was issued on May 2, 2004 and expired on May 2, - 2005; - - (f) the certificate contains a 1024-bit DSA public key with - parameters; - - (g) the certificate is an end entity certificate (not a CA - certificate); - - (h) the certificate includes a subject alternative name of - "" and an issuer - alternative name of "" -- both are URLs; - - - -Cooper, et al. Standards Track [Page 143] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - (i) the certificate includes an authority key identifier extension - and a certificate policies extension specifying the policy OID - 2.16.840.1.101.3.2.1.48.9; and - - (j) the certificate includes a critical key usage extension - specifying that the public key is intended for verification of - digital signatures. - - 0 910: SEQUENCE { - 4 846: SEQUENCE { - 8 3: [0] { - 10 1: INTEGER 2 - : } - 13 2: INTEGER 256 - 17 9: SEQUENCE { - 19 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 28 71: SEQUENCE { - 30 19: SET { - 32 17: SEQUENCE { - 34 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 46 3: IA5String 'com' - : } - : } - 51 23: SET { - 53 21: SEQUENCE { - 55 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 67 7: IA5String 'example' - : } - : } - 76 23: SET { - 78 21: SEQUENCE { - 80 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 85 14: PrintableString 'Example DSA CA' - : } - : } - : } - 101 30: SEQUENCE { - 103 13: UTCTime 02/05/2004 16:47:38 GMT - 118 13: UTCTime 02/05/2005 16:47:38 GMT - : } - 133 71: SEQUENCE { - 135 19: SET { - 137 17: SEQUENCE { - 139 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - - - -Cooper, et al. Standards Track [Page 144] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 151 3: IA5String 'com' - : } - : } - 156 23: SET { - 158 21: SEQUENCE { - 160 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 172 7: IA5String 'example' - : } - : } - 181 23: SET { - 183 21: SEQUENCE { - 185 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 190 14: PrintableString 'DSA End Entity' - : } - : } - : } - 206 439: SEQUENCE { - 210 300: SEQUENCE { - 214 7: OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) - 223 287: SEQUENCE { - 227 129: INTEGER - : 00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC FB 95 - : 32 AC 01 12 33 B9 E0 1C AD 90 9B BC 48 54 9E F3 - : 94 77 3C 2C 71 35 55 E6 FE 4F 22 CB D5 D8 3E 89 - : 93 33 4D FC BD 4F 41 64 3E A2 98 70 EC 31 B4 50 - : DE EB F1 98 28 0A C9 3E 44 B3 FD 22 97 96 83 D0 - : 18 A3 E3 BD 35 5B FF EE A3 21 72 6A 7B 96 DA B9 - : 3F 1E 5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A - : FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48 63 FE - : 43 - 359 21: INTEGER - : 00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA 55 F7 - : 7D 57 74 81 E5 - 382 129: INTEGER - : 00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91 C0 8E - : 47 F1 0A C3 01 47 C2 44 42 36 A9 92 81 DE 57 C5 - : E0 68 86 58 00 7B 1F F9 9B 77 A1 C5 10 A5 80 91 - : 78 51 51 3C F6 FC FC CC 46 C6 81 78 92 84 3D F4 - : 93 3D 0C 38 7E 1A 5B 99 4E AB 14 64 F6 0C 21 22 - : 4E 28 08 9C 92 B9 66 9F 40 E8 95 F6 D5 31 2A EF - : 39 A2 62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF - : F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE 1E 57 - : 18 - : } - : } - 514 132: BIT STRING, encapsulates { - 518 128: INTEGER - - - -Cooper, et al. Standards Track [Page 145] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : 30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB A0 9C - : 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C B7 C1 BA 4A - : BA A9 95 80 53 F0 0D 72 DC 33 37 F4 01 0B F5 04 - : 1F 9D 2E 1F 62 D8 84 3A 9B 25 09 5A 2D C8 46 8E - : 2B D4 F5 0D 3B C7 2D C6 6C B9 98 C1 25 3A 44 4E - : 8E CA 95 61 35 7C CE 15 31 5C 23 13 1E A2 05 D1 - : 7A 24 1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC - : 46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5 95 BE - : } - : } - 649 202: [3] { - 652 199: SEQUENCE { - 655 57: SEQUENCE { - 657 3: OBJECT IDENTIFIER subjectAltName (2 5 29 17) - 662 50: OCTET STRING, encapsulates { - 664 48: SEQUENCE { - 666 46: [6] - : 'http://www.example.com/users/DSAendentity.' - : 'html' - : } - : } - : } - 714 33: SEQUENCE { - 716 3: OBJECT IDENTIFIER issuerAltName (2 5 29 18) - 721 26: OCTET STRING, encapsulates { - 723 24: SEQUENCE { - 725 22: [6] 'http://www.example.com' - : } - : } - : } - 749 29: SEQUENCE { - 751 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) - 756 22: OCTET STRING, encapsulates { - 758 20: OCTET STRING - : DD 25 66 96 43 AB 78 11 43 44 FE 95 16 F9 D9 B6 - : B7 02 66 8D - : } - : } - 780 31: SEQUENCE { - 782 3: OBJECT IDENTIFIER - : authorityKeyIdentifier (2 5 29 35) - 787 24: OCTET STRING, encapsulates { - 789 22: SEQUENCE { - 791 20: [0] - : 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41 2C - : 29 49 F4 86 56 - : } - : } - - - -Cooper, et al. Standards Track [Page 146] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - : } - 813 23: SEQUENCE { - 815 3: OBJECT IDENTIFIER certificatePolicies (2 5 29 32) - 820 16: OCTET STRING, encapsulates { - 822 14: SEQUENCE { - 824 12: SEQUENCE { - 826 10: OBJECT IDENTIFIER '2 16 840 1 101 3 2 1 48 9' - : } - : } - : } - : } - 838 14: SEQUENCE { - 840 3: OBJECT IDENTIFIER keyUsage (2 5 29 15) - 845 1: BOOLEAN TRUE - 848 4: OCTET STRING, encapsulates { - 850 2: BIT STRING 7 unused bits - : '1'B (bit 0) - : } - : } - : } - : } - : } - 854 9: SEQUENCE { - 856 7: OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3) - : } - 865 47: BIT STRING, encapsulates { - 868 44: SEQUENCE { - 870 20: INTEGER - : 65 57 07 34 DD DC CA CC 5E F4 02 F4 56 42 2C 5E - : E1 B3 3B 80 - 892 20: INTEGER - : 60 F4 31 17 CA F4 CF FF EE F4 08 A7 D9 B2 61 BE - : B1 C3 DA BF - : } - : } - : } - -C.4. Certificate Revocation List - - This appendix contains an annotated hex dump of a version 2 CRL with - two extensions (cRLNumber and authorityKeyIdentifier). The CRL was - issued by cn=Example CA,dc=example,dc=com on February 5, 2005; the - next scheduled issuance was February 6, 2005. The CRL includes one - revoked certificate: serial number 18, which was revoked on November - 19, 2004 due to keyCompromise. The CRL itself is number 12, and it - was signed with RSA and SHA-1. - - - - - -Cooper, et al. Standards Track [Page 147] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 0 352: SEQUENCE { - 4 202: SEQUENCE { - 7 1: INTEGER 1 - 10 13: SEQUENCE { - 12 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 23 0: NULL - : } - 25 67: SEQUENCE { - 27 19: SET { - 29 17: SEQUENCE { - 31 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 43 3: IA5String 'com' - : } - : } - 48 23: SET { - 50 21: SEQUENCE { - 52 10: OBJECT IDENTIFIER - : domainComponent (0 9 2342 19200300 100 1 25) - 64 7: IA5String 'example' - : } - : } - 73 19: SET { - 75 17: SEQUENCE { - 77 3: OBJECT IDENTIFIER commonName (2 5 4 3) - 82 10: PrintableString 'Example CA' - : } - : } - : } - 94 13: UTCTime 05/02/2005 12:00:00 GMT - 109 13: UTCTime 06/02/2005 12:00:00 GMT - 124 34: SEQUENCE { - 126 32: SEQUENCE { - 128 1: INTEGER 18 - 131 13: UTCTime 19/11/2004 15:57:03 GMT - 146 12: SEQUENCE { - 148 10: SEQUENCE { - 150 3: OBJECT IDENTIFIER cRLReason (2 5 29 21) - 155 3: OCTET STRING, encapsulates { - 157 1: ENUMERATED 1 - : } - : } - : } - : } - : } - 160 47: [0] { - 162 45: SEQUENCE { - - - -Cooper, et al. Standards Track [Page 148] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - - 164 31: SEQUENCE { - 166 3: OBJECT IDENTIFIER - : authorityKeyIdentifier (2 5 29 35) - 171 24: OCTET STRING, encapsulates { - 173 22: SEQUENCE { - 175 20: [0] - : 08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E 70 6A - : 4A 20 84 2C 32 - : } - : } - : } - 197 10: SEQUENCE { - 199 3: OBJECT IDENTIFIER cRLNumber (2 5 29 20) - 204 3: OCTET STRING, encapsulates { - 206 1: INTEGER 12 - : } - : } - : } - : } - : } - 209 13: SEQUENCE { - 211 9: OBJECT IDENTIFIER - : sha1withRSAEncryption (1 2 840 113549 1 1 5) - 222 0: NULL - : } - 224 129: BIT STRING - : 22 DC 18 7D F7 08 CE CC 75 D0 D0 6A 9B AD 10 F4 - : 76 23 B4 81 6E B5 6D BE 0E FB 15 14 6C C8 17 6D - : 1F EE 90 17 A2 6F 60 E4 BD AA 8C 55 DE 8E 84 6F - : 92 F8 9F 10 12 27 AF 4A D4 2F 85 E2 36 44 7D AA - : A3 4C 25 38 15 FF 00 FD 3E 7E EE 3D 26 12 EB D8 - : E7 2B 62 E2 2B C3 46 80 EF 78 82 D1 15 C6 D0 9C - : 72 6A CB CE 7A ED 67 99 8B 6E 70 81 7D 43 42 74 - : C1 A6 AF C1 55 17 A2 33 4C D6 06 98 2B A4 FC 2E - : } - - - - - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 149] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -Authors' Addresses - - David Cooper - National Institute of Standards and Technology - 100 Bureau Drive, Mail Stop 8930 - Gaithersburg, MD 20899-8930 - USA - EMail: david.cooper@nist.gov - - Stefan Santesson - Microsoft - One Microsoft Way - Redmond, WA 98052 - USA - EMail: stefans@microsoft.com - - Stephen Farrell - Distributed Systems Group - Computer Science Department - Trinity College Dublin - Ireland - EMail: stephen.farrell@cs.tcd.ie - - Sharon Boeyen - Entrust - 1000 Innovation Drive - Ottawa, Ontario - Canada K2K 3E7 - EMail: sharon.boeyen@entrust.com - - Russell Housley - Vigil Security, LLC - 918 Spring Knoll Drive - Herndon, VA 20170 - USA - EMail: housley@vigilsec.com - - Tim Polk - National Institute of Standards and Technology - 100 Bureau Drive, Mail Stop 8930 - Gaithersburg, MD 20899-8930 - USA - EMail: wpolk@nist.gov - - - - - - - - -Cooper, et al. Standards Track [Page 150] - -RFC 5280 PKIX Certificate and CRL Profile May 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - -Cooper, et al. Standards Track [Page 151] - diff --git a/specifications/auth/rfc6570.pdf b/specifications/auth/rfc6570.pdf deleted file mode 100644 index 76def4cc..00000000 Binary files a/specifications/auth/rfc6570.pdf and /dev/null differ diff --git a/specifications/auth/rfc6570.txt b/specifications/auth/rfc6570.txt deleted file mode 100644 index 12d5c0f9..00000000 --- a/specifications/auth/rfc6570.txt +++ /dev/null @@ -1,1907 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) J. Gregorio -Request for Comments: 6570 Google -Category: Standards Track R. Fielding -ISSN: 2070-1721 Adobe - M. Hadley - MITRE - M. Nottingham - Rackspace - D. Orchard - Salesforce.com - March 2012 - - - URI Template - -Abstract - - A URI Template is a compact sequence of characters for describing a - range of Uniform Resource Identifiers through variable expansion. - This specification defines the URI Template syntax and the process - for expanding a URI Template into a URI reference, along with - guidelines for the use of URI Templates on the Internet. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 5741. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - http://www.rfc-editor.org/info/rfc6570. - -Copyright Notice - - Copyright (c) 2012 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - - - -Gregorio, et al. Standards Track [Page 1] - -RFC 6570 URI Template March 2012 - - - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Overview ...................................................3 - 1.2. Levels and Expression Types ................................5 - 1.3. Design Considerations ......................................9 - 1.4. Limitations ...............................................10 - 1.5. Notational Conventions ....................................11 - 1.6. Character Encoding and Unicode Normalization ..............12 - 2. Syntax .........................................................13 - 2.1. Literals ..................................................13 - 2.2. Expressions ...............................................13 - 2.3. Variables .................................................14 - 2.4. Value Modifiers ...........................................15 - 2.4.1. Prefix Values ......................................15 - 2.4.2. Composite Values ...................................16 - 3. Expansion ......................................................18 - 3.1. Literal Expansion .........................................18 - 3.2. Expression Expansion ......................................18 - 3.2.1. Variable Expansion .................................19 - 3.2.2. Simple String Expansion: {var} .....................21 - 3.2.3. Reserved Expansion: {+var} .........................22 - 3.2.4. Fragment Expansion: {#var} .........................23 - 3.2.5. Label Expansion with Dot-Prefix: {.var} ............24 - 3.2.6. Path Segment Expansion: {/var} .....................24 - 3.2.7. Path-Style Parameter Expansion: {;var} .............25 - 3.2.8. Form-Style Query Expansion: {?var} .................26 - 3.2.9. Form-Style Query Continuation: {&var} ..............27 - 4. Security Considerations ........................................27 - 5. Acknowledgments ................................................28 - 6. References .....................................................28 - 6.1. Normative References ......................................28 - 6.2. Informative References ....................................29 - Appendix A. Implementation Hints ..................................30 - - - - - - - - - - - - - -Gregorio, et al. Standards Track [Page 2] - -RFC 6570 URI Template March 2012 - - -1. Introduction - -1.1. Overview - - A Uniform Resource Identifier (URI) [RFC3986] is often used to - identify a specific resource within a common space of similar - resources (informally, a "URI space"). For example, personal web - spaces are often delegated using a common pattern, such as - - http://example.com/~fred/ - http://example.com/~mark/ - - or a set of dictionary entries might be grouped in a hierarchy by the - first letter of the term, as in - - http://example.com/dictionary/c/cat - http://example.com/dictionary/d/dog - - or a service interface might be invoked with various user input in a - common pattern, as in - - http://example.com/search?q=cat&lang=en - http://example.com/search?q=chien&lang=fr - - A URI Template is a compact sequence of characters for describing a - range of Uniform Resource Identifiers through variable expansion. - - URI Templates provide a mechanism for abstracting a space of resource - identifiers such that the variable parts can be easily identified and - described. URI Templates can have many uses, including the discovery - of available services, configuring resource mappings, defining - computed links, specifying interfaces, and other forms of - programmatic interaction with resources. For example, the above - resources could be described by the following URI Templates: - - http://example.com/~{username}/ - http://example.com/dictionary/{term:1}/{term} - http://example.com/search{?q,lang} - - We define the following terms: - - expression: The text between '{' and '}', including the enclosing - braces, as defined in Section 2. - - expansion: The string result obtained from a template expression - after processing it according to its expression type, list of - variable names, and value modifiers, as defined in Section 3. - - - - -Gregorio, et al. Standards Track [Page 3] - -RFC 6570 URI Template March 2012 - - - template processor: A program or library that, given a URI Template - and a set of variables with values, transforms the template string - into a URI reference by parsing the template for expressions and - substituting each one with its corresponding expansion. - - A URI Template provides both a structural description of a URI space - and, when variable values are provided, machine-readable instructions - on how to construct a URI corresponding to those values. A URI - Template is transformed into a URI reference by replacing each - delimited expression with its value as defined by the expression type - and the values of variables named within the expression. The - expression types range from simple string expansion to multiple - name=value lists. The expansions are based on the URI generic - syntax, allowing an implementation to process any URI Template - without knowing the scheme-specific requirements of every possible - resulting URI. - - For example, the following URI Template includes a form-style - parameter expression, as indicated by the "?" operator appearing - before the variable names. - - http://www.example.com/foo{?query,number} - - The expansion process for expressions beginning with the question- - mark ("?") operator follows the same pattern as form-style interfaces - on the World Wide Web: - - http://www.example.com/foo{?query,number} - \_____________/ - | - | - For each defined variable in [ 'query', 'number' ], - substitute "?" if it is the first substitution or "&" - thereafter, followed by the variable name, '=', and the - variable's value. - - If the variables have the values - - query := "mycelium" - number := 100 - - then the expansion of the above URI Template is - - http://www.example.com/foo?query=mycelium&number=100 - - Alternatively, if 'query' is undefined, then the expansion would be - - http://www.example.com/foo?number=100 - - - -Gregorio, et al. Standards Track [Page 4] - -RFC 6570 URI Template March 2012 - - - or if both variables are undefined, then it would be - - http://www.example.com/foo - - A URI Template may be provided in absolute form, as in the examples - above, or in relative form. A template is expanded before the - resulting reference is resolved from relative to absolute form. - - Although the URI syntax is used for the result, the template string - is allowed to contain the broader set of characters that can be found - in Internationalized Resource Identifier (IRI) references [RFC3987]. - Therefore, a URI Template is also an IRI template, and the result of - template processing can be transformed to an IRI by following the - process defined in Section 3.2 of [RFC3987]. - -1.2. Levels and Expression Types - - URI Templates are similar to a macro language with a fixed set of - macro definitions: the expression type determines the expansion - process. The default expression type is simple string expansion, - wherein a single named variable is replaced by its value as a string - after pct-encoding any characters not in the set of unreserved URI - characters (Section 1.5). - - Since most template processors implemented prior to this - specification have only implemented the default expression type, we - refer to these as Level 1 templates. - - .-----------------------------------------------------------------. - | Level 1 examples, with variables having values of | - | | - | var := "value" | - | hello := "Hello World!" | - | | - |-----------------------------------------------------------------| - | Op Expression Expansion | - |-----------------------------------------------------------------| - | | Simple string expansion (Sec 3.2.2) | - | | | - | | {var} value | - | | {hello} Hello%20World%21 | - `-----------------------------------------------------------------' - - Level 2 templates add the plus ("+") operator, for expansion of - values that are allowed to include reserved URI characters - (Section 1.5), and the crosshatch ("#") operator for expansion of - fragment identifiers. - - - - -Gregorio, et al. Standards Track [Page 5] - -RFC 6570 URI Template March 2012 - - - .-----------------------------------------------------------------. - | Level 2 examples, with variables having values of | - | | - | var := "value" | - | hello := "Hello World!" | - | path := "/foo/bar" | - | | - |-----------------------------------------------------------------| - | Op Expression Expansion | - |-----------------------------------------------------------------| - | + | Reserved string expansion (Sec 3.2.3) | - | | | - | | {+var} value | - | | {+hello} Hello%20World! | - | | {+path}/here /foo/bar/here | - | | here?ref={+path} here?ref=/foo/bar | - |-----+-----------------------------------------------------------| - | # | Fragment expansion, crosshatch-prefixed (Sec 3.2.4) | - | | | - | | X{#var} X#value | - | | X{#hello} X#Hello%20World! | - `-----------------------------------------------------------------' - - Level 3 templates allow multiple variables per expression, each - separated by a comma, and add more complex operators for dot-prefixed - labels, slash-prefixed path segments, semicolon-prefixed path - parameters, and the form-style construction of a query syntax - consisting of name=value pairs that are separated by an ampersand - character. - - .-----------------------------------------------------------------. - | Level 3 examples, with variables having values of | - | | - | var := "value" | - | hello := "Hello World!" | - | empty := "" | - | path := "/foo/bar" | - | x := "1024" | - | y := "768" | - | | - |-----------------------------------------------------------------| - | Op Expression Expansion | - |-----------------------------------------------------------------| - | | String expansion with multiple variables (Sec 3.2.2) | - | | | - | | map?{x,y} map?1024,768 | - | | {x,hello,y} 1024,Hello%20World%21,768 | - | | | - - - -Gregorio, et al. Standards Track [Page 6] - -RFC 6570 URI Template March 2012 - - - |-----+-----------------------------------------------------------| - | + | Reserved expansion with multiple variables (Sec 3.2.3) | - | | | - | | {+x,hello,y} 1024,Hello%20World!,768 | - | | {+path,x}/here /foo/bar,1024/here | - | | | - |-----+-----------------------------------------------------------| - | # | Fragment expansion with multiple variables (Sec 3.2.4) | - | | | - | | {#x,hello,y} #1024,Hello%20World!,768 | - | | {#path,x}/here #/foo/bar,1024/here | - | | | - |-----+-----------------------------------------------------------| - | . | Label expansion, dot-prefixed (Sec 3.2.5) | - | | | - | | X{.var} X.value | - | | X{.x,y} X.1024.768 | - | | | - |-----+-----------------------------------------------------------| - | / | Path segments, slash-prefixed (Sec 3.2.6) | - | | | - | | {/var} /value | - | | {/var,x}/here /value/1024/here | - | | | - |-----+-----------------------------------------------------------| - | ; | Path-style parameters, semicolon-prefixed (Sec 3.2.7) | - | | | - | | {;x,y} ;x=1024;y=768 | - | | {;x,y,empty} ;x=1024;y=768;empty | - | | | - |-----+-----------------------------------------------------------| - | ? | Form-style query, ampersand-separated (Sec 3.2.8) | - | | | - | | {?x,y} ?x=1024&y=768 | - | | {?x,y,empty} ?x=1024&y=768&empty= | - | | | - |-----+-----------------------------------------------------------| - | & | Form-style query continuation (Sec 3.2.9) | - | | | - | | ?fixed=yes{&x} ?fixed=yes&x=1024 | - | | {&x,y,empty} &x=1024&y=768&empty= | - | | | - `-----------------------------------------------------------------' - - Finally, Level 4 templates add value modifiers as an optional suffix - to each variable name. A prefix modifier (":") indicates that only a - limited number of characters from the beginning of the value are used - by the expansion (Section 2.4.1). An explode ("*") modifier - - - -Gregorio, et al. Standards Track [Page 7] - -RFC 6570 URI Template March 2012 - - - indicates that the variable is to be treated as a composite value, - consisting of either a list of names or an associative array of - (name, value) pairs, that is expanded as if each member were a - separate variable (Section 2.4.2). - - .-----------------------------------------------------------------. - | Level 4 examples, with variables having values of | - | | - | var := "value" | - | hello := "Hello World!" | - | path := "/foo/bar" | - | list := ("red", "green", "blue") | - | keys := [("semi",";"),("dot","."),("comma",",")] | - | | - | Op Expression Expansion | - |-----------------------------------------------------------------| - | | String expansion with value modifiers (Sec 3.2.2) | - | | | - | | {var:3} val | - | | {var:30} value | - | | {list} red,green,blue | - | | {list*} red,green,blue | - | | {keys} semi,%3B,dot,.,comma,%2C | - | | {keys*} semi=%3B,dot=.,comma=%2C | - | | | - |-----+-----------------------------------------------------------| - | + | Reserved expansion with value modifiers (Sec 3.2.3) | - | | | - | | {+path:6}/here /foo/b/here | - | | {+list} red,green,blue | - | | {+list*} red,green,blue | - | | {+keys} semi,;,dot,.,comma,, | - | | {+keys*} semi=;,dot=.,comma=, | - | | | - |-----+-----------------------------------------------------------| - | # | Fragment expansion with value modifiers (Sec 3.2.4) | - | | | - | | {#path:6}/here #/foo/b/here | - | | {#list} #red,green,blue | - | | {#list*} #red,green,blue | - | | {#keys} #semi,;,dot,.,comma,, | - | | {#keys*} #semi=;,dot=.,comma=, | - | | | - |-----+-----------------------------------------------------------| - | . | Label expansion, dot-prefixed (Sec 3.2.5) | - | | | - | | X{.var:3} X.val | - | | X{.list} X.red,green,blue | - - - -Gregorio, et al. Standards Track [Page 8] - -RFC 6570 URI Template March 2012 - - - | | X{.list*} X.red.green.blue | - | | X{.keys} X.semi,%3B,dot,.,comma,%2C | - | | X{.keys*} X.semi=%3B.dot=..comma=%2C | - | | | - |-----+-----------------------------------------------------------| - | / | Path segments, slash-prefixed (Sec 3.2.6) | - | | | - | | {/var:1,var} /v/value | - | | {/list} /red,green,blue | - | | {/list*} /red/green/blue | - | | {/list*,path:4} /red/green/blue/%2Ffoo | - | | {/keys} /semi,%3B,dot,.,comma,%2C | - | | {/keys*} /semi=%3B/dot=./comma=%2C | - | | | - |-----+-----------------------------------------------------------| - | ; | Path-style parameters, semicolon-prefixed (Sec 3.2.7) | - | | | - | | {;hello:5} ;hello=Hello | - | | {;list} ;list=red,green,blue | - | | {;list*} ;list=red;list=green;list=blue | - | | {;keys} ;keys=semi,%3B,dot,.,comma,%2C | - | | {;keys*} ;semi=%3B;dot=.;comma=%2C | - | | | - |-----+-----------------------------------------------------------| - | ? | Form-style query, ampersand-separated (Sec 3.2.8) | - | | | - | | {?var:3} ?var=val | - | | {?list} ?list=red,green,blue | - | | {?list*} ?list=red&list=green&list=blue | - | | {?keys} ?keys=semi,%3B,dot,.,comma,%2C | - | | {?keys*} ?semi=%3B&dot=.&comma=%2C | - | | | - |-----+-----------------------------------------------------------| - | & | Form-style query continuation (Sec 3.2.9) | - | | | - | | {&var:3} &var=val | - | | {&list} &list=red,green,blue | - | | {&list*} &list=red&list=green&list=blue | - | | {&keys} &keys=semi,%3B,dot,.,comma,%2C | - | | {&keys*} &semi=%3B&dot=.&comma=%2C | - | | | - `-----------------------------------------------------------------' - -1.3. Design Considerations - - Mechanisms similar to URI Templates have been defined within several - specifications, including WSDL [WSDL], WADL [WADL], and OpenSearch - [OpenSearch]. This specification extends and formally defines the - - - -Gregorio, et al. Standards Track [Page 9] - -RFC 6570 URI Template March 2012 - - - syntax so that URI Templates can be used consistently across multiple - Internet applications and within Internet message fields, while at - the same time retaining compatibility with those earlier definitions. - - The URI Template syntax has been designed to carefully balance the - need for a powerful expansion mechanism with the need for ease of - implementation. The syntax is designed to be trivial to parse while - at the same time providing enough flexibility to express many common - template scenarios. Implementations are able to parse the template - and perform the expansions in a single pass. - - Templates are simple and readable when used with common examples - because the single-character operators match the URI generic syntax - delimiters. The operator's associated delimiter (".", ";", "/", "?", - "&", and "#") is omitted when none of the listed variables are - defined. Likewise, the expansion process for ";" (path-style - parameters) will omit the "=" when the variable value is empty, - whereas the process for "?" (form-style parameters) will not omit the - "=" when the value is empty. Multiple variables and list values have - their values joined with "," if there is no predefined joining - mechanism for the operator. The "+" and "#" operators will - substitute unencoded reserved characters found inside the variable - values; the other operators will pct-encode reserved characters found - in the variable values prior to expansion. - - The most common cases for URI spaces can be described with Level 1 - template expressions. If we were only concerned with URI generation, - then the template syntax could be limited to just simple variable - expansion, since more complex forms could be generated by changing - the variable values. However, URI Templates have the additional goal - of describing the layout of identifiers in terms of preexisting data - values. Therefore, the template syntax includes operators that - reflect how resource identifiers are commonly allocated. Likewise, - since prefix substrings are often used to partition large spaces of - resources, modifiers on variable values provide a way to specify both - the substring and the full value string with a single variable name. - -1.4. Limitations - - Since a URI Template describes a superset of the identifiers, there - is no implication that every possible expansion for each delimited - variable expression corresponds to a URI of an existing resource. - Our expectation is that an application constructing URIs according to - the template will be provided with an appropriate set of values for - the variables being substituted, or at least a means of validating - user data-entry for those values. - - - - - -Gregorio, et al. Standards Track [Page 10] - -RFC 6570 URI Template March 2012 - - - URI Templates are not URIs: they do not identify an abstract or - physical resource, they are not parsed as URIs, and they should not - be used in places where a URI would be expected unless the template - expressions will be expanded by a template processor prior to use. - Distinct field, element, or attribute names should be used to - differentiate protocol elements that carry a URI Template from those - that expect a URI reference. - - Some URI Templates can be used in reverse for the purpose of variable - matching: comparing the template to a fully formed URI in order to - extract the variable parts from that URI and assign them to the named - variables. Variable matching only works well if the template - expressions are delimited by the beginning or end of the URI or by - characters that cannot be part of the expansion, such as reserved - characters surrounding a simple string expression. In general, - regular expression languages are better suited for variable matching. - -1.5. Notational Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - This specification uses the Augmented Backus-Naur Form (ABNF) - notation of [RFC5234]. The following ABNF rules are imported from - the normative references [RFC5234], [RFC3986], and [RFC3987]. - - ALPHA = %x41-5A / %x61-7A ; A-Z / a-z - DIGIT = %x30-39 ; 0-9 - HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" - ; case-insensitive - - pct-encoded = "%" HEXDIG HEXDIG - unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" - reserved = gen-delims / sub-delims - gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" - sub-delims = "!" / "$" / "&" / "'" / "(" / ")" - / "*" / "+" / "," / ";" / "=" - - ucschar = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF - / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD - / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD - / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD - / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD - / %xD0000-DFFFD / %xE1000-EFFFD - - iprivate = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD - - - - -Gregorio, et al. Standards Track [Page 11] - -RFC 6570 URI Template March 2012 - - -1.6. Character Encoding and Unicode Normalization - - This specification uses the terms "character", "character encoding - scheme", "code point", "coded character set", "glyph", "non-ASCII", - "normalization", "protocol element", and "regular expression" as they - are defined in [RFC6365]. - - The ABNF notation defines its terminal values to be non-negative - integers (code points) that are a superset of the US-ASCII coded - character set [ASCII]. This specification defines terminal values as - code points within the Unicode coded character set [UNIV6]. - - In spite of the syntax and template expansion process being defined - in terms of Unicode code points, it should be understood that - templates occur in practice as a sequence of characters in whatever - form or encoding is suitable for the context in which they occur, - whether that be octets embedded in a network protocol element or - glyphs painted on the side of a bus. This specification does not - mandate any particular character encoding scheme for mapping between - URI Template characters and the octets used to store or transmit - those characters. When a URI Template appears in a protocol element, - the character encoding scheme is defined by that protocol; without - such a definition, a URI Template is assumed to be in the same - character encoding scheme as the surrounding text. It is only during - the process of template expansion that a string of characters in a - URI Template is REQUIRED to be processed as a sequence of Unicode - code points. - - The Unicode Standard [UNIV6] defines various equivalences between - sequences of characters for various purposes. Unicode Standard Annex - #15 [UTR15] defines various Normalization Forms for these - equivalences. The normalization form determines how to consistently - encode equivalent strings. In theory, all URI processing - implementations, including template processors, should use the same - normalization form for generating a URI reference. In practice, they - do not. If a value has been provided by the same server as the - resource, then it can be assumed that the string is already in the - form expected by that server. If a value is provided by a user, such - as via a data-entry dialog, then the string SHOULD be normalized as - Normalization Form C (NFC: Canonical Decomposition, followed by - Canonical Composition) prior to being used in expansions by a - template processor. - - Likewise, when non-ASCII data that represents readable strings is - pct-encoded for use in a URI reference, a template processor MUST - first encode the string as UTF-8 [RFC3629] and then pct-encode any - octets that are not allowed in a URI reference. - - - - -Gregorio, et al. Standards Track [Page 12] - -RFC 6570 URI Template March 2012 - - -2. Syntax - - A URI Template is a string of printable Unicode characters that - contains zero or more embedded variable expressions, each expression - being delimited by a matching pair of braces ('{', '}'). - - URI-Template = *( literals / expression ) - - Although templates (and template processor implementations) are - described above in terms of four gradual levels, we define the URI- - Template syntax in terms of the ABNF for Level 4. A template - processor limited to lower-level templates MAY exclude the ABNF rules - applicable only to higher levels. However, it is RECOMMENDED that - all parsers implement the full syntax such that unsupported levels - can be properly identified as such to the end user. - -2.1. Literals - - The characters outside of expressions in a URI Template string are - intended to be copied literally to the URI reference if the character - is allowed in a URI (reserved / unreserved / pct-encoded) or, if not - allowed, copied to the URI reference as the sequence of pct-encoded - triplets corresponding to that character's encoding in UTF-8 - [RFC3629]. - - literals = %x21 / %x23-24 / %x26 / %x28-3B / %x3D / %x3F-5B - / %x5D / %x5F / %x61-7A / %x7E / ucschar / iprivate - / pct-encoded - ; any Unicode character except: CTL, SP, - ; DQUOTE, "'", "%" (aside from pct-encoded), - ; "<", ">", "\", "^", "`", "{", "|", "}" - -2.2. Expressions - - Template expressions are the parameterized parts of a URI Template. - Each expression contains an optional operator, which defines the - expression type and its corresponding expansion process, followed by - a comma-separated list of variable specifiers (variable names and - optional value modifiers). If no operator is provided, the - expression defaults to simple variable expansion of unreserved - values. - - expression = "{" [ operator ] variable-list "}" - operator = op-level2 / op-level3 / op-reserve - op-level2 = "+" / "#" - op-level3 = "." / "/" / ";" / "?" / "&" - op-reserve = "=" / "," / "!" / "@" / "|" - - - - -Gregorio, et al. Standards Track [Page 13] - -RFC 6570 URI Template March 2012 - - - The operator characters have been chosen to reflect each of their - roles as reserved characters in the URI generic syntax. The - operators defined in Section 3 of this specification include: - - + Reserved character strings; - - # Fragment identifiers prefixed by "#"; - - . Name labels or extensions prefixed by "."; - - / Path segments prefixed by "/"; - - ; Path parameter name or name=value pairs prefixed by ";"; - - ? Query component beginning with "?" and consisting of - name=value pairs separated by "&"; and, - - & Continuation of query-style &name=value pairs within - a literal query component. - - The operator characters equals ("="), comma (","), exclamation ("!"), - at sign ("@"), and pipe ("|") are reserved for future extensions. - - The expression syntax specifically excludes use of the dollar ("$") - and parentheses ["(" and ")"] characters so that they remain - available for use outside the scope of this specification. For - example, a macro language might use these characters to apply macro - substitution to a string prior to that string being processed as a - URI Template. - -2.3. Variables - - After the operator (if any), each expression contains a list of one - or more comma-separated variable specifiers (varspec). The variable - names serve multiple purposes: documentation for what kinds of values - are expected, identifiers for associating values within a template - processor, and the literal string to use for the name in name=value - expansions (aside from when exploding an associative array). - Variable names are case-sensitive because the name might be expanded - within a case-sensitive URI component. - - variable-list = varspec *( "," varspec ) - varspec = varname [ modifier-level4 ] - varname = varchar *( ["."] varchar ) - varchar = ALPHA / DIGIT / "_" / pct-encoded - - - - - - -Gregorio, et al. Standards Track [Page 14] - -RFC 6570 URI Template March 2012 - - - A varname MAY contain one or more pct-encoded triplets. These - triplets are considered an essential part of the variable name and - are not decoded during processing. A varname containing pct-encoded - characters is not the same variable as a varname with those same - characters decoded. Applications that provide URI Templates are - expected to be consistent in their use of pct-encoding within - variable names. - - An expression MAY reference variables that are unknown to the - template processor or whose value is set to a special "undefined" - value, such as undef or null. Such undefined variables are given - special treatment by the expansion process (Section 3.2.1). - - A variable value that is a string of length zero is not considered - undefined; it has the defined value of an empty string. - - In Level 4 templates, a variable may have a composite value in the - form of a list of values or an associative array of (name, value) - pairs. Such value types are not directly indicated by the template - syntax, but they do have an impact on the expansion process - (Section 3.2.1). - - A variable defined as a list value is considered undefined if the - list contains zero members. A variable defined as an associative - array of (name, value) pairs is considered undefined if the array - contains zero members or if all member names in the array are - associated with undefined values. - -2.4. Value Modifiers - - Each of the variables in a Level 4 template expression can have a - modifier indicating either that its expansion is limited to a prefix - of the variable's value string or that its expansion is exploded as a - composite value in the form of a value list or an associative array - of (name, value) pairs. - - modifier-level4 = prefix / explode - -2.4.1. Prefix Values - - A prefix modifier indicates that the variable expansion is limited to - a prefix of the variable's value string. Prefix modifiers are often - used to partition an identifier space hierarchically, as is common in - reference indices and hash-based storage. It also serves to limit - the expanded value to a maximum number of characters. Prefix - modifiers are not applicable to variables that have composite values. - - - - - -Gregorio, et al. Standards Track [Page 15] - -RFC 6570 URI Template March 2012 - - - prefix = ":" max-length - max-length = %x31-39 0*3DIGIT ; positive integer < 10000 - - The max-length is a positive integer that refers to a maximum number - of characters from the beginning of the variable's value as a Unicode - string. Note that this numbering is in characters, not octets, in - order to avoid splitting between the octets of a multi-octet-encoded - character or within a pct-encoded triplet. If the max-length is - greater than the length of the variable's value, then the entire - value string is used. - - For example, - - Given the variable assignments - - var := "value" - semi := ";" - - Example Template Expansion - - {var} value - {var:20} value - {var:3} val - {semi} %3B - {semi:2} %3B - -2.4.2. Composite Values - - An explode ("*") modifier indicates that the variable is to be - treated as a composite value consisting of either a list of values or - an associative array of (name, value) pairs. Hence, the expansion - process is applied to each member of the composite as if it were - listed as a separate variable. This kind of variable specification - is significantly less self-documenting than non-exploded variables, - since there is less correspondence between the variable name and how - the URI reference appears after expansion. - - explode = "*" - - Since URI Templates do not contain an indication of type or schema, - the type for an exploded variable is assumed to be determined by - context. For example, the processor might be supplied values in a - form that differentiates values as strings, lists, or associative - arrays. Likewise, the context in which the template is used (script, - mark-up language, Interface Definition Language, etc.) might define - rules for associating variable names with types, structures, or - schema. - - - - -Gregorio, et al. Standards Track [Page 16] - -RFC 6570 URI Template March 2012 - - - Explode modifiers improve brevity in the URI Template syntax. For - example, a resource that provides a geographic map for a given street - address might accept a hundred permutations on fields for address - input, including partial addresses (e.g., just the city or postal - code). Such a resource could be described as a template with each - and every address component listed in order, or with a far more - simple template that makes use of an explode modifier, as in - - /mapper{?address*} - - along with some context that defines what the variable named - "address" can include, such as by reference to some other standard - for addressing (e.g., [UPU-S42]). A recipient aware of the schema - can then provide appropriate expansions, such as: - - /mapper?city=Newport%20Beach&state=CA - - The expansion process for exploded variables is dependent on both the - operator being used and whether the composite value is to be treated - as a list of values or as an associative array of (name, value) - pairs. Structures are processed as if they are an associative array - with names corresponding to the fields in the structure definition - and "." separators used to indicate name hierarchy in substructures. - - If a variable has a composite structure and only some of the fields - in that structure have defined values, then only the defined pairs - are present in the expansion. This can be useful for templates that - consist of a large number of potential query terms. - - An explode modifier applied to a list variable causes the expansion - to iterate over the list's member values. For path and query - parameter expansions, each member value is paired with the variable's - name as a (varname, value) pair. This allows path and query - parameters to be repeated for multiple values, as in - - Given the variable assignments - - year := ("1965", "2000", "2012") - dom := ("example", "com") - - Example Template Expansion - - find{?year*} find?year=1965&year=2000&year=2012 - www{.dom*} www.example.com - - - - - - - -Gregorio, et al. Standards Track [Page 17] - -RFC 6570 URI Template March 2012 - - -3. Expansion - - The process of URI Template expansion is to scan the template string - from beginning to end, copying literal characters and replacing each - expression with the result of applying the expression's operator to - the value of each variable named in the expression. Each variable's - value MUST be formed prior to template expansion. - - The requirements on expansion for each aspect of the URI Template - grammar are defined in this section. A non-normative algorithm for - the expansion process as a whole is provided in Appendix A. - - If a template processor encounters a character sequence outside an - expression that does not match the grammar, then - processing of the template SHOULD cease, the URI reference result - SHOULD contain the expanded part of the template followed by the - remainder unexpanded, and the location and type of error SHOULD be - indicated to the invoking application. - - If an error is encountered in an expression, such as an operator or - value modifier that the template processor does not recognize or does - not yet support, or a character is found that is not allowed by the - grammar, then the unprocessed parts of the expression - SHOULD be copied to the result unexpanded, processing of the - remainder of the template SHOULD continue, and the location and type - of error SHOULD be indicated to the invoking application. - - If an error occurs, the result returned might not be a valid URI - reference; it will be an incompletely expanded template string that - is only intended for diagnostic use. - -3.1. Literal Expansion - - If the literal character is allowed anywhere in the URI syntax - (unreserved / reserved / pct-encoded ), then it is copied directly to - the result string. Otherwise, the pct-encoded equivalent of the - literal character is copied to the result string by first encoding - the character as its sequence of octets in UTF-8 and then encoding - each such octet as a pct-encoded triplet. - -3.2. Expression Expansion - - Each expression is indicated by an opening brace ("{") character and - continues until the next closing brace ("}"). Expressions cannot be - nested. - - - - - - -Gregorio, et al. Standards Track [Page 18] - -RFC 6570 URI Template March 2012 - - - An expression is expanded by determining its expression type and then - following that type's expansion process for each comma-separated - varspec in the expression. Level 1 templates are limited to the - default operator (simple string value expansion) and a single - variable per expression. Level 2 templates are limited to a single - varspec per expression. - - The expression type is determined by looking at the first character - after the opening brace. If the character is an operator, then - remember the expression type associated with that operator for later - expansion decisions and skip to the next character for the variable- - list. If the first character is not an operator, then the expression - type is simple string expansion and the first character is the - beginning of the variable-list. - - The examples in the subsections below use the following definitions - for variable values: - - count := ("one", "two", "three") - dom := ("example", "com") - dub := "me/too" - hello := "Hello World!" - half := "50%" - var := "value" - who := "fred" - base := "http://example.com/home/" - path := "/foo/bar" - list := ("red", "green", "blue") - keys := [("semi",";"),("dot","."),("comma",",")] - v := "6" - x := "1024" - y := "768" - empty := "" - empty_keys := [] - undef := null - -3.2.1. Variable Expansion - - A variable that is undefined (Section 2.3) has no value and is - ignored by the expansion process. If all of the variables in an - expression are undefined, then the expression's expansion is the - empty string. - - Variable expansion of a defined, non-empty value results in a - substring of allowed URI characters. As described in Section 1.6, - the expansion process is defined in terms of Unicode code points in - order to ensure that non-ASCII characters are consistently pct- - encoded in the resulting URI reference. One way for a template - - - -Gregorio, et al. Standards Track [Page 19] - -RFC 6570 URI Template March 2012 - - - processor to obtain a consistent expansion is to transcode the value - string to UTF-8 (if it is not already in UTF-8) and then transform - each octet that is not in the allowed set into the corresponding pct- - encoded triplet. Another is to map directly from the value's native - character encoding to the set of allowed URI characters, with any - remaining disallowed characters mapping to the sequence of pct- - encoded triplets that correspond to the octet(s) of that character - when encoded as UTF-8 [RFC3629]. - - The allowed set for a given expansion depends on the expression type: - reserved ("+") and fragment ("#") expansions allow the set of - characters in the union of ( unreserved / reserved / pct-encoded ) to - be passed through without pct-encoding, whereas all other expression - types allow only unreserved characters to be passed through without - pct-encoding. Note that the percent character ("%") is only allowed - as part of a pct-encoded triplet and only for reserved/fragment - expansion: in all other cases, a value character of "%" MUST be pct- - encoded as "%25" by variable expansion. - - If a variable appears more than once in an expression or within - multiple expressions of a URI Template, the value of that variable - MUST remain static throughout the expansion process (i.e., the - variable must have the same value for the purpose of calculating each - expansion). However, if reserved characters or pct-encoded triplets - occur in the value, they will be pct-encoded by some expression types - and not by others. - - For a variable that is a simple string value, expansion consists of - appending the encoded value to the result string. An explode - modifier has no effect. A prefix modifier limits the expansion to - the first max-length characters of the decoded value. If the value - contains multi-octet or pct-encoded characters, care must be taken to - avoid splitting the value in mid-character: count each Unicode code - point as one character. - - For a variable that is an associative array, expansion depends on - both the expression type and the presence of an explode modifier. If - there is no explode modifier, expansion consists of appending a - comma-separated concatenation of each (name, value) pair that has a - defined value. If there is an explode modifier, expansion consists - of appending each pair that has a defined value as either - "name=value" or, if the value is the empty string and the expression - type does not indicate form-style parameters (i.e., not a "?" or "&" - type), simply "name". Both name and value strings are encoded in the - same way as simple string values. A separator string is appended - between defined pairs according to the expression type, as defined by - the following table: - - - - -Gregorio, et al. Standards Track [Page 20] - -RFC 6570 URI Template March 2012 - - - Type Separator - "," (default) - + "," - # "," - . "." - / "/" - ; ";" - ? "&" - & "&" - - For a variable that is a list of values, expansion depends on both - the expression type and the presence of an explode modifier. If - there is no explode modifier, the expansion consists of a comma- - separated concatenation of the defined member string values. If - there is an explode modifier and the expression type expands named - parameters (";", "?", or "&"), then the list is expanded as if it - were an associative array in which each member value is paired with - the list's varname. Otherwise, the value will be expanded as if it - were a list of separate variable values, each value separated by the - expression type's associated separator as defined by the table above. - - Example Template Expansion - - {count} one,two,three - {count*} one,two,three - {/count} /one,two,three - {/count*} /one/two/three - {;count} ;count=one,two,three - {;count*} ;count=one;count=two;count=three - {?count} ?count=one,two,three - {?count*} ?count=one&count=two&count=three - {&count*} &count=one&count=two&count=three - -3.2.2. Simple String Expansion: {var} - - Simple string expansion is the default expression type when no - operator is given. - - For each defined variable in the variable-list, perform variable - expansion, as defined in Section 3.2.1, with the allowed characters - being those in the unreserved set. If more than one variable has a - defined value, append a comma (",") to the result string as a - separator between variable expansions. - - - - - - - - -Gregorio, et al. Standards Track [Page 21] - -RFC 6570 URI Template March 2012 - - - Example Template Expansion - - {var} value - {hello} Hello%20World%21 - {half} 50%25 - O{empty}X OX - O{undef}X OX - {x,y} 1024,768 - {x,hello,y} 1024,Hello%20World%21,768 - ?{x,empty} ?1024, - ?{x,undef} ?1024 - ?{undef,y} ?768 - {var:3} val - {var:30} value - {list} red,green,blue - {list*} red,green,blue - {keys} semi,%3B,dot,.,comma,%2C - {keys*} semi=%3B,dot=.,comma=%2C - -3.2.3. Reserved Expansion: {+var} - - Reserved expansion, as indicated by the plus ("+") operator for Level - 2 and above templates, is identical to simple string expansion except - that the substituted values may also contain pct-encoded triplets and - characters in the reserved set. - - For each defined variable in the variable-list, perform variable - expansion, as defined in Section 3.2.1, with the allowed characters - being those in the set (unreserved / reserved / pct-encoded). If - more than one variable has a defined value, append a comma (",") to - the result string as a separator between variable expansions. - - - - - - - - - - - - - - - - - - - - -Gregorio, et al. Standards Track [Page 22] - -RFC 6570 URI Template March 2012 - - - Example Template Expansion - - {+var} value - {+hello} Hello%20World! - {+half} 50%25 - - {base}index http%3A%2F%2Fexample.com%2Fhome%2Findex - {+base}index http://example.com/home/index - O{+empty}X OX - O{+undef}X OX - - {+path}/here /foo/bar/here - here?ref={+path} here?ref=/foo/bar - up{+path}{var}/here up/foo/barvalue/here - {+x,hello,y} 1024,Hello%20World!,768 - {+path,x}/here /foo/bar,1024/here - - {+path:6}/here /foo/b/here - {+list} red,green,blue - {+list*} red,green,blue - {+keys} semi,;,dot,.,comma,, - {+keys*} semi=;,dot=.,comma=, - -3.2.4. Fragment Expansion: {#var} - - Fragment expansion, as indicated by the crosshatch ("#") operator for - Level 2 and above templates, is identical to reserved expansion - except that a crosshatch character (fragment delimiter) is appended - first to the result string if any of the variables are defined. - - Example Template Expansion - - {#var} #value - {#hello} #Hello%20World! - {#half} #50%25 - foo{#empty} foo# - foo{#undef} foo - {#x,hello,y} #1024,Hello%20World!,768 - {#path,x}/here #/foo/bar,1024/here - {#path:6}/here #/foo/b/here - {#list} #red,green,blue - {#list*} #red,green,blue - {#keys} #semi,;,dot,.,comma,, - {#keys*} #semi=;,dot=.,comma=, - - - - - - - -Gregorio, et al. Standards Track [Page 23] - -RFC 6570 URI Template March 2012 - - -3.2.5. Label Expansion with Dot-Prefix: {.var} - - Label expansion, as indicated by the dot (".") operator for Level 3 - and above templates, is useful for describing URI spaces with varying - domain names or path selectors (e.g., filename extensions). - - For each defined variable in the variable-list, append "." to the - result string and then perform variable expansion, as defined in - Section 3.2.1, with the allowed characters being those in the - unreserved set. - - Since "." is in the unreserved set, a value that contains a "." has - the effect of adding multiple labels. - - Example Template Expansion - - {.who} .fred - {.who,who} .fred.fred - {.half,who} .50%25.fred - www{.dom*} www.example.com - X{.var} X.value - X{.empty} X. - X{.undef} X - X{.var:3} X.val - X{.list} X.red,green,blue - X{.list*} X.red.green.blue - X{.keys} X.semi,%3B,dot,.,comma,%2C - X{.keys*} X.semi=%3B.dot=..comma=%2C - X{.empty_keys} X - X{.empty_keys*} X - -3.2.6. Path Segment Expansion: {/var} - - Path segment expansion, as indicated by the slash ("/") operator in - Level 3 and above templates, is useful for describing URI path - hierarchies. - - For each defined variable in the variable-list, append "/" to the - result string and then perform variable expansion, as defined in - Section 3.2.1, with the allowed characters being those in the - unreserved set. - - Note that the expansion process for path segment expansion is - identical to that of label expansion aside from the substitution of - "/" instead of ".". However, unlike ".", a "/" is a reserved - character and will be pct-encoded if found in a value. - - - - - -Gregorio, et al. Standards Track [Page 24] - -RFC 6570 URI Template March 2012 - - - Example Template Expansion - - {/who} /fred - {/who,who} /fred/fred - {/half,who} /50%25/fred - {/who,dub} /fred/me%2Ftoo - {/var} /value - {/var,empty} /value/ - {/var,undef} /value - {/var,x}/here /value/1024/here - {/var:1,var} /v/value - {/list} /red,green,blue - {/list*} /red/green/blue - {/list*,path:4} /red/green/blue/%2Ffoo - {/keys} /semi,%3B,dot,.,comma,%2C - {/keys*} /semi=%3B/dot=./comma=%2C - -3.2.7. Path-Style Parameter Expansion: {;var} - - Path-style parameter expansion, as indicated by the semicolon (";") - operator in Level 3 and above templates, is useful for describing URI - path parameters, such as "path;property" or "path;name=value". - - For each defined variable in the variable-list: - - o append ";" to the result string; - - o if the variable has a simple string value or no explode modifier - is given, then: - - * append the variable name (encoded as if it were a literal - string) to the result string; - - * if the variable's value is not empty, append "=" to the result - string; - - o perform variable expansion, as defined in Section 3.2.1, with the - allowed characters being those in the unreserved set. - - - - - - - - - - - - - -Gregorio, et al. Standards Track [Page 25] - -RFC 6570 URI Template March 2012 - - - Example Template Expansion - - {;who} ;who=fred - {;half} ;half=50%25 - {;empty} ;empty - {;v,empty,who} ;v=6;empty;who=fred - {;v,bar,who} ;v=6;who=fred - {;x,y} ;x=1024;y=768 - {;x,y,empty} ;x=1024;y=768;empty - {;x,y,undef} ;x=1024;y=768 - {;hello:5} ;hello=Hello - {;list} ;list=red,green,blue - {;list*} ;list=red;list=green;list=blue - {;keys} ;keys=semi,%3B,dot,.,comma,%2C - {;keys*} ;semi=%3B;dot=.;comma=%2C - -3.2.8. Form-Style Query Expansion: {?var} - - Form-style query expansion, as indicated by the question-mark ("?") - operator in Level 3 and above templates, is useful for describing an - entire optional query component. - - For each defined variable in the variable-list: - - o append "?" to the result string if this is the first defined value - or append "&" thereafter; - - o if the variable has a simple string value or no explode modifier - is given, append the variable name (encoded as if it were a - literal string) and an equals character ("=") to the result - string; and, - - o perform variable expansion, as defined in Section 3.2.1, with the - allowed characters being those in the unreserved set. - - - Example Template Expansion - - {?who} ?who=fred - {?half} ?half=50%25 - {?x,y} ?x=1024&y=768 - {?x,y,empty} ?x=1024&y=768&empty= - {?x,y,undef} ?x=1024&y=768 - {?var:3} ?var=val - {?list} ?list=red,green,blue - {?list*} ?list=red&list=green&list=blue - {?keys} ?keys=semi,%3B,dot,.,comma,%2C - {?keys*} ?semi=%3B&dot=.&comma=%2C - - - -Gregorio, et al. Standards Track [Page 26] - -RFC 6570 URI Template March 2012 - - -3.2.9. Form-Style Query Continuation: {&var} - - Form-style query continuation, as indicated by the ampersand ("&") - operator in Level 3 and above templates, is useful for describing - optional &name=value pairs in a template that already contains a - literal query component with fixed parameters. - - For each defined variable in the variable-list: - - o append "&" to the result string; - - o if the variable has a simple string value or no explode modifier - is given, append the variable name (encoded as if it were a - literal string) and an equals character ("=") to the result - string; and, - - o perform variable expansion, as defined in Section 3.2.1, with the - allowed characters being those in the unreserved set. - - - Example Template Expansion - - {&who} &who=fred - {&half} &half=50%25 - ?fixed=yes{&x} ?fixed=yes&x=1024 - {&x,y,empty} &x=1024&y=768&empty= - {&x,y,undef} &x=1024&y=768 - - {&var:3} &var=val - {&list} &list=red,green,blue - {&list*} &list=red&list=green&list=blue - {&keys} &keys=semi,%3B,dot,.,comma,%2C - {&keys*} &semi=%3B&dot=.&comma=%2C - -4. Security Considerations - - A URI Template does not contain active or executable content. - However, it might be possible to craft unanticipated URIs if an - attacker is given control over the template or over the variable - values within an expression that allows reserved characters in the - expansion. In either case, the security considerations are largely - determined by who provides the template, who provides the values to - use for variables within the template, in what execution context the - expansion occurs (client or server), and where the resulting URIs are - used. - - - - - - -Gregorio, et al. Standards Track [Page 27] - -RFC 6570 URI Template March 2012 - - - This specification does not limit where URI Templates might be used. - Current implementations exist within server-side development - frameworks and within client-side javascript for computed links or - forms. - - Within frameworks, templates usually act as guides for where data - might occur within later (request-time) URIs in client requests. - Hence, the security concerns are not in the templates themselves, but - rather in how the server extracts and processes the user-provided - data within a normal Web request. - - Within client-side implementations, a URI Template has many of the - same properties as HTML forms, except limited to URI characters and - possibly included in HTTP header field values instead of just message - body content. Care ought to be taken to ensure that potentially - dangerous URI reference strings, such as those beginning with - "javascript:", do not appear in the expansion unless both the - template and the values are provided by a trusted source. - - Other security considerations are the same as those for URIs, as - described in Section 7 of [RFC3986]. - -5. Acknowledgments - - The following people made contributions to this specification: Mike - Burrows, Michaeljohn Clement, DeWitt Clinton, John Cowan, Stephen - Farrell, Robbie Gates, Vijay K. Gurbani, Peter Johanson, Murray S. - Kucherawy, James H. Manger, Tom Petch, Marc Portier, Pete Resnick, - James Snell, and Jiankang Yao. - -6. References - -6.1. Normative References - - [ASCII] American National Standards Institute, "Coded Character - Set - 7-bit American Standard Code for Information - Interchange", ANSI X3.4, 1986. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, - "Uniform Resource Identifier (URI): Generic Syntax", - STD 66, RFC 3986, January 2005. - - - - -Gregorio, et al. Standards Track [Page 28] - -RFC 6570 URI Template March 2012 - - - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, January 2005. - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, January 2008. - - [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in - Internationalization in the IETF", BCP 166, RFC 6365, - September 2011. - - [UNIV6] The Unicode Consortium, "The Unicode Standard, Version - 6.0.0", (Mountain View, CA: The Unicode Consortium, - 2011. ISBN 978-1-936213-01-6), - . - - [UTR15] Davis, M. and M. Duerst, "Unicode Normalization Forms", - Unicode Standard Annex # 15, April 2003, - . - -6.2. Informative References - - [OpenSearch] Clinton, D., "OpenSearch 1.1", Draft 5, December 2011, - . - - [UPU-S42] Universal Postal Union, "International Postal Address - Components and Templates", UPU S42-1, November 2002, - . - - [WADL] Hadley, M., "Web Application Description Language", - World Wide Web Consortium Member Submission - SUBM-wadl-20090831, August 2009, - . - - [WSDL] Weerawarana, S., Moreau, J., Ryman, A., and R. - Chinnici, "Web Services Description Language (WSDL) - Version 2.0 Part 1: Core Language", World Wide Web - Consortium Recommendation REC-wsdl20-20070626, - June 2007, . - - - - - - - - - -Gregorio, et al. Standards Track [Page 29] - -RFC 6570 URI Template March 2012 - - -Appendix A. Implementation Hints - - The normative sections on expansion describe each operator with a - separate expansion process for the sake of descriptive clarity. In - actual implementations, we expect the expressions to be processed - left-to-right using a common algorithm that has only minor variations - in process per operator. This non-normative appendix describes one - such algorithm. - - Initialize an empty result string and its non-error state. - - Scan the template and copy literals to the result string (as in - Section 3.1) until an expression is indicated by a "{", an error is - indicated by the presence of a non-literals character other than "{", - or the template ends. When it ends, return the result string and its - current error or non-error state. - - o If an expression is found, scan the template to the next "}" and - extract the characters in between the braces. - - o If the template ends before a "}", then append the "{" and - extracted characters to the result string and return with an error - status indicating the expression is malformed. - - Examine the first character of the extracted expression for an - operator. - - o If the expression ended (i.e., is "{}"), an operator is found that - is unknown or unimplemented, or the character is not in the - varchar set (Section 2.3), then append "{", the extracted - expression, and "}" to the result string, remember that the result - is in an error state, and then go back to scan the remainder of - the template. - - o If a known and implemented operator is found, store the operator - and skip to the next character to begin the varspec-list. - - o Otherwise, store the operator as NUL (simple string expansion). - - Use the following value table to determine the processing behavior by - expression type operator. The entry for "first" is the string to - append to the result first if any of the expression's variables are - defined. The entry for "sep" is the separator to append to the - result before any second (or subsequent) defined variable expansion. - The entry for "named" is a boolean for whether or not the expansion - includes the variable or key name when no explode modifier is given. - The entry for "ifemp" is a string to append to the name if its - corresponding value is empty. The entry for "allow" indicates what - - - -Gregorio, et al. Standards Track [Page 30] - -RFC 6570 URI Template March 2012 - - - characters to allow unencoded within the value expansion: (U) means - any character not in the unreserved set will be encoded; (U+R) means - any character not in the union of (unreserved / reserved / pct- - encoding) will be encoded; and, for both cases, each disallowed - character is first encoded as its sequence of octets in UTF-8 and - then each such octet is encoded as a pct-encoded triplet. - - .------------------------------------------------------------------. - | NUL + . / ; ? & # | - |------------------------------------------------------------------| - | first | "" "" "." "/" ";" "?" "&" "#" | - | sep | "," "," "." "/" ";" "&" "&" "," | - | named | false false false false true true true false | - | ifemp | "" "" "" "" "" "=" "=" "" | - | allow | U U+R U U U U U U+R | - `------------------------------------------------------------------' - - With the above table in mind, process the variable-list as follows: - - For each varspec, extract a variable name and optional modifier from - the expression by scanning the variable-list until a character not in - the varname set is found or the end of the expression is reached. - - o If it is the end of the expression and the varname is empty, go - back to scan the remainder of the template. - - o If it is not the end of the expression and the last character - found indicates a modifier ("*" or ":"), remember that modifier. - If it is an explode ("*"), scan the next character. If it is a - prefix (":"), continue scanning the next one to four characters - for the max-length represented as a decimal integer and then, if - it is still not the end of the expression, scan the next - character. - - o If it is not the end of the expression and the last character - found is not a comma (","), append "{", the stored operator (if - any), the scanned varname and modifier, the remaining expression, - and "}" to the result string, remember that the result is in an - error state, and then go back to scan the remainder of the - template. - - Lookup the value for the scanned variable name, and then - - o If the varname is unknown or corresponds to a variable with an - undefined value (Section 2.3), then skip to the next varspec. - - - - - - -Gregorio, et al. Standards Track [Page 31] - -RFC 6570 URI Template March 2012 - - - o If this is the first defined variable for this expression, append - the first string for this expression type to the result string and - remember that it has been done. Otherwise, append the sep string - to the result string. - - o If this variable's value is a string, then - - * if named is true, append the varname to the result string using - the same encoding process as for literals, and - - + if the value is empty, append the ifemp string to the result - string and skip to the next varspec; - - + otherwise, append "=" to the result string. - - * if a prefix modifier is present and the prefix length is less - than the value string length in number of Unicode characters, - append that number of characters from the beginning of the - value string to the result string, after pct-encoding any - characters that are not in the allow set, while taking care not - to split multi-octet or pct-encoded triplet characters that - represent a single Unicode code point; - - * otherwise, append the value to the result string after pct- - encoding any characters that are not in the allow set. - - o else if no explode modifier is given, then - - * if named is true, append the varname to the result string using - the same encoding process as for literals, and - - + if the value is empty, append the ifemp string to the result - string and skip to the next varspec; - - + otherwise, append "=" to the result string; and - - * if this variable's value is a list, append each defined list - member to the result string, after pct-encoding any characters - that are not in the allow set, with a comma (",") appended to - the result between each defined list member; - - * if this variable's value is an associative array or any other - form of paired (name, value) structure, append each pair with a - defined value to the result string as "name,value", after pct- - encoding any characters that are not in the allow set, with a - comma (",") appended to the result between each defined pair. - - - - - -Gregorio, et al. Standards Track [Page 32] - -RFC 6570 URI Template March 2012 - - - o else if an explode modifier is given, then - - * if named is true, then for each defined list member or array - (name, value) pair with a defined value, do: - - + if this is not the first defined member/value, append the - sep string to the result string; - - + if this is a list, append the varname to the result string - using the same encoding process as for literals; - - + if this is a pair, append the name to the result string - using the same encoding process as for literals; - - + if the member/value is empty, append the ifemp string to the - result string; otherwise, append "=" and the member/value to - the result string, after pct-encoding any member/value - characters that are not in the allow set. - - * else if named is false, then - - + if this is a list, append each defined list member to the - result string, after pct-encoding any characters that are - not in the allow set, with the sep string appended to the - result between each defined list member. - - + if this is an array of (name, value) pairs, append each pair - with a defined value to the result string as "name=value", - after pct-encoding any characters that are not in the allow - set, with the sep string appended to the result between each - defined pair. - - When the variable-list for this expression is exhausted, go back to - scan the remainder of the template. - - - - - - - - - - - - - - - - - -Gregorio, et al. Standards Track [Page 33] - -RFC 6570 URI Template March 2012 - - -Authors' Addresses - - Joe Gregorio - Google - - EMail: joe@bitworking.org - URI: http://bitworking.org/ - - - Roy T. Fielding - Adobe Systems Incorporated - - EMail: fielding@gbiv.com - URI: http://roy.gbiv.com/ - - - Marc Hadley - The MITRE Corporation - - EMail: mhadley@mitre.org - URI: http://mitre.org/ - - - Mark Nottingham - Rackspace - - EMail: mnot@mnot.net - URI: http://www.mnot.net/ - - - David Orchard - Salesforce.com - - EMail: orchard@pacificspirit.com - URI: http://www.pacificspirit.com/ - - - - - - - - - - - - - - - - -Gregorio, et al. Standards Track [Page 34] - diff --git a/specifications/auth/rfc7292.txt b/specifications/auth/rfc7292.txt deleted file mode 100644 index 92ba37d0..00000000 --- a/specifications/auth/rfc7292.txt +++ /dev/null @@ -1,1627 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) K. Moriarty, Ed. -Request for Comments: 7292 EMC -Category: Informational M. Nystrom -ISSN: 2070-1721 Microsoft Corporation - S. Parkinson - A. Rusch - M. Scott - RSA - July 2014 - - - PKCS #12: Personal Information Exchange Syntax v1.1 - -Abstract - - PKCS #12 v1.1 describes a transfer syntax for personal identity - information, including private keys, certificates, miscellaneous - secrets, and extensions. Machines, applications, browsers, Internet - kiosks, and so on, that support this standard will allow a user to - import, export, and exercise a single set of personal identity - information. This standard supports direct transfer of personal - information under several privacy and integrity modes. - - This document represents a republication of PKCS #12 v1.1 from RSA - Laboratories' Public Key Cryptography Standard (PKCS) series. By - publishing this RFC, change control is transferred to the IETF. - -IESG Note - - The IESG thanks RSA Laboratories for transferring change control to - the IETF. Enhancements to this specification that preserve backward - compatibility are expected in an upcoming IETF Standards Track - document. - - - - - - - - - - - - - - - - - - -Moriarty, et al. Informational [Page 1] - -RFC 7292 PKCS12 July 2014 - - -Status of This Memo - - This document is not an Internet Standards Track specification; it is - published for informational purposes. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Not all documents - approved by the IESG are a candidate for any level of Internet - Standard; see Section 2 of RFC 5741. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - http://www.rfc-editor.org/info/rfc7292. - -Copyright Notice - - Copyright (c) 2014 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - - - - - - - - - - - - - - - - - - -Moriarty, et al. Informational [Page 2] - -RFC 7292 PKCS12 July 2014 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Changes from PKCS #12 Version 1 . . . . . . . . . . . . . 4 - 2. Definitions and Notation . . . . . . . . . . . . . . . . . . 5 - 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. Exchange Modes . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Mode Choice Policies . . . . . . . . . . . . . . . . . . 8 - 3.3. Trusted Public Keys . . . . . . . . . . . . . . . . . . . 8 - 3.4. The AuthenticatedSafe . . . . . . . . . . . . . . . . . . 9 - 4. PFX PDU Syntax . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. The AuthenticatedSafe Type . . . . . . . . . . . . . . . 11 - 4.2. The SafeBag Type . . . . . . . . . . . . . . . . . . . . 12 - 4.2.1. The KeyBag Type . . . . . . . . . . . . . . . . . . . 13 - 4.2.2. The PKCS8ShroudedKeyBag Type . . . . . . . . . . . . 13 - 4.2.3. The CertBag Type . . . . . . . . . . . . . . . . . . 13 - 4.2.4. The CRLBag Type . . . . . . . . . . . . . . . . . . . 14 - 4.2.5. The SecretBag Type . . . . . . . . . . . . . . . . . 14 - 4.2.6. The SafeContents Type . . . . . . . . . . . . . . . . 14 - 5. Using PFX PDUs . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.1. Creating PFX PDUs . . . . . . . . . . . . . . . . . . . . 15 - 5.2. Importing Keys, etc., from a PFX PDU . . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 7. Normative References . . . . . . . . . . . . . . . . . . . . 17 - Appendix A. Message Authentication Codes (MACs) . . . . . . . . 19 - Appendix B. Deriving Keys and IVs from Passwords and Salt . . . 19 - B.1. Password Formatting . . . . . . . . . . . . . . . . . . . 19 - B.2. General Method . . . . . . . . . . . . . . . . . . . . . 20 - B.3. More on the ID Byte . . . . . . . . . . . . . . . . . . . 22 - B.4. Keys for Password Integrity Mode . . . . . . . . . . . . 22 - Appendix C. Keys and IVs for Password Privacy Mode . . . . . . . 22 - Appendix D. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 24 - Appendix E. Intellectual Property Considerations . . . . . . . . 28 - Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . 28 - Appendix G. About PKCS . . . . . . . . . . . . . . . . . . . . . 28 - - - - - - - - - - - - - - - - -Moriarty, et al. Informational [Page 3] - -RFC 7292 PKCS12 July 2014 - - -1. Introduction - - This document represents a republication of PKCS #12 v1.1 from RSA - Laboratories' Public Key Cryptography Standard (PKCS) series. By - publishing this RFC, change control is transferred to the IETF. RSA - and its parent company EMC reserve the right to continue publishing - and distributing PKCS #12 v1.1 and its predecessors. - - The body of this document, except for the Security Considerations - section, is taken directly from the PKCS #12 v1.1 specification. The - list of references and the in-line cites have been updated or added - where appropriate to cite the most current documents in addition to - those current at the original publication of PKCS #12 v1.1. - - This standard describes a transfer syntax for personal identity - information, including private keys, certificates, miscellaneous - secrets, and extensions. Machines, applications, browsers, Internet - kiosks, and so on, that support this standard will allow a user to - import, export, and exercise a single set of personal identity - information. - - This standard supports direct transfer of personal information under - several privacy and integrity modes. The most secure of the privacy - and integrity modes require the source and destination platforms to - have trusted public/private key pairs usable for digital signatures - and encryption, respectively. The standard also supports lower- - security, password-based privacy and integrity modes for those cases - where trusted public/private key pairs are not available. - - This standard should be amenable to both software and hardware - implementations. Hardware implementations offer physical security in - tamper-resistant tokens such as smart cards and Personal Computer - Memory Card International Association (PCMCIA) devices. - - This standard can be viewed as building on PKCS #8 [15] [24] by - including essential but ancillary identity information along with - private keys and by instituting higher security through public-key - privacy and integrity modes. - -1.1. Changes from PKCS #12 Version 1 - - This document transfers PKCS #12 [16] into the IETF and includes some - minor changes from the authors for this submission. - - o Addition of hash algorithms. - - o Incorporation of Technical Corrigendum #1, which makes some minor - corrections to the ASN.1 syntax. - - - -Moriarty, et al. Informational [Page 4] - -RFC 7292 PKCS12 July 2014 - - - o Removed (from the ASN.1 syntax) 1024 as an example of the - iteration count. - - o Addition of a recommendation that the technique in Appendix B no - longer be used for a specific mode (password privacy mode) and - that techniques from PKCS#5 v2.1 be used instead. - - o Addition of comments and minor corrections to the ASN.1 module in - Appendix C. - - o Removal of the export regulations discussion in the former - Appendix D. - - o Replacement of RSA with EMC in the "Intellectual Property - Considerations". - - o Many changes and additions to the references. - - o A reference was added to NIST SP 800-132 for its recommendations - on selection of the iteration count value for password integrity - (part of dictionary-attack resistance). - - o Comment included on acronym expansion of PFX: The acronym is - sometimes expanded as Personal Information Exchange. - - o In Appendix B, the phrase "no longer recommended" was changed to - "not recommended" in the following sentence to address a question - and make it clear the method was not recommended: "Note that this - method for password privacy mode is no longer recommended." - -2. Definitions and Notation - - AlgorithmIdentifier: An ASN.1 type that identifies an algorithm (by - an object identifier) and any associated parameters. This type is - defined in [8]. - - ASN.1: Abstract Syntax Notation One, as defined in [2], [3], [4], - and [5]. - - Attribute: An ASN.1 type that identifies an attribute type (by an - object identifier) and an associated attribute value. The ASN.1 - type Attribute is defined in [7]. - - Certificate: A digitally signed data unit binding a public key to - identity information. A specific format for identity certificates - is defined in [8]. Another format is described in [17]. - - - - - -Moriarty, et al. Informational [Page 5] - -RFC 7292 PKCS12 July 2014 - - - Certificate Revocation List (CRL): A digitally signed list of - certificates that should no longer be honored, having been revoked - by the issuers or a higher authority. One format for CRLs is - defined in [8]. - - ContentInfo: An ASN.1 type used to hold data that may have been - cryptographically protected. This type is defined in [21] and - [14]. - - DER: Distinguished Encoding Rules, as defined in [6]. - - Destination platform: The ultimate, final target platform for the - personal information originating from the source platform. Even - though certain information may be transported from the destination - platform to the source platform, the ultimate target for personal - information is always called the destination platform. - - DigestInfo: An ASN.1 type used to hold a message digest. This type - is defined in [21] and [14]. - - Encryption Key Pair (DestEncK): A public/private key pair used for - the public-key privacy mode of this standard. The public half is - called PDestEncK (TPDestEncK when emphasizing that the public key - is "trusted"), and the private half is called VDestEncK. - - Export time: The time that a user reads personal information from a - source platform and transforms the information into an - interoperable, secure Protocol Data Unit (PDU). - - Import time: The time that a user writes personal information from a - Safe PDU to a destination platform. - - Message Authentication Code (MAC): A type of collision-resistant, - "unpredictable" function of a message and a secret key. MACs are - used for data authentication and are akin to secret-key digital - signatures in many respects. - - Object Identifier: A sequence of integers that uniquely identifies - an associated data object in a global name space administrated by - a hierarchy of naming authorities. This is a primitive data type - in ASN.1. - - PFX: The top-level exchange PDU defined in this standard. The - acronym is sometimes expanded as Personal Information Exchange. - - - - - - - -Moriarty, et al. Informational [Page 6] - -RFC 7292 PKCS12 July 2014 - - - Platform: A combination of machine, operating system, and - applications software within which the user exercises personal - identity. An application, in this context, is software that uses - personal information. Two platforms differ if their machine types - differ or if their applications software differs. There is at - least one platform per user in multi-user systems. - - Protocol Data Unit (PDU): A sequence of bits in machine-independent - format constituting a message in a protocol. - - Shrouding: Encryption as applied to private keys, possibly in - concert with a policy that prevents the plaintext of the key from - ever being visible beyond a certain, well-defined interface. - - Signature Key Pair (SrcSigK): A platform-specific signature key pair - used for the public-key integrity mode of this standard. The - public half is called PSrcSigK (TPSrcSigK when emphasizing that - the public key is "trusted"), and the private half is called - VSrcSigK. - - Source platform: The origin platform of the personal information - ultimately intended for the destination platform. Even though - certain information may be transported from the destination - platform to the source platform, the platform that is the origin - of personal information is always called the source platform. - -3. Overview - -3.1. Exchange Modes - - There are four combinations of privacy modes and integrity modes. - The privacy modes use encryption to protect personal information from - exposure, and the integrity modes protect personal information from - tampering. Without protection from tampering, an adversary could - conceivably substitute invalid information for the user's personal - information without the user being aware of the substitution. - - The following are the privacy modes: - - o Public-key privacy mode: Personal information is enveloped on the - source platform using a trusted encryption public key of a known - destination platform (see Section 3.3). The envelope is opened - with the corresponding private key. - - - - - - - - -Moriarty, et al. Informational [Page 7] - -RFC 7292 PKCS12 July 2014 - - - o Password privacy mode: Personal information is encrypted with a - symmetric key derived from a user name and a privacy password, as - in [22] and [13]. If password integrity mode is used as well, the - privacy password and the integrity password may or may not be the - same. - - The following are the integrity modes: - - o Public-key integrity mode: Integrity is guaranteed through a - digital signature on the contents of the PFX PDU, which is - produced using the source platform's private signature key. The - signature is verified on the destination platform by using the - corresponding public key (see Section 3.4). - - o Password integrity mode: Integrity is guaranteed through a Message - Authentication Code (MAC) derived from a secret integrity - password. If password privacy mode is used as well, the privacy - password and the integrity password may or may not be the same. - -3.2. Mode Choice Policies - - All combinations of the privacy and integrity modes are permitted in - this standard. Of course, good security policy suggests that certain - practices be avoided, e.g., it can be unwise to transport private - keys without physical protection when using password privacy mode or - when using public-key privacy mode with weak symmetric encryption. - - In general, the public-key modes for both privacy and integrity are - preferable to the password modes (from a security viewpoint). - However, it is not always possible to use the public-key modes. For - example, it may not be known at export time what the destination - platform is; if this is the case, then the use of the public-key - privacy mode is precluded. - -3.3. Trusted Public Keys - - Asymmetric key pairs may be used in this standard in two ways: - public-key privacy mode and public-key integrity mode. For public- - key privacy mode, an encryption key pair is required; for public-key - integrity mode, a signature key pair is required. - - It may be appropriate for the keys discussed in this section to be - platform-specific keys dedicated solely for the purpose of - transporting a user's personal information. Whether or not that is - the case, though, the keys discussed here should not be confused with - the user's personal keys that the user wishes to transport from one - platform to another. (These latter keys are stored within the PDU.) - - - - -Moriarty, et al. Informational [Page 8] - -RFC 7292 PKCS12 July 2014 - - - For public-key privacy mode, the private key from the encryption key - pair is kept on the destination platform, where it is ultimately used - to open a private envelope. The corresponding trusted public key is - called TPDestEncK. - - For public-key integrity mode, the private key from the signature - pair is kept on the source platform, where it is used to sign - personal information. The corresponding trusted public key is called - TPSrcSigK. - - For both uses of public/private key pairs, the public key from the - key pair must be transported to the other platform such that it is - trusted to have originated at the correct platform. Judging whether - or not a public key is trusted in this sense must ultimately be left - to the user. There are a variety of methods for ensuring that a - public key is trusted. - - The processes of imbuing keys with trust and of verifying - trustworthiness of keys are not discussed further in this document. - Whenever asymmetric keys are discussed in what follows, the public - keys are assumed to be trusted. - -3.4. The AuthenticatedSafe - - Each compliant platform shall be able to import and export - AuthenticatedSafe PDUs wrapped in PFX PDUs. - - For integrity, the AuthenticatedSafe is either signed (if public-key - integrity mode is used) or MACed (if password integrity mode is used) - to produce a PFX PDU. If the AuthenticatedSafe is signed, then it is - accompanied by a digital signature, which was produced on the source - platform with a private signature key, VSrcSigK, corresponding to a - trusted public signature key, TPSrcSigK. TPSrcSigK must accompany - the PFX to the destination platform, where the user can verify the - trust in the key and can verify the signature on the - AuthenticatedSafe. If the AuthenticatedSafe is MACed, then it is - accompanied by a MAC computed from a secret integrity password, salt - bits, an iteration count, and the contents of the AuthenticatedSafe. - - The AuthenticatedSafe itself consists of a sequence of ContentInfo - values, some of which may consist of plaintext (data), and others - that may either be enveloped (if public-key privacy mode is used) or - encrypted (if password privacy mode is used). If the contents are - enveloped, then they are encrypted with a symmetric cipher under a - freshly generated key, which is in turn encrypted with RSA asymmetric - encryption. The RSA public key used to encrypt the symmetric key is - called TPDestEncK and corresponds to an RSA private key, VDestEncK, - on the destination platform. TPDestEncK needs to be trusted by the - - - -Moriarty, et al. Informational [Page 9] - -RFC 7292 PKCS12 July 2014 - - - user when it is used at export time. If the contents are encrypted, - then they are encrypted with a symmetric cipher under a key derived - from a secret privacy password, salt bits, and an iteration counter. - - Each ContentInfo contains an arbitrary collection of private keys, - PKCS #8-shrouded private keys, certificates, CRLs, or opaque data - objects, at the user's discretion, stored in values of type - SafeContents. - - The raison d'etre for the unencrypted option is that some governments - restrict certain uses of cryptography. Having several parts in an - AuthenticatedSafe keeps implementers' options open. For example, it - may be the case that strong cryptography can be used to make PKCS - #8-shrouded keys, but then these shrouded keys should not be further - encrypted, because super-encryption can limit a product's - exportability. The multi-part AuthenticatedSafe design permits this - possibility. - - Around the AuthenticatedSafe is the integrity-mode wrapper, which - protects the entire contents of the AuthenticatedSafe (including - unencrypted parts, if they are present). This is the reverse of the - wrapping order in many protocols, in which privacy is the outermost - protection. This latter, more-common wrapping order avoids - signatures on encrypted data, which are undesirable under certain - circumstances; however, these circumstances do not apply to this - document, and it is therefore preferable to protect the integrity of - as much information as possible. - -4. PFX PDU Syntax - - This format corresponds to the data model presented above, with - wrappers for privacy and integrity. This section makes free - reference to PKCS #7 [14] [21] and assumes the reader is familiar - with terms defined in that document. - - All modes of direct exchange use the same PDU format. ASN.1 and BER- - encoding ensure platform independence. - - This standard has one ASN.1 export: PFX. This is the outer integrity - wrapper. Instances of PFX contain: - - 1. A version indicator. The version shall be v3 for this version of - this document. - - 2. A PKCS #7 ContentInfo, whose contentType is signedData in public- - key integrity mode and data in password integrity mode. - - - - - -Moriarty, et al. Informational [Page 10] - -RFC 7292 PKCS12 July 2014 - - - 3. An optional instance of MacData, present only in password - integrity. This object, if present, contains a PKCS #7 - DigestInfo, which holds the MAC value, a macSalt, and an - iterationCount. As described in Appendix B, the MAC key is - derived from the password, the macSalt, and the iterationCount; - as described in Section 5, the MAC is computed from the authSafe - value and the MAC key via HMAC [11] [20]. The password and the - MAC key are not actually present anywhere in the PFX. The salt - and (to a certain extent) the iteration count thwarts dictionary - attacks against the integrity password. See NIST Special - Publication 800-132 [12] about how to choose a reasonable value - for the iteration count. - - PFX ::= SEQUENCE { - version INTEGER {v3(3)}(v3,...), - authSafe ContentInfo, - macData MacData OPTIONAL - } - - MacData ::= SEQUENCE { - mac DigestInfo, - macSalt OCTET STRING, - iterations INTEGER DEFAULT 1 - -- Note: The default is for historical reasons and its - -- use is deprecated. - } - -4.1. The AuthenticatedSafe Type - - As mentioned, the contentType field of authSafe shall be of type data - or signedData. The content field of the authSafe shall, either - directly (data case) or indirectly (signedData case), contain a BER- - encoded value of type AuthenticatedSafe. - - AuthenticatedSafe ::= SEQUENCE OF ContentInfo - -- Data if unencrypted - -- EncryptedData if password-encrypted - -- EnvelopedData if public key-encrypted - - An AuthenticatedSafe contains a sequence of ContentInfo values. The - content field of these ContentInfo values contains either plaintext, - encrypted, or enveloped data. In the case of encrypted or enveloped - data, the plaintext of the data holds the BER-encoding of an instance - of SafeContents. Section 5.1 of this document describes the - construction of values of type AuthenticatedSafe in more detail. - - - - - - -Moriarty, et al. Informational [Page 11] - -RFC 7292 PKCS12 July 2014 - - -4.2. The SafeBag Type - - The SafeContents type is made up of SafeBags. Each SafeBag holds one - piece of information -- a key, a certificate, etc. -- which is - identified by an object identifier. - - SafeContents ::= SEQUENCE OF SafeBag - - SafeBag ::= SEQUENCE { - bagId BAG-TYPE.&id ({PKCS12BagSet}) - bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}), - bagAttributes SET OF PKCS12Attribute OPTIONAL - } - - PKCS12Attribute ::= SEQUENCE { - attrId ATTRIBUTE.&id ({PKCS12AttrSet}), - attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId}) - } -- This type is compatible with the X.500 type 'Attribute' - - PKCS12AttrSet ATTRIBUTE ::= { - friendlyName | -- from PKCS #9 [23] - localKeyId, -- from PKCS #9 - ... -- Other attributes are allowed - } - - The optional bagAttributes field allows users to assign nicknames and - identifiers to keys, etc., and permits visual tools to display - meaningful strings of some sort to the user. - - Six types of SafeBags are defined in this version of this document: - - bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1} - - BAG-TYPE ::= TYPE-IDENTIFIER - - keyBag BAG-TYPE ::= - {KeyBag IDENTIFIED BY {bagtypes 1}} - pkcs8ShroudedKeyBag BAG-TYPE ::= - {PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}} - certBag BAG-TYPE ::= - {CertBag IDENTIFIED BY {bagtypes 3}} - crlBag BAG-TYPE ::= - {CRLBag IDENTIFIED BY {bagtypes 4}} - secretBag BAG-TYPE ::= - {SecretBag IDENTIFIED BY {bagtypes 5}} - safeContentsBag BAG-TYPE ::= - {SafeContents IDENTIFIED BY {bagtypes 6}} - - - - -Moriarty, et al. Informational [Page 12] - -RFC 7292 PKCS12 July 2014 - - - PKCS12BagSet BAG-TYPE ::= { - keyBag | - pkcs8ShroudedKeyBag | - certBag | - crlBag | - secretBag | - safeContentsBag, - ... -- For future extensions - } - - As new bag types become recognized in future versions of this - standard, the PKCS12BagSet may be extended. - -4.2.1. The KeyBag Type - - A KeyBag is a PKCS #8 PrivateKeyInfo. Note that a KeyBag contains - only one private key. - - KeyBag ::= PrivateKeyInfo - -4.2.2. The PKCS8ShroudedKeyBag Type - - A PKCS8ShroudedKeyBag holds a private key, which has been shrouded in - accordance with PKCS #8. Note that a PKCS8ShroudedKeyBag holds only - one shrouded private key. - - PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo - -4.2.3. The CertBag Type - - A CertBag contains a certificate of a certain type. Object - identifiers are used to distinguish between different certificate - types. - - CertBag ::= SEQUENCE { - certId BAG-TYPE.&id ({CertTypes}), - certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId}) - } - - x509Certificate BAG-TYPE ::= - {OCTET STRING IDENTIFIED BY {certTypes 1}} - -- DER-encoded X.509 certificate stored in OCTET STRING - sdsiCertificate BAG-TYPE ::= - {IA5String IDENTIFIED BY {certTypes 2}} - -- Base64-encoded SDSI certificate stored in IA5String - - CertTypes BAG-TYPE ::= { - x509Certificate | - - - -Moriarty, et al. Informational [Page 13] - -RFC 7292 PKCS12 July 2014 - - - sdsiCertificate, - ... -- For future extensions - } - -4.2.4. The CRLBag Type - - A CRLBag contains a Certificate Revocation List (CRL) of a certain - type. Object identifiers are used to distinguish between different - CRL types. - - CRLBag ::= SEQUENCE { - crlId BAG-TYPE.&id ({CRLTypes}), - crlValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId}) - } - - x509CRL BAG-TYPE ::= - {OCTET STRING IDENTIFIED BY {crlTypes 1}} - -- DER-encoded X.509 CRL stored in OCTET STRING - - CRLTypes BAG-TYPE ::= { - x509CRL, - ... -- For future extensions - } - -4.2.5. The SecretBag Type - - Each of the user's miscellaneous personal secrets is contained in an - instance of SecretBag, which holds an object identifier-dependent - value. Note that a SecretBag contains only one secret. - - SecretBag ::= SEQUENCE { - secretTypeId BAG-TYPE.&id ({SecretTypes}), - secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes} - {@secretTypeId}) - } - - SecretTypes BAG-TYPE ::= { - ... -- For future extensions - } - - Implementers can add values to this set at their own discretion. - -4.2.6. The SafeContents Type - - The sixth type of bag that can be held in a SafeBag is a - SafeContents. This recursive structure allows for arbitrary nesting - of multiple KeyBags, PKCS8ShroudedKeyBags, CertBags, CRLBags, and - SecretBags within the top-level SafeContents. - - - -Moriarty, et al. Informational [Page 14] - -RFC 7292 PKCS12 July 2014 - - -5. Using PFX PDUs - - This section describes the creation and usage of PFX PDUs. - -5.1. Creating PFX PDUs - - The steps for creating PFX PDUs are as follows. - - 1. It is somewhat clear from the ASN.1 how to make a number of - instances of SafeContents, each containing a number of (possibly - nested) instances of SafeBag. Let us assume, therefore, a number - of instances SC_1, SC_2,..., SC_n of SafeContents. Note that - there can be a more or less arbitrary number of instances of - SafeContents in a PFX PDU. As will be seen in step 2, each - instance can be encrypted (or not) separately. - - 2. For each SCI, depending on the chosen encryption option, - - A. If SC_i is not to be encrypted, make a ContentInfo CI_i - holding content type Data. The contents of the Data OCTET - STRING shall be a BER-encoding of SC_i (including tag, - length, and value octets). - - B. If SC_i is to be encrypted with a password, make a - ContentInfo CI_i of type EncryptedData. The - encryptedContentInfo field of CI_i has its contentType field - set to data and its encryptedContent field set to the - encryption of the BER-encoding of SC_i (note that the tag and - length octets shall be present). - - C. If SC_i is to be encrypted with a public key, make a - ContentInfo CI_i of type EnvelopedData in essentially the - same fashion as the EncryptedData ContentInfo was made in B. - - 3. Make an instance of AuthenticatedSafe by stringing together the - CI_i's in a SEQUENCE. - - 4. Make a ContentInfo T holding content type Data. The contents of - the Data OCTET STRING shall be a BER-encoding of the - AuthenticatedSafe value (including tag, length, and value - octets). - - 5. For integrity protection, - - A. If the PFX PDU is to be authenticated with a digital - signature, make a ContentInfo C of type SignedData. The - contentInfo field of the SignedData in C has T in it. C is - the ContentInfo in the top-level PFX structure. - - - -Moriarty, et al. Informational [Page 15] - -RFC 7292 PKCS12 July 2014 - - - B. If the PFX PDU is to be authenticated with HMAC, then an HMAC - with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, - or SHA-512/256 is computed on the contents of the Data in T - (i.e., excluding the OCTET STRING tag and length bytes). - This is exactly what would be initially digested in step 5A - if public-key authentication were being used. - -5.2. Importing Keys, etc., from a PFX PDU - - Importation from a PFX is accomplished essentially by reversing the - procedure for creating a PFX. In general, when an application - imports keys, etc., from a PFX, it should ignore any object - identifiers that it is not familiar with. At times, it may be - appropriate to alert the user to the presence of such object - identifiers. - - Special care may be taken by the application when importing an item - in the PFX would require overwriting an item that already exists - locally. The behavior of the application when such an item is - encountered may depend on what the item is (i.e., it may be that a - PKCS #8-shrouded private key and a CRL should be treated differently - here). Appropriate behavior may be to ask the user what action - should be taken for this item. - -6. Security Considerations - - When using passwords in privacy or integrity mode, it needs to be - considered that password-based cryptography is generally limited in - the security that it can provide, particularly for methods such as - those defined in this document where off-line password search is - possible. While the use of salt and iteration count can increase the - complexity of attack, it is essential that passwords are selected - well and that relevant guidelines (e.g., NIST SP 800-61-1) are taken - into account. It is also important that passwords be protected well - if stored. - - When choosing a salt value in password privacy or integrity mode, the - recommendations in Section 4 of PKCS #5 2.1 [13] [22] should be taken - into account. Ideally, the salt is as long as the output of the hash - function being used and consists of randomly generated data. - - - - - - - - - - - -Moriarty, et al. Informational [Page 16] - -RFC 7292 PKCS12 July 2014 - - -7. Normative References - - [1] Dobbertin, H., "The status of MD5 after a recent attack.", - CryptoBytes Vol. 2, #2, 1996. - - [2] ISO/IEC, "Information technology -- Abstract Syntax Notation - One (ASN.1) -- Specification of basic notation", ISO/IEC - 8824-1:2008, 2008. - - [3] ISO/IEC, "Information technology -- Abstract Syntax Notation - One (ASN.1) -- Information object specification", ISO/IEC - 8824-2:2008, 2008. - - [4] ISO/IEC, "Information technology -- Abstract Syntax Notation - One (ASN.1) -- Constraint specification", ISO/IEC 88247-3:2008, - 2008. - - [5] ISO/IEC, "Information technology -- Abstract Syntax Notation - One (ASN.1) -- Parameterization of ASN.1 specifications", - ISO/IEC 8824-4:2008, 2008. - - [6] ISO/IEC, "Information Technology - ASN.1 Encoding Rules: - Specification of Basic Encoding Rules (BER), Canonical Encoding - Rules (CER), and Distinguished Encoding Rules", ISO/IEC - 8825-1:2008, 2008. - - [7] ISO/IEC, "Information technology -- Open Systems - Interconnection -- The Directory: Models", ISO/IEC 9594-2:1997, - 1997. - - [8] ISO/IEC, "Information technology -- Open Systems - Interconnection -- The Directory: Authentication Framework", - ISO/IEC 9594-8:1997, 1997. - - [9] Microsoft, "PFX: Personal Exchange Syntax and Protocol - Standard", ISO/IEC Version 0.020, January 1997. - - [10] National Institute of Standards and Technology (NIST), "Secure - Hash Standard", FIPS Publication 180-4, March 2012. - - [11] National Institute of Standards and Technology (NIST), "The - Keyed-Hash Message Authentication Code (HMAC)", FIPS - Publication 198-1, July 2008. - - [12] National Institute of Standards and Technology (NIST), "The - Recommendation for Password-Based Key Derivation, Part 1: - Storage Applications", NIST Special Publication 800-132, - December 2010. - - - -Moriarty, et al. Informational [Page 17] - -RFC 7292 PKCS12 July 2014 - - - [13] RSA Laboratories, "PKCS #5: Password-Based Encryption - Standard", PKCS Version 2.1, October 2012. - - [14] RSA Laboratories, "PKCS #7: Cryptographic Message Syntax - Standard", PKCS Version 1.5, November 1993. - - [15] RSA Laboratories, "PKCS #8: Private-Key Information Syntax - Standard", PKCS Version 1.2, November 1993. - - [16] RSA Laboratories, "PKCS #12: Personal Information Exchange - Syntax", PKCS Version 1.1, December 2012. - - [17] Rivest, R. and B. Lampson, "SDSI - A Simple Distributed - Security Infrastructure", 1996, - . - - [18] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, - March 2011. - - [19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - - [20] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [21] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version - 1.5", RFC 2315, March 1998. - - [22] Kaliski, B., "PKCS #5: Password-Based Cryptography - Specification Version 2.0", RFC 2898, September 2000. - - [23] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes - and Attribute Types Version 2.0", RFC 2985, November 2000. - - [24] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010. - - [25] Turner, S. and L. Chen, "Updated Security Considerations for - the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, - March 2011. - - - - - - - - - - - - -Moriarty, et al. Informational [Page 18] - -RFC 7292 PKCS12 July 2014 - - -Appendix A. Message Authentication Codes (MACs) - - A MAC is a special type of function of a message (data bits) and an - integrity key. It can be computed or checked only by someone - possessing both the message and the integrity key. Its security - follows from the secrecy of the integrity key. In this standard, - MACing is used in password integrity mode. - - This document uses a particular type of MAC called HMAC [11] [20], - which can be constructed from any of a variety of hash functions. - Note that the specifications in [20] and [11] differ somewhat from - the specification in [9]. The hash function HMAC is based on is - identified in the MacData, which holds the MAC; for this version of - this standard, the hash function can be one of the following: SHA-1, - SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or SHA-512/256 [10]. - As indicated in Appendix B.4, this structure implies that the same - hash algorithm must be used to derive the MAC key itself in password - integrity mode and that the MAC key has either 160, 224, 256, 384, or - 512 bits. - - When password integrity mode is used to secure a PFX PDU, an HMAC - with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, or - SHA-512/256 is computed on the BER-encoding of the contents of the - content field of the authSafe field in the PFX PDU (see Section 5.1). - -Appendix B. Deriving Keys and IVs from Passwords and Salt - - Note that this method for password privacy mode is not recommended - and is deprecated for new usage. The procedures and algorithms - defined in PKCS #5 v2.1 [13] [22] should be used instead. - Specifically, PBES2 should be used as encryption scheme, with PBKDF2 - as the key derivation function. - - The method presented here is still used to generate the key in - password integrity mode. - - We present here a general method for using a hash function to produce - various types of pseudorandom bits from a password and a string of - salt bits. This method is used for password privacy mode and - password integrity mode in the present standard. - -B.1. Password Formatting - - The underlying password-based encryption methods in PKCS #5 v2.1 view - passwords (and salt) as being simple byte strings. The underlying - password-based encryption methods and the underlying password-based - authentication methods in this version of this document are similar. - - - - -Moriarty, et al. Informational [Page 19] - -RFC 7292 PKCS12 July 2014 - - - What's left unspecified in the above paragraph is precisely where the - byte string representing a password comes from. (This is not an - issue with salt strings, since they are supplied as a password-based - encryption (or authentication) parameter.) PKCS #5 v2.1 says: "[...] - a password is considered to be an octet string of arbitrary length - whose interpretation as a text string is unspecified. In the - interest of interoperability, however, it is recommended that - applications follow some common text encoding rules. ASCII and UTF-8 - are two possibilities." - - In this specification, however, all passwords are created from - BMPStrings with a NULL terminator. This means that each character in - the original BMPString is encoded in 2 bytes in big-endian format - (most-significant byte first). There are no Unicode byte order - marks. The 2 bytes produced from the last character in the BMPString - are followed by 2 additional bytes with the value 0x00. - - To illustrate with a simple example, if a user enters the 6-character - password "Beavis", the string that PKCS #12 implementations should - treat as the password is the following string of 14 bytes: - - 0x00 0x42 0x00 0x65 0x00 0x61 0x00 0x76 0x00 0x69 0x00 0x73 0x00 0x00 - -B.2. General Method - - Let H be a hash function built around a compression function f: - - Z_2^u x Z_2^v -> Z_2^u - - (that is, H has a chaining variable and output of length u bits, and - the message input to the compression function of H is v bits). The - values for u and v are as follows: - - HASH FUNCTION VALUE u VALUE v - MD2, MD5 128 512 - SHA-1 160 512 - SHA-224 224 512 - SHA-256 256 512 - SHA-384 384 1024 - SHA-512 512 1024 - SHA-512/224 224 1024 - SHA-512/256 256 1024 - - - - - - - - - -Moriarty, et al. Informational [Page 20] - -RFC 7292 PKCS12 July 2014 - - - Furthermore, let r be the iteration count. - - We assume here that u and v are both multiples of 8, as are the - lengths of the password and salt strings (which we denote by p and s, - respectively) and the number n of pseudorandom bits required. In - addition, u and v are of course non-zero. - - For information on security considerations for MD5 [19], see [25] and - [1], and on those for MD2, see [18]. - - The following procedure can be used to produce pseudorandom bits for - a particular "purpose" that is identified by a byte called "ID". The - meaning of this ID byte will be discussed later. - - 1. Construct a string, D (the "diversifier"), by concatenating v/8 - copies of ID. - - 2. Concatenate copies of the salt together to create a string S of - length v(ceiling(s/v)) bits (the final copy of the salt may be - truncated to create S). Note that if the salt is the empty - string, then so is S. - - 3. Concatenate copies of the password together to create a string P - of length v(ceiling(p/v)) bits (the final copy of the password - may be truncated to create P). Note that if the password is the - empty string, then so is P. - - 4. Set I=S||P to be the concatenation of S and P. - - 5. Set c=ceiling(n/u). - - 6. For i=1, 2, ..., c, do the following: - - A. Set A2=H^r(D||I). (i.e., the r-th hash of D||1, - H(H(H(... H(D||I)))) - - B. Concatenate copies of Ai to create a string B of length v - bits (the final copy of Ai may be truncated to create B). - - C. Treating I as a concatenation I_0, I_1, ..., I_(k-1) of v-bit - blocks, where k=ceiling(s/v)+ceiling(p/v), modify I by - setting I_j=(I_j+B+1) mod 2^v for each j. - - 7. Concatenate A_1, A_2, ..., A_c together to form a pseudorandom - bit string, A. - - 8. Use the first n bits of A as the output of this entire process. - - - - -Moriarty, et al. Informational [Page 21] - -RFC 7292 PKCS12 July 2014 - - - If the above process is being used to generate a DES key, the process - should be used to create 64 random bits, and the key's parity bits - should be set after the 64 bits have been produced. Similar concerns - hold for 2-key and 3-key triple-DES keys, for CDMF keys, and for any - similar keys with parity bits "built into them". - -B.3. More on the ID Byte - - This standard specifies 3 different values for the ID byte mentioned - above: - - 1. If ID=1, then the pseudorandom bits being produced are to be used - as key material for performing encryption or decryption. - - 2. If ID=2, then the pseudorandom bits being produced are to be used - as an IV (Initial Value) for encryption or decryption. - - 3. If ID=3, then the pseudorandom bits being produced are to be used - as an integrity key for MACing. - -B.4. Keys for Password Integrity Mode - - When password integrity mode is used to protect a PFX PDU, a password - and salt are used to derive a MAC key. As with password privacy - mode, the password is a Unicode string, and the salt is a byte - string. No particular lengths are prescribed in this standard for - either the password or the salt, but the general advice about - passwords and salt that is given in Appendix C applies here, as well. - - The hash function used to derive MAC keys is whatever hash function - is going to be used for MACing. The MAC keys that are derived have - the same length as the hash function's output. In this version of - this standard, SHA-1, SHA-224, SHA-256, SHA384, SHA-512, SHA-512/224, - or SHA/512/256 can be used to perform MACing, and so the MAC keys can - be 160, 224, 256, 384, or 512 bits. See Appendix A for more - information on MACing. - -Appendix C. Keys and IVs for Password Privacy Mode - - As stated at the start of Appendix B, use of this method for password - privacy mode is not recommended; this specification of keys and IVs - for password privacy mode is retained for backwards compatibility - with PKCS #12 v1.0 only. - - When password privacy mode is used to encrypt a PFX PDU, a password - (typically entered by the user), a salt and an iteration parameter - are used to derive a key (and an IV, if necessary). The password is - - - - -Moriarty, et al. Informational [Page 22] - -RFC 7292 PKCS12 July 2014 - - - a Unicode string, and as such, each character in it is represented by - 2 bytes. The salt is a byte string and so can be represented - directly as a sequence of bytes. - - This standard does not prescribe a length for the password. As - usual, however, too short a password might compromise privacy. A - particular application might well require a user-entered privacy - password for creating a PFX PDU to have a password exceeding some - specific length. - - This standard does not prescribe a length for the salt either. - Ideally, the salt is as long as the output of the hash function being - used and consists of completely random bits. - - The iteration count is recommended to be 1024 or more. (See [22] and - [13] for more information.) - - The PBES1 encryption scheme defined in PKCS #5 provides a number of - algorithm identifiers for deriving keys and IVs; here, we specify a - few more, all of which use the procedure detailed in Appendices B.2 - and B.3 to construct keys (and IVs, where needed). As is implied by - their names, all of the object identifiers below use the hash - function SHA-1. - -pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} -pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} -pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} -pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} -pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} -pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} -pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6} - - Each of the six PBE object identifiers above has the following ASN.1 - type for parameters: - - pkcs-12PbeParams ::= SEQUENCE { - salt OCTET STRING, - iterations INTEGER - } - - The pkcs-12PbeParams holds the salt that is used to generate the key - (and IV, if necessary) and the number of iterations to carry out. - - Note that the first two algorithm identifiers above (the algorithm - identifiers for RC4) only derive keys; it is unnecessary to derive an - IV for RC4. - - - - - -Moriarty, et al. Informational [Page 23] - -RFC 7292 PKCS12 July 2014 - - - This section is here for two reasons: first, to enable backwards - compatibility as described in the first paragraph of this section; - second, because it is still used in password integrity mode. In - order to not use it in password integrity mode, the ASN.1 definitions - require updates. This document recommends that future definitions of - the PFX structure replace the existing MacData object, optionally - present in password integrity mode, with a new object definition that - holds a MAC based on PKCS#5 [13] [22] PBMAC1 message authentication - scheme. This change would simplify the requirements for key - derivation functions used across all parts of the PFX structure. - -Appendix D. ASN.1 Module - - This appendix documents all ASN.1 types, values, and object sets - defined in this specification. It does so by providing an ASN.1 - module called PKCS-12. - - PKCS-12 { - iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-12(12) - modules(0) pkcs-12(1)} - - -- PKCS #12 v1.1 ASN.1 Module - -- Revised October 27, 2012 - - -- This module has been checked for conformance with the ASN.1 standard - -- by the OSS ASN.1 Tools - - DEFINITIONS IMPLICIT TAGS ::= - - BEGIN - - -- EXPORTS ALL - -- All types and values defined in this module are exported for use - -- in other ASN.1 modules. - - IMPORTS - - informationFramework - FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1) - usefulDefinitions(0) 3} - - ATTRIBUTE - FROM InformationFramework informationFramework - - ContentInfo, DigestInfo - FROM PKCS-7 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) - pkcs-7(7) modules(0) pkcs-7(1)} - - - - -Moriarty, et al. Informational [Page 24] - -RFC 7292 PKCS12 July 2014 - - - PrivateKeyInfo, EncryptedPrivateKeyInfo - FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) - pkcs-8(8) modules(1) pkcs-8(1)} - - pkcs-9, friendlyName, localKeyId, certTypes, crlTypes - FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) - pkcs-9(9) modules(0) pkcs-9(1)}; - - -- ============================ - -- Object identifiers - -- ============================ - - - rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) - rsadsi(113549)} - pkcs OBJECT IDENTIFIER ::= {rsadsi pkcs(1)} - pkcs-12 OBJECT IDENTIFIER ::= {pkcs 12} - pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} - pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} - pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} - pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} - pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} - pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} - pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6} - - bagtypes OBJECT IDENTIFIER ::= {pkcs-12 10 1} - - -- ============================ - -- The PFX PDU - -- ============================ - - PFX ::= SEQUENCE { - version INTEGER {v3(3)}(v3,...), - authSafe ContentInfo, - macData MacData OPTIONAL - } - - MacData ::= SEQUENCE { - mac DigestInfo, - macSalt OCTET STRING, - iterations INTEGER DEFAULT 1 - -- Note: The default is for historical reasons and its use is - -- deprecated. - } - - - - - - - -Moriarty, et al. Informational [Page 25] - -RFC 7292 PKCS12 July 2014 - - - AuthenticatedSafe ::= SEQUENCE OF ContentInfo - -- Data if unencrypted - -- EncryptedData if password-encrypted - -- EnvelopedData if public key-encrypted - - SafeContents ::= SEQUENCE OF SafeBag - - SafeBag ::= SEQUENCE { - bagId BAG-TYPE.&id ({PKCS12BagSet}), - bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}), - bagAttributes SET OF PKCS12Attribute OPTIONAL - } - - -- ============================ - -- Bag types - -- ============================ - - keyBag BAG-TYPE ::= - {KeyBag IDENTIFIED BY {bagtypes 1}} - pkcs8ShroudedKeyBag BAG-TYPE ::= - {PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}} - certBag BAG-TYPE ::= - {CertBag IDENTIFIED BY {bagtypes 3}} - crlBag BAG-TYPE ::= - {CRLBag IDENTIFIED BY {bagtypes 4}} - secretBag BAG-TYPE ::= - {SecretBag IDENTIFIED BY {bagtypes 5}} - safeContentsBag BAG-TYPE ::= - {SafeContents IDENTIFIED BY {bagtypes 6}} - - PKCS12BagSet BAG-TYPE ::= { - keyBag | - pkcs8ShroudedKeyBag | - certBag | - crlBag | - secretBag | - safeContentsBag, - ... -- For future extensions - } - - BAG-TYPE ::= TYPE-IDENTIFIER - - -- KeyBag - KeyBag ::= PrivateKeyInfo - - -- Shrouded KeyBag - PKCS8ShroudedKeyBag ::= EncryptedPrivateKeyInfo - - - - -Moriarty, et al. Informational [Page 26] - -RFC 7292 PKCS12 July 2014 - - - -- CertBag - CertBag ::= SEQUENCE { - certId BAG-TYPE.&id ({CertTypes}), - certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId}) - } - - x509Certificate BAG-TYPE ::= - {OCTET STRING IDENTIFIED BY {certTypes 1}} - -- DER-encoded X.509 certificate stored in OCTET STRING - sdsiCertificate BAG-TYPE ::= - {IA5String IDENTIFIED BY {certTypes 2}} - -- Base64-encoded SDSI certificate stored in IA5String - - CertTypes BAG-TYPE ::= { - x509Certificate | - sdsiCertificate, - ... -- For future extensions - } - - -- CRLBag - CRLBag ::= SEQUENCE { - crlId BAG-TYPE.&id ({CRLTypes}), - crltValue [0] EXPLICIT BAG-TYPE.&Type ({CRLTypes}{@crlId}) - } - - x509CRL BAG-TYPE ::= - {OCTET STRING IDENTIFIED BY {crlTypes 1}} - -- DER-encoded X.509 CRL stored in OCTET STRING - - CRLTypes BAG-TYPE ::= { - x509CRL, - ... -- For future extensions - } - - -- Secret Bag - SecretBag ::= SEQUENCE { - secretTypeId BAG-TYPE.&id ({SecretTypes}), - secretValue [0] EXPLICIT BAG-TYPE.&Type ({SecretTypes} - {@secretTypeId}) - } - - SecretTypes BAG-TYPE ::= { - ... -- For future extensions - } - - -- ============================ - -- Attributes - -- ============================ - - - -Moriarty, et al. Informational [Page 27] - -RFC 7292 PKCS12 July 2014 - - - PKCS12Attribute ::= SEQUENCE { - attrId ATTRIBUTE.&id ({PKCS12AttrSet}), - attrValues SET OF ATTRIBUTE.&Type ({PKCS12AttrSet}{@attrId}) - } -- This type is compatible with the X.500 type 'Attribute' - - PKCS12AttrSet ATTRIBUTE ::= { - friendlyName | - localKeyId, - ... -- Other attributes are allowed - } - - END - -Appendix E. Intellectual Property Considerations - - EMC Corporation makes no patent claims on the general constructions - described in this document, although specific underlying techniques - may be covered. - - RC2 and RC4 are trademarks of EMC Corporation. - - EMC Corporation makes no representations regarding intellectual - property claims by other parties. Such determination is the - responsibility of the user. - -Appendix F. Acknowledgments - - Many thanks to Dan Simon of Microsoft Corporation and Jim Spring of - Netscape Communications Corporation for their assistance in preparing - early drafts of this document. Especial thanks to Brian Beckman of - Microsoft Corporation for writing the specification that this - document is based on. - -Appendix G. About PKCS - - The Public-Key Cryptography Standards are specifications produced by - RSA Laboratories in cooperation with secure systems developers - worldwide for the purpose of accelerating the deployment of public- - key cryptography. First published in 1991 as a result of meetings - with a small group of early adopters of public-key technology, the - PKCS documents have become widely referenced and implemented. - Contributions from the PKCS series have become part of many formal - and de facto standards, including ANSI X9 documents, PKIX, SET, S/ - MIME, and SSL. - - Further development of PKCS occurs through the IETF. Suggestions for - improvement are welcome. - - - - -Moriarty, et al. Informational [Page 28] - -RFC 7292 PKCS12 July 2014 - - -Authors' Addresses - - Kathleen M. Moriarty (editor) - EMC Corporation - 176 South Street - Hopkinton, MA - United States - - EMail: Kathleen.Moriarty@emc.com - - - Magnus Nystrom - Microsoft Corporation - 1 Microsoft Way - Redmond, WA 98052 - United States - - EMail: mnystrom@microsoft.com - - - Sean Parkinson - RSA Security Inc. - 345 Queen Street - Brisbane, QLD, 4000 - Australia - - EMail: Sean.Parkinson@rsa.com - - - Andreas Rusch - RSA Security Inc. - 345 Queen Street - Brisbane, QLD, 4000 - Australia - - EMail: Andreas.Rusch@rsa.com - - - Michael Scott - RSA Security Inc. - 345 Queen Street - Brisbane, QLD, 4000 - Australia - - EMail: Michael2.Scott@rsa.com - - - - - - -Moriarty, et al. Informational [Page 29] - diff --git a/specifications/auth/rfc7636.pdf b/specifications/auth/rfc7636.pdf deleted file mode 100644 index 4acbd26f..00000000 Binary files a/specifications/auth/rfc7636.pdf and /dev/null differ diff --git a/specifications/auth/rfc7636.txt b/specifications/auth/rfc7636.txt deleted file mode 100644 index 653cb531..00000000 --- a/specifications/auth/rfc7636.txt +++ /dev/null @@ -1,1123 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) N. Sakimura, Ed. -Request for Comments: 7636 Nomura Research Institute -Category: Standards Track J. Bradley -ISSN: 2070-1721 Ping Identity - N. Agarwal - Google - September 2015 - - - Proof Key for Code Exchange by OAuth Public Clients - -Abstract - - OAuth 2.0 public clients utilizing the Authorization Code Grant are - susceptible to the authorization code interception attack. This - specification describes the attack as well as a technique to mitigate - against the threat through the use of Proof Key for Code Exchange - (PKCE, pronounced "pixy"). - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 5741. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - http://www.rfc-editor.org/info/rfc7636. - -Copyright Notice - - Copyright (c) 2015 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - -Sakimura, et al. Standards Track [Page 1] - -RFC 7636 OAUTH PKCE September 2015 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Protocol Flow ..............................................5 - 2. Notational Conventions ..........................................6 - 3. Terminology .....................................................7 - 3.1. Abbreviations ..............................................7 - 4. Protocol ........................................................8 - 4.1. Client Creates a Code Verifier .............................8 - 4.2. Client Creates the Code Challenge ..........................8 - 4.3. Client Sends the Code Challenge with the - Authorization Request ......................................9 - 4.4. Server Returns the Code ....................................9 - 4.4.1. Error Response ......................................9 - 4.5. Client Sends the Authorization Code and the Code - Verifier to the Token Endpoint ............................10 - 4.6. Server Verifies code_verifier before Returning the - Tokens ....................................................10 - 5. Compatibility ..................................................11 - 6. IANA Considerations ............................................11 - 6.1. OAuth Parameters Registry .................................11 - 6.2. PKCE Code Challenge Method Registry .......................11 - 6.2.1. Registration Template ..............................12 - 6.2.2. Initial Registry Contents ..........................13 - 7. Security Considerations ........................................13 - 7.1. Entropy of the code_verifier ..............................13 - 7.2. Protection against Eavesdroppers ..........................13 - 7.3. Salting the code_challenge ................................14 - 7.4. OAuth Security Considerations .............................14 - 7.5. TLS Security Considerations ...............................15 - 8. References .....................................................15 - 8.1. Normative References ......................................15 - 8.2. Informative References ....................................16 - Appendix A. Notes on Implementing Base64url Encoding without - Padding .............................................17 - Appendix B. Example for the S256 code_challenge_method ...........17 - Acknowledgements ..................................................19 - Authors' Addresses ................................................20 - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 2] - -RFC 7636 OAUTH PKCE September 2015 - - -1. Introduction - - OAuth 2.0 [RFC6749] public clients are susceptible to the - authorization code interception attack. - - In this attack, the attacker intercepts the authorization code - returned from the authorization endpoint within a communication path - not protected by Transport Layer Security (TLS), such as inter- - application communication within the client's operating system. - - Once the attacker has gained access to the authorization code, it can - use it to obtain the access token. - - Figure 1 shows the attack graphically. In step (1), the native - application running on the end device, such as a smartphone, issues - an OAuth 2.0 Authorization Request via the browser/operating system. - The Redirection Endpoint URI in this case typically uses a custom URI - scheme. Step (1) happens through a secure API that cannot be - intercepted, though it may potentially be observed in advanced attack - scenarios. The request then gets forwarded to the OAuth 2.0 - authorization server in step (2). Because OAuth requires the use of - TLS, this communication is protected by TLS and cannot be - intercepted. The authorization server returns the authorization code - in step (3). In step (4), the Authorization Code is returned to the - requester via the Redirection Endpoint URI that was provided in step - (1). - - Note that it is possible for a malicious app to register itself as a - handler for the custom scheme in addition to the legitimate OAuth 2.0 - app. Once it does so, the malicious app is now able to intercept the - authorization code in step (4). This allows the attacker to request - and obtain an access token in steps (5) and (6), respectively. - - - - - - - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 3] - -RFC 7636 OAUTH PKCE September 2015 - - - +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ - | End Device (e.g., Smartphone) | - | | - | +-------------+ +----------+ | (6) Access Token +----------+ - | |Legitimate | | Malicious|<--------------------| | - | |OAuth 2.0 App| | App |-------------------->| | - | +-------------+ +----------+ | (5) Authorization | | - | | ^ ^ | Grant | | - | | \ | | | | - | | \ (4) | | | | - | (1) | \ Authz| | | | - | Authz| \ Code | | | Authz | - | Request| \ | | | Server | - | | \ | | | | - | | \ | | | | - | v \ | | | | - | +----------------------------+ | | | - | | | | (3) Authz Code | | - | | Operating System/ |<--------------------| | - | | Browser |-------------------->| | - | | | | (2) Authz Request | | - | +----------------------------+ | +----------+ - +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ - - Figure 1: Authorization Code Interception Attack - - A number of pre-conditions need to hold for this attack to work: - - 1. The attacker manages to register a malicious application on the - client device and registers a custom URI scheme that is also used - by another application. The operating systems must allow a custom - URI scheme to be registered by multiple applications. - - 2. The OAuth 2.0 authorization code grant is used. - - 3. The attacker has access to the OAuth 2.0 [RFC6749] "client_id" and - "client_secret" (if provisioned). All OAuth 2.0 native app - client-instances use the same "client_id". Secrets provisioned in - client binary applications cannot be considered confidential. - - 4. Either one of the following condition is met: - - 4a. The attacker (via the installed application) is able to - observe only the responses from the authorization endpoint. - When "code_challenge_method" value is "plain", only this - attack is mitigated. - - - - - -Sakimura, et al. Standards Track [Page 4] - -RFC 7636 OAUTH PKCE September 2015 - - - 4b. A more sophisticated attack scenario allows the attacker to - observe requests (in addition to responses) to the - authorization endpoint. The attacker is, however, not able to - act as a man in the middle. This was caused by leaking http - log information in the OS. To mitigate this, - "code_challenge_method" value must be set either to "S256" or - a value defined by a cryptographically secure - "code_challenge_method" extension. - - While this is a long list of pre-conditions, the described attack has - been observed in the wild and has to be considered in OAuth 2.0 - deployments. While the OAuth 2.0 threat model (Section 4.4.1 of - [RFC6819]) describes mitigation techniques, they are, unfortunately, - not applicable since they rely on a per-client instance secret or a - per-client instance redirect URI. - - To mitigate this attack, this extension utilizes a dynamically - created cryptographically random key called "code verifier". A - unique code verifier is created for every authorization request, and - its transformed value, called "code challenge", is sent to the - authorization server to obtain the authorization code. The - authorization code obtained is then sent to the token endpoint with - the "code verifier", and the server compares it with the previously - received request code so that it can perform the proof of possession - of the "code verifier" by the client. This works as the mitigation - since the attacker would not know this one-time key, since it is sent - over TLS and cannot be intercepted. - -1.1. Protocol Flow - - +-------------------+ - | Authz Server | - +--------+ | +---------------+ | - | |--(A)- Authorization Request ---->| | | - | | + t(code_verifier), t_m | | Authorization | | - | | | | Endpoint | | - | |<-(B)---- Authorization Code -----| | | - | | | +---------------+ | - | Client | | | - | | | +---------------+ | - | |--(C)-- Access Token Request ---->| | | - | | + code_verifier | | Token | | - | | | | Endpoint | | - | |<-(D)------ Access Token ---------| | | - +--------+ | +---------------+ | - +-------------------+ - - Figure 2: Abstract Protocol Flow - - - -Sakimura, et al. Standards Track [Page 5] - -RFC 7636 OAUTH PKCE September 2015 - - - This specification adds additional parameters to the OAuth 2.0 - Authorization and Access Token Requests, shown in abstract form in - Figure 2. - - A. The client creates and records a secret named the "code_verifier" - and derives a transformed version "t(code_verifier)" (referred to - as the "code_challenge"), which is sent in the OAuth 2.0 - Authorization Request along with the transformation method "t_m". - - B. The Authorization Endpoint responds as usual but records - "t(code_verifier)" and the transformation method. - - C. The client then sends the authorization code in the Access Token - Request as usual but includes the "code_verifier" secret generated - at (A). - - D. The authorization server transforms "code_verifier" and compares - it to "t(code_verifier)" from (B). Access is denied if they are - not equal. - - An attacker who intercepts the authorization code at (B) is unable to - redeem it for an access token, as they are not in possession of the - "code_verifier" secret. - -2. Notational Conventions - - 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 - "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. - If these words are used without being spelled in uppercase, then they - are to be interpreted with their natural language meanings. - - This specification uses the Augmented Backus-Naur Form (ABNF) - notation of [RFC5234]. - - STRING denotes a sequence of zero or more ASCII [RFC20] characters. - - OCTETS denotes a sequence of zero or more octets. - - ASCII(STRING) denotes the octets of the ASCII [RFC20] representation - of STRING where STRING is a sequence of zero or more ASCII - characters. - - BASE64URL-ENCODE(OCTETS) denotes the base64url encoding of OCTETS, - per Appendix A, producing a STRING. - - - - - -Sakimura, et al. Standards Track [Page 6] - -RFC 7636 OAUTH PKCE September 2015 - - - BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, - per Appendix A, producing a sequence of octets. - - SHA256(OCTETS) denotes a SHA2 256-bit hash [RFC6234] of OCTETS. - -3. Terminology - - In addition to the terms defined in OAuth 2.0 [RFC6749], this - specification defines the following terms: - - code verifier - A cryptographically random string that is used to correlate the - authorization request to the token request. - - code challenge - A challenge derived from the code verifier that is sent in the - authorization request, to be verified against later. - - code challenge method - A method that was used to derive code challenge. - - Base64url Encoding - Base64 encoding using the URL- and filename-safe character set - defined in Section 5 of [RFC4648], with all trailing '=' - characters omitted (as permitted by Section 3.2 of [RFC4648]) and - without the inclusion of any line breaks, whitespace, or other - additional characters. (See Appendix A for notes on implementing - base64url encoding without padding.) - -3.1. Abbreviations - - ABNF Augmented Backus-Naur Form - - Authz Authorization - - PKCE Proof Key for Code Exchange - - MITM Man-in-the-middle - - MTI Mandatory To Implement - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 7] - -RFC 7636 OAUTH PKCE September 2015 - - -4. Protocol - -4.1. Client Creates a Code Verifier - - The client first creates a code verifier, "code_verifier", for each - OAuth 2.0 [RFC6749] Authorization Request, in the following manner: - - code_verifier = high-entropy cryptographic random STRING using the - unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" - from Section 2.3 of [RFC3986], with a minimum length of 43 characters - and a maximum length of 128 characters. - - ABNF for "code_verifier" is as follows. - - code-verifier = 43*128unreserved - unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" - ALPHA = %x41-5A / %x61-7A - DIGIT = %x30-39 - - NOTE: The code verifier SHOULD have enough entropy to make it - impractical to guess the value. It is RECOMMENDED that the output of - a suitable random number generator be used to create a 32-octet - sequence. The octet sequence is then base64url-encoded to produce a - 43-octet URL safe string to use as the code verifier. - -4.2. Client Creates the Code Challenge - - The client then creates a code challenge derived from the code - verifier by using one of the following transformations on the code - verifier: - - plain - code_challenge = code_verifier - - S256 - code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) - - If the client is capable of using "S256", it MUST use "S256", as - "S256" is Mandatory To Implement (MTI) on the server. Clients are - permitted to use "plain" only if they cannot support "S256" for some - technical reason and know via out-of-band configuration that the - server supports "plain". - - The plain transformation is for compatibility with existing - deployments and for constrained environments that can't use the S256 - transformation. - - - - - -Sakimura, et al. Standards Track [Page 8] - -RFC 7636 OAUTH PKCE September 2015 - - - ABNF for "code_challenge" is as follows. - - code-challenge = 43*128unreserved - unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" - ALPHA = %x41-5A / %x61-7A - DIGIT = %x30-39 - -4.3. Client Sends the Code Challenge with the Authorization Request - - The client sends the code challenge as part of the OAuth 2.0 - Authorization Request (Section 4.1.1 of [RFC6749]) using the - following additional parameters: - - code_challenge - REQUIRED. Code challenge. - - code_challenge_method - OPTIONAL, defaults to "plain" if not present in the request. Code - verifier transformation method is "S256" or "plain". - -4.4. Server Returns the Code - - When the server issues the authorization code in the authorization - response, it MUST associate the "code_challenge" and - "code_challenge_method" values with the authorization code so it can - be verified later. - - Typically, the "code_challenge" and "code_challenge_method" values - are stored in encrypted form in the "code" itself but could - alternatively be stored on the server associated with the code. The - server MUST NOT include the "code_challenge" value in client requests - in a form that other entities can extract. - - The exact method that the server uses to associate the - "code_challenge" with the issued "code" is out of scope for this - specification. - -4.4.1. Error Response - - If the server requires Proof Key for Code Exchange (PKCE) by OAuth - public clients and the client does not send the "code_challenge" in - the request, the authorization endpoint MUST return the authorization - error response with the "error" value set to "invalid_request". The - "error_description" or the response of "error_uri" SHOULD explain the - nature of error, e.g., code challenge required. - - - - - - -Sakimura, et al. Standards Track [Page 9] - -RFC 7636 OAUTH PKCE September 2015 - - - If the server supporting PKCE does not support the requested - transformation, the authorization endpoint MUST return the - authorization error response with "error" value set to - "invalid_request". The "error_description" or the response of - "error_uri" SHOULD explain the nature of error, e.g., transform - algorithm not supported. - -4.5. Client Sends the Authorization Code and the Code Verifier to the - Token Endpoint - - Upon receipt of the Authorization Code, the client sends the Access - Token Request to the token endpoint. In addition to the parameters - defined in the OAuth 2.0 Access Token Request (Section 4.1.3 of - [RFC6749]), it sends the following parameter: - - code_verifier - REQUIRED. Code verifier - - The "code_challenge_method" is bound to the Authorization Code when - the Authorization Code is issued. That is the method that the token - endpoint MUST use to verify the "code_verifier". - -4.6. Server Verifies code_verifier before Returning the Tokens - - Upon receipt of the request at the token endpoint, the server - verifies it by calculating the code challenge from the received - "code_verifier" and comparing it with the previously associated - "code_challenge", after first transforming it according to the - "code_challenge_method" method specified by the client. - - If the "code_challenge_method" from Section 4.3 was "S256", the - received "code_verifier" is hashed by SHA-256, base64url-encoded, and - then compared to the "code_challenge", i.e.: - - BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge - - If the "code_challenge_method" from Section 4.3 was "plain", they are - compared directly, i.e.: - - code_verifier == code_challenge. - - If the values are equal, the token endpoint MUST continue processing - as normal (as defined by OAuth 2.0 [RFC6749]). If the values are not - equal, an error response indicating "invalid_grant" as described in - Section 5.2 of [RFC6749] MUST be returned. - - - - - - -Sakimura, et al. Standards Track [Page 10] - -RFC 7636 OAUTH PKCE September 2015 - - -5. Compatibility - - Server implementations of this specification MAY accept OAuth2.0 - clients that do not implement this extension. If the "code_verifier" - is not received from the client in the Authorization Request, servers - supporting backwards compatibility revert to the OAuth 2.0 [RFC6749] - protocol without this extension. - - As the OAuth 2.0 [RFC6749] server responses are unchanged by this - specification, client implementations of this specification do not - need to know if the server has implemented this specification or not - and SHOULD send the additional parameters as defined in Section 4 to - all servers. - -6. IANA Considerations - - IANA has made the following registrations per this document. - -6.1. OAuth Parameters Registry - - This specification registers the following parameters in the IANA - "OAuth Parameters" registry defined in OAuth 2.0 [RFC6749]. - - o Parameter name: code_verifier - o Parameter usage location: token request - o Change controller: IESG - o Specification document(s): RFC 7636 (this document) - - o Parameter name: code_challenge - o Parameter usage location: authorization request - o Change controller: IESG - o Specification document(s): RFC 7636 (this document) - - o Parameter name: code_challenge_method - o Parameter usage location: authorization request - o Change controller: IESG - o Specification document(s): RFC 7636 (this document) - -6.2. PKCE Code Challenge Method Registry - - This specification establishes the "PKCE Code Challenge Methods" - registry. The new registry should be a sub-registry of the "OAuth - Parameters" registry. - - Additional "code_challenge_method" types for use with the - authorization endpoint are registered using the Specification - Required policy [RFC5226], which includes review of the request by - one or more Designated Experts (DEs). The DEs will ensure that there - - - -Sakimura, et al. Standards Track [Page 11] - -RFC 7636 OAUTH PKCE September 2015 - - - is at least a two-week review of the request on the oauth-ext- - review@ietf.org mailing list and that any discussion on that list - converges before they respond to the request. To allow for the - allocation of values prior to publication, the Designated Expert(s) - may approve registration once they are satisfied that an acceptable - specification will be published. - - Registration requests and discussion on the oauth-ext-review@ietf.org - mailing list should use an appropriate subject, such as "Request for - PKCE code_challenge_method: example"). - - The Designated Expert(s) should consider the discussion on the - mailing list, as well as the overall security properties of the - challenge method when evaluating registration requests. New methods - should not disclose the value of the code_verifier in the request to - the Authorization endpoint. Denials should include an explanation - and, if applicable, suggestions as to how to make the request - successful. - -6.2.1. Registration Template - - Code Challenge Method Parameter Name: - The name requested (e.g., "example"). Because a core goal of this - specification is for the resulting representations to be compact, - it is RECOMMENDED that the name be short -- not to exceed 8 - characters without a compelling reason to do so. This name is - case-sensitive. Names may not match other registered names in a - case-insensitive manner unless the Designated Expert(s) states - that there is a compelling reason to allow an exception in this - particular case. - - Change Controller: - For Standards Track RFCs, state "IESG". For others, give the name - of the responsible party. Other details (e.g., postal address, - email address, and home page URI) may also be included. - - Specification Document(s): - Reference to the document(s) that specifies the parameter, - preferably including URI(s) that can be used to retrieve copies of - the document(s). An indication of the relevant sections may also - be included but is not required. - - - - - - - - - - -Sakimura, et al. Standards Track [Page 12] - -RFC 7636 OAUTH PKCE September 2015 - - -6.2.2. Initial Registry Contents - - Per this document, IANA has registered the Code Challenge Method - Parameter Names defined in Section 4.2 in this registry. - - o Code Challenge Method Parameter Name: plain - o Change Controller: IESG - o Specification Document(s): Section 4.2 of RFC 7636 (this document) - - o Code Challenge Method Parameter Name: S256 - o Change Controller: IESG - o Specification Document(s): Section 4.2 of RFC 7636 (this document) - -7. Security Considerations - -7.1. Entropy of the code_verifier - - The security model relies on the fact that the code verifier is not - learned or guessed by the attacker. It is vitally important to - adhere to this principle. As such, the code verifier has to be - created in such a manner that it is cryptographically random and has - high entropy that it is not practical for the attacker to guess. - - The client SHOULD create a "code_verifier" with a minimum of 256 bits - of entropy. This can be done by having a suitable random number - generator create a 32-octet sequence. The octet sequence can then be - base64url-encoded to produce a 43-octet URL safe string to use as a - "code_challenge" that has the required entropy. - -7.2. Protection against Eavesdroppers - - Clients MUST NOT downgrade to "plain" after trying the "S256" method. - Servers that support PKCE are required to support "S256", and servers - that do not support PKCE will simply ignore the unknown - "code_verifier". Because of this, an error when "S256" is presented - can only mean that the server is faulty or that a MITM attacker is - trying a downgrade attack. - - The "S256" method protects against eavesdroppers observing or - intercepting the "code_challenge", because the challenge cannot be - used without the verifier. With the "plain" method, there is a - chance that "code_challenge" will be observed by the attacker on the - device or in the http request. Since the code challenge is the same - as the code verifier in this case, the "plain" method does not - protect against the eavesdropping of the initial request. - - The use of "S256" protects against disclosure of the "code_verifier" - value to an attacker. - - - -Sakimura, et al. Standards Track [Page 13] - -RFC 7636 OAUTH PKCE September 2015 - - - Because of this, "plain" SHOULD NOT be used and exists only for - compatibility with deployed implementations where the request path is - already protected. The "plain" method SHOULD NOT be used in new - implementations, unless they cannot support "S256" for some technical - reason. - - The "S256" code challenge method or other cryptographically secure - code challenge method extension SHOULD be used. The "plain" code - challenge method relies on the operating system and transport - security not to disclose the request to an attacker. - - If the code challenge method is "plain" and the code challenge is to - be returned inside authorization "code" to achieve a stateless - server, it MUST be encrypted in such a manner that only the server - can decrypt and extract it. - -7.3. Salting the code_challenge - - To reduce implementation complexity, salting is not used in the - production of the code challenge, as the code verifier contains - sufficient entropy to prevent brute-force attacks. Concatenating a - publicly known value to a code verifier (containing 256 bits of - entropy) and then hashing it with SHA256 to produce a code challenge - would not increase the number of attempts necessary to brute force a - valid value for code verifier. - - While the "S256" transformation is like hashing a password, there are - important differences. Passwords tend to be relatively low-entropy - words that can be hashed offline and the hash looked up in a - dictionary. By concatenating a unique though public value to each - password prior to hashing, the dictionary space that an attacker - needs to search is greatly expanded. - - Modern graphics processors now allow attackers to calculate hashes in - real time faster than they could be looked up from a disk. This - eliminates the value of the salt in increasing the complexity of a - brute-force attack for even low-entropy passwords. - -7.4. OAuth Security Considerations - - All the OAuth security analysis presented in [RFC6819] applies, so - readers SHOULD carefully follow it. - - - - - - - - - -Sakimura, et al. Standards Track [Page 14] - -RFC 7636 OAUTH PKCE September 2015 - - -7.5. TLS Security Considerations - - Current security considerations can be found in "Recommendations for - Secure Use of Transport Layer Security (TLS) and Datagram Transport - Layer Security (DTLS)" [BCP195]. This supersedes the TLS version - recommendations in OAuth 2.0 [RFC6749]. - -8. References - -8.1. Normative References - - [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, - "Recommendations for Secure Use of Transport Layer - Security (TLS) and Datagram Transport Layer Security - (DTLS)", BCP 195, RFC 7525, May 2015, - . - - [RFC20] Cerf, V., "ASCII format for network interchange", STD 80, - RFC 20, DOI 10.17487/RFC0020, October 1969, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC - 3986, DOI 10.17487/RFC3986, January 2005, - . - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - DOI 10.17487/RFC5226, May 2008, - . - - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . - - - - - - - -Sakimura, et al. Standards Track [Page 15] - -RFC 7636 OAUTH PKCE September 2015 - - - [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms - (SHA and SHA-based HMAC and HKDF)", RFC 6234, - DOI 10.17487/RFC6234, May 2011, - . - - [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", - RFC 6749, DOI 10.17487/RFC6749, October 2012, - . - -8.2. Informative References - - [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 - Threat Model and Security Considerations", RFC 6819, - DOI 10.17487/RFC6819, January 2013, - . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 16] - -RFC 7636 OAUTH PKCE September 2015 - - -Appendix A. Notes on Implementing Base64url Encoding without Padding - - This appendix describes how to implement a base64url-encoding - function without padding, based upon the standard base64-encoding - function that uses padding. - - To be concrete, example C# code implementing these functions is shown - below. Similar code could be used in other languages. - - static string base64urlencode(byte [] arg) - { - string s = Convert.ToBase64String(arg); // Regular base64 encoder - s = s.Split('=')[0]; // Remove any trailing '='s - s = s.Replace('+', '-'); // 62nd char of encoding - s = s.Replace('/', '_'); // 63rd char of encoding - return s; - } - - An example correspondence between unencoded and encoded values - follows. The octet sequence below encodes into the string below, - which when decoded, reproduces the octet sequence. - - 3 236 255 224 193 - - A-z_4ME - -Appendix B. Example for the S256 code_challenge_method - - The client uses output of a suitable random number generator to - create a 32-octet sequence. The octets representing the value in - this example (using JSON array notation) are: - - [116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, - 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, - 132, 141, 121] - - Encoding this octet sequence as base64url provides the value of the - code_verifier: - - dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk - - The code_verifier is then hashed via the SHA256 hash function to - produce: - - [19, 211, 30, 150, 26, 26, 216, 236, 47, 22, 177, 12, 76, 152, 46, - 8, 118, 168, 120, 173, 109, 241, 68, 86, 110, 225, 137, 74, 203, - 112, 249, 195] - - - - -Sakimura, et al. Standards Track [Page 17] - -RFC 7636 OAUTH PKCE September 2015 - - - Encoding this octet sequence as base64url provides the value of the - code_challenge: - - E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM - - The authorization request includes: - - code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM - &code_challenge_method=S256 - - The authorization server then records the code_challenge and - code_challenge_method along with the code that is granted to the - client. - - In the request to the token_endpoint, the client includes the code - received in the authorization response as well as the additional - parameter: - - code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk - - The authorization server retrieves the information for the code - grant. Based on the recorded code_challenge_method being S256, it - then hashes and base64url-encodes the value of code_verifier: - - BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) - - The calculated value is then compared with the value of - "code_challenge": - - BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge - - If the two values are equal, then the authorization server can - provide the tokens as long as there are no other errors in the - request. If the values are not equal, then the request must be - rejected, and an error returned. - - - - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 18] - -RFC 7636 OAUTH PKCE September 2015 - - -Acknowledgements - - The initial draft version of this specification was created by the - OpenID AB/Connect Working Group of the OpenID Foundation. - - This specification is the work of the OAuth Working Group, which - includes dozens of active and dedicated participants. In particular, - the following individuals contributed ideas, feedback, and wording - that shaped and formed the final specification: - - Anthony Nadalin, Microsoft - Axel Nenker, Deutsche Telekom - Breno de Medeiros, Google - Brian Campbell, Ping Identity - Chuck Mortimore, Salesforce - Dirk Balfanz, Google - Eduardo Gueiros, Jive Communications - Hannes Tschonfenig, ARM - James Manger, Telstra - Justin Richer, MIT Kerberos - Josh Mandel, Boston Children's Hospital - Lewis Adam, Motorola Solutions - Madjid Nakhjiri, Samsung - Michael B. Jones, Microsoft - Paul Madsen, Ping Identity - Phil Hunt, Oracle - Prateek Mishra, Oracle - Ryo Ito, mixi - Scott Tomilson, Ping Identity - Sergey Beryozkin - Takamichi Saito - Torsten Lodderstedt, Deutsche Telekom - William Denniss, Google - - - - - - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 19] - -RFC 7636 OAUTH PKCE September 2015 - - -Authors' Addresses - - Nat Sakimura (editor) - Nomura Research Institute - 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. - Chiyoda-ku, Tokyo 100-0005 - Japan - - Phone: +81-3-5533-2111 - Email: n-sakimura@nri.co.jp - URI: http://nat.sakimura.org/ - - - John Bradley - Ping Identity - Casilla 177, Sucursal Talagante - Talagante, RM - Chile - - Phone: +44 20 8133 3718 - Email: ve7jtb@ve7jtb.com - URI: http://www.thread-safe.com/ - - - Naveen Agarwal - Google - 1600 Amphitheatre Parkway - Mountain View, CA 94043 - United States - - Phone: +1 650-253-0000 - Email: naa@google.com - URI: http://google.com/ - - - - - - - - - - - - - - - - - - -Sakimura, et al. Standards Track [Page 20] - diff --git a/specifications/calendar/rfc5545.txt b/specifications/calendar/rfc5545.txt deleted file mode 100644 index 47ea31d6..00000000 --- a/specifications/calendar/rfc5545.txt +++ /dev/null @@ -1,9411 +0,0 @@ - - - - - - -Network Working Group B. Desruisseaux, Ed. -Request for Comments: 5545 Oracle -Obsoletes: 2445 September 2009 -Category: Standards Track - - - Internet Calendaring and Scheduling Core Object Specification - (iCalendar) - -Abstract - -This document defines the iCalendar data format for representing and -exchanging calendaring and scheduling information such as events, -to-dos, journal entries, and free/busy information, independent of any -particular calendar service or protocol. - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright and License Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - - - -Desruisseaux Standards Track [Page 1] - -RFC 5545 iCalendar September 2009 - - - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 - 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 - 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 - 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 - 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 - 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 - 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 - 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 - 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 - 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 - 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 - 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 - 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 - 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 - 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 - 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 - 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 - 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 - 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 - 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 - 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 - 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 - 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 - 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 - 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 - 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 - 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 - 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 - 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 - 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 - 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 - 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 - 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 - 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 - 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 - 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 - 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 - 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 - 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 - 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 - - - -Desruisseaux Standards Track [Page 2] - -RFC 5545 iCalendar September 2009 - - - 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 - 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 - 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 - 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 - 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 - 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 - 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 - 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 - 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 - 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 - 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 - 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 - 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 - 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 - 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 - 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 - 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 - 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 - 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 - 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 - 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 - 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 - 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 - 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 - 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 - 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 - 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 - 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 - 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 - 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 - 3.8.2. Date and Time Component Properties . . . . . . . . . 95 - 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 - 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 - 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 - 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 - 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 - 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 - 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 - 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 - 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 - 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 - 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 - 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 - 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 - 3.8.4. Relationship Component Properties . . . . . . . . . . 108 - 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 - 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 - - - -Desruisseaux Standards Track [Page 3] - -RFC 5545 iCalendar September 2009 - - - 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 - 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 - 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 - 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 - 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 - 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 - 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 - 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 - 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 - 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 - 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 - 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 - 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 - 3.8.7. Change Management Component Properties . . . . . . . 138 - 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 - 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 - 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 - 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 - 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 - 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 - 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 - 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 - 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 - 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 - 6. Internationalization Considerations . . . . . . . . . . . . . 151 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 - 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 - 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 - 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 - 8.2.2. Registration Template for Components . . . . . . . . 155 - 8.2.3. Registration Template for Properties . . . . . . . . 156 - 8.2.4. Registration Template for Parameters . . . . . . . . 156 - 8.2.5. Registration Template for Value Data Types . . . . . 157 - 8.2.6. Registration Template for Values . . . . . . . . . . 157 - 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 - 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 - 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 - 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 - 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 - 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 - 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 - 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 - 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 - 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 - 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 - 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 - 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 - - - -Desruisseaux Standards Track [Page 4] - -RFC 5545 iCalendar September 2009 - - - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 - 10.2. Informative References . . . . . . . . . . . . . . . . . 167 - Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 - A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 - A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 - A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 - -1. Introduction - - The use of calendaring and scheduling has grown considerably in the - last decade. Enterprise and inter-enterprise business has become - dependent on rapid scheduling of events and actions using this - information technology. This memo is intended to progress the level - of interoperability possible between dissimilar calendaring and - scheduling applications. This memo defines a MIME content type for - exchanging electronic calendaring and scheduling information. The - Internet Calendaring and Scheduling Core Object Specification, or - iCalendar, allows for the capture and exchange of information - normally stored within a calendaring and scheduling application; such - as a Personal Information Manager (PIM) or a Group-Scheduling - product. - - The iCalendar format is suitable as an exchange format between - applications or systems. The format is defined in terms of a MIME - content type. This will enable the object to be exchanged using - several transports, including but not limited to SMTP, HTTP, a file - system, desktop interactive protocols such as the use of a memory- - based clipboard or drag/drop interactions, point-to-point - asynchronous communication, wired-network transport, or some form of - unwired transport such as infrared. - - The memo also provides for the definition of iCalendar object methods - that will map this content type to a set of messages for supporting - calendaring and scheduling operations such as requesting, replying - to, modifying, and canceling meetings or appointments, to-dos, and - journal entries. The iCalendar object methods can be used to define - other calendaring and scheduling operations such as requesting for - and replying with free/busy time data. Such a scheduling protocol is - defined in the iCalendar Transport-independent Interoperability - Protocol (iTIP) defined in [2446bis]. - - The memo also includes a formal grammar for the content type based on - the Internet ABNF defined in [RFC5234]. This ABNF is required for - the implementation of parsers and to serve as the definitive - reference when ambiguities or questions arise in interpreting the - descriptive prose definition of the memo. Additional restrictions - - - -Desruisseaux Standards Track [Page 5] - -RFC 5545 iCalendar September 2009 - - - that could not easily be expressed with the ABNF syntax are specified - as comments in the ABNF. Comments with normative statements should - be treated as such. - -2. Basic Grammar and Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - This memo makes use of both a descriptive prose and a more formal - notation for defining the calendaring and scheduling format. - - The notation used in this memo is the ABNF notation of [RFC5234]. - Readers intending on implementing the format defined in this memo - should be familiar with this notation in order to properly interpret - the specifications of this memo. - - All numeric values used in this memo are given in decimal notation. - - All names of properties, property parameters, enumerated property - values, and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - - Note: All indented editorial notes, such as this one, are intended - to provide the reader with additional information. The - information is not essential to the building of an implementation - conformant with this memo. The information is provided to - highlight a particular feature or characteristic of the memo. - - The format for the iCalendar object is based on the syntax of the - text/directory media type [RFC2425]. While the iCalendar object is - not a profile of the text/directory media type [RFC2425], it does - reuse a number of the elements from the [RFC2425] specification. - -2.1. Formatting Conventions - - The elements defined in this memo are defined in prose. Many of the - terms used to describe these have common usage that is different than - the standards usage of this memo. In order to reference, within this - memo, elements of the calendaring and scheduling model, core object - (this memo), or interoperability protocol [2446bis] some formatting - conventions have been used. Calendaring and scheduling roles are - referred to in quoted-strings of text with the first character of - each word in uppercase. For example, "Organizer" refers to a role of - a "Calendar User" within the scheduling protocol defined by - [2446bis]. Calendar components defined by this memo are referred to - - - -Desruisseaux Standards Track [Page 6] - -RFC 5545 iCalendar September 2009 - - - with capitalized, quoted-strings of text. All calendar components - start with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component, - and "VJOURNAL" refers to the daily journal calendar component. - Scheduling methods defined by iTIP [2446bis] are referred to with - capitalized, quoted-strings of text. For example, "REQUEST" refers - to the method for requesting a scheduling calendar component be - created or modified, and "REPLY" refers to the method a recipient of - a request uses to update their status with the "Organizer" of the - calendar component. - - The properties defined by this memo are referred to with capitalized, - quoted-strings of text, followed by the word "property". For - example, "ATTENDEE" property refers to the iCalendar property used to - convey the calendar address of a calendar user. Property parameters - defined by this memo are referred to with lowercase, quoted-strings - of text, followed by the word "parameter". For example, "value" - parameter refers to the iCalendar property parameter used to override - the default value type for a property value. Enumerated values - defined by this memo are referred to with capitalized text, either - alone or followed by the word "value". For example, the "MINUTELY" - value can be used with the "FREQ" component of the "RECUR" value type - to specify repeating components based on an interval of one minute or - more. - - The following table lists the different characters from the - [US-ASCII] character set that is referenced in this document. For - each character, the table specifies the character name used - throughout this document, along with its US-ASCII decimal codepoint. - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 7] - -RFC 5545 iCalendar September 2009 - - - +------------------------+-------------------+ - | Character name | Decimal codepoint | - +------------------------+-------------------+ - | HTAB | 9 | - | LF | 10 | - | CR | 13 | - | DQUOTE | 22 | - | SPACE | 32 | - | PLUS SIGN | 43 | - | COMMA | 44 | - | HYPHEN-MINUS | 45 | - | PERIOD | 46 | - | SOLIDUS | 47 | - | COLON | 58 | - | SEMICOLON | 59 | - | LATIN CAPITAL LETTER N | 78 | - | LATIN CAPITAL LETTER T | 84 | - | LATIN CAPITAL LETTER X | 88 | - | LATIN CAPITAL LETTER Z | 90 | - | BACKSLASH | 92 | - | LATIN SMALL LETTER N | 110 | - +------------------------+-------------------+ - -2.2. Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. This memo specifies a core specification of - objects, value types, properties, and property parameters. - - o iTIP [2446bis] specifies an interoperability protocol for - scheduling between different implementations; - - o iCalendar Message-Based Interoperability Protocol (iMIP) [2447bis] - specifies an Internet email binding for [2446bis]. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -3. iCalendar Object Specification - - The following sections define the details of a Calendaring and - Scheduling Core Object Specification. The Calendaring and Scheduling - Core Object is a collection of calendaring and scheduling - information. Typically, this information will consist of an - iCalendar stream with one or more iCalendar objects. The body of the - - - -Desruisseaux Standards Track [Page 8] - -RFC 5545 iCalendar September 2009 - - - iCalendar object consists of a sequence of calendar properties and - one or more calendar components. - - Section 3.1 defines the content line format; Section 3.2 defines the - property parameter format; Section 3.3 defines the data types for - property values; Section 3.4 defines the iCalendar object format; - Section 3.5 defines the iCalendar property format; Section 3.6 - defines the calendar component format; Section 3.7 defines calendar - properties; and Section 3.8 defines calendar component properties. - - This information is intended to be an integral part of the MIME - content type registration. In addition, this information can be used - independent of such content registration. In particular, this memo - has direct applicability for use as a calendaring and scheduling - exchange format in file-, memory-, or network-based transport - mechanisms. - -3.1. Content Lines - - The iCalendar object is organized into individual lines of text, - called content lines. Content lines are delimited by a line break, - which is a CRLF sequence (CR character followed by LF character). - - Lines of text SHOULD NOT be longer than 75 octets, excluding the line - break. Long content lines SHOULD be split into a multiple line - representations using a line "folding" technique. That is, a long - line can be split between any two characters by inserting a CRLF - immediately followed by a single linear white-space character (i.e., - SPACE or HTAB). Any sequence of CRLF followed immediately by a - single linear white-space character is ignored (i.e., removed) when - processing the content type. - - For example, the line: - - DESCRIPTION:This is a long description that exists on a long line. - - Can be represented as: - - DESCRIPTION:This is a lo - ng description - that exists on a long line. - - The process of moving from this folded multiple-line representation - to its single-line representation is called "unfolding". Unfolding - is accomplished by removing the CRLF and the linear white-space - character that immediately follows. - - - - - -Desruisseaux Standards Track [Page 9] - -RFC 5545 iCalendar September 2009 - - - When parsing a content line, folded lines MUST first be unfolded - according to the unfolding procedure described above. - - Note: It is possible for very simple implementations to generate - improperly folded lines in the middle of a UTF-8 multi-octet - sequence. For this reason, implementations need to unfold lines - in such a way to properly restore the original sequence. - - The content information associated with an iCalendar object is - formatted using a syntax similar to that defined by [RFC2425]. That - is, the content information consists of CRLF-separated content lines. - - The following notation defines the lines of content in an iCalendar - object: - - contentline = name *(";" param ) ":" value CRLF - ; This ABNF is just a general definition for an initial parsing - ; of the content line into its property name, parameter list, - ; and value string - - ; When parsing a content line, folded lines MUST first - ; be unfolded according to the unfolding procedure - ; described above. When generating a content line, lines - ; longer than 75 octets SHOULD be folded according to - ; the folding procedure described above. - - name = iana-token / x-name - - iana-token = 1*(ALPHA / DIGIT / "-") - ; iCalendar identifier registered with IANA - - x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") - ; Reserved for experimental use. - - vendorid = 3*(ALPHA / DIGIT) - ; Vendor identification - - param = param-name "=" param-value *("," param-value) - ; Each property defines the specific ABNF for the parameters - ; allowed on the property. Refer to specific properties for - ; precise parameter ABNF. - - param-name = iana-token / x-name - - param-value = paramtext / quoted-string - - paramtext = *SAFE-CHAR - - - - -Desruisseaux Standards Track [Page 10] - -RFC 5545 iCalendar September 2009 - - - value = *VALUE-CHAR - - quoted-string = DQUOTE *QSAFE-CHAR DQUOTE - - QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII - ; Any character except CONTROL and DQUOTE - - SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E - / NON-US-ASCII - ; Any character except CONTROL, DQUOTE, ";", ":", "," - - VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII - ; Any textual character - - NON-US-ASCII = UTF8-2 / UTF8-3 / UTF8-4 - ; UTF8-2, UTF8-3, and UTF8-4 are defined in [RFC3629] - - CONTROL = %x00-08 / %x0A-1F / %x7F - ; All the controls except HTAB - - The property value component of a content line has a format that is - property specific. Refer to the section describing each property for - a definition of this format. - - All names of properties, property parameters, enumerated property - values and property parameter values are case-insensitive. However, - all other property values are case-sensitive, unless otherwise - stated. - -3.1.1. List and Field Separators - - Some properties and parameters allow a list of values. Values in a - list of values MUST be separated by a COMMA character. There is no - significance to the order of values in a list. For those parameter - values (such as those that specify URI values) that are specified in - quoted-strings, the individual quoted-strings are separated by a - COMMA character. - - Some property values are defined in terms of multiple parts. These - structured property values MUST have their value parts separated by a - SEMICOLON character. - - Some properties allow a list of parameters. Each property parameter - in a list of property parameters MUST be separated by a SEMICOLON - character. - - - - - - -Desruisseaux Standards Track [Page 11] - -RFC 5545 iCalendar September 2009 - - - Property parameters with values containing a COLON character, a - SEMICOLON character or a COMMA character MUST be placed in quoted - text. - - For example, in the following properties, a SEMICOLON is used to - separate property parameters from each other and a COMMA character is - used to separate property values in a value list. - - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:mailto: - jsmith@example.com - - RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 - -3.1.2. Multiple Values - - Some properties defined in the iCalendar object can have multiple - values. The general rule for encoding multi-valued items is to - simply create a new content line for each value, including the - property name. However, it should be noted that some properties - support encoding multiple values in a single property by separating - the values with a COMMA character. Individual property definitions - should be consulted for determining whether a specific property - allows multiple values and in which of these two forms. Multi-valued - properties MUST NOT be used to specify multiple language variants of - the same value. Calendar applications SHOULD display all values. - -3.1.3. Binary Content - - Binary content information in an iCalendar object SHOULD be - referenced using a URI within a property value. That is, the binary - content information SHOULD be placed in an external MIME entity that - can be referenced by a URI from within the iCalendar object. In - applications where this is not feasible, binary content information - can be included within an iCalendar object, but only after first - encoding it into text using the "BASE64" encoding method defined in - [RFC4648]. Inline binary content SHOULD only be used in applications - whose special circumstances demand that an iCalendar object be - expressed as a single entity. A property containing inline binary - content information MUST specify the "ENCODING" property parameter. - Binary content information placed external to the iCalendar object - MUST be referenced by a uniform resource identifier (URI). - - The following example specifies an "ATTACH" property that references - an attachment external to the iCalendar object with a URI reference: - - ATTACH:http://example.com/public/quarterly-report.doc - - - - - -Desruisseaux Standards Track [Page 12] - -RFC 5545 iCalendar September 2009 - - - The following example specifies an "ATTACH" property with inline - binary encoded content information: - - ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:VGhlIH - F1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZy4 - -3.1.4. Character Set - - There is not a property parameter to declare the charset used in a - property value. The default charset for an iCalendar stream is UTF-8 - as defined in [RFC3629]. - - The "charset" Content-Type parameter MUST be used in MIME transports - to specify the charset being used. - -3.2. Property Parameters - - A property can have attributes with which it is associated. These - "property parameters" contain meta-information about the property or - the property value. Property parameters are provided to specify such - information as the location of an alternate text representation for a - property value, the language of a text property value, the value type - of the property value, and other attributes. - - Property parameter values that contain the COLON, SEMICOLON, or COMMA - character separators MUST be specified as quoted-string text values. - Property parameter values MUST NOT contain the DQUOTE character. The - DQUOTE character is used as a delimiter for parameter values that - contain restricted characters or URI text. For example: - - DESCRIPTION;ALTREP="cid:part1.0001@example.org":The Fall'98 Wild - Wizards Conference - - Las Vegas\, NV\, USA - - Property parameter values that are not in quoted-strings are case- - insensitive. - - The general property parameters defined by this memo are defined by - the following notation: - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 13] - -RFC 5545 iCalendar September 2009 - - - icalparameter = altrepparam ; Alternate text representation - / cnparam ; Common name - / cutypeparam ; Calendar user type - / delfromparam ; Delegator - / deltoparam ; Delegatee - / dirparam ; Directory entry - / encodingparam ; Inline encoding - / fmttypeparam ; Format type - / fbtypeparam ; Free/busy time type - / languageparam ; Language for text - / memberparam ; Group or list membership - / partstatparam ; Participation status - / rangeparam ; Recurrence identifier range - / trigrelparam ; Alarm trigger relationship - / reltypeparam ; Relationship type - / roleparam ; Participation role - / rsvpparam ; RSVP expectation - / sentbyparam ; Sent by - / tzidparam ; Reference to time zone object - / valuetypeparam ; Property value data type - / other-param - - other-param = (iana-param / x-param) - - iana-param = iana-token "=" param-value *("," param-value) - ; Some other IANA-registered iCalendar parameter. - - x-param = x-name "=" param-value *("," param-value) - ; A non-standard, experimental parameter. - - Applications MUST ignore x-param and iana-param values they don't - recognize. - -3.2.1. Alternate Text Representation - - Parameter Name: ALTREP - - Purpose: To specify an alternate text representation for the - property value. - - Format Definition: This property parameter is defined by the - following notation: - - altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE - - Description: This parameter specifies a URI that points to an - alternate representation for a textual property value. A property - specifying this parameter MUST also include a value that reflects - - - -Desruisseaux Standards Track [Page 14] - -RFC 5545 iCalendar September 2009 - - - the default representation of the text value. The URI parameter - value MUST be specified in a quoted-string. - - Note: While there is no restriction imposed on the URI schemes - allowed for this parameter, Content Identifier (CID) [RFC2392], - HTTP [RFC2616], and HTTPS [RFC2818] are the URI schemes most - commonly used by current implementations. - - Example: - - DESCRIPTION;ALTREP="CID:part3.msg.970415T083000@example.com": - Project XYZ Review Meeting will include the following agenda - items: (a) Market Overview\, (b) Finances\, (c) Project Man - agement - - The "ALTREP" property parameter value might point to a "text/html" - content portion. - - Content-Type:text/html - Content-Id: - - - - - - -

- Project XYZ Review Meeting will include - the following agenda items: -

    -
  1. Market Overview
    2. -
  2. Finances
    3. -
  3. Project Management
    4. -
-

- - - -3.2.2. Common Name - - Parameter Name: CN - - Purpose: To specify the common name to be associated with the - calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - - - -Desruisseaux Standards Track [Page 15] - -RFC 5545 iCalendar September 2009 - - - cnparam = "CN" "=" param-value - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the common name - to be associated with the calendar user specified by the property. - The parameter value is text. The parameter value can be used for - display text to be associated with the calendar address specified - by the property. - - Example: - - ORGANIZER;CN="John Smith":mailto:jsmith@example.com - -3.2.3. Calendar User Type - - Parameter Name: CUTYPE - - Purpose: To identify the type of calendar user specified by the - property. - - Format Definition: This property parameter is defined by the - following notation: - - 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 values they don't - recognize the same way as they would the UNKNOWN value. - - Example: - - ATTENDEE;CUTYPE=GROUP:mailto:ietf-calsch@example.org - - - - - - - -Desruisseaux Standards Track [Page 16] - -RFC 5545 iCalendar September 2009 - - -3.2.4. Delegators - - Parameter Name: DELEGATED-FROM - - Purpose: To specify the calendar users that have delegated their - participation to the calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address - DQUOTE *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar - users that have delegated their participation in a group-scheduled - event or to-do to the calendar user specified by the property. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - Example: - - ATTENDEE;DELEGATED-FROM="mailto:jsmith@example.com":mailto: - jdoe@example.com - -3.2.5. Delegatees - - Parameter Name: DELEGATED-TO - - Purpose: To specify the calendar users to whom the calendar user - specified by the property has delegated participation. - - Format Definition: This property parameter is defined by the - following notation: - - deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. This parameter specifies those calendar - users whom have been delegated participation in a group-scheduled - event or to-do by the calendar user specified by the property. - The individual calendar address parameter values MUST each be - specified in a quoted-string. - - - - - - - -Desruisseaux Standards Track [Page 17] - -RFC 5545 iCalendar September 2009 - - - Example: - - ATTENDEE;DELEGATED-TO="mailto:jdoe@example.com","mailto:jqpublic - @example.com":mailto:jsmith@example.com - -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. - - Note: While there is no restriction imposed on the URI schemes - allowed for this parameter, CID [RFC2392], DATA [RFC2397], FILE - [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS [RFC2818], LDAP - [RFC4516], and MID [RFC2392] are the URI schemes most commonly - used by current implementations. - - Example: - - ORGANIZER;DIR="ldap://example.com:6666/o=ABC%20Industries, - c=US???(cn=Jim%20Dolittle)":mailto:jimdo@example.com - -3.2.7. Inline Encoding - - Parameter Name: ENCODING - - Purpose: To specify an alternate inline encoding for the property - value. - - Format Definition: This property parameter is defined by the - following notation: - - - - - - - - -Desruisseaux Standards Track [Page 18] - -RFC 5545 iCalendar September 2009 - - - encodingparam = "ENCODING" "=" - ( "8BIT" - ; "8bit" text encoding is defined in [RFC2045] - / "BASE64" - ; "BASE64" binary encoding format is defined in [RFC4648] - ) - - Description: This property parameter identifies the inline encoding - used in a property value. The default encoding is "8BIT", - corresponding to a property value consisting of text. The - "BASE64" encoding type corresponds to a property value encoded - using the "BASE64" encoding defined in [RFC2045]. - - If the value type parameter is ";VALUE=BINARY", then the inline - encoding parameter MUST be specified with the value - ";ENCODING=BASE64". - - Example: - - ATTACH;FMTTYPE=text/plain;ENCODING=BASE64;VALUE=BINARY:TG9yZW - 0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2ljaW - 5nIGVsaXQsIHNlZCBkbyBlaXVzbW9kIHRlbXBvciBpbmNpZGlkdW50IHV0IG - xhYm9yZSBldCBkb2xvcmUgbWFnbmEgYWxpcXVhLiBVdCBlbmltIGFkIG1pbm - ltIHZlbmlhbSwgcXVpcyBub3N0cnVkIGV4ZXJjaXRhdGlvbiB1bGxhbWNvIG - xhYm9yaXMgbmlzaSB1dCBhbGlxdWlwIGV4IGVhIGNvbW1vZG8gY29uc2VxdW - F0LiBEdWlzIGF1dGUgaXJ1cmUgZG9sb3IgaW4gcmVwcmVoZW5kZXJpdCBpbi - B2b2x1cHRhdGUgdmVsaXQgZXNzZSBjaWxsdW0gZG9sb3JlIGV1IGZ1Z2lhdC - BudWxsYSBwYXJpYXR1ci4gRXhjZXB0ZXVyIHNpbnQgb2NjYWVjYXQgY3VwaW - RhdGF0IG5vbiBwcm9pZGVudCwgc3VudCBpbiBjdWxwYSBxdWkgb2ZmaWNpYS - BkZXNlcnVudCBtb2xsaXQgYW5pbSBpZCBlc3QgbGFib3J1bS4= - -3.2.8. Format Type - - Parameter Name: FMTTYPE - - Purpose: To specify the content type of a referenced object. - - Format Definition: This property parameter is defined by the - following notation: - - fmttypeparam = "FMTTYPE" "=" type-name "/" subtype-name - ; Where "type-name" and "subtype-name" are - ; defined in Section 4.2 of [RFC4288]. - - Description: This parameter can be specified on properties that are - used to reference an object. The parameter specifies the media - type [RFC4288] of the referenced object. For example, on the - "ATTACH" property, an FTP type URI value does not, by itself, - - - -Desruisseaux Standards Track [Page 19] - -RFC 5545 iCalendar September 2009 - - - necessarily convey the type of content associated with the - resource. The parameter value MUST be the text for either an - IANA-registered media type or a non-standard media type. - - Example: - - ATTACH;FMTTYPE=application/msword:ftp://example.com/pub/docs/ - agenda.doc - -3.2.9. Free/Busy Time Type - - Parameter Name: FBTYPE - - Purpose: To specify the free or busy time type. - - Format Definition: This property parameter is defined by the - following notation: - - fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" - / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" - / x-name - ; Some experimental iCalendar free/busy type. - / iana-token) - ; Some other IANA-registered iCalendar free/busy type. - - Description: This parameter specifies the free or busy time type. - The value FREE indicates that the time interval is free for - scheduling. The value BUSY indicates that the time interval is - busy because one or more events have been scheduled for that - interval. The value BUSY-UNAVAILABLE indicates that the time - interval is busy and that the interval can not be scheduled. The - value BUSY-TENTATIVE indicates that the time interval is busy - because one or more events have been tentatively scheduled for - that interval. If not specified on a property that allows this - parameter, the default is BUSY. Applications MUST treat x-name - and iana-token values they don't recognize the same way as they - would the BUSY value. - - Example: The following is an example of this parameter on a - "FREEBUSY" property. - - FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z - - - - - - - - - -Desruisseaux Standards Track [Page 20] - -RFC 5545 iCalendar September 2009 - - -3.2.10. Language - - Parameter Name: LANGUAGE - - Purpose: To specify the language for text values in a property or - property parameter. - - Format Definition: This property parameter is defined by the - following notation: - - languageparam = "LANGUAGE" "=" language - - language = Language-Tag - ; As defined in [RFC5646]. - - Description: This parameter identifies the language of the text in - the property value and of all property parameter values of the - property. The value of the "LANGUAGE" property parameter is that - defined in [RFC5646]. - - For transport in a MIME entity, the Content-Language header field - can be used to set the default language for the entire body part. - Otherwise, no default language is assumed. - - Example: The following are examples of this parameter on the - "SUMMARY" and "LOCATION" properties: - - SUMMARY;LANGUAGE=en-US:Company Holiday Party - - LOCATION;LANGUAGE=en:Germany - - LOCATION;LANGUAGE=no:Tyskland - -3.2.11. Group or List Membership - - Parameter Name: MEMBER - - Purpose: To specify the group or list membership of the calendar - user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE - *("," DQUOTE cal-address DQUOTE) - - - - - - -Desruisseaux Standards Track [Page 21] - -RFC 5545 iCalendar September 2009 - - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the groups or - list membership for the calendar user specified by the property. - The parameter value is either a single calendar address in a - quoted-string or a COMMA-separated list of calendar addresses, - each in a quoted-string. The individual calendar address - parameter values MUST each be specified in a quoted-string. - - Example: - - ATTENDEE;MEMBER="mailto:ietf-calsch@example.org":mailto: - jsmith@example.com - - ATTENDEE;MEMBER="mailto:projectA@example.com","mailto:pr - ojectB@example.com":mailto:janedoe@example.com - -3.2.12. Participation Status - - Parameter Name: PARTSTAT - - Purpose: To specify the participation status for the calendar user - specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - partstatparam = "PARTSTAT" "=" - (partstat-event - / partstat-todo - / partstat-jour) - - partstat-event = ("NEEDS-ACTION" ; Event needs action - / "ACCEPTED" ; Event accepted - / "DECLINED" ; Event declined - / "TENTATIVE" ; Event tentatively - ; accepted - / "DELEGATED" ; Event delegated - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VEVENT". - ; Default is NEEDS-ACTION. - - partstat-todo = ("NEEDS-ACTION" ; To-do needs action - / "ACCEPTED" ; To-do accepted - / "DECLINED" ; To-do declined - / "TENTATIVE" ; To-do tentatively - ; accepted - - - -Desruisseaux Standards Track [Page 22] - -RFC 5545 iCalendar September 2009 - - - / "DELEGATED" ; To-do delegated - / "COMPLETED" ; To-do completed - ; COMPLETED property has - ; DATE-TIME completed - / "IN-PROCESS" ; To-do in process of - ; being completed - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VTODO". - ; Default is NEEDS-ACTION. - - - - partstat-jour = ("NEEDS-ACTION" ; Journal needs action - / "ACCEPTED" ; Journal accepted - / "DECLINED" ; Journal declined - / x-name ; Experimental status - / iana-token) ; Other IANA-registered - ; status - ; These are the participation statuses for a "VJOURNAL". - ; Default is NEEDS-ACTION. - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the - participation status for the calendar user specified by the - property value. The parameter values differ depending on whether - they are associated with a group-scheduled "VEVENT", "VTODO", or - "VJOURNAL". The values MUST match one of the values allowed for - the given calendar component. If not specified on a property that - allows this parameter, the default value is NEEDS-ACTION. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the NEEDS-ACTION value. - - Example: - - ATTENDEE;PARTSTAT=DECLINED:mailto:jsmith@example.com - -3.2.13. Recurrence Identifier Range - - Parameter Name: RANGE - - Purpose: To specify the effective range of recurrence instances from - the instance specified by the recurrence identifier specified by - the property. - - Format Definition: This property parameter is defined by the - following notation: - - - -Desruisseaux Standards Track [Page 23] - -RFC 5545 iCalendar September 2009 - - - rangeparam = "RANGE" "=" "THISANDFUTURE" - ; To specify the instance specified by the recurrence identifier - ; and all subsequent recurrence instances. - - Description: This parameter can be specified on a property that - specifies a recurrence identifier. The parameter specifies the - effective range of recurrence instances that is specified by the - property. The effective range is from the recurrence identifier - specified by the property. If this parameter is not specified on - an allowed property, then the default range is the single instance - specified by the recurrence identifier value of the property. The - parameter value can only be "THISANDFUTURE" to indicate a range - defined by the recurrence identifier and all subsequent instances. - The value "THISANDPRIOR" is deprecated by this revision of - iCalendar and MUST NOT be generated by applications. - - Example: - - RECURRENCE-ID;RANGE=THISANDFUTURE:19980401T133000Z - -3.2.14. Alarm Trigger Relationship - - Parameter Name: RELATED - - Purpose: To specify the relationship of the alarm trigger with - respect to the start or end of the calendar component. - - Format Definition: This property parameter is defined by the - following notation: - - trigrelparam = "RELATED" "=" - ("START" ; Trigger off of start - / "END") ; Trigger off of end - - Description: This parameter can be specified on properties that - specify an alarm trigger with a "DURATION" value type. The - parameter specifies whether the alarm will trigger relative to the - start or end of the calendar component. The parameter value START - will set the alarm to trigger off the start of the calendar - component; the parameter value END will set the alarm to trigger - off the end of the calendar component. If the parameter is not - specified on an allowable property, then the default is START. - - Example: - - TRIGGER;RELATED=END:PT5M - - - - - -Desruisseaux Standards Track [Page 24] - -RFC 5545 iCalendar September 2009 - - -3.2.15. Relationship Type - - Parameter Name: RELTYPE - - Purpose: To specify the type of hierarchical relationship associated - with the calendar component specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - reltypeparam = "RELTYPE" "=" - ("PARENT" ; Parent relationship - Default - / "CHILD" ; Child relationship - / "SIBLING" ; Sibling relationship - / iana-token ; Some other IANA-registered - ; iCalendar relationship type - / x-name) ; A non-standard, experimental - ; relationship type - - Description: This parameter can be specified on a property that - references another related calendar. The parameter specifies the - hierarchical relationship type of the calendar component - referenced by the property. The parameter value can be PARENT, to - indicate that the referenced calendar component is a superior of - calendar component; CHILD to indicate that the referenced calendar - component is a subordinate of the calendar component; or SIBLING - to indicate that the referenced calendar component is a peer of - the calendar component. If this parameter is not specified on an - allowable property, the default relationship type is PARENT. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the PARENT value. - - Example: - - RELATED-TO;RELTYPE=SIBLING:19960401-080045-4000F192713@ - example.com - -3.2.16. Participation Role - - Parameter Name: ROLE - - Purpose: To specify the participation role for the calendar user - specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - - - - -Desruisseaux Standards Track [Page 25] - -RFC 5545 iCalendar September 2009 - - - roleparam = "ROLE" "=" - ("CHAIR" ; Indicates chair of the - ; calendar entity - / "REQ-PARTICIPANT" ; Indicates a participant whose - ; participation is required - / "OPT-PARTICIPANT" ; Indicates a participant whose - ; participation is optional - / "NON-PARTICIPANT" ; Indicates a participant who - ; is copied for information - ; purposes only - / x-name ; Experimental role - / iana-token) ; Other IANA role - ; Default is REQ-PARTICIPANT - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the participation - role for the calendar user specified by the property in the group - schedule calendar component. If not specified on a property that - allows this parameter, the default value is REQ-PARTICIPANT. - Applications MUST treat x-name and iana-token values they don't - recognize the same way as they would the REQ-PARTICIPANT value. - - Example: - - ATTENDEE;ROLE=CHAIR:mailto:mrbig@example.com - -3.2.17. RSVP Expectation - - Parameter Name: RSVP - - Purpose: To specify whether there is an expectation of a favor of a - reply from the calendar user specified by the property value. - - Format Definition: This property parameter is defined by the - following notation: - - rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") - ; Default is FALSE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter identifies the expectation - of a reply from the calendar user specified by the property value. - This parameter is used by the "Organizer" to request a - participation status reply from an "Attendee" of a group-scheduled - event or to-do. If not specified on a property that allows this - parameter, the default value is FALSE. - - - - - -Desruisseaux Standards Track [Page 26] - -RFC 5545 iCalendar September 2009 - - - Example: - - ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com - -3.2.18. Sent By - - Parameter Name: SENT-BY - - Purpose: To specify the calendar user that is acting on behalf of - the calendar user specified by the property. - - Format Definition: This property parameter is defined by the - following notation: - - sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE - - Description: This parameter can be specified on properties with a - CAL-ADDRESS value type. The parameter specifies the calendar user - that is acting on behalf of the calendar user specified by the - property. The parameter value MUST be a mailto URI as defined in - [RFC2368]. The individual calendar address parameter values MUST - each be specified in a quoted-string. - - Example: - - ORGANIZER;SENT-BY="mailto:sray@example.com":mailto: - jsmith@example.com - -3.2.19. Time Zone Identifier - - Parameter Name: TZID - - Purpose: To specify the identifier for the time zone definition for - a time component in the property value. - - Format Definition: This property parameter is defined by the - following notation: - - tzidparam = "TZID" "=" [tzidprefix] paramtext - - tzidprefix = "/" - - Description: This 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 - neither a UTC or a "floating" time. Refer to the DATE-TIME or - TIME value type definition for a description of UTC and "floating - time" formats. This property parameter specifies a text value - - - -Desruisseaux Standards Track [Page 27] - -RFC 5545 iCalendar September 2009 - - - that uniquely identifies the "VTIMEZONE" calendar component to be - used when evaluating the time portion of the property. The value - of the "TZID" property parameter will be equal to the value of the - "TZID" property for the matching time zone definition. An - individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar - object. - - The parameter MUST be specified on properties with a DATE-TIME - value if the DATE-TIME is not either a UTC or a "floating" time. - Failure to include and follow VTIMEZONE definitions in iCalendar - objects may lead to inconsistent understanding of the local time - at any given location. - - The presence of the SOLIDUS character as a prefix, indicates that - this "TZID" represents a unique ID in a globally defined time zone - registry (when such registry is defined). - - Note: This document does not define a naming convention for - time zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such - as the public-domain TZ database [TZDB]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - The following are examples of this property parameter: - - DTSTART;TZID=America/New_York:19980119T020000 - - DTEND;TZID=America/New_York:19980119T030000 - - The "TZID" property parameter MUST NOT be applied to DATE - properties and DATE-TIME or TIME properties whose time values are - specified in UTC. - - The use of local time in a DATE-TIME or TIME value without the - "TZID" property parameter is to be interpreted as floating time, - regardless of the existence of "VTIMEZONE" calendar components in - the iCalendar object. - - For more information, see the sections on the value types DATE- - TIME and TIME. - - - - - - - - - -Desruisseaux Standards Track [Page 28] - -RFC 5545 iCalendar September 2009 - - -3.2.20. Value Data Types - - Parameter Name: VALUE - - Purpose: To explicitly specify the value type format for a property - value. - - Format Definition: This property parameter is defined by the - following notation: - - valuetypeparam = "VALUE" "=" valuetype - - valuetype = ("BINARY" - / "BOOLEAN" - / "CAL-ADDRESS" - / "DATE" - / "DATE-TIME" - / "DURATION" - / "FLOAT" - / "INTEGER" - / "PERIOD" - / "RECUR" - / "TEXT" - / "TIME" - / "URI" - / "UTC-OFFSET" - / x-name - ; Some experimental iCalendar value type. - / iana-token) - ; Some other IANA-registered iCalendar value type. - - Description: This parameter specifies the value type and format of - the property value. The property values MUST be of a single value - type. For example, a "RDATE" property cannot have a combination - of DATE-TIME and TIME value types. - - 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. - - Applications MUST preserve the value data for x-name and iana- - token values that they don't recognize without attempting to - interpret or parse the value data. - - - - - - - -Desruisseaux Standards Track [Page 29] - -RFC 5545 iCalendar September 2009 - - -3.3. Property Value Data Types - - The properties in an iCalendar object are strongly typed. The - definition of each property restricts the value to be one of the - value data types, or simply value types, defined in this section. - The value type for a property will either be specified implicitly as - the default value type or will be explicitly specified with the - "VALUE" parameter. If the value type of a property is one of the - alternate valid types, then it MUST be explicitly specified with the - "VALUE" parameter. - -3.3.1. Binary - - Value Name: BINARY - - Purpose: This value type is used to identify properties that contain - a character encoding of inline binary data. For example, an - inline attachment of a document might be included in an iCalendar - object. - - Format Definition: This value type is defined by the following - notation: - - binary = *(4b-char) [b-end] - ; A "BASE64" encoded character string, as defined by [RFC4648]. - - b-end = (2b-char "==") / (3b-char "=") - - b-char = ALPHA / DIGIT / "+" / "/" - - Description: Property values with this value type MUST also include - the inline encoding parameter sequence of ";ENCODING=BASE64". - That is, all inline binary data MUST first be character encoded - using the "BASE64" encoding method defined in [RFC2045]. No - additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 30] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of a "BASE64" encoded binary - value data: - - ATTACH;FMTTYPE=image/vnd.microsoft.icon;ENCODING=BASE64;VALUE - =BINARY:AAABAAEAEBAQAAEABAAoAQAAFgAAACgAAAAQAAAAIAAAAAEABAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAgIAAAICAgADAwMAA////AAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAAAAAAAAAAAAMwAAAAAAABNEMQAAAAAAAkQgAAAAAAJEREQgAA - ACECQ0QgEgAAQxQzM0E0AABERCRCREQAADRDJEJEQwAAAhA0QwEQAAAAAERE - AAAAAAAAREQAAAAAAAAkQgAAAAAAAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA - AAAAAAAAAAAA - -3.3.2. Boolean - - Value Name: BOOLEAN - - Purpose: This value type is used to identify properties that contain - either a "TRUE" or "FALSE" Boolean value. - - Format Definition: This value type is defined by the following - notation: - - boolean = "TRUE" / "FALSE" - - Description: These values are case-insensitive text. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - Example: The following is an example of a hypothetical property that - has a BOOLEAN value type: - - TRUE - -3.3.3. Calendar User Address - - Value Name: CAL-ADDRESS - - Purpose: This value type is used to identify properties that contain - a calendar user address. - - Format Definition: This value type is defined by the following - notation: - - cal-address = uri - - Description: The value is a URI as defined by [RFC3986] or any other - IANA-registered form for a URI. When used to address an Internet - - - -Desruisseaux Standards Track [Page 31] - -RFC 5545 iCalendar September 2009 - - - email transport address for a calendar user, the value MUST be a - mailto URI, as defined by [RFC2368]. No additional content value - encoding (i.e., BACKSLASH character encoding, see Section 3.3.11) - is defined for this value type. - - Example: - - mailto:jane_doe@example.com - -3.3.4. Date - - Value Name: DATE - - Purpose: This value type is used to identify values that contain a - calendar date. - - Format Definition: This value type is defined by the following - notation: - - date = date-value - - date-value = date-fullyear date-month date-mday - date-fullyear = 4DIGIT - date-month = 2DIGIT ;01-12 - date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 - ;based on month/year - - Description: If the property permits, multiple "date" values are - specified as a COMMA-separated list of values. The format for the - value type is based on the [ISO.8601.2004] complete - representation, basic format for a calendar date. The textual - format specifies a four-digit year, two-digit month, and two-digit - day of the month. There are no separator characters between the - year, month, and day component text. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following represents July 14, 1997: - - 19970714 - -3.3.5. Date-Time - - Value Name: DATE-TIME - - Purpose: This value type is used to identify values that specify a - precise calendar date and time of day. - - - -Desruisseaux Standards Track [Page 32] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This value type is defined by the following - notation: - - date-time = date "T" time ;As specified in the DATE and TIME - ;value definitions - - Description: If the property permits, multiple "DATE-TIME" values - are specified as a COMMA-separated list of values. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - The "DATE-TIME" value type is used to identify values that contain - a precise calendar date and time of day. The format is based on - the [ISO.8601.2004] complete representation, basic format for a - calendar date and time of day. The text format is a concatenation - of the "date", followed by the LATIN CAPITAL LETTER T character, - the time designator, followed by the "time" format. - - The "DATE-TIME" value type expresses time values in three forms: - - The form of date and time with UTC offset MUST NOT be used. For - example, the following is not valid for a DATE-TIME value: - - 19980119T230000-0800 ;Invalid time format - - FORM #1: DATE WITH 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. For example, the following represents January 18, 1998, at - 11 PM: - - 19980118T230000 - - DATE-TIME values of this type are said to be "floating" and are - not bound to any time zone in particular. They are used to - represent the same hour, minute, and second value regardless of - which time zone is currently being observed. For example, an - event can be defined that indicates that an individual will be - busy from 11:00 AM to 1:00 PM every day, no matter which time zone - the person is in. In these cases, a local time can be specified. - 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. This means - that two "Attendees", in different time zones, receiving the same - event definition as a floating time, may be participating in the - - - - -Desruisseaux Standards Track [Page 33] - -RFC 5545 iCalendar September 2009 - - - event at different actual times. Floating time SHOULD only be - used where that is the reasonable behavior. - - 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. - - The use of local time in a DATE-TIME value without the "TZID" - property parameter is to be interpreted as floating time, - regardless of the existence of "VTIMEZONE" calendar components in - the iCalendar object. - - FORM #2: DATE WITH UTC TIME - - The date with UTC time, or absolute time, is identified by a LATIN - CAPITAL LETTER Z suffix character, the UTC designator, appended to - the time value. For example, the following represents January 19, - 1998, at 0700 UTC: - - 19980119T070000Z - - The "TZID" property parameter MUST NOT be applied to DATE-TIME - properties whose time values are specified in UTC. - - FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE - - The date and local time with reference to time zone information is - identified by the use the "TZID" property parameter to reference - the appropriate time zone definition. "TZID" is discussed in - detail in Section 3.2.19. For example, the following represents - 2:00 A.M. in New York on January 19, 1998: - - TZID=America/New_York:19980119T020000 - - If, based on the definition of the referenced time zone, the local - time described occurs more than once (when changing from daylight - to standard time), the DATE-TIME value refers to the first - occurrence of the referenced time. Thus, TZID=America/ - New_York:20071104T013000 indicates November 4, 2007 at 1:30 A.M. - EDT (UTC-04:00). If the local time described does not occur (when - changing from standard to daylight time), the DATE-TIME value is - interpreted using the UTC offset before the gap in local times. - Thus, TZID=America/New_York:20070311T023000 indicates March 11, - 2007 at 3:30 A.M. EDT (UTC-04:00), one hour after 1:30 A.M. EST - (UTC-05:00). - - - - - - -Desruisseaux Standards Track [Page 34] - -RFC 5545 iCalendar September 2009 - - - A time value MUST only specify the second 60 when specifying a - positive leap second. For example: - - 19970630T235960Z - - Implementations that do not support leap seconds SHOULD interpret - the second 60 as equivalent to the second 59. - - Example: The following represents July 14, 1997, at 1:30 PM in New - York City in each of the three time formats, using the "DTSTART" - property. - - DTSTART:19970714T133000 ; Local time - DTSTART:19970714T173000Z ; UTC time - DTSTART;TZID=America/New_York:19970714T133000 - ; Local time and time - ; zone reference - -3.3.6. Duration - - Value Name: DURATION - - Purpose: This value type is used to identify properties that contain - a duration of time. - - Format Definition: This value type is defined by the following - notation: - - dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) - - dur-date = dur-day [dur-time] - dur-time = "T" (dur-hour / dur-minute / dur-second) - dur-week = 1*DIGIT "W" - dur-hour = 1*DIGIT "H" [dur-minute] - dur-minute = 1*DIGIT "M" [dur-second] - dur-second = 1*DIGIT "S" - dur-day = 1*DIGIT "D" - - Description: If the property permits, multiple "duration" values are - specified by a COMMA-separated list of values. The format is - based on the [ISO.8601.2004] complete representation basic format - with designators for the duration of time. The format can - represent nominal durations (weeks and days) and accurate - durations (hours, minutes, and seconds). Note that unlike - [ISO.8601.2004], this value type doesn't support the "Y" and "M" - designators to specify durations in terms of years and months. - - - - - -Desruisseaux Standards Track [Page 35] - -RFC 5545 iCalendar September 2009 - - - The duration of a week or a day depends on its position in the - calendar. In the case of discontinuities in the time scale, such - as the change from standard time to daylight time and back, the - computation of the exact duration requires the subtraction or - addition of the change of duration of the discontinuity. Leap - seconds MUST NOT be considered when computing an exact duration. - When computing an exact duration, the greatest order time - components MUST be added first, that is, the number of days MUST - be added first, followed by the number of hours, number of - minutes, and number of seconds. - - Negative durations are typically used to schedule an alarm to - trigger before an associated time (see Section 3.8.6.3). - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) are defined for this value type. - - Example: A duration of 15 days, 5 hours, and 20 seconds would be: - - P15DT5H0M20S - - A duration of 7 weeks would be: - - P7W - -3.3.7. Float - - Value Name: FLOAT - - Purpose: This value type is used to identify properties that contain - a real-number value. - - Format Definition: This value type is defined by the following - notation: - - float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] - - Description: If the property permits, multiple "float" values are - specified by a COMMA-separated list of values. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: - - 1000000.0000001 - 1.333 - -3.14 - - - -Desruisseaux Standards Track [Page 36] - -RFC 5545 iCalendar September 2009 - - -3.3.8. Integer - - Value Name: INTEGER - - Purpose: This value type is used to identify properties that contain - a signed integer value. - - Format Definition: This value type is defined by the following - notation: - - integer = (["+"] / "-") 1*DIGIT - - Description: If the property permits, multiple "integer" values are - specified by a COMMA-separated list of values. The valid range - for "integer" is -2147483648 to 2147483647. If the sign is not - specified, then the value is assumed to be positive. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: - - 1234567890 - -1234567890 - +1234567890 - 432109876 - -3.3.9. Period of Time - - Value Name: PERIOD - - Purpose: This value type is used to identify values that contain a - precise period of time. - - Format Definition: This value type is defined by the following - notation: - - period = period-explicit / period-start - - period-explicit = date-time "/" date-time - ; [ISO.8601.2004] complete representation basic format for a - ; period of time consisting of a start and end. The start MUST - ; be before the end. - - period-start = date-time "/" dur-value - ; [ISO.8601.2004] complete representation basic format for a - ; period of time consisting of a start and positive duration - ; of time. - - - -Desruisseaux Standards Track [Page 37] - -RFC 5545 iCalendar September 2009 - - - Description: If the property permits, multiple "period" values are - specified by a COMMA-separated list of values. There are two - forms of a period of time. First, a period of time is identified - by its start and its end. This format is based on the - [ISO.8601.2004] complete representation, basic format for "DATE- - TIME" start of the period, followed by a SOLIDUS character - followed by the "DATE-TIME" of the end of the period. The start - of the period MUST be before the end of the period. Second, a - period of time can also be defined by a start and a positive - duration of time. The format is based on the [ISO.8601.2004] - complete representation, basic format for the "DATE-TIME" start of - the period, followed by a SOLIDUS character, followed by the - [ISO.8601.2004] basic format for "DURATION" of the period. - - Example: The period starting at 18:00:00 UTC, on January 1, 1997 and - ending at 07:00:00 UTC on January 2, 1997 would be: - - 19970101T180000Z/19970102T070000Z - - The period start at 18:00:00 on January 1, 1997 and lasting 5 - hours and 30 minutes would be: - - 19970101T180000Z/PT5H30M - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - -3.3.10. Recurrence Rule - - Value Name: RECUR - - Purpose: This value type is used to identify properties that contain - a recurrence rule specification. - - Format Definition: This value type is defined by the following - notation: - - recur = recur-rule-part *( ";" recur-rule-part ) - ; - ; The rule parts are not ordered in any - ; particular sequence. - ; - ; The FREQ rule part is REQUIRED, - ; but MUST NOT occur more than once. - ; - ; The UNTIL or COUNT rule parts are OPTIONAL, - ; but they MUST NOT occur in the same 'recur'. - ; - - - -Desruisseaux Standards Track [Page 38] - -RFC 5545 iCalendar September 2009 - - - ; The other rule parts are OPTIONAL, - ; but MUST NOT occur more than once. - - recur-rule-part = ( "FREQ" "=" freq ) - / ( "UNTIL" "=" enddate ) - / ( "COUNT" "=" 1*DIGIT ) - / ( "INTERVAL" "=" 1*DIGIT ) - / ( "BYSECOND" "=" byseclist ) - / ( "BYMINUTE" "=" byminlist ) - / ( "BYHOUR" "=" byhrlist ) - / ( "BYDAY" "=" bywdaylist ) - / ( "BYMONTHDAY" "=" bymodaylist ) - / ( "BYYEARDAY" "=" byyrdaylist ) - / ( "BYWEEKNO" "=" bywknolist ) - / ( "BYMONTH" "=" bymolist ) - / ( "BYSETPOS" "=" bysplist ) - / ( "WKST" "=" weekday ) - - freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" - / "WEEKLY" / "MONTHLY" / "YEARLY" - - enddate = date / date-time - - byseclist = ( seconds *("," seconds) ) - - seconds = 1*2DIGIT ;0 to 60 - - byminlist = ( minutes *("," minutes) ) - - minutes = 1*2DIGIT ;0 to 59 - - byhrlist = ( hour *("," hour) ) - - hour = 1*2DIGIT ;0 to 23 - - bywdaylist = ( weekdaynum *("," weekdaynum) ) - - weekdaynum = [[plus / minus] ordwk] weekday - - plus = "+" - - minus = "-" - - ordwk = 1*2DIGIT ;1 to 53 - - weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" - ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, - ;FRIDAY, and SATURDAY days of the week. - - - -Desruisseaux Standards Track [Page 39] - -RFC 5545 iCalendar September 2009 - - - bymodaylist = ( monthdaynum *("," monthdaynum) ) - - monthdaynum = [plus / minus] ordmoday - - ordmoday = 1*2DIGIT ;1 to 31 - - byyrdaylist = ( yeardaynum *("," yeardaynum) ) - - yeardaynum = [plus / minus] ordyrday - - ordyrday = 1*3DIGIT ;1 to 366 - - bywknolist = ( weeknum *("," weeknum) ) - - weeknum = [plus / minus] ordwk - - bymolist = ( monthnum *("," monthnum) ) - - monthnum = 1*2DIGIT ;1 to 12 - - bysplist = ( setposday *("," setposday) ) - - setposday = yeardaynum - - Description: This value type is a structured value consisting of a - list of one or more recurrence grammar parts. Each rule part is - defined by a NAME=VALUE pair. The rule parts are separated from - each other by the SEMICOLON character. The rule parts are not - ordered in any particular sequence. Individual rule parts MUST - only be specified once. Compliant applications MUST accept rule - parts ordered in any sequence, but to ensure backward - compatibility with applications that pre-date this revision of - iCalendar the FREQ rule part MUST be the first rule part specified - in a RECUR value. - - The FREQ rule part identifies the type of recurrence rule. This - rule part MUST be specified in the recurrence rule. Valid values - include SECONDLY, to specify repeating events based on an interval - of a second or more; MINUTELY, to specify repeating events based - on an interval of a minute or more; HOURLY, to specify repeating - events based on an interval of an hour or more; DAILY, to specify - repeating events based on an interval of a day or more; WEEKLY, to - specify repeating events based on an interval of a week or more; - MONTHLY, to specify repeating events based on an interval of a - month or more; and YEARLY, to specify repeating events based on an - interval of a year or more. - - - - - -Desruisseaux Standards Track [Page 40] - -RFC 5545 iCalendar September 2009 - - - The INTERVAL rule part contains a positive integer representing at - which intervals the recurrence rule repeats. The default value is - "1", meaning every second for a SECONDLY rule, every minute for a - MINUTELY rule, every hour for an HOURLY rule, every day for a - DAILY rule, every week for a WEEKLY rule, every month for a - MONTHLY rule, and every year for a YEARLY rule. For example, - within a DAILY rule, a value of "8" means every eight days. - - The UNTIL rule part defines a DATE or DATE-TIME value that bounds - the recurrence rule in an inclusive manner. If the value - specified by UNTIL is synchronized with the specified recurrence, - this DATE or DATE-TIME becomes the last instance of the - recurrence. The value of the UNTIL rule part MUST have the same - value type as the "DTSTART" property. Furthermore, if the - "DTSTART" property is specified as a date with local time, then - the UNTIL rule part MUST also be specified as a date with local - time. If the "DTSTART" property is specified as a date with UTC - time or a date with local time and time zone reference, then the - UNTIL rule part MUST be specified as a date with UTC time. In the - case of the "STANDARD" and "DAYLIGHT" sub-components the UNTIL - rule part MUST always be specified as a date with UTC time. If - specified as a DATE-TIME value, then it MUST be specified in a UTC - time format. If not present, and the COUNT rule part is also not - present, the "RRULE" is considered to repeat forever. - - The COUNT rule part defines the number of occurrences at which to - range-bound the recurrence. The "DTSTART" property value always - counts as the first occurrence. - - The BYSECOND rule part specifies a COMMA-separated list of seconds - within a minute. Valid values are 0 to 60. The BYMINUTE rule - part specifies a COMMA-separated list of minutes within an hour. - Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA- - separated list of hours of the day. Valid values are 0 to 23. - The BYSECOND, BYMINUTE and BYHOUR rule parts MUST NOT be specified - when the associated "DTSTART" property has a DATE value type. - These rule parts MUST be ignored in RECUR value that violate the - above requirement (e.g., generated by applications that pre-date - this revision of iCalendar). - - The BYDAY rule part specifies a COMMA-separated list of days of - the week; SU indicates Sunday; MO indicates Monday; TU indicates - Tuesday; WE indicates Wednesday; TH indicates Thursday; FR - indicates Friday; and SA indicates Saturday. - - Each BYDAY value can also be preceded by a positive (+n) or - negative (-n) integer. If present, this indicates the nth - occurrence of a specific day within the MONTHLY or YEARLY "RRULE". - - - -Desruisseaux Standards Track [Page 41] - -RFC 5545 iCalendar September 2009 - - - For example, within a MONTHLY rule, +1MO (or simply 1MO) - represents the first Monday within the month, whereas -1MO - represents the last Monday of the month. The numeric value in a - BYDAY rule part with the FREQ rule part set to YEARLY corresponds - to an offset within the month when the BYMONTH rule part is - present, and corresponds to an offset within the year when the - BYWEEKNO or BYMONTH rule parts are present. If an integer - modifier is not present, it means all days of this type within the - specified frequency. For example, within a MONTHLY rule, MO - represents all Mondays within the month. The BYDAY rule part MUST - NOT be specified with a numeric value when the FREQ rule part is - not set to MONTHLY or YEARLY. Furthermore, the BYDAY rule part - MUST NOT be specified with a numeric value with the FREQ rule part - set to YEARLY when the BYWEEKNO rule part is specified. - - The BYMONTHDAY rule part specifies a COMMA-separated list of days - of the month. Valid values are 1 to 31 or -31 to -1. For - example, -10 represents the tenth to the last day of the month. - The BYMONTHDAY rule part MUST NOT be specified when the FREQ rule - part is set to WEEKLY. - - The BYYEARDAY rule part specifies a COMMA-separated list of days - of the year. Valid values are 1 to 366 or -366 to -1. For - example, -1 represents the last day of the year (December 31st) - and -306 represents the 306th to the last day of the year (March - 1st). The BYYEARDAY rule part MUST NOT be specified when the FREQ - rule part is set to DAILY, WEEKLY, or MONTHLY. - - The BYWEEKNO rule part specifies a COMMA-separated list of - ordinals specifying weeks of the year. Valid values are 1 to 53 - or -53 to -1. This corresponds to weeks according to week - numbering as defined in [ISO.8601.2004]. A week is defined as a - seven day period, starting on the day of the week defined to be - the week start (see WKST). Week number one of the calendar year - is the first week that contains at least four (4) days in that - calendar year. This rule part MUST NOT be used when the FREQ rule - part is set to anything other than YEARLY. For example, 3 - represents the third week of the year. - - Note: Assuming a Monday week start, week 53 can only occur when - Thursday is January 1 or if it is a leap year and Wednesday is - January 1. - - The BYMONTH rule part specifies a COMMA-separated list of months - of the year. Valid values are 1 to 12. - - The WKST rule part specifies the day on which the workweek starts. - Valid values are MO, TU, WE, TH, FR, SA, and SU. This is - - - -Desruisseaux Standards Track [Page 42] - -RFC 5545 iCalendar September 2009 - - - significant when a WEEKLY "RRULE" has an interval greater than 1, - and a BYDAY rule part is specified. This is also significant when - in a YEARLY "RRULE" when a BYWEEKNO rule part is specified. The - default value is MO. - - The BYSETPOS rule part specifies a COMMA-separated list of values - that corresponds to the nth occurrence within the set of - recurrence instances specified by the rule. BYSETPOS operates on - a set of recurrence instances in one interval of the recurrence - rule. For example, in a WEEKLY rule, the interval would be one - week A set of recurrence instances starts at the beginning of the - interval defined by the FREQ rule part. Valid values are 1 to 366 - or -366 to -1. It MUST only be used in conjunction with another - BYxxx rule part. For example "the last work day of the month" - could be represented as: - - FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 - - Each BYSETPOS value can include a positive (+n) or negative (-n) - integer. If present, this indicates the nth occurrence of the - specific occurrence within the set of occurrences specified by the - rule. - - Recurrence rules may generate recurrence instances with an invalid - date (e.g., February 30) or nonexistent local time (e.g., 1:30 AM - on a day where the local time is moved forward by an hour at 1:00 - AM). Such recurrence instances MUST be ignored and MUST NOT be - counted as part of the recurrence set. - - Information, not contained in the rule, necessary to determine the - various recurrence instance start time and dates are derived from - the Start Time ("DTSTART") component attribute. For example, - "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the - month or a time. This information would be the same as what is - specified for "DTSTART". - - BYxxx rule parts modify the recurrence in some manner. BYxxx rule - parts for a period of time that is the same or greater than the - frequency generally reduce or limit the number of occurrences of - the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" - reduces the number of recurrence instances from all days (if - BYMONTH rule part is not present) to all days in January. BYxxx - rule parts for a period of time less than the frequency generally - increase or expand the number of occurrences of the recurrence. - For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of - days within the yearly recurrence set from 1 (if BYMONTH rule part - is not present) to 2. - - - - -Desruisseaux Standards Track [Page 43] - -RFC 5545 iCalendar September 2009 - - - If multiple BYxxx rule parts are specified, then after evaluating - the specified FREQ and INTERVAL rule parts, the BYxxx rule parts - are applied to the current set of evaluated occurrences in the - following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, - BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are - evaluated. - - The table below summarizes the dependency of BYxxx rule part - expand or limit behavior on the FREQ rule part value. - - The term "N/A" means that the corresponding BYxxx rule part MUST - NOT be used with the corresponding FREQ value. - - BYDAY has some special behavior depending on the FREQ value and - this is described in separate notes below the table. - - +----------+--------+--------+-------+-------+------+-------+------+ - | |SECONDLY|MINUTELY|HOURLY |DAILY |WEEKLY|MONTHLY|YEARLY| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTH |Limit |Limit |Limit |Limit |Limit |Limit |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYWEEKNO |N/A |N/A |N/A |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYYEARDAY |Limit |Limit |Limit |N/A |N/A |N/A |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYMONTHDAY|Limit |Limit |Limit |Limit |N/A |Expand |Expand| - +----------+--------+--------+-------+-------+------+-------+------+ - |BYDAY |Limit |Limit |Limit |Limit |Expand|Note 1 |Note 2| - +----------+--------+--------+-------+-------+------+-------+------+ - |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 | - +----------+--------+--------+-------+-------+------+-------+------+ - - Note 1: Limit if BYMONTHDAY is present; otherwise, special expand - for MONTHLY. - - Note 2: 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. - - - - - - -Desruisseaux Standards Track [Page 44] - -RFC 5545 iCalendar September 2009 - - - Here is an example of evaluating multiple BYxxx rule parts. - - DTSTART;TZID=America/New_York:19970105T083000 - RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; - BYMINUTE=30 - - First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to - arrive at "every other year". Then, "BYMONTH=1" would be applied - to arrive at "every January, every other year". Then, "BYDAY=SU" - would be applied to arrive at "every Sunday in January, every - other year". Then, "BYHOUR=8,9" would be applied to arrive at - "every Sunday in January at 8 AM and 9 AM, every other year". - Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in - January at 8:30 AM and 9:30 AM, every other year". Then, lacking - information from "RRULE", the second is derived from "DTSTART", to - end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, - every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, - BYMONTHDAY, or BYMONTH rule part were missing, the appropriate - minute, hour, day, or month would have been retrieved from the - "DTSTART" property. - - If the computed local start time of a recurrence instance does not - exist, or occurs more than once, for the specified time zone, the - time of the recurrence instance is interpreted in the same manner - as an explicit DATE-TIME value describing that date and time, as - specified in Section 3.3.5. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following is a rule that specifies 10 occurrences that - occur every other day: - - FREQ=DAILY;COUNT=10;INTERVAL=2 - - There are other examples specified in Section 3.8.5.3. - -3.3.11. Text - - Value Name: TEXT - - Purpose: This value type is used to identify values that contain - human-readable text. - - Format Definition: This value type is defined by the following - notation: - - - - - -Desruisseaux Standards Track [Page 45] - -RFC 5545 iCalendar September 2009 - - - text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) - ; Folded according to description above - - ESCAPED-CHAR = ("\\" / "\;" / "\," / "\N" / "\n") - ; \\ encodes \, \N or \n encodes newline - ; \; encodes ;, \, encodes , - - TSAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-5B / - %x5D-7E / NON-US-ASCII - ; Any character except CONTROLs not needed by the current - ; character set, DQUOTE, ";", ":", "\", "," - - Description: If the property permits, multiple TEXT values are - specified by a COMMA-separated list of values. - - The language in which the text is represented can be controlled by - the "LANGUAGE" property parameter. - - 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, followed by a LATIN SMALL LETTER - N or a LATIN CAPITAL LETTER N, that is "\n" or "\N". - - The "TEXT" property values may also contain special characters - that are used to signify delimiters, such as a COMMA character for - lists of values or a SEMICOLON character for structured values. - In order to support the inclusion of these special characters in - "TEXT" property values, they MUST be escaped with a BACKSLASH - character. A BACKSLASH character in a "TEXT" property value MUST - be escaped with another BACKSLASH character. A COMMA character in - a "TEXT" property value MUST be escaped with a BACKSLASH - character. A SEMICOLON character in a "TEXT" property value MUST - be escaped with a BACKSLASH character. However, a COLON character - in a "TEXT" property value SHALL NOT be escaped with a BACKSLASH - character. - - Example: A multiple line value of: - - Project XYZ Final Review - Conference Room - 3B - Come Prepared. - - would be represented as: - - Project XYZ Final Review\nConference Room - 3B\nCome Prepared. - - - - - - -Desruisseaux Standards Track [Page 46] - -RFC 5545 iCalendar September 2009 - - -3.3.12. Time - - Value Name: TIME - - Purpose: This value type is used to identify values that contain a - time of day. - - Format Definition: This value type is defined by the following - notation: - - time = time-hour time-minute time-second [time-utc] - - time-hour = 2DIGIT ;00-23 - time-minute = 2DIGIT ;00-59 - time-second = 2DIGIT ;00-60 - ;The "60" value is used to account for positive "leap" seconds. - - time-utc = "Z" - - Description: If the property permits, multiple "time" values are - specified by a COMMA-separated list of values. No additional - content value encoding (i.e., BACKSLASH character encoding, see - Section 3.3.11) is defined for this value type. - - The "TIME" value type is used to identify values that contain a - time of day. The format is based on the [ISO.8601.2004] complete - representation, basic format for a time of day. The text format - consists of a two-digit, 24-hour of the day (i.e., values 00-23), - two-digit minute in the hour (i.e., values 00-59), and two-digit - seconds in the minute (i.e., values 00-60). The seconds value of - 60 MUST only be used to account for positive "leap" seconds. - Fractions of a second are not supported by this format. - - In parallel to the "DATE-TIME" definition above, the "TIME" value - type expresses time values in three forms: - - The form of time with UTC offset MUST NOT be used. For example, - the following is not valid for a time value: - - 230000-0800 ;Invalid time format - - FORM #1 LOCAL TIME - - The local time form is simply a time value that does not contain - the UTC designator nor does it reference a time zone. For - example, 11:00 PM: - - 230000 - - - -Desruisseaux Standards Track [Page 47] - -RFC 5545 iCalendar September 2009 - - - Time values of this type are said to be "floating" and are not - bound to any time zone in particular. They are used to represent - the same hour, minute, and second value regardless of which time - zone is currently being observed. For example, an event can be - defined that indicates that an individual will be busy from 11:00 - AM to 1:00 PM every day, no matter which time zone the person is - in. In these cases, a local time can be specified. 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. This means that two "Attendees", may - participate in the same event at different UTC times; floating - time SHOULD only be used where that is reasonable behavior. - - 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. - - The use of local time in a TIME value without the "TZID" property - parameter is to be interpreted as floating time, regardless of the - existence of "VTIMEZONE" calendar components in the iCalendar - object. - - FORM #2: UTC TIME - - UTC time, or absolute time, is identified by a LATIN CAPITAL - LETTER Z suffix character, the UTC designator, appended to the - time value. For example, the following represents 07:00 AM UTC: - - 070000Z - - The "TZID" property parameter MUST NOT be applied to TIME - properties whose time values are specified in UTC. - - FORM #3: LOCAL TIME AND TIME ZONE REFERENCE - - The local time with reference to time zone information form is - identified by the use the "TZID" property parameter to reference - the appropriate time zone definition. "TZID" is discussed in - detail in Section 3.2.19. - - Example: The following represents 8:30 AM in New York in winter, - five hours behind UTC, in each of the three formats: - - 083000 - 133000Z - TZID=America/New_York:083000 - - - - -Desruisseaux Standards Track [Page 48] - -RFC 5545 iCalendar September 2009 - - -3.3.13. URI - - Value Name: URI - - Purpose: This value type is used to identify values that contain a - uniform resource identifier (URI) type of reference to the - property value. - - Format Definition: This value type is defined by the following - notation: - - uri = - - Description: This value type might be used to reference binary - information, for values that are large, or otherwise undesirable - to include directly in the iCalendar object. - - Property values with this value type MUST follow the generic URI - syntax defined in [RFC3986]. - - When a property parameter value is a URI value type, the URI MUST - be specified as a quoted-string value. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following is a URI for a network file: - - http://example.com/my-report.txt - -3.3.14. UTC Offset - - Value Name: UTC-OFFSET - - Purpose: This value type is used to identify properties that contain - an offset from UTC to local time. - - Format Definition: This value type is defined by the following - notation: - - utc-offset = time-numzone - - time-numzone = ("+" / "-") time-hour time-minute [time-second] - - Description: The PLUS SIGN character MUST be specified for positive - UTC offsets (i.e., ahead of UTC). The HYPHEN-MINUS character MUST - be specified for negative UTC offsets (i.e., behind of UTC). The - - - - -Desruisseaux Standards Track [Page 49] - -RFC 5545 iCalendar September 2009 - - - value of "-0000" and "-000000" are not allowed. The time-second, - if present, MUST NOT be 60; if absent, it defaults to zero. - - No additional content value encoding (i.e., BACKSLASH character - encoding, see Section 3.3.11) is defined for this value type. - - Example: The following UTC offsets are given for standard time for - New York (five hours behind UTC) and Geneva (one hour ahead of - UTC): - - -0500 - - +0100 - -3.4. iCalendar Object - - The Calendaring and Scheduling Core Object is a collection of - calendaring and scheduling information. Typically, this information - will consist of an iCalendar stream with a single iCalendar object. - However, multiple iCalendar objects can be sequentially grouped - together in an iCalendar stream. The first line and last line of the - iCalendar object MUST contain a pair of iCalendar object delimiter - strings. The syntax for an iCalendar stream is as follows: - - icalstream = 1*icalobject - - icalobject = "BEGIN" ":" "VCALENDAR" CRLF - icalbody - "END" ":" "VCALENDAR" CRLF - - The following is a simple example of an iCalendar object: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//hacksw/handcal//NONSGML v1.0//EN - BEGIN:VEVENT - UID:19970610T172345Z-AF23B2@example.com - DTSTAMP:19970610T172345Z - DTSTART:19970714T170000Z - DTEND:19970715T040000Z - SUMMARY:Bastille Day Party - END:VEVENT - END:VCALENDAR - - - - - - - - -Desruisseaux Standards Track [Page 50] - -RFC 5545 iCalendar September 2009 - - -3.5. Property - - A property is the definition of an individual attribute describing a - calendar object or a calendar component. A property takes the form - defined by the "contentline" notation defined in Section 3.1. - - The following is an example of a property: - - DTSTART:19960415T133000Z - - This memo imposes no ordering of properties within an iCalendar - object. - - Property names, parameter names, and enumerated parameter values are - case-insensitive. For example, the property name "DUE" is the same - as "due" and "Due", DTSTART;TZID=America/New_York:19980714T120000 is - the same as DtStart;TzID=America/New_York:19980714T120000. - -3.6. Calendar Components - - The body of the iCalendar object consists of a sequence of calendar - properties and one or more calendar components. The calendar - properties are attributes that apply to the calendar object as a - whole. The calendar components are collections of properties that - express a particular calendar semantic. For example, the calendar - component can specify an event, a to-do, a journal entry, time zone - information, free/busy time information, or an alarm. - - The body of the iCalendar object is defined by the following - notation: - - icalbody = calprops component - - calprops = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - prodid / version / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - calscale / method / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - - - -Desruisseaux Standards Track [Page 51] - -RFC 5545 iCalendar September 2009 - - - x-prop / iana-prop - ; - ) - - component = 1*(eventc / todoc / journalc / freebusyc / - timezonec / iana-comp / x-comp) - - iana-comp = "BEGIN" ":" iana-token CRLF - 1*contentline - "END" ":" iana-token CRLF - - x-comp = "BEGIN" ":" x-name CRLF - 1*contentline - "END" ":" x-name CRLF - - An iCalendar object MUST include the "PRODID" and "VERSION" calendar - properties. In addition, it MUST include at least one calendar - component. Special forms of iCalendar objects are possible to - publish just busy time (i.e., only a "VFREEBUSY" calendar component) - or time zone (i.e., only a "VTIMEZONE" calendar component) - information. In addition, a complex iCalendar object that is used to - capture a complete snapshot of the contents of a calendar is possible - (e.g., composite of many different calendar components). More - commonly, an iCalendar object will consist of just a single "VEVENT", - "VTODO", or "VJOURNAL" calendar component. Applications MUST ignore - x-comp and iana-comp values they don't recognize. Applications that - support importing iCalendar objects SHOULD support all of the - component types defined in this document, and SHOULD NOT silently - drop any components as that can lead to user data loss. - -3.6.1. Event Component - - Component Name: VEVENT - - Purpose: Provide a grouping of component properties that describe an - event. - - Format Definition: A "VEVENT" calendar component is defined by the - following notation: - - eventc = "BEGIN" ":" "VEVENT" CRLF - eventprop *alarmc - "END" ":" "VEVENT" CRLF - - eventprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - - - -Desruisseaux Standards Track [Page 52] - -RFC 5545 iCalendar September 2009 - - - ; - dtstamp / uid / - ; - ; The following is REQUIRED if the component - ; appears in an iCalendar object that doesn't - ; specify the "METHOD" property; otherwise, it - ; is OPTIONAL; in any case, it MUST NOT occur - ; more than once. - ; - dtstart / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / created / description / geo / - last-mod / location / organizer / priority / - seq / status / summary / transp / - url / recurid / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; Either 'dtend' or 'duration' MAY appear in - ; a 'eventprop', but 'dtend' and 'duration' - ; MUST NOT occur in the same 'eventprop'. - ; - dtend / duration / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / - contact / exdate / rstatus / related / - resources / rdate / x-prop / iana-prop - ; - ) - - Description: A "VEVENT" calendar component is a grouping of - component properties, possibly including "VALARM" calendar - components, that represents a scheduled amount of time on a - calendar. For example, it can be an activity; such as a one-hour - long, department meeting from 8:00 AM to 9:00 AM, tomorrow. - Generally, an event will take up time on an individual calendar. - Hence, the event will appear as an opaque interval in a search for - busy time. Alternately, the event can have its Time Transparency - - - - -Desruisseaux Standards Track [Page 53] - -RFC 5545 iCalendar September 2009 - - - set to "TRANSPARENT" in order to prevent blocking of the event in - searches for busy time. - - The "VEVENT" is also the calendar component used to specify an - anniversary or daily reminder within a calendar. These events - have a DATE value type for the "DTSTART" property instead of the - default value type of DATE-TIME. If such a "VEVENT" has a "DTEND" - property, it MUST be specified as a DATE value also. The - anniversary type of "VEVENT" can span more than one date (i.e., - "DTEND" property value is set to a calendar date after the - "DTSTART" property value). If such a "VEVENT" has a "DURATION" - property, it MUST be specified as a "dur-day" or "dur-week" value. - - The "DTSTART" property for a "VEVENT" specifies the inclusive - start of the event. For recurring events, it also specifies the - very first instance in the recurrence set. The "DTEND" property - for a "VEVENT" calendar component specifies the non-inclusive end - of the event. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE value type but no - "DTEND" nor "DURATION" property, the event's duration is taken to - be one day. For cases where a "VEVENT" calendar component - specifies a "DTSTART" property with a DATE-TIME value type but no - "DTEND" property, the event ends on the same calendar date and - time of day specified by the "DTSTART" property. - - The "VEVENT" calendar component cannot be nested within another - calendar component. However, "VEVENT" calendar components can be - related to each other or to a "VTODO" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - Example: The following is an example of the "VEVENT" calendar - component used to represent a meeting that will also be opaque to - searches for busy time: - - BEGIN:VEVENT - UID:19970901T130000Z-123401@example.com - DTSTAMP:19970901T130000Z - DTSTART:19970903T163000Z - DTEND:19970903T190000Z - SUMMARY:Annual Employee Review - CLASS:PRIVATE - CATEGORIES:BUSINESS,HUMAN RESOURCES - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent a reminder that will not be opaque, but rather - transparent, to searches for busy time: - - - - -Desruisseaux Standards Track [Page 54] - -RFC 5545 iCalendar September 2009 - - - BEGIN:VEVENT - UID:19970901T130000Z-123402@example.com - DTSTAMP:19970901T130000Z - DTSTART:19970401T163000Z - DTEND:19970402T010000Z - SUMMARY:Laurel is in sensitivity awareness class. - CLASS:PUBLIC - CATEGORIES:BUSINESS,HUMAN RESOURCES - TRANSP:TRANSPARENT - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent an anniversary that will occur annually: - - BEGIN:VEVENT - UID:19970901T130000Z-123403@example.com - DTSTAMP:19970901T130000Z - DTSTART;VALUE=DATE:19971102 - SUMMARY:Our Blissful Anniversary - TRANSP:TRANSPARENT - CLASS:CONFIDENTIAL - CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION - RRULE:FREQ=YEARLY - END:VEVENT - - The following is an example of the "VEVENT" calendar component - used to represent a multi-day event scheduled from June 28th, 2007 - to July 8th, 2007 inclusively. Note that the "DTEND" property is - set to July 9th, 2007, since the "DTEND" property specifies the - non-inclusive end of the event. - - BEGIN:VEVENT - UID:20070423T123432Z-541111@example.com - DTSTAMP:20070423T123432Z - DTSTART;VALUE=DATE:20070628 - DTEND;VALUE=DATE:20070709 - SUMMARY:Festival International de Jazz de Montreal - TRANSP:TRANSPARENT - END:VEVENT - -3.6.2. To-Do Component - - Component Name: VTODO - - Purpose: Provide a grouping of calendar properties that describe a - to-do. - - - - - -Desruisseaux Standards Track [Page 55] - -RFC 5545 iCalendar September 2009 - - - Format Definition: A "VTODO" calendar component is defined by the - following notation: - - todoc = "BEGIN" ":" "VTODO" CRLF - todoprop *alarmc - "END" ":" "VTODO" CRLF - - todoprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / completed / created / description / - dtstart / geo / last-mod / location / organizer / - percent / priority / recurid / seq / status / - summary / url / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; Either 'due' or 'duration' MAY appear in - ; a 'todoprop', but 'due' and 'duration' - ; MUST NOT occur in the same 'todoprop'. - ; If 'duration' appear in a 'todoprop', - ; then 'dtstart' MUST also appear in - ; the same 'todoprop'. - ; - due / duration / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / contact / - exdate / rstatus / related / resources / - rdate / x-prop / iana-prop - ; - ) - - Description: A "VTODO" calendar component is a grouping of component - properties and possibly "VALARM" calendar components that - represent an action-item or assignment. For example, it can be - - - -Desruisseaux Standards Track [Page 56] - -RFC 5545 iCalendar September 2009 - - - used to represent an item of work assigned to an individual; such - as "turn in travel expense today". - - The "VTODO" calendar component cannot be nested within another - calendar component. However, "VTODO" calendar components can be - related to each other or to a "VEVENT" or to a "VJOURNAL" calendar - component with the "RELATED-TO" property. - - A "VTODO" calendar component without the "DTSTART" and "DUE" (or - "DURATION") properties specifies a to-do that will be associated - with each successive calendar date, until it is completed. - - Examples: The following is an example of a "VTODO" calendar - component that needs to be completed before May 1st, 2007. On - midnight May 1st, 2007 this to-do would be considered overdue. - - BEGIN:VTODO - UID:20070313T123432Z-456553@example.com - DTSTAMP:20070313T123432Z - DUE;VALUE=DATE:20070501 - SUMMARY:Submit Quebec Income Tax Return for 2006 - CLASS:CONFIDENTIAL - CATEGORIES:FAMILY,FINANCE - STATUS:NEEDS-ACTION - END:VTODO - - The following is an example of a "VTODO" calendar component that - was due before 1:00 P.M. UTC on July 9th, 2007 and was completed - on July 7th, 2007 at 10:00 A.M. UTC. - - BEGIN:VTODO - UID:20070514T103211Z-123404@example.com - DTSTAMP:20070514T103211Z - DTSTART:20070514T110000Z - DUE:20070709T130000Z - COMPLETED:20070707T100000Z - SUMMARY:Submit Revised Internet-Draft - PRIORITY:1 - STATUS:NEEDS-ACTION - END:VTODO - -3.6.3. Journal Component - - Component Name: VJOURNAL - - Purpose: Provide a grouping of component properties that describe a - journal entry. - - - - -Desruisseaux Standards Track [Page 57] - -RFC 5545 iCalendar September 2009 - - - Format Definition: A "VJOURNAL" calendar component is defined by the - following notation: - - journalc = "BEGIN" ":" "VJOURNAL" CRLF - jourprop - "END" ":" "VJOURNAL" CRLF - - jourprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - class / created / dtstart / - last-mod / organizer / recurid / seq / - status / summary / url / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / attendee / categories / comment / - contact / description / exdate / related / rdate / - rstatus / x-prop / iana-prop - ; - ) - - Description: A "VJOURNAL" calendar component is a grouping of - component properties that represent one or more descriptive text - notes associated with a particular calendar date. The "DTSTART" - property is used to specify the calendar date with which the - journal entry is associated. Generally, it will have a DATE value - data type, but it can also be used to specify a DATE-TIME value - data type. Examples of a journal entry include a daily record of - a legislative body or a journal entry of individual telephone - contacts for the day or an ordered list of accomplishments for the - day. The "VJOURNAL" calendar component can also be used to - associate a document with a calendar date. - - - - - -Desruisseaux Standards Track [Page 58] - -RFC 5545 iCalendar September 2009 - - - The "VJOURNAL" calendar component does not take up time on a - calendar. Hence, it does not play a role in free or busy time - searches -- it is as though it has a time transparency value of - TRANSPARENT. It is transparent to any such searches. - - The "VJOURNAL" calendar component cannot be nested within another - calendar component. However, "VJOURNAL" calendar components can - be related to each other or to a "VEVENT" or to a "VTODO" calendar - component, with the "RELATED-TO" property. - - Example: The following is an example of the "VJOURNAL" calendar - component: - - BEGIN:VJOURNAL - UID:19970901T130000Z-123405@example.com - DTSTAMP:19970901T130000Z - DTSTART;VALUE=DATE:19970317 - SUMMARY:Staff meeting minutes - DESCRIPTION:1. Staff meeting: Participants include Joe\, - Lisa\, and Bob. Aurora project plans were reviewed. - There is currently no budget reserves for this project. - Lisa will escalate to management. Next meeting on Tuesday.\n - 2. Telephone Conference: ABC Corp. sales representative - called to discuss new printer. Promised to get us a demo by - Friday.\n3. Henry Miller (Handsoff Insurance): Car was - totaled by tree. Is looking into a loaner car. 555-2323 - (tel). - END:VJOURNAL - -3.6.4. Free/Busy Component - - Component Name: VFREEBUSY - - Purpose: Provide a grouping of component properties that 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. - - Format Definition: A "VFREEBUSY" calendar component is defined by - the following notation: - - freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF - fbprop - "END" ":" "VFREEBUSY" CRLF - - fbprop = *( - ; - ; The following are REQUIRED, - - - -Desruisseaux Standards Track [Page 59] - -RFC 5545 iCalendar September 2009 - - - ; but MUST NOT occur more than once. - ; - dtstamp / uid / - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - contact / dtstart / dtend / - organizer / url / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attendee / comment / freebusy / rstatus / x-prop / - iana-prop - ; - ) - - Description: A "VFREEBUSY" calendar component is a grouping of - component properties that represents either a request for free or - busy time information, a reply to a request for free or busy time - information, or a published set of busy time information. - - When used to request free/busy time information, the "ATTENDEE" - property specifies the calendar users whose free/busy time is - being requested; the "ORGANIZER" property specifies the calendar - user who is requesting the free/busy time; the "DTSTART" and - "DTEND" properties specify the window of time for which the free/ - busy time is being requested; the "UID" and "DTSTAMP" properties - are specified to assist in proper sequencing of multiple free/busy - time requests. - - When used to reply to a request for free/busy time, the "ATTENDEE" - property specifies the calendar user responding to the free/busy - time request; the "ORGANIZER" property specifies the calendar user - that originally requested the free/busy time; the "FREEBUSY" - property specifies the free/busy time information (if it exists); - and the "UID" and "DTSTAMP" properties are specified to assist in - proper sequencing of multiple free/busy time replies. - - When used to publish busy time, the "ORGANIZER" property specifies - the calendar user associated with the published busy time; the - "DTSTART" and "DTEND" properties specify an inclusive time window - that surrounds the busy time information; the "FREEBUSY" property - specifies the published busy time information; and the "DTSTAMP" - property specifies the DATE-TIME that iCalendar object was - created. - - - - -Desruisseaux Standards Track [Page 60] - -RFC 5545 iCalendar September 2009 - - - The "VFREEBUSY" calendar component cannot be nested within another - calendar component. Multiple "VFREEBUSY" calendar components can - be specified within an iCalendar object. This permits the - grouping of free/busy information into logical collections, such - as monthly groups of busy time information. - - The "VFREEBUSY" calendar component is intended for use in - iCalendar object methods involving requests for free time, - requests for busy time, requests for both free and busy, and the - associated replies. - - Free/Busy information is represented with the "FREEBUSY" property. - This property provides a terse representation of time periods. - One or more "FREEBUSY" properties can be specified in the - "VFREEBUSY" calendar component. - - When present in a "VFREEBUSY" calendar component, the "DTSTART" - and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" - properties. - - The recurrence properties ("RRULE", "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. - - Example: The following is an example of a "VFREEBUSY" calendar - component used to request free or busy time information: - - BEGIN:VFREEBUSY - UID:19970901T082949Z-FA43EF@example.com - ORGANIZER:mailto:jane_doe@example.com - ATTENDEE:mailto:john_public@example.com - DTSTART:19971015T050000Z - DTEND:19971016T050000Z - DTSTAMP:19970901T083000Z - END:VFREEBUSY - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 61] - -RFC 5545 iCalendar September 2009 - - - The following is an example of a "VFREEBUSY" calendar component - used to reply to the request with busy time information: - - BEGIN:VFREEBUSY - UID:19970901T095957Z-76A912@example.com - ORGANIZER:mailto:jane_doe@example.com - ATTENDEE:mailto:john_public@example.com - DTSTAMP:19970901T100000Z - FREEBUSY:19971015T050000Z/PT8H30M, - 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M - URL:http://example.com/pub/busy/jpublic-01.ifb - COMMENT:This iCalendar file contains busy time information for - the next three months. - END:VFREEBUSY - - The following is an example of a "VFREEBUSY" calendar component - used to publish busy time information: - - BEGIN:VFREEBUSY - UID:19970901T115957Z-76A912@example.com - DTSTAMP:19970901T120000Z - ORGANIZER:jsmith@example.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.example.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - -3.6.5. Time Zone Component - - Component Name: VTIMEZONE - - Purpose: Provide a grouping of component properties that defines a - time zone. - - Format Definition: A "VTIMEZONE" calendar component is defined by - the following notation: - - timezonec = "BEGIN" ":" "VTIMEZONE" CRLF - *( - ; - ; 'tzid' is REQUIRED, but MUST NOT occur more - ; than once. - ; - tzid / - ; - - - -Desruisseaux Standards Track [Page 62] - -RFC 5545 iCalendar September 2009 - - - ; 'last-mod' and 'tzurl' are OPTIONAL, - ; but MUST NOT occur more than once. - ; - last-mod / tzurl / - ; - ; One of 'standardc' or 'daylightc' MUST occur - ; and each MAY occur more than once. - ; - standardc / daylightc / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - "END" ":" "VTIMEZONE" CRLF - - standardc = "BEGIN" ":" "STANDARD" CRLF - tzprop - "END" ":" "STANDARD" CRLF - - daylightc = "BEGIN" ":" "DAYLIGHT" CRLF - tzprop - "END" ":" "DAYLIGHT" CRLF - - tzprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - dtstart / tzoffsetto / tzoffsetfrom / - ; - ; The following is OPTIONAL, - ; but SHOULD NOT occur more than once. - ; - rrule / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - comment / rdate / tzname / x-prop / iana-prop - ; - ) - - Description: A time zone is unambiguously defined by the set of time - measurement rules determined by the governing body for a given - geographic area. These rules describe, at a minimum, the base - - - -Desruisseaux Standards Track [Page 63] - -RFC 5545 iCalendar September 2009 - - - offset from UTC for the time zone, often referred to as the - Standard Time offset. Many locations adjust their Standard Time - forward or backward by one hour, in order to accommodate seasonal - changes in number of daylight hours, often referred to as Daylight - Saving Time. Some locations adjust their time by a fraction of an - hour. Standard Time is also known as Winter Time. Daylight - Saving Time is also known as Advanced Time, Summer Time, or Legal - Time in certain countries. The following table shows the changes - in time zone rules in effect for New York City starting from 1967. - Each line represents a description or rule for a particular - observance. - - Effective Observance Rule - - +-----------+--------------------------+--------+--------------+ - | Date | (Date-Time) | Offset | Abbreviation | - +-----------+--------------------------+--------+--------------+ - | 1967-1973 | last Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 1967-2006 | last Sun in Oct, 02:00 | -0500 | EST | - | | | | | - | 1974-1974 | Jan 6, 02:00 | -0400 | EDT | - | | | | | - | 1975-1975 | Feb 23, 02:00 | -0400 | EDT | - | | | | | - | 1976-1986 | last Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 1987-2006 | first Sun in Apr, 02:00 | -0400 | EDT | - | | | | | - | 2007-* | second Sun in Mar, 02:00 | -0400 | EDT | - | | | | | - | 2007-* | first Sun in Nov, 02:00 | -0500 | EST | - +-----------+--------------------------+--------+--------------+ - - Note: The specification of a global time zone registry is not - addressed by this document and is left for future study. - However, implementers may find the TZ database [TZDB] a useful - reference. It is an informal, public-domain collection of time - zone information, which is currently being maintained by - volunteer Internet participants, and is used in several - operating systems. This database contains current and - historical time zone information for a wide variety of - locations around the globe; it provides a time zone identifier - for every unique time zone rule set in actual use since 1970, - with historical data going back to the introduction of standard - time. - - - - - -Desruisseaux Standards Track [Page 64] - -RFC 5545 iCalendar September 2009 - - - Interoperability between two calendaring and scheduling - applications, especially for recurring events, to-dos or journal - entries, is dependent on the ability to capture and convey date - and time information in an unambiguous format. The specification - of current time zone information is integral to this behavior. - - If present, the "VTIMEZONE" calendar component defines the set of - Standard Time and Daylight Saving Time observances (or rules) for - a particular time zone for a given interval of time. The - "VTIMEZONE" calendar component cannot be nested within other - calendar components. Multiple "VTIMEZONE" calendar components can - exist in an iCalendar object. In this situation, each "VTIMEZONE" - MUST represent a unique time zone definition. This is necessary - for some classes of events, such as airline flights, that start in - one time zone and end in another. - - The "VTIMEZONE" calendar component MUST include the "TZID" - property and at least one definition of a "STANDARD" or "DAYLIGHT" - sub-component. The "STANDARD" or "DAYLIGHT" sub-component MUST - include the "DTSTART", "TZOFFSETFROM", and "TZOFFSETTO" - properties. - - An individual "VTIMEZONE" calendar component MUST be specified for - each unique "TZID" parameter value specified in the iCalendar - object. In addition, a "VTIMEZONE" calendar component, referred - to by a recurring calendar component, MUST provide valid time zone - information for all recurrence instances. - - Each "VTIMEZONE" calendar component consists of a collection of - one or more sub-components that describe the rule for a particular - observance (either a Standard Time or a Daylight Saving Time - observance). The "STANDARD" sub-component consists of a - collection of properties that describe Standard Time. The - "DAYLIGHT" sub-component consists of a collection of properties - that describe Daylight Saving Time. In general, this collection - of properties consists of: - - * the first onset DATE-TIME for the observance; - - * the last onset DATE-TIME for the observance, if a last onset is - known; - - * the offset to be applied for the observance; - - * a rule that describes the day and time when the observance - takes effect; - - * an optional name for the observance. - - - -Desruisseaux Standards Track [Page 65] - -RFC 5545 iCalendar September 2009 - - - For a given time zone, there may be multiple unique definitions of - the observances over a period of time. Each observance is - described using either a "STANDARD" or "DAYLIGHT" sub-component. - The collection of these sub-components is used to describe the - time zone for a given period of time. The offset to apply at any - given time is found by locating the observance that has the last - onset date and time before the time in question, and using the - offset value from that observance. - - The top-level properties in a "VTIMEZONE" calendar component are: - - The mandatory "TZID" property is a text value that uniquely - identifies the "VTIMEZONE" calendar component within the scope of - an iCalendar object. - - The optional "LAST-MODIFIED" property is a UTC value that - specifies the date and time that this time zone definition was - last updated. - - The optional "TZURL" property is a url value that points to a - published "VTIMEZONE" definition. "TZURL" SHOULD refer to a - resource that is accessible by anyone who might need to interpret - the object. This SHOULD NOT normally be a "file" URL or other URL - that is not widely accessible. - - The collection of properties that are used to define the - "STANDARD" and "DAYLIGHT" sub-components include: - - The mandatory "DTSTART" property gives the effective onset date - and local time for the time zone sub-component definition. - "DTSTART" in this usage MUST be specified as a date with a local - time value. - - The mandatory "TZOFFSETFROM" property gives the UTC offset that is - in use when the onset of this time zone observance begins. - "TZOFFSETFROM" is combined with "DTSTART" to define the effective - onset for the time zone sub-component definition. For example, - the following represents the time at which the observance of - Standard Time took effect in Fall 1967 for New York City: - - DTSTART:19671029T020000 - - TZOFFSETFROM:-0400 - - The mandatory "TZOFFSETTO" property gives the UTC offset for the - time zone sub-component (Standard Time or Daylight Saving Time) - when this observance is in use. - - - - -Desruisseaux Standards Track [Page 66] - -RFC 5545 iCalendar September 2009 - - - The optional "TZNAME" property is the customary name for the time - zone. This could be used for displaying dates. - - The onset DATE-TIME values for the observance defined by the time - zone sub-component is defined by the "DTSTART", "RRULE", and - "RDATE" properties. - - The "RRULE" property defines the recurrence rule for the onset of - the observance defined by this time zone sub-component. Some - specific requirements for the usage of "RRULE" for this purpose - include: - - * If observance is known to have an effective end date, the - "UNTIL" recurrence rule parameter MUST be used to specify the - last valid onset of this observance (i.e., the UNTIL DATE-TIME - will be equal to the last instance generated by the recurrence - pattern). It MUST be specified in UTC time. - - * The "DTSTART" and the "TZOFFSETFROM" properties MUST be used - when generating the onset DATE-TIME values (instances) from the - "RRULE". - - The "RDATE" property can also be used to define the onset of the - observance by giving the individual onset date and times. "RDATE" - in this usage MUST be specified as a date with local time value, - relative to the UTC offset specified in the "TZOFFSETFROM" - property. - - The optional "COMMENT" property is also allowed for descriptive - explanatory text. - - Example: The following are examples of the "VTIMEZONE" calendar - component: - - This is an example showing all the time zone rules for New York - City since April 30, 1967 at 03:00:00 EDT. - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - BEGIN:DAYLIGHT - DTSTART:19670430T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19730429T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:STANDARD - - - -Desruisseaux Standards Track [Page 67] - -RFC 5545 iCalendar September 2009 - - - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU;UNTIL=20061029T060000Z - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19740106T020000 - RDATE:19750223T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19760425T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=-1SU;UNTIL=19860427T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=20060402T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - END:VTIMEZONE - - This is an example showing time zone information for New York City - using only the "DTSTART" property. Note that this is only - suitable for a recurring event that starts on or later than March - 11, 2007 at 03:00:00 EDT (i.e., the earliest effective transition - date and time) and ends no later than March 9, 2008 at 01:59:59 - - - -Desruisseaux Standards Track [Page 68] - -RFC 5545 iCalendar September 2009 - - - EST (i.e., latest valid date and time for EST in this scenario). - For example, this can be used for a recurring event that occurs - every Friday, 8:00 A.M.-9:00 A.M., starting June 1, 2007, ending - December 31, 2007, - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - BEGIN:STANDARD - DTSTART:20071104T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - This is a simple example showing the current time zone rules for - New York City using a "RRULE" recurrence pattern. Note that there - is no effective end date to either of the Standard Time or - Daylight Time rules. This information would be valid for a - recurring event starting today and continuing indefinitely. - - BEGIN:VTIMEZONE - TZID:America/New_York - LAST-MODIFIED:20050809T050000Z - TZURL:http://zones.example.com/tz/America-New_York.ics - BEGIN:STANDARD - DTSTART:20071104T020000 - RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:20070311T020000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - - - -Desruisseaux Standards Track [Page 69] - -RFC 5545 iCalendar September 2009 - - - This is an example showing a set of rules for a fictitious time - zone where the Daylight Time rule has an effective end date (i.e., - after that date, Daylight Time is no longer observed). - - BEGIN:VTIMEZONE - TZID:Fictitious - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 70] - -RFC 5545 iCalendar September 2009 - - - This is an example showing a set of rules for a fictitious time - zone where the first Daylight Time rule has an effective end date. - There is a second Daylight Time rule that picks up where the other - left off. - - BEGIN:VTIMEZONE - TZID:Fictitious - LAST-MODIFIED:19870101T000000Z - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - BEGIN:DAYLIGHT - DTSTART:19990424T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - -3.6.6. Alarm Component - - Component Name: VALARM - - Purpose: Provide a grouping of component properties that define an - alarm. - - Format Definition: A "VALARM" calendar component is defined by the - following notation: - - alarmc = "BEGIN" ":" "VALARM" CRLF - (audioprop / dispprop / emailprop) - "END" ":" "VALARM" CRLF - - audioprop = *( - ; - ; 'action' and 'trigger' are both REQUIRED, - - - -Desruisseaux Standards Track [Page 71] - -RFC 5545 iCalendar September 2009 - - - ; but MUST NOT occur more than once. - ; - action / trigger / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - attach / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - - dispprop = *( - ; - ; The following are REQUIRED, - ; but MUST NOT occur more than once. - ; - action / description / trigger / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - x-prop / iana-prop - ; - ) - - emailprop = *( - ; - ; The following are all REQUIRED, - ; but MUST NOT occur more than once. - ; - action / description / trigger / summary / - - - -Desruisseaux Standards Track [Page 72] - -RFC 5545 iCalendar September 2009 - - - ; - ; The following is REQUIRED, - ; and MAY occur more than once. - ; - attendee / - ; - ; 'duration' and 'repeat' are both OPTIONAL, - ; and MUST NOT occur more than once each; - ; but if one occurs, so MUST the other. - ; - duration / repeat / - ; - ; The following are OPTIONAL, - ; and MAY occur more than once. - ; - attach / x-prop / iana-prop - ; - ) - - Description: A "VALARM" calendar component is a grouping of - component properties that is a reminder or alarm for an event or a - to-do. For example, it may be used to define a reminder for a - pending event or an overdue to-do. - - The "VALARM" calendar component MUST include the "ACTION" and - "TRIGGER" properties. The "ACTION" property further constrains - the "VALARM" calendar component in the following ways: - - 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. - - 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. - - 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. It - can also include one or more "ATTACH" properties, which are - intended to be sent as message attachments. When the alarm is - triggered, the email message is sent. - - The "VALARM" calendar component MUST only appear within either a - "VEVENT" or "VTODO" calendar component. "VALARM" calendar - components cannot be nested. Multiple mutually independent - - - -Desruisseaux Standards Track [Page 73] - -RFC 5545 iCalendar September 2009 - - - "VALARM" calendar components can be specified for a single - "VEVENT" or "VTODO" calendar component. - - The "TRIGGER" property specifies when the alarm will be triggered. - The "TRIGGER" property specifies a duration prior to the start of - an event or a to-do. The "TRIGGER" edge may be explicitly set to - be relative to the "START" or "END" of the event or to-do with the - "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" - property value type can alternatively be set to an absolute - calendar date with UTC time. - - 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. 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. 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. - - The alarm can be defined such that it triggers repeatedly. A - definition of an alarm with a repeating trigger MUST include both - the "DURATION" and "REPEAT" properties. The "DURATION" property - specifies the delay period, after which the alarm will repeat. - The "REPEAT" property specifies the number of additional - repetitions that the alarm will be triggered. This repetition - count is in addition to the initial triggering of the alarm. Both - of these 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. - - The "ACTION" property is used within the "VALARM" calendar - component to specify the type of action invoked when the alarm is - triggered. The "VALARM" properties provide enough information for - a specific action to be invoked. It is typically the - responsibility of a "Calendar User Agent" (CUA) to deliver the - alarm in the specified fashion. An "ACTION" property value of - AUDIO specifies an alarm that causes a sound to be played to alert - the user; DISPLAY specifies an alarm that causes a text message to - be displayed to the user; and EMAIL specifies an alarm that causes - an electronic email message to be delivered to one or more email - addresses. - - In an AUDIO alarm, if the optional "ATTACH" property is included, - it MUST specify an audio sound resource. The intention is that - the sound will be played as the alarm effect. If an "ATTACH" - property is specified that does not refer to a sound resource, or - - - -Desruisseaux Standards Track [Page 74] - -RFC 5545 iCalendar September 2009 - - - if the specified sound resource cannot be rendered (because its - format is unsupported, or because it cannot be retrieved), then - the CUA or other entity responsible for playing the sound may - choose a fallback action, such as playing a built-in default - sound, or playing no sound at all. - - In a DISPLAY alarm, the intended alarm effect is for the text - value of the "DESCRIPTION" property to be displayed to the user. - - In an EMAIL alarm, the intended alarm effect is for an email - message to be composed and delivered to all the addresses - specified by the "ATTENDEE" properties in the "VALARM" calendar - component. 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. Any "ATTACH" - properties in the "VALARM" calendar component SHOULD be sent as - attachments to the message. - - Note: Implementations should carefully consider whether they - accept alarm components from untrusted sources, e.g., when - importing calendar objects from external sources. One - reasonable policy is to always ignore alarm components that the - calendar user has not set herself, or at least ask for - confirmation in such a case. - - Example: The following example is for a "VALARM" calendar component - that specifies an audio alarm that will sound at a precise time - and repeat 4 more times at 15-minute intervals: - - BEGIN:VALARM - TRIGGER;VALUE=DATE-TIME:19970317T133000Z - REPEAT:4 - DURATION:PT15M - ACTION:AUDIO - ATTACH;FMTTYPE=audio/basic:ftp://example.com/pub/ - sounds/bell-01.aud - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies a display alarm that will trigger 30 minutes before the - scheduled start of the event or of the to-do it is associated with - and will repeat 2 more times at 15-minute intervals: - - - - - - - - - -Desruisseaux Standards Track [Page 75] - -RFC 5545 iCalendar September 2009 - - - BEGIN:VALARM - TRIGGER:-PT30M - REPEAT:2 - DURATION:PT15M - ACTION:DISPLAY - DESCRIPTION:Breakfast meeting with executive\n - team at 8:30 AM EST. - END:VALARM - - The following example is for a "VALARM" calendar component that - specifies an email alarm that will trigger 2 days before the - scheduled due DATE-TIME of a to-do with which it is associated. - It does not repeat. The email has a subject, body, and attachment - link. - - BEGIN:VALARM - TRIGGER;RELATED=END:-P2D - ACTION:EMAIL - ATTENDEE:mailto:john_doe@example.com - SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** - DESCRIPTION:A draft agenda needs to be sent out to the attendees - to the weekly managers meeting (MGR-LIST). Attached is a - pointer the document template for the agenda file. - ATTACH;FMTTYPE=application/msword:http://example.com/ - templates/agenda.doc - END:VALARM - -3.7. Calendar Properties - - The Calendar Properties are attributes that apply to the iCalendar - object, as a whole. These properties do not appear within a calendar - component. They SHOULD be specified after the "BEGIN:VCALENDAR" - delimiter string and prior to any calendar component. - -3.7.1. Calendar Scale - - Property Name: CALSCALE - - Purpose: This property defines the calendar scale used for the - calendar information specified in the iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in an iCalendar - object. The default value is "GREGORIAN". - - - -Desruisseaux Standards Track [Page 76] - -RFC 5545 iCalendar September 2009 - - - Description: This memo is based on the Gregorian calendar scale. - The Gregorian calendar scale is assumed if this property is not - specified in the iCalendar object. It is expected that other - calendar scales will be defined in other specifications or by - future versions of this memo. - - Format Definition: This property is defined by the following - notation: - - calscale = "CALSCALE" calparam ":" calvalue CRLF - - calparam = *(";" other-param) - - calvalue = "GREGORIAN" - - Example: The following is an example of this property: - - CALSCALE:GREGORIAN - -3.7.2. Method - - Property Name: METHOD - - Purpose: This property defines the iCalendar object method - associated with the calendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in an iCalendar - object. - - Description: When used in a MIME message entity, the value of this - property MUST be the same as the Content-Type "method" parameter - value. If either the "METHOD" property or the Content-Type - "method" parameter is specified, then the other MUST also be - specified. - - No methods are defined by this specification. This is the subject - of other specifications, such as the iCalendar Transport- - independent Interoperability Protocol (iTIP) defined by [2446bis]. - - If this property is not present in the iCalendar object, then a - scheduling transaction MUST NOT be assumed. In such cases, the - iCalendar object is merely being used to transport a snapshot of - - - - -Desruisseaux Standards Track [Page 77] - -RFC 5545 iCalendar September 2009 - - - some calendar information; without the intention of conveying a - scheduling semantic. - - Format Definition: This property is defined by the following - notation: - - method = "METHOD" metparam ":" metvalue CRLF - - metparam = *(";" other-param) - - metvalue = iana-token - - Example: The following is a hypothetical example of this property to - convey that the iCalendar object is a scheduling request: - - METHOD:REQUEST - -3.7.3. Product Identifier - - Property Name: PRODID - - Purpose: This property specifies the identifier for the product that - created the iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property MUST be specified once in an iCalendar - object. - - Description: 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 [ISO.9070.1991]. - - This property SHOULD NOT be used to alter the interpretation of an - iCalendar object beyond the semantics specified in this memo. For - example, it is not to be used to further the understanding of non- - standard properties. - - Format Definition: This property is defined by the following - notation: - - prodid = "PRODID" pidparam ":" pidvalue CRLF - - pidparam = *(";" other-param) - - - - -Desruisseaux Standards Track [Page 78] - -RFC 5545 iCalendar September 2009 - - - pidvalue = text - ;Any text that describes the product and version - ;and that is generally assured of being unique. - - Example: The following is an example of this property. It does not - imply that English is the default language. - - PRODID:-//ABC Corporation//NONSGML My Product//EN - -3.7.4. Version - - Property Name: VERSION - - Purpose: This property specifies the identifier corresponding to the - highest version number or the minimum and maximum range of the - iCalendar specification that is required in order to interpret the - iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified once in an iCalendar - object. - - Description: A value of "2.0" corresponds to this memo. - - Format Definition: This property is defined by the following - notation: - - version = "VERSION" verparam ":" vervalue CRLF - - verparam = *(";" other-param) - - vervalue = "2.0" ;This memo - / maxver - / (minver ";" maxver) - - minver = - ;Minimum iCalendar version needed to parse the iCalendar object. - - maxver = - ;Maximum iCalendar version needed to parse the iCalendar object. - - - - - - - -Desruisseaux Standards Track [Page 79] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of this property: - - VERSION:2.0 - -3.8. Component Properties - - The following properties can appear within calendar components, as - specified by each component property definition. - -3.8.1. Descriptive Component Properties - - The following properties specify descriptive information about - calendar components. - -3.8.1.1. Attachment - - Property Name: ATTACH - - Purpose: This property provides the capability to associate a - document object with a calendar component. - - Value Type: The default value type for this property is URI. The - value type can also be set to BINARY to indicate inline binary - encoded content information. - - Property Parameters: IANA, non-standard, inline encoding, and value - data type property parameters can be specified on this property. - The format type parameter can be specified on this property and is - RECOMMENDED for inline binary encoded content information. - - Conformance: This property can be specified multiple times in a - "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar component with - the exception of AUDIO alarm that only allows this property to - occur once. - - Description: This property is used in "VEVENT", "VTODO", and - "VJOURNAL" calendar components to associate a resource (e.g., - document) with the calendar component. This property is used in - "VALARM" calendar components to specify an audio sound resource or - an email message attachment. This property can be specified as a - URI pointing to a resource or as inline binary encoded content. - - When this property is specified as inline binary encoded content, - calendar applications MAY attempt to guess the media type of the - resource via inspection of its content if and only if the media - type of the resource is not given by the "FMTTYPE" parameter. If - the media type remains unknown, calendar applications SHOULD treat - it as type "application/octet-stream". - - - -Desruisseaux Standards Track [Page 80] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - attach = "ATTACH" attachparam ( ":" uri ) / - ( - ";" "ENCODING" "=" "BASE64" - ";" "VALUE" "=" "BINARY" - ":" binary - ) - CRLF - - attachparam = *( - ; - ; The following is OPTIONAL for a URI value, - ; RECOMMENDED for a BINARY value, - ; and MUST NOT occur more than once. - ; - (";" fmttypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - ATTACH:CID:jsmith.part3.960817T083000.xyzMail@example.com - - ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ - reports/r-960812.ps - -3.8.1.2. Categories - - Property Name: CATEGORIES - - Purpose: This property defines the categories for a calendar - component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: The property can be specified within "VEVENT", "VTODO", - or "VJOURNAL" calendar components. - - - - -Desruisseaux Standards Track [Page 81] - -RFC 5545 iCalendar September 2009 - - - Description: This property is used to specify categories or subtypes - of the calendar component. The categories are useful in searching - for a calendar component of a particular type and category. - Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, - more than one category can be specified as a COMMA-separated list - of categories. - - Format Definition: This property is defined by the following - notation: - - categories = "CATEGORIES" catparam ":" text *("," text) - CRLF - - catparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam ) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - CATEGORIES:APPOINTMENT,EDUCATION - - CATEGORIES:MEETING - -3.8.1.3. Classification - - Property Name: CLASS - - Purpose: This property defines the access classification for a - calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified once in a "VEVENT", - "VTODO", or "VJOURNAL" calendar components. - - - - -Desruisseaux Standards Track [Page 82] - -RFC 5545 iCalendar September 2009 - - - Description: An access classification is only one component of the - general security system within a calendar application. It - provides a method of capturing the scope of the access the - calendar owner intends for information within an individual - calendar entry. The access classification of an individual - iCalendar component is useful when measured along with the other - security components of a calendar system (e.g., calendar user - authentication, authorization, access rights, access role, etc.). - Hence, the semantics of the individual access classifications - cannot be completely defined by this memo alone. Additionally, - due to the "blind" nature of most exchange processes using this - memo, these access classifications cannot serve as an enforcement - statement for a system receiving an iCalendar object. Rather, - they provide a method for capturing the intention of the calendar - owner for the access to the calendar component. If not specified - in a component that allows this property, the default value is - PUBLIC. Applications MUST treat x-name and iana-token values they - don't recognize the same way as they would the PRIVATE value. - - Format Definition: This property is defined by the following - notation: - - class = "CLASS" classparam ":" classvalue CRLF - - classparam = *(";" other-param) - - classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token - / x-name - ;Default is PUBLIC - - Example: The following is an example of this property: - - CLASS:PUBLIC - -3.8.1.4. Comment - - Property Name: COMMENT - - Purpose: This property specifies non-processing information intended - to provide a comment to the calendar user. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - - -Desruisseaux Standards Track [Page 83] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified multiple times in - "VEVENT", "VTODO", "VJOURNAL", and "VFREEBUSY" calendar components - as well as in the "STANDARD" and "DAYLIGHT" sub-components. - - Description: This property is used to specify a comment to the - calendar user. - - Format Definition: This property is defined by the following - notation: - - comment = "COMMENT" commparam ":" text CRLF - - commparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - COMMENT:The meeting really needs to include both ourselves - and the customer. We can't hold this meeting without them. - As a matter of fact\, the venue for the meeting ought to be at - their site. - - John - -3.8.1.5. Description - - Property Name: DESCRIPTION - - Purpose: This property provides a more complete description of the - calendar component than that provided by the "SUMMARY" property. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - - - -Desruisseaux Standards Track [Page 84] - -RFC 5545 iCalendar September 2009 - - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. The property can be - specified multiple times only within a "VJOURNAL" calendar - component. - - Description: This property is used in the "VEVENT" and "VTODO" to - capture lengthy textual descriptions associated with the activity. - - This property is used in the "VJOURNAL" calendar component to - capture one or more textual journal entries. - - This property is used in the "VALARM" calendar component to - capture the display text for a DISPLAY category of alarm, and to - capture the body text for an EMAIL category of alarm. - - Format Definition: This property is defined by the following - notation: - - description = "DESCRIPTION" descparam ":" text CRLF - - descparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property with formatted - line breaks in the property value: - - DESCRIPTION:Meeting to provide technical review for "Phoenix" - design.\nHappy Face Conference Room. Phoenix design team - MUST attend this meeting.\nRSVP to team leader. - -3.8.1.6. Geographic Position - - Property Name: GEO - - Purpose: This property specifies information related to the global - position for the activity specified by a calendar component. - - - - -Desruisseaux Standards Track [Page 85] - -RFC 5545 iCalendar September 2009 - - - Value Type: FLOAT. The value MUST be two SEMICOLON-separated FLOAT - values. - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar components. - - Description: This property value specifies latitude and longitude, - in that order (i.e., "LAT LON" ordering). The longitude - represents the location east or west of the prime meridian as a - positive or negative real number, respectively. The longitude and - latitude values MAY be specified up to six decimal places, which - will allow for accuracy to within one meter of geographical - position. Receiving applications MUST accept values of this - precision and MAY truncate values of greater precision. - - Values for latitude and longitude shall be expressed as decimal - fractions of degrees. Whole degrees of latitude shall be - represented by a two-digit decimal number ranging from 0 through - 90. Whole degrees of longitude shall be represented by a decimal - number ranging from 0 through 180. When a decimal fraction of a - degree is specified, it shall be separated from the whole number - of degrees by a decimal point. - - Latitudes north of the equator shall be specified by a plus sign - (+), or by the absence of a minus sign (-), preceding the digits - designating degrees. Latitudes south of the Equator shall be - designated by a minus sign (-) preceding the digits designating - degrees. A point on the Equator shall be assigned to the Northern - Hemisphere. - - Longitudes east of the prime meridian shall be specified by a plus - sign (+), or by the absence of a minus sign (-), preceding the - digits designating degrees. Longitudes west of the meridian shall - be designated by minus sign (-) preceding the digits designating - degrees. A point on the prime meridian shall be assigned to the - Eastern Hemisphere. A point on the 180th meridian shall be - assigned to the Western Hemisphere. One exception to this last - convention is permitted. For the special condition of describing - a band of latitude around the earth, the East Bounding Coordinate - data element shall be assigned the value +180 (180) degrees. - - Any spatial address with a latitude of +90 (90) or -90 degrees - will specify the position at the North or South Pole, - respectively. The component for longitude may have any legal - value. - - - -Desruisseaux Standards Track [Page 86] - -RFC 5545 iCalendar September 2009 - - - With the exception of the special condition described above, this - form is specified in [ANSI INCITS 61-1986]. - - The simple formula for converting degrees-minutes-seconds into - decimal degrees is: - - decimal = degrees + minutes/60 + seconds/3600. - - Format Definition: This property is defined by the following - notation: - - geo = "GEO" geoparam ":" geovalue CRLF - - geoparam = *(";" other-param) - - geovalue = float ";" float - ;Latitude and Longitude components - - Example: The following is an example of this property: - - GEO:37.386013;-122.082932 - -3.8.1.7. Location - - Property Name: LOCATION - - Purpose: This property defines the intended venue for the activity - defined by a calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: This property can be specified in "VEVENT" or "VTODO" - calendar component. - - Description: Specific venues such as conference or meeting rooms may - be explicitly specified using this property. An alternate - representation may be specified that is a URI that points to - directory information with more structured specification of the - location. For example, the alternate representation may specify - either an LDAP URL [RFC4516] pointing to an LDAP server entry or a - CID URL [RFC2392] pointing to a MIME body part containing a - Virtual-Information Card (vCard) [RFC2426] for the location. - - - - - -Desruisseaux Standards Track [Page 87] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - location = "LOCATION" locparam ":" text CRLF - - locparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are some examples of this property: - - LOCATION:Conference Room - F123\, Bldg. 002 - - LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": - Conference Room - F123\, Bldg. 002 - -3.8.1.8. Percent Complete - - Property Name: PERCENT-COMPLETE - - Purpose: This property is used by an assignee or delegatee of a - to-do to convey the percent completion of a to-do to the - "Organizer". - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in a "VTODO" - calendar component. - - Description: The property value is a positive integer between 0 and - 100. A value of "0" indicates the to-do has not yet been started. - A value of "100" indicates that the to-do has been completed. - Integer values in between indicate the percent partially complete. - - - - - -Desruisseaux Standards Track [Page 88] - -RFC 5545 iCalendar September 2009 - - - When a to-do is assigned to multiple individuals, the property - value indicates the percent complete for that portion of the to-do - assigned to the assignee or delegatee. For example, if a to-do is - assigned to both individuals "A" and "B". A reply from "A" with a - percent complete of "70" indicates that "A" has completed 70% of - the to-do assigned to them. A reply from "B" with a percent - complete of "50" indicates "B" has completed 50% of the to-do - assigned to them. - - Format Definition: This property is defined by the following - notation: - - percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF - - pctparam = *(";" other-param) - - Example: The following is an example of this property to show 39% - completion: - - PERCENT-COMPLETE:39 - -3.8.1.9. Priority - - Property Name: PRIORITY - - Purpose: This property defines the relative priority for a calendar - component. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT" and "VTODO" - calendar components. - - Description: This priority is specified as an integer in the range 0 - to 9. A value of 0 specifies an undefined priority. A value of 1 - is the highest priority. A value of 2 is the second highest - priority. Subsequent numbers specify a decreasing ordinal - priority. A value of 9 is the lowest priority. - - A CUA with a three-level priority scheme of "HIGH", "MEDIUM", and - "LOW" is mapped into this property such that a property value in - the range of 1 to 4 specifies "HIGH" priority. A value of 5 is - the normal or "MEDIUM" priority. A value in the range of 6 to 9 - is "LOW" priority. - - - - -Desruisseaux Standards Track [Page 89] - -RFC 5545 iCalendar September 2009 - - - A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., - "C3" is mapped into this property such that a property value of 1 - specifies "A1", a property value of 2 specifies "A2", a property - value of 3 specifies "A3", and so forth up to a property value of - 9 specifies "C3". - - Other integer values are reserved for future use. - - Within a "VEVENT" calendar component, this property specifies a - priority for the event. This property may be useful when more - than one event is scheduled for a given time period. - - Within a "VTODO" calendar component, this property specified a - priority for the to-do. This property is useful in prioritizing - multiple action items for a given time period. - - Format Definition: This property is defined by the following - notation: - - priority = "PRIORITY" prioparam ":" priovalue CRLF - ;Default is zero (i.e., undefined). - - prioparam = *(";" other-param) - - priovalue = integer ;Must be in the range [0..9] - ; All other values are reserved for future use. - - Example: The following is an example of a property with the highest - priority: - - PRIORITY:1 - - The following is an example of a property with a next highest - priority: - - PRIORITY:2 - - The following is an example of a property with no priority. This - is equivalent to not specifying the "PRIORITY" property: - - PRIORITY:0 - - - - - - - - - - -Desruisseaux Standards Track [Page 90] - -RFC 5545 iCalendar September 2009 - - -3.8.1.10. Resources - - Property Name: RESOURCES - - Purpose: This property defines the equipment or resources - anticipated for an activity specified by a calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: This property can be specified once in "VEVENT" or - "VTODO" calendar component. - - Description: The property value is an arbitrary text. More than one - resource can be specified as a COMMA-separated list of resources. - - Format Definition: This property is defined by the following - notation: - - resources = "RESOURCES" resrcparam ":" text *("," text) CRLF - - resrcparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - RESOURCES:EASEL,PROJECTOR,VCR - - RESOURCES;LANGUAGE=fr:Nettoyeur haute pression - - - - - - - - -Desruisseaux Standards Track [Page 91] - -RFC 5545 iCalendar September 2009 - - -3.8.1.11. Status - - Property Name: STATUS - - Purpose: This property defines the overall status or confirmation - for the calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in "VEVENT", - "VTODO", or "VJOURNAL" calendar components. - - Description: In a group-scheduled calendar component, the property - is used by the "Organizer" to provide a confirmation of the event - to the "Attendees". For example in a "VEVENT" calendar component, - the "Organizer" can indicate that a meeting is tentative, - confirmed, or cancelled. In a "VTODO" calendar component, the - "Organizer" can indicate that an action item needs action, is - completed, is in process or being worked on, or has been - cancelled. In a "VJOURNAL" calendar component, the "Organizer" - can indicate that a journal entry is draft, final, or has been - cancelled or removed. - - Format Definition: This property is defined by the following - notation: - - status = "STATUS" statparam ":" statvalue CRLF - - statparam = *(";" other-param) - - statvalue = (statvalue-event - / statvalue-todo - / statvalue-jour) - - statvalue-event = "TENTATIVE" ;Indicates event is tentative. - / "CONFIRMED" ;Indicates event is definite. - / "CANCELLED" ;Indicates event was cancelled. - ;Status values for a "VEVENT" - - statvalue-todo = "NEEDS-ACTION" ;Indicates to-do needs action. - / "COMPLETED" ;Indicates to-do completed. - / "IN-PROCESS" ;Indicates to-do in process of. - / "CANCELLED" ;Indicates to-do was cancelled. - ;Status values for "VTODO". - - - - -Desruisseaux Standards Track [Page 92] - -RFC 5545 iCalendar September 2009 - - - statvalue-jour = "DRAFT" ;Indicates journal is draft. - / "FINAL" ;Indicates journal is final. - / "CANCELLED" ;Indicates journal is removed. - ;Status values for "VJOURNAL". - - Example: The following is an example of this property for a "VEVENT" - calendar component: - - STATUS:TENTATIVE - - The following is an example of this property for a "VTODO" - calendar component: - - STATUS:NEEDS-ACTION - - The following is an example of this property for a "VJOURNAL" - calendar component: - - STATUS:DRAFT - -3.8.1.12. Summary - - Property Name: SUMMARY - - Purpose: This property defines a short summary or subject for the - calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - Conformance: The property can be specified in "VEVENT", "VTODO", - "VJOURNAL", or "VALARM" calendar components. - - Description: This property is used in the "VEVENT", "VTODO", and - "VJOURNAL" calendar components to capture a short, one-line - summary about the activity or journal entry. - - This property is used in the "VALARM" calendar component to - capture the subject of an EMAIL category of alarm. - - Format Definition: This property is defined by the following - notation: - - - - - - -Desruisseaux Standards Track [Page 93] - -RFC 5545 iCalendar September 2009 - - - summary = "SUMMARY" summparam ":" text CRLF - - summparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - SUMMARY:Department Party - -3.8.2. Date and Time Component Properties - - The following properties specify date and time related information in - calendar components. - -3.8.2.1. Date-Time Completed - - Property Name: COMPLETED - - Purpose: This property defines the date and time that a to-do was - actually completed. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified in a "VTODO" calendar - component. The value MUST be specified as a date with UTC time. - - Description: This property defines the date and time that a to-do - was actually completed. - - Format Definition: This property is defined by the following - notation: - - - - - - -Desruisseaux Standards Track [Page 94] - -RFC 5545 iCalendar September 2009 - - - completed = "COMPLETED" compparam ":" date-time CRLF - - compparam = *(";" other-param) - - Example: The following is an example of this property: - - COMPLETED:19960401T150000Z - -3.8.2.2. Date-Time End - - Property Name: DTEND - - Purpose: This property specifies the date and time that a calendar - component ends. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified in "VEVENT" or - "VFREEBUSY" calendar components. - - Description: Within the "VEVENT" calendar component, this property - defines the date and time by which the event ends. The value type - of this property MUST be the same as the "DTSTART" property, and - its value MUST be later in time than the value of the "DTSTART" - property. Furthermore, this property MUST be specified as a date - with local time if and only if the "DTSTART" property is also - specified as a date with local time. - - Within the "VFREEBUSY" calendar component, this property defines - the end date and time for the free or busy time information. The - time MUST be specified in the UTC time format. The value MUST be - later in time than the value of the "DTSTART" property. - - Format Definition: This property is defined by the following - notation: - - - - - - - - - - - -Desruisseaux Standards Track [Page 95] - -RFC 5545 iCalendar September 2009 - - - dtend = "DTEND" dtendparam ":" dtendval CRLF - - dtendparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dtendval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTEND:19960401T150000Z - - DTEND;VALUE=DATE:19980704 - -3.8.2.3. Date-Time Due - - Property Name: DUE - - Purpose: This property defines the date and time that a to-do is - expected to be completed. - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: The property can be specified once in a "VTODO" - calendar component. - - Description: This property defines the date and time before which a - to-do is expected to be completed. For cases where this property - is specified in a "VTODO" calendar component that also specifies a - "DTSTART" property, the value type of this property MUST be the - same as the "DTSTART" property, and the value of this property - - - -Desruisseaux Standards Track [Page 96] - -RFC 5545 iCalendar September 2009 - - - MUST be later in time than the value of the "DTSTART" property. - Furthermore, this property MUST be specified as a date with local - time if and only if the "DTSTART" property is also specified as a - date with local time. - - Format Definition: This property is defined by the following - notation: - - due = "DUE" dueparam ":" dueval CRLF - - dueparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dueval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DUE:19980430T000000Z - -3.8.2.4. Date-Time Start - - Property Name: DTSTART - - Purpose: This property specifies when the calendar component begins. - - Value Type: The default value type is DATE-TIME. The time value - MUST be one of the forms defined for the DATE-TIME value type. - The value type can be set to a DATE value type. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", or "VFREEBUSY" calendar components as well as in the - - - -Desruisseaux Standards Track [Page 97] - -RFC 5545 iCalendar September 2009 - - - "STANDARD" and "DAYLIGHT" sub-components. This property is - REQUIRED in all types of recurring calendar components that - specify the "RRULE" property. This property is also REQUIRED in - "VEVENT" calendar components contained in iCalendar objects that - don't specify the "METHOD" property. - - Description: Within the "VEVENT" calendar component, this property - defines the start date and time for the event. - - Within the "VFREEBUSY" calendar component, this property defines - the start date and time for the free or busy time information. - The time MUST be specified in UTC time. - - Within the "STANDARD" and "DAYLIGHT" sub-components, this property - defines the effective start date and time for a time zone - specification. This property is REQUIRED within each "STANDARD" - and "DAYLIGHT" sub-components included in "VTIMEZONE" calendar - components and MUST be specified as a date with local time without - the "TZID" property parameter. - - Format Definition: This property is defined by the following - notation: - - dtstart = "DTSTART" dtstparam ":" dtstval CRLF - - dtstparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - dtstval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - DTSTART:19980118T073000Z - - - - - -Desruisseaux Standards Track [Page 98] - -RFC 5545 iCalendar September 2009 - - -3.8.2.5. Duration - - Property Name: DURATION - - Purpose: This property specifies a positive duration of time. - - Value Type: DURATION - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in "VEVENT", "VTODO", or - "VALARM" calendar components. - - Description: In a "VEVENT" calendar component the property may be - used to specify a duration of the event, instead of an explicit - end DATE-TIME. In a "VTODO" calendar component the property may - be used to specify a duration for the to-do, instead of an - explicit due DATE-TIME. In a "VALARM" calendar component the - property may be used to specify the delay period prior to - repeating an alarm. When the "DURATION" property relates to a - "DTSTART" property that is specified as a DATE value, then the - "DURATION" property MUST be specified as a "dur-day" or "dur-week" - value. - - Format Definition: This property is defined by the following - notation: - - duration = "DURATION" durparam ":" dur-value CRLF - ;consisting of a positive duration of time. - - durparam = *(";" other-param) - - Example: The following is an example of this property that specifies - an interval of time of one hour and zero minutes and zero seconds: - - DURATION:PT1H0M0S - - The following is an example of this property that specifies an - interval of time of 15 minutes. - - DURATION:PT15M - - - - - - - - - -Desruisseaux Standards Track [Page 99] - -RFC 5545 iCalendar September 2009 - - -3.8.2.6. Free/Busy Time - - Property Name: FREEBUSY - - Purpose: This property defines one or more free or busy time - intervals. - - Value Type: PERIOD - - Property Parameters: IANA, non-standard, and free/busy time type - property parameters can be specified on this property. - - Conformance: The property can be specified in a "VFREEBUSY" calendar - component. - - Description: These time periods can be specified as either a start - and end DATE-TIME or a start DATE-TIME and DURATION. The date and - time MUST be a UTC time format. - - "FREEBUSY" properties within the "VFREEBUSY" calendar component - SHOULD be sorted in ascending order, based on start time and then - end time, with the earliest periods first. - - The "FREEBUSY" property can specify more than one value, separated - by the COMMA character. In such cases, the "FREEBUSY" property - values MUST all be of the same "FBTYPE" property parameter type - (e.g., all values of a particular "FBTYPE" listed together in a - single property). - - Format Definition: This property is defined by the following - notation: - - freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF - - fbparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" fbtypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - - - -Desruisseaux Standards Track [Page 100] - -RFC 5545 iCalendar September 2009 - - - fbvalue = period *("," period) - ;Time value MUST be in the UTC time format. - - Example: The following are some examples of this property: - - FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - - FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H - ,19970308T230000Z/19970309T000000Z - -3.8.2.7. Time Transparency - - Property Name: TRANSP - - Purpose: This property defines whether or not an event is - transparent to busy time searches. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in a "VEVENT" - calendar component. - - Description: Time Transparency is the characteristic of an event - that determines whether it appears to consume time on a calendar. - 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. 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. - - Format Definition: This property is defined by the following - notation: - - transp = "TRANSP" transparam ":" transvalue CRLF - - transparam = *(";" other-param) - - transvalue = "OPAQUE" - ;Blocks or opaque on busy time searches. - / "TRANSPARENT" - ;Transparent on busy time searches. - ;Default value is OPAQUE - - - -Desruisseaux Standards Track [Page 101] - -RFC 5545 iCalendar September 2009 - - - Example: The following is an example of this property for an event - that is transparent or does not block on free/busy time searches: - - TRANSP:TRANSPARENT - - The following is an example of this property for an event that is - opaque or blocks on free/busy time searches: - - TRANSP:OPAQUE - -3.8.3. Time Zone Component Properties - - The following properties specify time zone information in calendar - components. - -3.8.3.1. Time Zone Identifier - - Property Name: TZID - - Purpose: This property specifies the text value that uniquely - identifies the "VTIMEZONE" calendar component in the scope of an - iCalendar object. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in a "VTIMEZONE" - calendar component. - - Description: This is the label by which a time zone calendar - component is referenced by any iCalendar properties whose value - type is either DATE-TIME or TIME and not intended to specify a UTC - or a "floating" time. The presence of the SOLIDUS character as a - prefix, indicates that this "TZID" represents an unique ID in a - globally defined time zone registry (when such registry is - defined). - - Note: This document does not define a naming convention for - time zone identifiers. Implementers may want to use the naming - conventions defined in existing time zone specifications such - as the public-domain TZ database [TZDB]. The specification of - globally unique time zone identifiers is not addressed by this - document and is left for future study. - - - - - - -Desruisseaux Standards Track [Page 102] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF - - tzidpropparam = *(";" other-param) - - ;tzidprefix = "/" - ; Defined previously. Just listed here for reader convenience. - - Example: The following are examples of non-globally unique time zone - identifiers: - - TZID:America/New_York - - TZID:America/Los_Angeles - - The following is an example of a fictitious globally unique time - zone identifier: - - TZID:/example.org/America/New_York - -3.8.3.2. Time Zone Name - - Property Name: TZNAME - - Purpose: This property specifies the customary designation for a - time zone description. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: This property can be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies a customary name that can be - used when displaying dates that occur during the observance - defined by the time zone sub-component. - - Format Definition: This property is defined by the following - notation: - - - - - - - - -Desruisseaux Standards Track [Page 103] - -RFC 5545 iCalendar September 2009 - - - tzname = "TZNAME" tznparam ":" text CRLF - - tznparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property: - - TZNAME:EST - - TZNAME;LANGUAGE=fr-CA:HNE - -3.8.3.3. Time Zone Offset From - - Property Name: TZOFFSETFROM - - Purpose: This property specifies the offset that is in use prior to - this time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies the offset that is in use prior - to this time observance. It is used to calculate the absolute - time at which the transition to a given observance takes place. - This property MUST only be specified in a "VTIMEZONE" calendar - component. A "VTIMEZONE" calendar component MUST include this - property. The property value is a signed numeric indicating the - number of hours and possibly minutes from UTC. Positive numbers - represent time zones east of the prime meridian, or ahead of UTC. - Negative numbers represent time zones west of the prime meridian, - or behind UTC. - - - - -Desruisseaux Standards Track [Page 104] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset - CRLF - - frmparam = *(";" other-param) - - Example: The following are examples of this property: - - TZOFFSETFROM:-0500 - - TZOFFSETFROM:+1345 - -3.8.3.4. Time Zone Offset To - - Property Name: TZOFFSETTO - - Purpose: This property specifies the offset that is in use in this - time zone observance. - - Value Type: UTC-OFFSET - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified in "STANDARD" and - "DAYLIGHT" sub-components. - - Description: This property specifies the offset that is in use in - this time zone observance. It is used to calculate the absolute - time for the new observance. The property value is a signed - numeric indicating the number of hours and possibly minutes from - UTC. Positive numbers represent time zones east of the prime - meridian, or ahead of UTC. Negative numbers represent time zones - west of the prime meridian, or behind UTC. - - Format Definition: This property is defined by the following - notation: - - tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF - - toparam = *(";" other-param) - - - - - - - - -Desruisseaux Standards Track [Page 105] - -RFC 5545 iCalendar September 2009 - - - Example: The following are examples of this property: - - TZOFFSETTO:-0400 - - TZOFFSETTO:+1245 - -3.8.3.5. Time Zone URL - - Property Name: TZURL - - Purpose: This property provides a means for a "VTIMEZONE" component - to point to a network location that can be used to retrieve an up- - to-date version of itself. - - Value Type: URI - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in a "VTIMEZONE" - calendar component. - - Description: This property provides a means for a "VTIMEZONE" - component to point to a network location that can be used to - retrieve an up-to-date version of itself. This provides a hook to - handle changes government bodies impose upon time zone - definitions. Retrieval of this resource results in an iCalendar - object containing a single "VTIMEZONE" component and a "METHOD" - property set to PUBLISH. - - Format Definition: This property is defined by the following - notation: - - tzurl = "TZURL" tzurlparam ":" uri CRLF - - tzurlparam = *(";" other-param) - - Example: The following is an example of this property: - - TZURL:http://timezones.example.org/tz/America-Los_Angeles.ics - -3.8.4. Relationship Component Properties - - The following properties specify relationship information in calendar - components. - - - - - - -Desruisseaux Standards Track [Page 106] - -RFC 5545 iCalendar September 2009 - - -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. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group-scheduled calendar entity. This property - MUST NOT be specified in an iCalendar object when publishing the - calendar information (e.g., NOT in an iCalendar object that - specifies the publication of a calendar user's busy time, event, - to-do, or journal). This property is not specified in an - iCalendar object that specifies only a time zone definition or - that defines calendar components that are not group-scheduled - components, but are components only on a single user's calendar. - - 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. - - The property parameter "CN" is for the common or displayable name - associated with the calendar address; "ROLE", for the intended - role that the attendee will have in the calendar component; - "PARTSTAT", for the status of the attendee's participation; - "RSVP", for indicating whether the favor of a reply is requested; - "CUTYPE", to indicate the type of calendar user; "MEMBER", to - indicate the groups that the attendee belongs to; "DELEGATED-TO", - to indicate the calendar users that the original request was - delegated to; and "DELEGATED-FROM", to indicate whom the request - was delegated from; "SENT-BY", to indicate whom is acting on - behalf of the "ATTENDEE"; and "DIR", to indicate the URI that - points to the directory information corresponding to the attendee. - These property parameters can be specified on an "ATTENDEE" - property in either a "VEVENT", "VTODO", or "VJOURNAL" calendar - component. They MUST NOT be specified in an "ATTENDEE" property - in a "VFREEBUSY" or "VALARM" calendar component. If the - - - -Desruisseaux Standards Track [Page 107] - -RFC 5545 iCalendar September 2009 - - - "LANGUAGE" property parameter is specified, the identified - language applies to the "CN" parameter. - - A recipient delegated a request MUST inherit the "RSVP" and "ROLE" - values from the attendee that delegated the request to them. - - Multiple attendees can be specified by including multiple - "ATTENDEE" properties within the calendar component. - - Format Definition: This property is defined by the following - notation: - - attendee = "ATTENDEE" attparam ":" cal-address CRLF - - attparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" cutypeparam) / (";" memberparam) / - (";" roleparam) / (";" partstatparam) / - (";" rsvpparam) / (";" deltoparam) / - (";" delfromparam) / (";" sentbyparam) / - (";" cnparam) / (";" dirparam) / - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following are examples of this property's use for a - to-do: - - ATTENDEE;MEMBER="mailto:DEV-GROUP@example.com": - mailto:joecool@example.com - ATTENDEE;DELEGATED-FROM="mailto:immud@example.com": - mailto:ildoit@example.com - - - - - - - - - - - -Desruisseaux Standards Track [Page 108] - -RFC 5545 iCalendar September 2009 - - - The following is an example of this property used for specifying - multiple attendees to an event: - - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry - Cabot:mailto:hcabot@example.com - ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="mailto:bob@ - example.com";PARTSTAT=ACCEPTED;CN=Jane Doe:mailto:jdoe@ - example.com - - The following is an example of this property with a URI to the - directory information associated with the attendee: - - ATTENDEE;CN=John Smith;DIR="ldap://example.com:6666/o=ABC% - 20Industries,c=US???(cn=Jim%20Dolittle)":mailto:jimdo@ - example.com - - The following is an example of this property with "delegatee" and - "delegator" information for an event: - - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= - "mailto:iamboss@example.com";CN=Henry Cabot:mailto:hcabot@ - example.com - ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= - "mailto:hcabot@example.com";CN=The Big Cheese:mailto:iamboss - @example.com - ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe - :mailto:jdoe@example.com - - Example: The following is an example of this property's use when - another calendar user is acting on behalf of the "Attendee": - - ATTENDEE;SENT-BY=mailto:jan_doe@example.com;CN=John Smith: - mailto:jsmith@example.com - -3.8.4.2. Contact - - Property Name: CONTACT - - Purpose: This property is used to represent contact information or - alternately a reference to contact information associated with the - calendar component. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, alternate text - representation, and language property parameters can be specified - on this property. - - - - -Desruisseaux Standards Track [Page 109] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified in a "VEVENT", "VTODO", - "VJOURNAL", or "VFREEBUSY" calendar component. - - Description: The property value consists of textual contact - information. An alternative representation for the property value - can also be specified that refers to a URI pointing to an - alternate form, such as a vCard [RFC2426], for the contact - information. - - Format Definition: This property is defined by the following - notation: - - contact = "CONTACT" contparam ":" text CRLF - - contparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" altrepparam) / (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property referencing - textual contact information: - - CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - The following is an example of this property with an alternate - representation of an LDAP URI to a directory entry containing the - contact information: - - CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, - c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, - +1-919-555-1234 - - The following is an example of this property with an alternate - representation of a MIME body part containing the contact - information, such as a vCard [RFC2426] embedded in a text/ - directory media type [RFC2425]: - - CONTACT;ALTREP="CID:part3.msg970930T083000SILVER@example.com": - Jim Dolittle\, ABC Industries\, +1-919-555-1234 - - - -Desruisseaux Standards Track [Page 110] - -RFC 5545 iCalendar September 2009 - - - The following is an example of this property referencing a network - resource, such as a vCard [RFC2426] object containing the contact - information: - - CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim - Dolittle\, ABC Industries\, +1-919-555-1234 - -3.8.4.3. Organizer - - Property Name: ORGANIZER - - Purpose: This property defines the organizer for a calendar - component. - - Value Type: CAL-ADDRESS - - Property Parameters: IANA, non-standard, language, common name, - directory entry reference, and sent-by property parameters can be - specified on this property. - - Conformance: This property MUST be specified in an iCalendar object - that specifies a group-scheduled calendar entity. This property - MUST be specified in an iCalendar object that specifies the - publication of a calendar user's busy time. This property MUST - NOT be specified in an iCalendar object that specifies only a time - zone definition or that defines calendar components that are not - group-scheduled components, but are components only on a single - user's calendar. - - Description: This property is specified within the "VEVENT", - "VTODO", and "VJOURNAL" calendar components to specify the - organizer of a group-scheduled calendar entity. The property is - specified within the "VFREEBUSY" calendar component to specify the - calendar user requesting the free or busy time. When publishing a - "VFREEBUSY" calendar component, the property is used to specify - the calendar that the published busy time came from. - - The property has the property parameters "CN", for specifying the - common or display name associated with the "Organizer", "DIR", for - specifying a pointer to the directory information associated with - the "Organizer", "SENT-BY", for specifying another calendar user - that is acting on behalf of the "Organizer". The non-standard - parameters may also be specified on this property. If the - "LANGUAGE" property parameter is specified, the identified - language applies to the "CN" parameter value. - - - - - - -Desruisseaux Standards Track [Page 111] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - organizer = "ORGANIZER" orgparam ":" - cal-address CRLF - - orgparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" cnparam) / (";" dirparam) / (";" sentbyparam) / - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - Example: The following is an example of this property: - - ORGANIZER;CN=John Smith:mailto:jsmith@example.com - - The following is an example of this property with a pointer to the - directory information associated with the organizer: - - ORGANIZER;CN=JohnSmith;DIR="ldap://example.com:6666/o=DC%20Ass - ociates,c=US???(cn=John%20Smith)":mailto:jsmith@example.com - - The following is an example of this property used by another - calendar user who is acting on behalf of the organizer, with - responses intended to be sent back to the organizer, not the other - calendar user: - - ORGANIZER;SENT-BY="mailto:jane_doe@example.com": - mailto:jsmith@example.com - -3.8.4.4. Recurrence ID - - Property Name: RECURRENCE-ID - - Purpose: This property is used in conjunction with the "UID" and - "SEQUENCE" properties to identify a specific instance of a - recurring "VEVENT", "VTODO", or "VJOURNAL" calendar component. - The property value is the original value of the "DTSTART" property - of the recurrence instance. - - - -Desruisseaux Standards Track [Page 112] - -RFC 5545 iCalendar September 2009 - - - Value Type: The default value type is DATE-TIME. The value type can - be set to a DATE value type. This property MUST have the same - value type as the "DTSTART" property contained within the - recurring component. Furthermore, this property MUST be specified - as a date with local time if and only if the "DTSTART" property - contained within the recurring component is specified as a date - with local time. - - Property Parameters: IANA, non-standard, value data type, time zone - identifier, and recurrence identifier range parameters can be - specified on this property. - - Conformance: This property can be specified in an iCalendar object - containing a recurring calendar component. - - Description: The full range of calendar components specified by a - recurrence set is referenced by referring to just the "UID" - property value corresponding to the calendar component. The - "RECURRENCE-ID" property allows the reference to an individual - instance within the recurrence set. - - If the value of the "DTSTART" property is a DATE type value, then - the value MUST be the calendar date for the recurrence instance. - - The DATE-TIME value is set to the time when the original - recurrence instance would occur; meaning that if the intent is to - change a Friday meeting to Thursday, the DATE-TIME is still set to - the original Friday meeting. - - The "RECURRENCE-ID" property is used in conjunction with the "UID" - and "SEQUENCE" properties to identify a particular instance of a - recurring event, to-do, or journal. For a given pair of "UID" and - "SEQUENCE" property values, the "RECURRENCE-ID" value for a - recurrence instance is fixed. - - The "RANGE" parameter is used to specify the effective range of - recurrence instances from the instance specified by the - "RECURRENCE-ID" property value. The value for the range parameter - can only be "THISANDFUTURE" to indicate a range defined by the - given recurrence instance and all subsequent instances. - Subsequent instances are determined by their "RECURRENCE-ID" value - and not their current scheduled start time. Subsequent instances - defined in separate components are not impacted by the given - recurrence instance. When the given recurrence instance is - rescheduled, all subsequent instances are also rescheduled by the - same time difference. For instance, if the given recurrence - instance is rescheduled to start 2 hours later, then all - subsequent instances are also rescheduled 2 hours later. - - - -Desruisseaux Standards Track [Page 113] - -RFC 5545 iCalendar September 2009 - - - Similarly, if the duration of the given recurrence instance is - modified, then all subsequence instances are also modified to have - this same duration. - - Note: The "RANGE" parameter may not be appropriate to - reschedule specific subsequent instances of complex recurring - calendar component. Assuming an unbounded recurring calendar - component scheduled to occur on Mondays and Wednesdays, the - "RANGE" parameter could not be used to reschedule only the - future Monday instances to occur on Tuesday instead. In such - cases, the calendar application could simply truncate the - unbounded recurring calendar component (i.e., with the "COUNT" - or "UNTIL" rule parts), and create two new unbounded recurring - calendar components for the future instances. - - Format Definition: This property is defined by the following - notation: - - recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF - - ridparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - (";" tzidparam) / (";" rangeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - ridval = date-time / date - ;Value MUST match value type - - Example: The following are examples of this property: - - RECURRENCE-ID;VALUE=DATE:19960401 - - RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z - - - - - - - - -Desruisseaux Standards Track [Page 114] - -RFC 5545 iCalendar September 2009 - - -3.8.4.5. Related To - - Property Name: RELATED-TO - - Purpose: This property is used to represent a relationship or - reference between one calendar component and another. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and relationship type - property parameters can be specified on this property. - - Conformance: This property can be specified in the "VEVENT", - "VTODO", and "VJOURNAL" calendar components. - - Description: The property value consists of the persistent, globally - unique identifier of another calendar component. This value would - be represented in a calendar component by the "UID" property. - - By default, the property value points to another calendar - component that has a PARENT relationship to the referencing - object. The "RELTYPE" property parameter is used to either - explicitly state the default PARENT relationship type to the - referenced calendar component or to override the default PARENT - relationship type and specify either a CHILD or SIBLING - relationship. The PARENT relationship indicates that the calendar - component is a subordinate of the referenced calendar component. - The CHILD relationship indicates that the calendar component is a - superior of the referenced calendar component. The SIBLING - relationship indicates that the calendar component is a peer of - the referenced calendar component. - - Changes to a calendar component referenced by this property can - have an implicit impact on the related calendar component. For - example, if a group event changes its start or end date or time, - then the related, dependent events will need to have their start - and end dates changed in a corresponding way. Similarly, if a - PARENT calendar component is cancelled or deleted, then there is - an implied impact to the related CHILD calendar components. This - property is intended only to provide information on the - relationship of calendar components. It is up to the target - calendar system to maintain any property implications of this - relationship. - - - - - - - - -Desruisseaux Standards Track [Page 115] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - related = "RELATED-TO" relparam ":" text CRLF - - relparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" reltypeparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - The following is an example of this property: - - RELATED-TO:jsmith.part7.19960817T083000.xyzMail@example.com - - RELATED-TO:19960401-080045-4000F192713-0052@example.com - -3.8.4.6. Uniform Resource Locator - - Property Name: URL - - Purpose: This property defines a Uniform Resource Locator (URL) - associated with the iCalendar object. - - Value Type: URI - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified once in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: This property may be used in a calendar component to - convey a location where a more dynamic rendition of the calendar - information associated with the calendar component can be found. - This memo does not attempt to standardize the form of the URI, nor - the format of the resource pointed to by the property value. If - the URL property and Content-Location MIME header are both - specified, they MUST point to the same resource. - - - - -Desruisseaux Standards Track [Page 116] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - url = "URL" urlparam ":" uri CRLF - - urlparam = *(";" other-param) - - Example: The following is an example of this property: - - URL:http://example.com/pub/calendars/jsmith/mytime.ics - -3.8.4.7. Unique Identifier - - Property Name: UID - - Purpose: This property defines the persistent, globally unique - identifier for the calendar component. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property MUST be specified in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: The "UID" itself MUST be a globally unique identifier. - The generator of the identifier MUST guarantee that the identifier - is unique. There are several algorithms that can be used to - accomplish this. A good method to assure uniqueness is to put the - domain name or a domain literal IP address of the host on which - the identifier was created on the right-hand side of an "@", and - on the left-hand side, put a combination of the current calendar - date and time of day (i.e., formatted in as a DATE-TIME value) - along with some other currently unique (perhaps sequential) - identifier available on the system (for example, a process id - number). Using a DATE-TIME value on the left-hand side and a - domain name or domain literal on the right-hand side makes it - possible to guarantee uniqueness since no two hosts should be - using the same domain name or IP address at the same time. Though - other algorithms will work, it is RECOMMENDED that the right-hand - side contain some domain identifier (either of the host itself or - otherwise) such that the generator of the message identifier can - guarantee the uniqueness of the left-hand side within the scope of - that domain. - - This is the method for correlating scheduling messages with the - referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. - - - -Desruisseaux Standards Track [Page 117] - -RFC 5545 iCalendar September 2009 - - - The full range of calendar components specified by a recurrence - set is referenced by referring to just the "UID" property value - corresponding to the calendar component. The "RECURRENCE-ID" - property allows the reference to an individual instance within the - recurrence set. - - This property is an important method for group-scheduling - applications to match requests with later replies, modifications, - or deletion requests. Calendaring and scheduling applications - MUST generate this property in "VEVENT", "VTODO", and "VJOURNAL" - calendar components to assure interoperability with other group- - scheduling applications. This identifier is created by the - calendar system that generates an iCalendar object. - - Implementations MUST be able to receive and persist values of at - least 255 octets for this property, but they MUST NOT truncate - values in the middle of a UTF-8 multi-octet sequence. - - Format Definition: This property is defined by the following - notation: - - uid = "UID" uidparam ":" text CRLF - - uidparam = *(";" other-param) - - Example: The following is an example of this property: - - UID:19960401T080045Z-4000F192713-0052@example.com - -3.8.5. Recurrence Component Properties - - The following properties specify recurrence information in calendar - components. - -3.8.5.1. Exception Date-Times - - Property Name: EXDATE - - Purpose: This property defines the list of DATE-TIME exceptions for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - - -Desruisseaux Standards Track [Page 118] - -RFC 5545 iCalendar September 2009 - - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component. - - Description: The exception dates, if specified, are used in - computing the recurrence set. The recurrence set is the complete - set of recurrence instances for a calendar component. The - recurrence set is generated by considering the initial "DTSTART" - property along with the "RRULE", "RDATE", and "EXDATE" properties - contained within the recurring component. The "DTSTART" property - defines the first instance in the recurrence set. The "DTSTART" - property value SHOULD match the pattern of the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value that doesn't match the pattern of the rule is undefined. - The final recurrence set is generated by gathering all of the - start DATE-TIME values generated by any of the specified "RRULE" - and "RDATE" properties, and then excluding any start DATE-TIME - values specified by "EXDATE" properties. This implies that start - DATE-TIME values specified by "EXDATE" properties take precedence - over those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). When duplicate instances are generated by the "RRULE" - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - 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". - - Format Definition: This property is defined by the following - notation: - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 119] - -RFC 5545 iCalendar September 2009 - - - exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF - - exdtparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / - ; - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - exdtval = date-time / date - ;Value MUST match value type - - Example: The following is an example of this property: - - EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z - -3.8.5.2. Recurrence Date-Times - - Property Name: RDATE - - Purpose: This property defines the list of DATE-TIME values for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: The default value type for this property is DATE-TIME. - The value type can be set to DATE or PERIOD. - - Property Parameters: IANA, non-standard, value data type, and time - zone identifier property parameters can be specified on this - property. - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component. - - Description: This property can appear along with the "RRULE" - property to define an aggregate set of repeating occurrences. - When they both appear in a recurring component, the recurrence - - - -Desruisseaux Standards Track [Page 120] - -RFC 5545 iCalendar September 2009 - - - instances are defined by the union of occurrences defined by both - the "RDATE" and "RRULE". - - The recurrence dates, if specified, are used in computing the - recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set - is generated by considering the initial "DTSTART" property along - with the "RRULE", "RDATE", and "EXDATE" properties contained - within the recurring component. The "DTSTART" property defines - the first instance in the recurrence set. The "DTSTART" property - value SHOULD match the pattern of the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value that doesn't match the pattern of the rule is undefined. - The final recurrence set is generated by gathering all of the - start DATE-TIME values generated by any of the specified "RRULE" - and "RDATE" properties, and then excluding any start DATE-TIME - values specified by "EXDATE" properties. This implies that start - DATE-TIME values specified by "EXDATE" properties take precedence - over those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). Where duplicate instances are generated by the "RRULE" - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - Format Definition: This property is defined by the following - notation: - - rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF - - rdtparam = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / - (";" tzidparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - rdtval = date-time / date / period - ;Value MUST match value type - - - - - - -Desruisseaux Standards Track [Page 121] - -RFC 5545 iCalendar September 2009 - - - Example: The following are examples of this property: - - RDATE:19970714T123000Z - RDATE;TZID=America/New_York:19970714T083000 - - RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, - 19960404T010000Z/PT3H - - RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 - 19970526,19970704,19970901,19971014,19971128,19971129,19971225 - -3.8.5.3. Recurrence Rule - - Property Name: RRULE - - Purpose: This property defines a rule or repeating pattern for - recurring events, to-dos, journal entries, or time zone - definitions. - - Value Type: RECUR - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in recurring "VEVENT", - "VTODO", and "VJOURNAL" calendar components as well as in the - "STANDARD" and "DAYLIGHT" sub-components of the "VTIMEZONE" - calendar component, but it SHOULD NOT be specified more than once. - The recurrence set generated with multiple "RRULE" properties is - undefined. - - Description: The recurrence rule, if specified, is used in computing - the recurrence set. The recurrence set is the complete set of - recurrence instances for a calendar component. The recurrence set - is generated by considering the initial "DTSTART" property along - with the "RRULE", "RDATE", and "EXDATE" properties contained - within the recurring component. The "DTSTART" property defines - the first instance in the recurrence set. The "DTSTART" property - value SHOULD be synchronized with the recurrence rule, if - specified. The recurrence set generated with a "DTSTART" property - value not synchronized with the recurrence rule is undefined. The - final recurrence set is generated by gathering all of the start - DATE-TIME values generated by any of the specified "RRULE" and - "RDATE" properties, and then excluding any start DATE-TIME values - specified by "EXDATE" properties. This implies that start DATE- - TIME values specified by "EXDATE" properties take precedence over - those specified by inclusion properties (i.e., "RDATE" and - "RRULE"). Where duplicate instances are generated by the "RRULE" - - - -Desruisseaux Standards Track [Page 122] - -RFC 5545 iCalendar September 2009 - - - and "RDATE" properties, only one recurrence is considered. - Duplicate instances are ignored. - - The "DTSTART" property specified within the iCalendar object - defines the first instance of the recurrence. In most cases, a - "DTSTART" property of DATE-TIME value type used with a recurrence - rule, should be specified as a date with local time and time zone - reference to make sure all the recurrence instances start at the - same local time regardless of time zone changes. - - If the duration of the recurring component is specified with the - "DTEND" or "DUE" property, then the same exact duration will apply - to all the members of the generated recurrence set. Else, if the - duration of the recurring component is specified with the - "DURATION" property, then the same nominal duration will apply to - all the members of the generated recurrence set and the exact - duration of each recurrence instance will depend on its specific - start time. For example, recurrence instances of a nominal - duration of one day will have an exact duration of more or less - than 24 hours on a day where a time zone shift occurs. The - duration of a specific recurrence may be modified in an exception - component or simply by using an "RDATE" property of PERIOD value - type. - - Format Definition: This property is defined by the following - notation: - - rrule = "RRULE" rrulparam ":" recur CRLF - - rrulparam = *(";" other-param) - - Example: All examples assume the Eastern United States time zone. - - Daily for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;COUNT=10 - - ==> (1997 9:00 AM EDT) September 2-11 - - Daily until December 24, 1997: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT) September 2-30;October 1-25 - (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 - - - - -Desruisseaux Standards Track [Page 123] - -RFC 5545 iCalendar September 2009 - - - Every other day - forever: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=2 - - ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30; - October 2,4,6...20,22,24 - (1997 9:00 AM EST) October 26,28,30; - November 1,3,5,7...25,27,29; - December 1,3,... - - Every 10 days, 5 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 - - ==> (1997 9:00 AM EDT) September 2,12,22; - October 2,12 - - Every day in January, for 3 years: - - DTSTART;TZID=America/New_York:19980101T090000 - - RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; - BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA - or - RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 - - ==> (1998 9:00 AM EST)January 1-31 - (1999 9:00 AM EST)January 1-31 - (2000 9:00 AM EST)January 1-31 - - Weekly for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;COUNT=10 - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30;October 7,14,21 - (1997 9:00 AM EST) October 28;November 4 - - - - - - - - - - - - -Desruisseaux Standards Track [Page 124] - -RFC 5545 iCalendar September 2009 - - - Weekly until December 24, 1997: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30; - October 7,14,21 - (1997 9:00 AM EST) October 28; - November 4,11,18,25; - December 2,9,16,23 - - Every other week - forever: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU - - ==> (1997 9:00 AM EDT) September 2,16,30; - October 14 - (1997 9:00 AM EST) October 28; - November 11,25; - December 9,23 - (1998 9:00 AM EST) January 6,20; - February 3, 17 - ... - - Weekly on Tuesday and Thursday for five weeks: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH - - or - - RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT) September 2,4,9,11,16,18,23,25,30; - October 2 - - Every other week on Monday, Wednesday, and Friday until December - 24, 1997, starting on Monday, September 1, 1997: - - DTSTART;TZID=America/New_York:19970901T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; - BYDAY=MO,WE,FR - - ==> (1997 9:00 AM EDT) September 1,3,5,15,17,19,29; - October 1,3,13,15,17 - (1997 9:00 AM EST) October 27,29,31; - November 10,12,14,24,26,28; - - - -Desruisseaux Standards Track [Page 125] - -RFC 5545 iCalendar September 2009 - - - December 8,10,12,22 - - Every other week on Tuesday and Thursday, for 8 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH - - ==> (1997 9:00 AM EDT) September 2,4,16,18,30; - October 2,14,16 - - Monthly on the first Friday for 10 occurrences: - - DTSTART;TZID=America/New_York:19970905T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - - ==> (1997 9:00 AM EDT) September 5;October 3 - (1997 9:00 AM EST) November 7;December 5 - (1998 9:00 AM EST) January 2;February 6;March 6;April 3 - (1998 9:00 AM EDT) May 1;June 5 - - Monthly on the first Friday until December 24, 1997: - - DTSTART;TZID=America/New_York:19970905T090000 - RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR - - ==> (1997 9:00 AM EDT) September 5; October 3 - (1997 9:00 AM EST) November 7; December 5 - - Every other month on the first and last Sunday of the month for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970907T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU - - ==> (1997 9:00 AM EDT) September 7,28 - (1997 9:00 AM EST) November 2,30 - (1998 9:00 AM EST) January 4,25;March 1,29 - (1998 9:00 AM EDT) May 3,31 - - Monthly on the second-to-last Monday of the month for 6 months: - - DTSTART;TZID=America/New_York:19970922T090000 - RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO - - ==> (1997 9:00 AM EDT) September 22;October 20 - (1997 9:00 AM EST) November 17;December 22 - (1998 9:00 AM EST) January 19;February 16 - - - - -Desruisseaux Standards Track [Page 126] - -RFC 5545 iCalendar September 2009 - - - Monthly on the third-to-the-last day of the month, forever: - - DTSTART;TZID=America/New_York:19970928T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 - - ==> (1997 9:00 AM EDT) September 28 - (1997 9:00 AM EST) October 29;November 28;December 29 - (1998 9:00 AM EST) January 29;February 26 - ... - - Monthly on the 2nd and 15th of the month for 10 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 - - ==> (1997 9:00 AM EDT) September 2,15;October 2,15 - (1997 9:00 AM EST) November 2,15;December 2,15 - (1998 9:00 AM EST) January 2,15 - - Monthly on the first and last day of the month for 10 occurrences: - - DTSTART;TZID=America/New_York:19970930T090000 - RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 - - ==> (1997 9:00 AM EDT) September 30;October 1 - (1997 9:00 AM EST) October 31;November 1,30;December 1,31 - (1998 9:00 AM EST) January 1,31;February 1 - - Every 18 months on the 10th thru 15th of the month for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970910T090000 - RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12, - 13,14,15 - - ==> (1997 9:00 AM EDT) September 10,11,12,13,14,15 - (1999 9:00 AM EST) March 10,11,12,13 - - Every Tuesday, every other month: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU - - ==> (1997 9:00 AM EDT) September 2,9,16,23,30 - (1997 9:00 AM EST) November 4,11,18,25 - (1998 9:00 AM EST) January 6,13,20,27;March 3,10,17,24,31 - ... - - - - -Desruisseaux Standards Track [Page 127] - -RFC 5545 iCalendar September 2009 - - - Yearly in June and July for 10 occurrences: - - DTSTART;TZID=America/New_York:19970610T090000 - RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 - - ==> (1997 9:00 AM EDT) June 10;July 10 - (1998 9:00 AM EDT) June 10;July 10 - (1999 9:00 AM EDT) June 10;July 10 - (2000 9:00 AM EDT) June 10;July 10 - (2001 9:00 AM EDT) June 10;July 10 - - Note: Since none of the BYDAY, BYMONTHDAY, or BYYEARDAY - components are specified, the day is gotten from "DTSTART". - - Every other year on January, February, and March for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970310T090000 - RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 - - ==> (1997 9:00 AM EST) March 10 - (1999 9:00 AM EST) January 10;February 10;March 10 - (2001 9:00 AM EST) January 10;February 10;March 10 - (2003 9:00 AM EST) January 10;February 10;March 10 - - Every third year on the 1st, 100th, and 200th day for 10 - occurrences: - - DTSTART;TZID=America/New_York:19970101T090000 - RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 - - ==> (1997 9:00 AM EST) January 1 - (1997 9:00 AM EDT) April 10;July 19 - (2000 9:00 AM EST) January 1 - (2000 9:00 AM EDT) April 9;July 18 - (2003 9:00 AM EST) January 1 - (2003 9:00 AM EDT) April 10;July 19 - (2006 9:00 AM EST) January 1 - - Every 20th Monday of the year, forever: - - DTSTART;TZID=America/New_York:19970519T090000 - RRULE:FREQ=YEARLY;BYDAY=20MO - - ==> (1997 9:00 AM EDT) May 19 - (1998 9:00 AM EDT) May 18 - (1999 9:00 AM EDT) May 17 - ... - - - -Desruisseaux Standards Track [Page 128] - -RFC 5545 iCalendar September 2009 - - - Monday of week number 20 (where the default start of the week is - Monday), forever: - - DTSTART;TZID=America/New_York:19970512T090000 - RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO - - ==> (1997 9:00 AM EDT) May 12 - (1998 9:00 AM EDT) May 11 - (1999 9:00 AM EDT) May 17 - ... - - Every Thursday in March, forever: - - DTSTART;TZID=America/New_York:19970313T090000 - RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH - - ==> (1997 9:00 AM EST) March 13,20,27 - (1998 9:00 AM EST) March 5,12,19,26 - (1999 9:00 AM EST) March 4,11,18,25 - ... - - Every Thursday, but only during June, July, and August, forever: - - DTSTART;TZID=America/New_York:19970605T090000 - RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 - - ==> (1997 9:00 AM EDT) June 5,12,19,26;July 3,10,17,24,31; - August 7,14,21,28 - (1998 9:00 AM EDT) June 4,11,18,25;July 2,9,16,23,30; - August 6,13,20,27 - (1999 9:00 AM EDT) June 3,10,17,24;July 1,8,15,22,29; - August 5,12,19,26 - ... - - Every Friday the 13th, forever: - - DTSTART;TZID=America/New_York:19970902T090000 - EXDATE;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 - - ==> (1998 9:00 AM EST) February 13;March 13;November 13 - (1999 9:00 AM EDT) August 13 - (2000 9:00 AM EDT) October 13 - ... - - - - - - - -Desruisseaux Standards Track [Page 129] - -RFC 5545 iCalendar September 2009 - - - The first Saturday that follows the first Sunday of the month, - forever: - - DTSTART;TZID=America/New_York:19970913T090000 - RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 - - ==> (1997 9:00 AM EDT) September 13;October 11 - (1997 9:00 AM EST) November 8;December 13 - (1998 9:00 AM EST) January 10;February 7;March 7 - (1998 9:00 AM EDT) April 11;May 9;June 13... - ... - - Every 4 years, the first Tuesday after a Monday in November, - forever (U.S. Presidential Election day): - - DTSTART;TZID=America/New_York:19961105T090000 - RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU; - BYMONTHDAY=2,3,4,5,6,7,8 - - ==> (1996 9:00 AM EST) November 5 - (2000 9:00 AM EST) November 7 - (2004 9:00 AM EST) November 2 - ... - - The third instance into the month of one of Tuesday, Wednesday, or - Thursday, for the next 3 months: - - DTSTART;TZID=America/New_York:19970904T090000 - RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 - - ==> (1997 9:00 AM EDT) September 4;October 7 - (1997 9:00 AM EST) November 6 - - The second-to-last weekday of the month: - - DTSTART;TZID=America/New_York:19970929T090000 - RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 - - ==> (1997 9:00 AM EDT) September 29 - (1997 9:00 AM EST) October 30;November 27;December 30 - (1998 9:00 AM EST) January 29;February 26;March 30 - ... - - - - - - - - - -Desruisseaux Standards Track [Page 130] - -RFC 5545 iCalendar September 2009 - - - Every 3 hours from 9:00 AM to 5:00 PM on a specific day: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z - - ==> (September 2, 1997 EDT) 09:00,12:00,15:00 - - Every 15 minutes for 6 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 - - ==> (September 2, 1997 EDT) 09:00,09:15,09:30,09:45,10:00,10:15 - - Every hour and a half for 4 occurrences: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 - - ==> (September 2, 1997 EDT) 09:00,10:30;12:00;13:30 - - Every 20 minutes from 9:00 AM to 4:40 PM every day: - - DTSTART;TZID=America/New_York:19970902T090000 - RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 - or - RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 - - ==> (September 2, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, - ... 16:00,16:20,16:40 - (September 3, 1997 EDT) 9:00,9:20,9:40,10:00,10:20, - ...16:00,16:20,16:40 - ... - - An example where the days generated makes a difference because of - WKST: - - DTSTART;TZID=America/New_York:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO - - ==> (1997 EDT) August 5,10,19,24 - - changing only WKST from MO to SU, yields different results... - - DTSTART;TZID=America/New_York:19970805T090000 - RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU - - ==> (1997 EDT) August 5,17,19,31 - - - -Desruisseaux Standards Track [Page 131] - -RFC 5545 iCalendar September 2009 - - - An example where an invalid date (i.e., February 30) is ignored. - - DTSTART;TZID=America/New_York:20070115T090000 - RRULE:FREQ=MONTHLY;BYMONTHDAY=15,30;COUNT=5 - - ==> (2007 EST) January 15,30 - (2007 EST) February 15 - (2007 EDT) March 15,30 - -3.8.6. Alarm Component Properties - - The following properties specify alarm information in calendar - components. - -3.8.6.1. Action - - Property Name: ACTION - - Purpose: This property defines the action to be invoked when an - alarm is triggered. - - Value Type: TEXT - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be specified once in a "VALARM" - calendar component. - - Description: Each "VALARM" calendar component has a particular type - of action with which it is associated. This property specifies - the type of action. Applications MUST ignore alarms with x-name - and iana-token values they don't recognize. - - Format Definition: This property is defined by the following - notation: - - action = "ACTION" actionparam ":" actionvalue CRLF - - actionparam = *(";" other-param) - - - actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" - / iana-token / x-name - - Example: The following are examples of this property in a "VALARM" - calendar component: - - - - -Desruisseaux Standards Track [Page 132] - -RFC 5545 iCalendar September 2009 - - - ACTION:AUDIO - - ACTION:DISPLAY - -3.8.6.2. Repeat Count - - Property Name: REPEAT - - Purpose: This property defines the number of times the alarm should - be repeated, after the initial trigger. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in a "VALARM" calendar - component. - - Description: This property defines the number of times an alarm - should be repeated after its initial trigger. If the alarm - triggers more than once, then this property MUST be specified - along with the "DURATION" property. - - Format Definition: This property is defined by the following - notation: - - repeat = "REPEAT" repparam ":" integer CRLF - ;Default is "0", zero. - - repparam = *(";" other-param) - - Example: The following is an example of this property for an alarm - that repeats 4 additional times with a 5-minute delay after the - initial triggering of the alarm: - - REPEAT:4 - DURATION:PT5M - -3.8.6.3. Trigger - - Property Name: TRIGGER - - Purpose: This property specifies when an alarm will trigger. - - Value Type: The default value type is DURATION. 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. - - - -Desruisseaux Standards Track [Page 133] - -RFC 5545 iCalendar September 2009 - - - Property Parameters: IANA, non-standard, value data type, time zone - identifier, or trigger relationship property parameters can be - specified on this property. The trigger relationship property - parameter MUST only be specified when the value type is - "DURATION". - - Conformance: This property MUST be specified in the "VALARM" - calendar component. - - Description: This property defines when an alarm will trigger. The - default value type is DURATION, specifying a relative time for the - trigger of the alarm. The default duration is relative to the - start of an event or to-do with which the alarm is associated. - The duration can be explicitly set to trigger from either the end - or the start of the associated event or to-do with the "RELATED" - parameter. A value of START will set the alarm to trigger off the - start of the associated event or to-do. A value of END will set - the alarm to trigger off the end of the associated event or to-do. - - Either a positive or negative duration may be specified for the - "TRIGGER" property. An alarm with a positive duration is - triggered after the associated start or end of the event or to-do. - An alarm with a negative duration is triggered before the - associated start or end of the event or to-do. - - The "RELATED" property parameter is not valid if the value type of - the property is set to DATE-TIME (i.e., for an absolute date and - time alarm trigger). If a value type of DATE-TIME is specified, - then the property value MUST be specified in the UTC time format. - If an absolute trigger is specified on an alarm for a recurring - event or to-do, then the alarm will only trigger for the specified - absolute DATE-TIME, along with any specified repeating instances. - - If the trigger is set relative to START, then the "DTSTART" - property MUST be present in the associated "VEVENT" or "VTODO" - calendar component. If an alarm is specified for an event with - the trigger set relative to the END, then the "DTEND" property or - the "DTSTART" and "DURATION " properties MUST be present in the - associated "VEVENT" calendar component. If the alarm is specified - for a to-do with a trigger set relative to the END, then either - the "DUE" property or the "DTSTART" and "DURATION " properties - MUST be present in the associated "VTODO" calendar component. - - Alarms specified in an event or to-do that is defined in terms of - a DATE value type will be triggered relative to 00:00:00 of the - user's configured time zone on the specified date, or relative to - 00:00:00 UTC on the specified date if no configured time zone can - be found for the user. For example, if "DTSTART" is a DATE value - - - -Desruisseaux Standards Track [Page 134] - -RFC 5545 iCalendar September 2009 - - - set to 19980205 then the duration trigger will be relative to - 19980205T000000 America/New_York for a user configured with the - America/New_York time zone. - - Format Definition: This property is defined by the following - notation: - - trigger = "TRIGGER" (trigrel / trigabs) CRLF - - trigrel = *( - ; - ; The following are OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" "DURATION") / - (";" trigrelparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) ":" dur-value - - trigabs = *( - ; - ; The following is REQUIRED, - ; but MUST NOT occur more than once. - ; - (";" "VALUE" "=" "DATE-TIME") / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) ":" date-time - - Example: A trigger set 15 minutes prior to the start of the event or - to-do. - - TRIGGER:-PT15M - - A trigger set five minutes after the end of an event or the due - date of a to-do. - - TRIGGER;RELATED=END:PT5M - - - - -Desruisseaux Standards Track [Page 135] - -RFC 5545 iCalendar September 2009 - - - A trigger set to an absolute DATE-TIME. - - TRIGGER;VALUE=DATE-TIME:19980101T050000Z - -3.8.7. Change Management Component Properties - - The following properties specify change management information in - calendar components. - -3.8.7.1. Date-Time Created - - Property Name: CREATED - - Purpose: This property specifies the date and time that the calendar - information was created by the calendar user agent in the calendar - store. - - Note: This is analogous to the creation date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: The property can be specified once in "VEVENT", - "VTODO", or "VJOURNAL" calendar components. The value MUST be - specified as a date with UTC time. - - Description: This property specifies the date and time that the - calendar information was created by the calendar user agent in the - calendar store. - - Format Definition: This property is defined by the following - notation: - - created = "CREATED" creaparam ":" date-time CRLF - - creaparam = *(";" other-param) - - Example: The following is an example of this property: - - CREATED:19960329T133000Z - - - - - - - - -Desruisseaux Standards Track [Page 136] - -RFC 5545 iCalendar September 2009 - - -3.8.7.2. Date-Time Stamp - - Property Name: DTSTAMP - - Purpose: In the case of an iCalendar object that specifies a - "METHOD" property, this property specifies the date and time that - the instance of the iCalendar object was created. In the case of - an iCalendar object that doesn't specify a "METHOD" property, this - property specifies the date and time that the information - associated with the calendar component was last revised in the - calendar store. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property MUST be included in the "VEVENT", - "VTODO", "VJOURNAL", or "VFREEBUSY" calendar components. - - Description: The value MUST be specified in the UTC time format. - - This property is also useful to protocols such as [2447bis] that - have inherent latency issues with the delivery of content. This - property will assist in the proper sequencing of messages - containing iCalendar objects. - - In the case of an iCalendar object that specifies a "METHOD" - property, this property differs from the "CREATED" and "LAST- - MODIFIED" properties. These two properties are used to specify - when the particular calendar data in the calendar store was - created and last modified. This is different than when the - iCalendar object representation of the calendar service - information was created or last modified. - - In the case of an iCalendar object that doesn't specify a "METHOD" - property, this property is equivalent to the "LAST-MODIFIED" - property. - - Format Definition: This property is defined by the following - notation: - - dtstamp = "DTSTAMP" stmparam ":" date-time CRLF - - stmparam = *(";" other-param) - - - - - - -Desruisseaux Standards Track [Page 137] - -RFC 5545 iCalendar September 2009 - - - Example: - - DTSTAMP:19971210T080000Z - -3.8.7.3. Last Modified - - Property Name: LAST-MODIFIED - - Purpose: This property specifies the date and time that the - information associated with the calendar component was last - revised in the calendar store. - - Note: This is analogous to the modification date and time for a - file in the file system. - - Value Type: DATE-TIME - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - Conformance: This property can be specified in the "VEVENT", - "VTODO", "VJOURNAL", or "VTIMEZONE" calendar components. - - Description: The property value MUST be specified in the UTC time - format. - - Format Definition: This property is defined by the following - notation: - - last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF - - lstparam = *(";" other-param) - - Example: The following is an example of this property: - - LAST-MODIFIED:19960817T133000Z - -3.8.7.4. Sequence Number - - Property Name: SEQUENCE - - Purpose: This property defines the revision sequence number of the - calendar component within a sequence of revisions. - - Value Type: INTEGER - - Property Parameters: IANA and non-standard property parameters can - be specified on this property. - - - -Desruisseaux Standards Track [Page 138] - -RFC 5545 iCalendar September 2009 - - - Conformance: The property can be specified in "VEVENT", "VTODO", or - "VJOURNAL" calendar component. - - Description: When a calendar component is created, its sequence - number is 0. It is monotonically incremented by the "Organizer's" - CUA each time the "Organizer" makes a significant revision to the - calendar component. - - The "Organizer" includes this property in an iCalendar object that - it sends to an "Attendee" to specify the current version of the - calendar component. - - The "Attendee" includes this property in an iCalendar object that - it sends to the "Organizer" to specify the version of the calendar - component to which the "Attendee" is referring. - - A change to the sequence number is not the mechanism that an - "Organizer" uses to request a response from the "Attendees". The - "RSVP" parameter on the "ATTENDEE" property is used by the - "Organizer" to indicate that a response from the "Attendees" is - requested. - - Recurrence instances of a recurring component MAY have different - sequence numbers. - - Format Definition: This property is defined by the following - notation: - - seq = "SEQUENCE" seqparam ":" integer CRLF - ; Default is "0" - - seqparam = *(";" other-param) - - Example: The following is an example of this property for a calendar - component that was just created by the "Organizer": - - SEQUENCE:0 - - The following is an example of this property for a calendar - component that has been revised two different times by the - "Organizer": - - SEQUENCE:2 - -3.8.8. Miscellaneous Component Properties - - The following properties specify information about a number of - miscellaneous features of calendar components. - - - -Desruisseaux Standards Track [Page 139] - -RFC 5545 iCalendar September 2009 - - -3.8.8.1. IANA Properties - - Property Name: An IANA-registered property name - - Value Type: The default value type is TEXT. The value type can be - set to any value type. - - Property Parameters: Any parameter can be specified on this - property. - - Description: This specification allows other properties registered - with IANA to be specified in any calendar components. Compliant - applications are expected to be able to parse these other IANA- - registered properties but can ignore them. - - Format Definition: This property is defined by the following - notation: - - iana-prop = iana-token *(";" icalparameter) ":" value CRLF - - Example: The following are examples of properties that might be - registered to IANA: - - DRESSCODE:CASUAL - - NON-SMOKING;VALUE=BOOLEAN:TRUE - -3.8.8.2. Non-Standard Properties - - Property Name: Any property name with a "X-" prefix - - Purpose: This class of property provides a framework for defining - non-standard properties. - - Value Type: The default value type is TEXT. The value type can be - set to any value type. - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: This property can be specified in any calendar - component. - - Description: The MIME Calendaring and Scheduling Content Type - provides a "standard mechanism for doing non-standard things". - This extension support is provided for implementers to "push the - envelope" on the existing version of the memo. Extension - properties are specified by property and/or property parameter - - - -Desruisseaux Standards Track [Page 140] - -RFC 5545 iCalendar September 2009 - - - names that have the prefix text of "X-" (the two-character - sequence: LATIN CAPITAL LETTER X character followed by the HYPHEN- - MINUS character). It is recommended that vendors concatenate onto - this sentinel another short prefix text to identify the vendor. - This will facilitate readability of the extensions and minimize - possible collision of names between different vendors. User - agents that support this content type are expected to be able to - parse the extension properties and property parameters but can - ignore them. - - At present, there is no registration authority for names of - extension properties and property parameters. The value type for - this property is TEXT. Optionally, the value type can be any of - the other valid value types. - - Format Definition: This property is defined by the following - notation: - - x-prop = x-name *(";" icalparameter) ":" value CRLF - - Example: The following might be the ABC vendor's extension for an - audio-clip form of subject property: - - X-ABC-MMSUBJ;VALUE=URI;FMTTYPE=audio/basic:http://www.example. - org/mysubj.au - -3.8.8.3. Request Status - - Property Name: REQUEST-STATUS - - Purpose: This property defines the status code returned for a - scheduling request. - - Value Type: TEXT - - Property Parameters: IANA, non-standard, and language property - parameters can be specified on this property. - - Conformance: The property can be specified in the "VEVENT", "VTODO", - "VJOURNAL", or "VFREEBUSY" calendar component. - - Description: This property is used to return status code information - related to the processing of an associated iCalendar object. The - value type for this property is TEXT. - - - - - - - -Desruisseaux Standards Track [Page 141] - -RFC 5545 iCalendar September 2009 - - - The value consists of a short return status component, a longer - return status description component, and optionally a status- - specific data component. The components of the value are - separated by the SEMICOLON character. - - The short return status is a PERIOD character separated pair or - 3-tuple of integers. For example, "3.1" or "3.1.1". The - successive levels of integers provide for a successive level of - status code granularity. - - The following are initial classes for the return status code. - Individual iCalendar object methods will define specific return - status codes for these classes. In addition, other classes for - the return status code may be defined using the registration - process defined later in this memo. - - +--------+----------------------------------------------------------+ - | Short | Longer Return Status Description | - | Return | | - | Status | | - | Code | | - +--------+----------------------------------------------------------+ - | 1.xx | Preliminary success. This class of status code | - | | indicates that the request has been initially processed | - | | but that completion is pending. | - | | | - | 2.xx | Successful. This class of status code indicates that | - | | the request was completed successfully. However, the | - | | exact status code can indicate that a fallback has been | - | | taken. | - | | | - | 3.xx | Client Error. This class of status code indicates that | - | | the request was not successful. The error is the result | - | | of either a syntax or a semantic error in the client- | - | | formatted request. Request should not be retried until | - | | the condition in the request is corrected. | - | | | - | 4.xx | Scheduling Error. This class of status code indicates | - | | that the request was not successful. Some sort of error | - | | occurred within the calendaring and scheduling service, | - | | not directly related to the request itself. | - +--------+----------------------------------------------------------+ - - - - - - - - - -Desruisseaux Standards Track [Page 142] - -RFC 5545 iCalendar September 2009 - - - Format Definition: This property is defined by the following - notation: - - rstatus = "REQUEST-STATUS" rstatparam ":" - statcode ";" statdesc [";" extdata] - - rstatparam = *( - ; - ; The following is OPTIONAL, - ; but MUST NOT occur more than once. - ; - (";" languageparam) / - ; - ; The following is OPTIONAL, - ; and MAY occur more than once. - ; - (";" other-param) - ; - ) - - statcode = 1*DIGIT 1*2("." 1*DIGIT) - ;Hierarchical, numeric return status code - - statdesc = text - ;Textual status description - - extdata = text - ;Textual exception data. For example, the offending property - ;name and value or complete property line. - - Example: The following are some possible examples of this property. - - The COMMA and SEMICOLON separator characters in the property value - are BACKSLASH character escaped because they appear in a text - value. - - REQUEST-STATUS:2.0;Success - - REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 - - REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled - as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 - - REQUEST-STATUS:4.1;Event conflict. Date-time is busy. - - REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: - mailto:jsmith@example.com - - - - -Desruisseaux Standards Track [Page 143] - -RFC 5545 iCalendar September 2009 - - -4. iCalendar Object Examples - - The following examples are provided as an informational source of - illustrative iCalendar objects consistent with this content type. - - The following example specifies a three-day conference that begins at - 2:30 P.M. UTC, September 18, 1996 and ends at 10:00 P.M. UTC, - September 20, 1996. - - BEGIN:VCALENDAR - PRODID:-//xyz Corp//NONSGML PDA Calendar Version 1.0//EN - VERSION:2.0 - BEGIN:VEVENT - DTSTAMP:19960704T120000Z - UID:uid1@example.com - ORGANIZER:mailto:jsmith@example.com - DTSTART:19960918T143000Z - DTEND:19960920T220000Z - STATUS:CONFIRMED - CATEGORIES:CONFERENCE - SUMMARY:Networld+Interop Conference - DESCRIPTION:Networld+Interop Conference - and Exhibit\nAtlanta World Congress Center\n - Atlanta\, Georgia - END:VEVENT - END:VCALENDAR - - The following example specifies a group-scheduled meeting that begins - at 8:30 AM EST on March 12, 1998 and ends at 9:30 AM EST on March 12, - 1998. The "Organizer" has scheduled the meeting with one or more - calendar users in a group. A time zone specification for Eastern - United States has been specified. - - BEGIN:VCALENDAR - PRODID:-//RDU Software//NONSGML HandCal//EN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America/New_York - BEGIN:STANDARD - DTSTART:19981025T020000 - TZOFFSETFROM:-0400 - TZOFFSETTO:-0500 - TZNAME:EST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19990404T020000 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0400 - - - -Desruisseaux Standards Track [Page 144] - -RFC 5545 iCalendar September 2009 - - - TZNAME:EDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - DTSTAMP:19980309T231000Z - UID:guid-1.example.com - ORGANIZER:mailto:mrbig@example.com - ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: - mailto:employee-A@example.com - DESCRIPTION:Project XYZ Review Meeting - CATEGORIES:MEETING - CLASS:PUBLIC - CREATED:19980309T130000Z - SUMMARY:XYZ Project Review - DTSTART;TZID=America/New_York:19980312T083000 - DTEND;TZID=America/New_York:19980312T093000 - LOCATION:1CP Conference Room 4350 - END:VEVENT - END:VCALENDAR - - The following is an example of an iCalendar object passed in a MIME - message with a single body part consisting of a "text/calendar" - Content Type. - - TO:jsmith@example.com - FROM:jdoe@example.com - MIME-VERSION:1.0 - MESSAGE-ID: - CONTENT-TYPE:text/calendar; method="xyz"; component="VEVENT" - - BEGIN:VCALENDAR - METHOD:xyz - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VEVENT - DTSTAMP:19970324T120000Z - SEQUENCE:0 - UID:uid3@example.com - ORGANIZER:mailto:jdoe@example.com - ATTENDEE;RSVP=TRUE:mailto:jsmith@example.com - DTSTART:19970324T123000Z - DTEND:19970324T210000Z - CATEGORIES:MEETING,PROJECT - CLASS:PUBLIC - SUMMARY:Calendaring Interoperability Planning Meeting - DESCRIPTION:Discuss how we can test c&s interoperability\n - using iCalendar and other IETF standards. - LOCATION:LDB Lobby - - - -Desruisseaux Standards Track [Page 145] - -RFC 5545 iCalendar September 2009 - - - ATTACH;FMTTYPE=application/postscript:ftp://example.com/pub/ - conf/bkgrnd.ps - END:VEVENT - END:VCALENDAR - - The following is an example of a to-do due on April 15, 1998. An - audio alarm has been specified to remind the calendar user at noon, - the day before the to-do is expected to be completed and repeat - hourly, four additional times. The to-do definition has been - modified twice since it was initially created. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VTODO - DTSTAMP:19980130T134500Z - SEQUENCE:2 - UID:uid4@example.com - ORGANIZER:mailto:unclesam@example.com - ATTENDEE;PARTSTAT=ACCEPTED:mailto:jqpublic@example.com - DUE:19980415T000000 - STATUS:NEEDS-ACTION - SUMMARY:Submit Income Taxes - BEGIN:VALARM - ACTION:AUDIO - TRIGGER:19980403T120000Z - ATTACH;FMTTYPE=audio/basic:http://example.com/pub/audio- - files/ssbanner.aud - REPEAT:4 - DURATION:PT1H - END:VALARM - END:VTODO - END:VCALENDAR - - The following is an example of a journal entry: - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//ABC Corporation//NONSGML My Product//EN - BEGIN:VJOURNAL - DTSTAMP:19970324T120000Z - UID:uid5@example.com - ORGANIZER:mailto:jsmith@example.com - STATUS:DRAFT - CLASS:PUBLIC - CATEGORIES:Project Report,XYZ,Weekly Meeting - DESCRIPTION:Project xyz Review Meeting Minutes\n - Agenda\n1. Review of project version 1.0 requirements.\n2. - - - -Desruisseaux Standards Track [Page 146] - -RFC 5545 iCalendar September 2009 - - - Definition - of project processes.\n3. Review of project schedule.\n - Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was - decided that the requirements need to be signed off by - product marketing.\n-Project processes were accepted.\n - -Project schedule needs to account for scheduled holidays - and employee vacation time. Check with HR for specific - dates.\n-New schedule will be distributed by Friday.\n- - Next weeks meeting is cancelled. No meeting until 3/23. - END:VJOURNAL - END:VCALENDAR - - The following is an example of published busy time information. The - iCalendar object might be placed in the network resource - http://www.example.com/calendar/busytime/jsmith.ifb. - - BEGIN:VCALENDAR - VERSION:2.0 - PRODID:-//RDU Software//NONSGML HandCal//EN - BEGIN:VFREEBUSY - ORGANIZER:mailto:jsmith@example.com - DTSTART:19980313T141711Z - DTEND:19980410T141711Z - FREEBUSY:19980314T233000Z/19980315T003000Z - FREEBUSY:19980316T153000Z/19980316T163000Z - FREEBUSY:19980318T030000Z/19980318T040000Z - URL:http://www.example.com/calendar/busytime/jsmith.ifb - END:VFREEBUSY - END:VCALENDAR - -5. Recommended Practices - - These recommended practices should be followed in order to assure - consistent handling of the following cases for an iCalendar object. - - 1. Content lines longer than 75 octets SHOULD be folded. - - 2. When the combination of the "RRULE" and "RDATE" properties in a - recurring component produces multiple instances having the same - start DATE-TIME value, they should be collapsed to, and - considered as, a single instance. If the "RDATE" property is - specified as a PERIOD value the duration of the recurrence - instance will be the one specified by the "RDATE" property, and - not the duration of the recurrence instance defined by the - "DTSTART" property. - - 3. When a calendar user receives multiple requests for the same - calendar component (e.g., REQUEST for a "VEVENT" calendar - - - -Desruisseaux Standards Track [Page 147] - -RFC 5545 iCalendar September 2009 - - - component) as a result of being on multiple mailing lists - specified by "ATTENDEE" properties in the request, they SHOULD - respond to only one of the requests. The calendar user SHOULD - also specify (using the "MEMBER" parameter of the "ATTENDEE" - property) of which mailing list they are a member. - - 4. An implementation can truncate a "SUMMARY" property value to 255 - octets, but it MUST NOT truncate the value in the middle of a - UTF-8 multi-octet sequence. - - 5. If seconds of the minute are not supported by an implementation, - then a value of "00" SHOULD be specified for the seconds - component in a time value. - - 6. "TZURL" values SHOULD NOT be specified as a file URI type. This - URI form can be useful within an organization, but is problematic - in the Internet. - - 7. Some possible English values for "CATEGORIES" property include: - "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", "HOLIDAY", - "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT IN OFFICE", - "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL OCCASION", - "TRAVEL", "VACATION". Categories can be specified in any - registered language. - - 8. Some possible English values for the "RESOURCES" property - include: "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", - "OVERHEAD PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", - "VIDEO PHONE", "VEHICLE". Resources can be specified in any - registered language. - -6. Internationalization Considerations - - Applications MUST generate iCalendar streams in the UTF-8 charset and - MUST accept an iCalendar stream in the UTF-8 or US-ASCII charset. - -7. Security Considerations - - Because calendaring and scheduling information is very privacy- - sensitive, the protocol used for the transmission of calendaring and - scheduling information should have capabilities to protect the - information from possible threats, such as eavesdropping, replay, - message insertion, deletion, modification, and man-in-the-middle - attacks. - - As this document only defines the data format and media type of text/ - calendar that is independent of any calendar service or protocol, it - is up to the actual protocol specifications such as iTIP [2446bis], - - - -Desruisseaux Standards Track [Page 148] - -RFC 5545 iCalendar September 2009 - - - iMIP [2447bis], and "Calendaring Extensions to WebDAV (CalDAV)" - [RFC4791] to describe the threats that the above attacks present, as - well as ways in which to mitigate them. - -8. IANA Considerations - -8.1. iCalendar Media Type Registration - - The Calendaring and Scheduling Core Object Specification is intended - for use as a MIME content type. - - To: ietf-types@iana.org - - Subject: Registration of media type text/calendar - - Type name: text - - Subtype name: calendar - - Required parameters: none - - Optional parameters: charset, method, component, and optinfo - - The "charset" parameter is defined in [RFC2046] for subtypes of - the "text" media type. It is used to indicate the charset used in - the body part. The charset supported by this revision of - iCalendar is UTF-8. The use of any other charset is deprecated by - this revision of iCalendar; however, note that this revision - requires that compliant applications MUST accept iCalendar streams - using either the UTF-8 or US-ASCII charset. - - The "method" parameter is used to convey the iCalendar object - method or transaction semantics for the calendaring and scheduling - information. It also is an identifier for the restricted set of - properties and values of which the iCalendar object consists. The - parameter is to be used as a guide for applications interpreting - the information contained within the body part. It SHOULD NOT be - used to exclude or require particular pieces of information unless - the identified method definition specifically calls for this - behavior. Unless specifically forbidden by a particular method - definition, a text/calendar content type can contain any set of - properties permitted by the Calendaring and Scheduling Core Object - Specification. The "method" parameter MUST be specified and MUST - be set to the same value as the "METHOD" component property of the - iCalendar objects of the iCalendar stream if and only if the - iCalendar objects in the iCalendar stream all have a "METHOD" - component property set to the same value. - - - - -Desruisseaux Standards Track [Page 149] - -RFC 5545 iCalendar September 2009 - - - The value for the "method" parameter is defined as follows: - - method = 1*(ALPHA / DIGIT / "-") - ; IANA-registered iCalendar object method - - The "component" parameter conveys the type of iCalendar calendar - component within the body part. If the iCalendar object contains - more than one calendar component type, then multiple component - parameters MUST be specified. - - The value for the "component" parameter is defined as follows: - - component = "VEVENT" - / "VTODO" - / "VJOURNAL" - / "VFREEBUSY" - / "VTIMEZONE" - / iana-token - / x-name - - The "optinfo" parameter conveys optional information about the - iCalendar object within the body part. This parameter can only - specify semantics already specified by the iCalendar object and - that can be otherwise determined by parsing the body part. In - addition, the optional information specified by this parameter - MUST be consistent with that information specified by the - iCalendar object. For example, it can be used to convey the - "Attendee" response status to a meeting request. The parameter - value consists of a string value. - - The parameter can be specified multiple times. - - The value for the "optinfo" parameter is defined as follows: - - optinfo = infovalue / qinfovalue - - infovalue = iana-token / x-name - - qinfovalue = DQUOTE (infovalue) DQUOTE - - Encoding considerations: This media type can contain 8bit - characters, so the use of quoted-printable or base64 MIME Content- - Transfer-Encodings might be necessary when iCalendar objects are - transferred across protocols restricted to the 7bit repertoire. - Note that a text valued property in the content entity can also - have content encoding of special characters using a BACKSLASH - character escapement technique. This means that content values - can end up being encoded twice. - - - -Desruisseaux Standards Track [Page 150] - -RFC 5545 iCalendar September 2009 - - - Security considerations: See Section 7. - - Interoperability considerations: This media type is intended to - define a common format for conveying calendaring and scheduling - information between different systems. It is heavily based on the - earlier [VCAL] industry specification. - - Published specification: This specification. - - Applications that use this media type: This media type is designed - for widespread use by Internet calendaring and scheduling - applications. In addition, applications in the workflow and - document management area might find this content-type applicable. - The iTIP [2446bis], iMIP [2447bis], and CalDAV [RFC4791] Internet - protocols directly use this media type also. - - Additional information: - - Magic number(s): None. - - File extension(s): The file extension of "ics" is to be used to - designate a file containing (an arbitrary set of) calendaring - and scheduling information consistent with this MIME content - type. - - The file extension of "ifb" is to be used to designate a file - containing free or busy time information consistent with this - MIME content type. - - Macintosh file type code(s): The file type code of "iCal" is to - be used in Apple MacIntosh operating system environments to - designate a file containing calendaring and scheduling - information consistent with this MIME media type. - - The file type code of "iFBf" is to be used in Apple MacIntosh - operating system environments to designate a file containing - free or busy time information consistent with this MIME media - type. - - Person & email address to contact for further information: See the - "Author's Address" section of this document. - - Intended usage: COMMON - - Restrictions on usage: There are no restrictions on where this media - type can be used. - - Author: See the "Author's Address" section of this document. - - - -Desruisseaux Standards Track [Page 151] - -RFC 5545 iCalendar September 2009 - - - Change controller: IETF - -8.2. New iCalendar Elements Registration - - This section defines the process to register new or modified - iCalendar elements, that is, components, properties, parameters, - value data types, and values, with IANA. - -8.2.1. iCalendar Elements Registration Procedure - - The IETF will create a mailing list, icalendar@ietf.org, which can be - used for public discussion of iCalendar elements proposals prior to - registration. Use of the mailing list is strongly encouraged. The - IESG will appoint a designated expert who will monitor the - icalendar@ietf.org mailing list and review registrations. - - Registration of new iCalendar elements MUST be reviewed by the - designated expert and published in an RFC. A Standards Track RFC is - REQUIRED for the registration of new value data types that modify - existing properties, as well as for the registration of participation - status values to be used in "VEVENT" calendar components. A - Standards Track RFC is also REQUIRED for registration of iCalendar - elements that modify iCalendar elements previously documented in a - Standards Track RFC. - - The registration procedure begins when a completed registration - template, defined in the sections below, is sent to - icalendar@ietf.org and iana@iana.org. The designated expert is - expected to tell IANA and the submitter of the registration within - two weeks whether the registration is approved, approved with minor - changes, or rejected with cause. When a registration is rejected - with cause, it can be re-submitted if the concerns listed in the - cause are addressed. Decisions made by the designated expert can be - appealed to the IESG Applications Area Director, then to the IESG. - They follow the normal appeals procedure for IESG decisions. - -8.2.2. Registration Template for Components - - A component is defined by completing the following template. - - Component name: The name of the component. - - Purpose: The purpose of the component. Give a short but clear - description. - - Format definition: The ABNF for the component definition needs to be - specified. - - - - -Desruisseaux Standards Track [Page 152] - -RFC 5545 iCalendar September 2009 - - - Description: Any special notes about the component, how it is to be - used, etc. - - Example(s): One or more examples of instances of the component need - to be specified. - -8.2.3. Registration Template for Properties - - A property is defined by completing the following template. - - Property name: The name of the property. - - Purpose: The purpose of the property. Give a short but clear - description. - - Value type: Any of the valid value types for the property value need - to be specified. The default value type also needs to be - specified. - - Property parameters: Any of the valid property parameters for the - property MUST be specified. - - Conformance: The calendar components in which the property can - appear MUST be specified. - - Description: Any special notes about the property, how it is to be - used, etc. - - Format definition: The ABNF for the property definition needs to be - specified. - - Example(s): One or more examples of instances of the property need - to be specified. - -8.2.4. Registration Template for Parameters - - A parameter is defined by completing the following template. - - Parameter name: The name of the parameter. - - Purpose: The purpose of the parameter. Give a short but clear - description. - - Format definition: The ABNF for the parameter definition needs to be - specified. - - Description: Any special notes about the parameter, how it is to be - used, etc. - - - -Desruisseaux Standards Track [Page 153] - -RFC 5545 iCalendar September 2009 - - - Example(s): One or more examples of instances of the parameter need - to be specified. - -8.2.5. Registration Template for Value Data Types - - A value data type is defined by completing the following template. - - Value name: The name of the value type. - - Purpose: The purpose of the value type. Give a short but clear - description. - - Format definition: The ABNF for the value type definition needs to - be specified. - - Description: Any special notes about the value type, how it is to be - used, etc. - - Example(s): One or more examples of instances of the value type need - to be specified. - -8.2.6. Registration Template for Values - - A value is defined by completing the following template. - - Value: The value literal. - - Purpose: The purpose of the value. Give a short but clear - description. - - Conformance: The calendar properties and/or parameters that can take - this value need to be specified. - - Example(s): One or more examples of instances of the value need to - be specified. - - The following is a fictitious example of a registration of an - iCalendar value: - - Value: TOP-SECRET - - Purpose: This value is used to specify the access classification of - top-secret calendar components. - - Conformance: This value can be used with the "CLASS" property. - - - - - - -Desruisseaux Standards Track [Page 154] - -RFC 5545 iCalendar September 2009 - - - Example(s): The following is an example of this value used with the - "CLASS" property: - - CLASS:TOP-SECRET - -8.3. Initial iCalendar Elements Registries - - The IANA created and maintains the following registries for iCalendar - elements with pointers to appropriate reference documents. - -8.3.1. Components Registry - - The following table has been used to initialize the components - registry. - - +-----------+---------+-------------------------+ - | Component | Status | Reference | - +-----------+---------+-------------------------+ - | VCALENDAR | Current | RFC 5545, Section 3.4 | - | | | | - | VEVENT | Current | RFC 5545, Section 3.6.1 | - | | | | - | VTODO | Current | RFC 5545, Section 3.6.2 | - | | | | - | VJOURNAL | Current | RFC 5545, Section 3.6.3 | - | | | | - | VFREEBUSY | Current | RFC 5545, Section 3.6.4 | - | | | | - | VTIMEZONE | Current | RFC 5545, Section 3.6.5 | - | | | | - | VALARM | Current | RFC 5545, Section 3.6.6 | - | | | | - | STANDARD | Current | RFC 5545, Section 3.6.5 | - | | | | - | DAYLIGHT | Current | RFC 5545, Section 3.6.5 | - +-----------+---------+-------------------------+ - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 155] - -RFC 5545 iCalendar September 2009 - - -8.3.2. Properties Registry - - The following table is has been used to initialize the properties - registry. - - +------------------+------------+----------------------------+ - | Property | Status | Reference | - +------------------+------------+----------------------------+ - | CALSCALE | Current | RFC 5545, Section 3.7.1 | - | METHOD | Current | RFC 5545, Section 3.7.2 | - | | | | - | PRODID | Current | RFC 5545, Section 3.7.3 | - | | | | - | VERSION | Current | RFC 5545, Section 3.7.4 | - | | | | - | ATTACH | Current | RFC 5545, Section 3.8.1.1 | - | | | | - | CATEGORIES | Current | RFC 5545, Section 3.8.1.2 | - | | | | - | CLASS | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | COMMENT | Current | RFC 5545, Section 3.8.1.4 | - | | | | - | DESCRIPTION | Current | RFC 5545, Section 3.8.1.5 | - | | | | - | GEO | Current | RFC 5545, Section 3.8.1.6 | - | | | | - | LOCATION | Current | RFC 5545, Section 3.8.1.7 | - | | | | - | PERCENT-COMPLETE | Current | RFC 5545, Section 3.8.1.8 | - | | | | - | PRIORITY | Current | RFC 5545, Section 3.8.1.9 | - | | | | - | RESOURCES | Current | RFC 5545, Section 3.8.1.10 | - | | | | - | STATUS | Current | RFC 5545, Section 3.8.1.11 | - | | | | - | SUMMARY | Current | RFC 5545, Section 3.8.1.12 | - | | | | - | COMPLETED | Current | RFC 5545, Section 3.8.2.1 | - | | | | - | DTEND | Current | RFC 5545, Section 3.8.2.2 | - | | | | - | DUE | Current | RFC 5545, Section 3.8.2.3 | - | | | | - | DTSTART | Current | RFC 5545, Section 3.8.2.4 | - | | | | - | DURATION | Current | RFC 5545, Section 3.8.2.5 | - - - -Desruisseaux Standards Track [Page 156] - -RFC 5545 iCalendar September 2009 - - - | | | | - | FREEBUSY | Current | RFC 5545, Section 3.8.2.6 | - | | | | - | TRANSP | Current | RFC 5545, Section 3.8.2.7 | - | | | | - | TZID | Current | RFC 5545, Section 3.8.3.1 | - | | | | - | TZNAME | Current | RFC 5545, Section 3.8.3.2 | - | | | | - | TZOFFSETFROM | Current | RFC 5545, Section 3.8.3.3 | - | | | | - | TZOFFSETTO | Current | RFC 5545, Section 3.8.3.4 | - | | | | - | TZURL | Current | RFC 5545, Section 3.8.3.5 | - | | | | - | ATTENDEE | Current | RFC 5545, Section 3.8.4.1 | - | | | | - | CONTACT | Current | RFC 5545, Section 3.8.4.2 | - | | | | - | ORGANIZER | Current | RFC 5545, Section 3.8.4.3 | - | | | | - | RECURRENCE-ID | Current | RFC 5545, Section 3.8.4.4 | - | | | | - | RELATED-TO | Current | RFC 5545, Section 3.8.4.5 | - | | | | - | URL | Current | RFC 5545, Section 3.8.4.6 | - | | | | - | UID | Current | RFC 5545, Section 3.8.4.7 | - | | | | - | EXDATE | Current | RFC 5545, Section 3.8.5.1 | - | | | | - | EXRULE | Deprecated | [RFC2445], Section 4.8.5.2 | - | | | | - | RDATE | Current | RFC 5545, Section 3.8.5.2 | - | | | | - | RRULE | Current | RFC 5545, Section 3.8.5.3 | - | | | | - | ACTION | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | REPEAT | Current | RFC 5545, Section 3.8.6.2 | - | | | | - | TRIGGER | Current | RFC 5545, Section 3.8.6.3 | - | | | | - | CREATED | Current | RFC 5545, Section 3.8.7.1 | - | | | | - | DTSTAMP | Current | RFC 5545, Section 3.8.7.2 | - | | | | - | LAST-MODIFIED | Current | RFC 5545, Section 3.8.7.3 | - - - -Desruisseaux Standards Track [Page 157] - -RFC 5545 iCalendar September 2009 - - - | | | | - | SEQUENCE | Current | RFC 5545, Section 3.8.7.4 | - | | | | - | REQUEST-STATUS | Current | RFC 5545, Section 3.8.8.3 | - +------------------+------------+----------------------------+ - -8.3.3. Parameters Registry - - The following table has been used to initialize the parameters - registry. - - +----------------+---------+--------------------------+ - | Parameter | Status | Reference | - +----------------+---------+--------------------------+ - | ALTREP | Current | RFC 5545, Section 3.2.1 | - | | | | - | CN | Current | RFC 5545, Section 3.2.2 | - | | | | - | CUTYPE | Current | RFC 5545, Section 3.2.3 | - | | | | - | DELEGATED-FROM | Current | RFC 5545, Section 3.2.4 | - | | | | - | DELEGATED-TO | Current | RFC 5545, Section 3.2.5 | - | | | | - | DIR | Current | RFC 5545, Section 3.2.6 | - | | | | - | ENCODING | Current | RFC 5545, Section 3.2.7 | - | | | | - | FMTTYPE | Current | RFC 5545, Section 3.2.8 | - | | | | - | FBTYPE | Current | RFC 5545, Section 3.2.9 | - | | | | - | LANGUAGE | Current | RFC 5545, Section 3.2.10 | - | | | | - | MEMBER | Current | RFC 5545, Section 3.2.11 | - | | | | - | PARTSTAT | Current | RFC 5545, Section 3.2.12 | - | | | | - | RANGE | Current | RFC 5545, Section 3.2.13 | - | | | | - | RELATED | Current | RFC 5545, Section 3.2.14 | - | | | | - | RELTYPE | Current | RFC 5545, Section 3.2.15 | - | | | | - | ROLE | Current | RFC 5545, Section 3.2.16 | - | | | | - | RSVP | Current | RFC 5545, Section 3.2.17 | - | | | | - - - -Desruisseaux Standards Track [Page 158] - -RFC 5545 iCalendar September 2009 - - - | SENT-BY | Current | RFC 5545, Section 3.2.18 | - | | | | - | TZID | Current | RFC 5545, Section 3.2.19 | - | | | | - | VALUE | Current | RFC 5545, Section 3.2.20 | - +----------------+---------+--------------------------+ - -8.3.4. Value Data Types Registry - - The following table has been used to initialize the value data types - registry. - - +-----------------+---------+--------------------------+ - | Value Data Type | Status | Reference | - +-----------------+---------+--------------------------+ - | BINARY | Current | RFC 5545, Section 3.3.1 | - | | | | - | BOOLEAN | Current | RFC 5545, Section 3.3.2 | - | | | | - | CAL-ADDRESS | Current | RFC 5545, Section 3.3.3 | - | | | | - | DATE | Current | RFC 5545, Section 3.3.4 | - | | | | - | DATE-TIME | Current | RFC 5545, Section 3.3.5 | - | | | | - | DURATION | Current | RFC 5545, Section 3.3.6 | - | | | | - | FLOAT | Current | RFC 5545, Section 3.3.7 | - | | | | - | INTEGER | Current | RFC 5545, Section 3.3.8 | - | | | | - | PERIOD | Current | RFC 5545, Section 3.3.9 | - | | | | - | RECUR | Current | RFC 5545, Section 3.3.10 | - | | | | - | TEXT | Current | RFC 5545, Section 3.3.11 | - | | | | - | TIME | Current | RFC 5545, Section 3.3.12 | - | | | | - | URI | Current | RFC 5545, Section 3.3.13 | - | | | | - | UTC-OFFSET | Current | RFC 5545, Section 3.3.14 | - +-----------------+---------+--------------------------+ - - - - - - - - -Desruisseaux Standards Track [Page 159] - -RFC 5545 iCalendar September 2009 - - -8.3.5. Calendar User Types Registry - - The following table has been used to initialize the calendar user - types registry. - - +--------------------+---------+-------------------------+ - | Calendar User Type | Status | Reference | - +--------------------+---------+-------------------------+ - | INDIVIDUAL | Current | RFC 5545, Section 3.2.3 | - | | | | - | GROUP | Current | RFC 5545, Section 3.2.3 | - | | | | - | RESOURCE | Current | RFC 5545, Section 3.2.3 | - | | | | - | ROOM | Current | RFC 5545, Section 3.2.3 | - | | | | - | UNKNOWN | Current | RFC 5545, Section 3.2.3 | - +--------------------+---------+-------------------------+ - -8.3.6. Free/Busy Time Types Registry - - The following table has been used to initialize the free/busy time - types registry. - - +---------------------+---------+-------------------------+ - | Free/Busy Time Type | Status | Reference | - +---------------------+---------+-------------------------+ - | FREE | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY-UNAVAILABLE | Current | RFC 5545, Section 3.2.9 | - | | | | - | BUSY-TENTATIVE | Current | RFC 5545, Section 3.2.9 | - +---------------------+---------+-------------------------+ - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 160] - -RFC 5545 iCalendar September 2009 - - -8.3.7. Participation Statuses Registry - - The following table has been used to initialize the participation - statuses registry. - - +--------------------+---------+--------------------------+ - | Participant Status | Status | Reference | - +--------------------+---------+--------------------------+ - | NEEDS-ACTION | Current | RFC 5545, Section 3.2.12 | - | | | | - | ACCEPTED | Current | RFC 5545, Section 3.2.12 | - | | | | - | DECLINED | Current | RFC 5545, Section 3.2.12 | - | | | | - | TENTATIVE | Current | RFC 5545, Section 3.2.12 | - | | | | - | DELEGATED | Current | RFC 5545, Section 3.2.12 | - | | | | - | COMPLETED | Current | RFC 5545, Section 3.2.12 | - | | | | - | IN-PROCESS | Current | RFC 5545, Section 3.2.12 | - +--------------------+---------+--------------------------+ - -8.3.8. Relationship Types Registry - - The following table has been used to initialize the relationship - types registry. - - +-------------------+---------+--------------------------+ - | Relationship Type | Status | Reference | - +-------------------+---------+--------------------------+ - | CHILD | Current | RFC 5545, Section 3.2.15 | - | | | | - | PARENT | Current | RFC 5545, Section 3.2.15 | - | | | | - | SIBLING | Current | RFC 5545, Section 3.2.15 | - +-------------------+---------+--------------------------+ - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 161] - -RFC 5545 iCalendar September 2009 - - -8.3.9. Participation Roles Registry - - The following table has been used to initialize the participation - roles registry. - - +-----------------+---------+--------------------------+ - | Role Type | Status | Reference | - +-----------------+---------+--------------------------+ - | CHAIR | Current | RFC 5545, Section 3.2.16 | - | | | | - | REQ-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - | | | | - | OPT-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - | | | | - | NON-PARTICIPANT | Current | RFC 5545, Section 3.2.16 | - +-----------------+---------+--------------------------+ - -8.3.10. Actions Registry - - The following table has been used to initialize the actions registry. - - +-----------+------------+----------------------------+ - | Action | Status | Reference | - +-----------+------------+----------------------------+ - | AUDIO | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | DISPLAY | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | EMAIL | Current | RFC 5545, Section 3.8.6.1 | - | | | | - | PROCEDURE | Deprecated | [RFC2445], Section 4.8.6.1 | - +-----------+------------+----------------------------+ - -8.3.11. Classifications Registry - - The following table has been used to initialize the classifications - registry. - - +----------------+---------+---------------------------+ - | Classification | Status | Reference | - +----------------+---------+---------------------------+ - | PUBLIC | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | PRIVATE | Current | RFC 5545, Section 3.8.1.3 | - | | | | - | CONFIDENTIAL | Current | RFC 5545, Section 3.8.1.3 | - +----------------+---------+---------------------------+ - - - - -Desruisseaux Standards Track [Page 162] - -RFC 5545 iCalendar September 2009 - - -8.3.12. Methods Registry - - No values are defined in this document for the "METHOD" property. - -9. Acknowledgments - - The editor of this document wishes to thank Frank Dawson and Derik - Stenerson, the original authors of RFC 2445, as well as the following - individuals who have participated in the drafting, review, and - discussion of this memo: - - Joe Abley, Hervey Allen, Steve Allen, Jay Batson, Oliver Block, - Stephane Bortzmeyer, Chris Bryant, Tantek Celik, Mark Crispin, Cyrus - Daboo, Mike Douglass, Andrew N. Dowden, Lisa Dusseault, Lars Eggert, - Gren Eliot, Pasi Eronen, Ben Fortuna, Ned Freed, Neal Gafter, Ted - Hardie, Tim Hare, Jeffrey Harris, Helge Hess, Paul B. Hill, Thomas - Hnetila, Russ Housley, Leif Johansson, Ciny Joy, Bruce Kahn, Reinhold - Kainhofer, Martin Kiff, Patrice Lapierre, Michiel van Leeuwen, - Jonathan Lennox, Jeff McCullough, Bill McQuillan, Alexey Melnikov, - John W. Noerenberg II, Chuck Norris, Mark Paterson, Simon Pilette, - Arnaud Quillaud, Robert Ransdell, Julian F. Reschke, Caleb - Richardson, Sam Roberts, Dan Romascanu, Mike Samuel, George Sexton, - Nigel Swinson, Clint Talbert, Simon Vaillancourt, Magnus Westerlund, - and Sandy Wills. - - A special thanks to the working group chairs Aki Niemi and Eliot Lear - for their support and guidance. - - The editor would also like to thank the Calendaring and Scheduling - Consortium for advice with this specification, and for organizing - interoperability testing events to help refine it. - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 163] - -RFC 5545 iCalendar September 2009 - - -10. References - -10.1. Normative References - - [ISO.8601.2004] International Organization for - Standardization, "Data elements and - interchange formats -- Information interchange - -- Representation of dates and times", 2004. - - [ISO.9070.1991] International Organization for - Standardization, "Information Technology_SGML - Support Facilities -- Registration Procedures - for Public Text Owner Identifiers, Second - Edition", April 1991. - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose - Internet Mail Extensions (MIME) Part One: - Format of Internet Message Bodies", RFC 2045, - November 1996. - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose - Internet Mail Extensions (MIME) Part Two: - Media Types", RFC 2046, November 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to - Indicate Requirement Levels", BCP 14, - RFC 2119, March 1997. - - [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, - "The mailto URL scheme", RFC 2368, July 1998. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format - of ISO 10646", STD 63, RFC 3629, - November 2003. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. - Masinter, "Uniform Resource Identifier (URI): - Generic Syntax", STD 66, RFC 3986, - January 2005. - - [RFC4288] Freed, N. and J. Klensin, "Media Type - Specifications and Registration Procedures", - BCP 13, RFC 4288, December 2005. - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 - Data Encodings", RFC 4648, October 2006. - - - - - -Desruisseaux Standards Track [Page 164] - -RFC 5545 iCalendar September 2009 - - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", STD 68, - RFC 5234, January 2008. - - [RFC5646] Phillips, A., Ed., and M. Davis, Ed., "Tags - for Identifying Languages", BCP 47, RFC 5646, - September 2009. - - [US-ASCII] American National Standards Institute, "Coded - Character Set - 7-bit American Standard Code - for Information Interchange", ANSI X3.4, 1986. - -10.2. Informative References - - [2446bis] Daboo, C., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", Work - in Progress, April 2009. - - [2447bis] Melnikov, A., "iCalendar Message-Based - Interoperability Protocol (iMIP)", Work - in Progress, June 2008. - - [ANSI INCITS 61-1986] International Committee for Information - Technology, "Representation of Geographic - Point Locations for Information Interchange - (formerly ANSI X3.61-1986 (R1997))", ANSI - INCITS 61-1986 (R2007), 2007. - - [RFC1738] Berners-Lee, T., Masinter, L., and M. - McCahill, "Uniform Resource Locators (URL)", - RFC 1738, December 1994. - - [RFC2392] Levinson, E., "Content-ID and Message-ID - Uniform Resource Locators", RFC 2392, - August 1998. - - [RFC2397] Masinter, L., "The "data" URL scheme", - RFC 2397, August 1998. - - [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME - Content-Type for Directory Information", - RFC 2425, September 1998. - - [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory - Profile", RFC 2426, September 1998. - - - - - - -Desruisseaux Standards Track [Page 165] - -RFC 5545 iCalendar September 2009 - - - [RFC2445] Dawson, F. and Stenerson, D., "Internet - Calendaring and Scheduling Core Object - Specification (iCalendar)", RFC 2445, - November 1998. - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, - H., Masinter, L., Leach, P., and T. Berners- - Lee, "Hypertext Transfer Protocol -- - HTTP/1.1", RFC 2616, June 1999. - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - May 2000. - - [RFC4516] Smith, M. and T. Howes, "Lightweight Directory - Access Protocol (LDAP): Uniform Resource - Locator", RFC 4516, June 2006. - - [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, - "Calendaring Extensions to WebDAV (CalDAV)", - RFC 4791, March 2007. - - [TZDB] Eggert, P. and A.D. Olson, "Sources for Time - Zone and Daylight Saving Time Data", - July 2009, - . - - [VCAL] Internet Mail Consortium, "vCalendar: The - Electronic Calendaring and Scheduling Exchange - Format", September 1996, - . - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 166] - -RFC 5545 iCalendar September 2009 - - -Appendix A. Differences from RFC 2445 - - This appendix contains a list of changes that have been made in the - Internet Calendaring and Scheduling Core Object Specification from - RFC 2445. - -A.1. New Restrictions - - 1. The "DTSTART" property SHOULD be synchronized with the recurrence - rule, if specified. - - 2. The "RRULE" property SHOULD NOT occur more than once in a - component. - - 3. The BYHOUR, BYMINUTE, and BYSECOND rule parts MUST NOT be - specified in the "RRULE" property when the "DTSTART" property is - specified as a DATE value. - - 4. The value type of the "DTEND" or "DUE" properties MUST match the - value type of "DTSTART" property. - - 5. The "DURATION" property can no longer appear in "VFREEBUSY" - components. - -A.2. Restrictions Removed - - 1. The "DTSTART" and "DTEND" properties are no longer required to be - specified as date with local time and time zone reference when - used with a recurrence rule. - -A.3. Deprecated Features - - 1. The "EXRULE" property can no longer be specified in a component. - - 2. The "THISANDPRIOR" value can no longer be used with the "RANGE" - parameter. - - 3. The "PROCEDURE" value can no longer be used with the "ACTION" - property. - - 4. The value type RECUR no longer allows multiple values to be - specified by a COMMA-separated list of values. - - 5. x-name rule parts can no longer be specified in properties of - RECUR value type (e.g., "RRULE"). x-param can be used on RECUR - value type properties instead. - - - - - -Desruisseaux Standards Track [Page 167] - -RFC 5545 iCalendar September 2009 - - -Author's Address - - Bernard Desruisseaux (editor) - Oracle Corporation - 600 blvd. de Maisonneuve West - Suite 1900 - Montreal, QC H3A 3J2 - CANADA - - EMail: bernard.desruisseaux@oracle.com - URI: http://www.oracle.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Desruisseaux Standards Track [Page 168] - diff --git a/specifications/calendar/rfc5546.txt b/specifications/calendar/rfc5546.txt deleted file mode 100644 index 80361d81..00000000 --- a/specifications/calendar/rfc5546.txt +++ /dev/null @@ -1,7451 +0,0 @@ - - - - - - -Network Working Group C. Daboo, Ed. -Request for Comments: 5546 Apple Inc. -Obsoletes: 2446 December 2009 -Updates: 5545 -Category: Standards Track - - - iCalendar Transport-Independent Interoperability Protocol (iTIP) - -Abstract - - This document specifies a protocol that uses the iCalendar object - specification to provide scheduling interoperability between - different calendaring systems. This is done without reference to a - specific transport protocol so as to allow multiple methods of - communication between systems. Subsequent documents will define - profiles of this protocol that use specific, interoperable methods of - communication between systems. - - The iCalendar Transport-Independent Interoperability Protocol (iTIP) - complements the iCalendar object specification by adding semantics - for group scheduling methods commonly available in current - calendaring systems. These scheduling methods permit two or more - calendaring systems to perform transactions such as publishing, - scheduling, rescheduling, responding to scheduling requests, - negotiating changes, or canceling. - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - - - - - -Daboo Standards Track [Page 1] - -RFC 5546 iTIP December 2009 - - - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction and Overview .......................................5 - 1.1. Formatting Conventions .....................................5 - 1.2. Related Documents ..........................................6 - 1.3. Roles ......................................................6 - 1.4. Methods ....................................................7 - 2. Interoperability Models .........................................9 - 2.1. Application Protocol ......................................10 - 2.1.1. Scheduling State ...................................10 - 2.1.2. Delegation .........................................10 - 2.1.3. Acting on Behalf of Other Calendar Users ...........11 - 2.1.4. Component Revisions ................................11 - 2.1.5. Message Sequencing .................................12 - 3. Application Protocol Elements ..................................13 - 3.1. Common Component Restriction Tables .......................15 - 3.1.1. VCALENDAR ..........................................15 - 3.1.2. VTIMEZONE ..........................................15 - 3.1.3. VALARM .............................................17 - 3.2. Methods for VEVENT Calendar Components ....................17 - 3.2.1. PUBLISH ............................................18 - 3.2.2. REQUEST ............................................20 - 3.2.3. REPLY ..............................................25 - 3.2.4. ADD ................................................27 - 3.2.5. CANCEL .............................................29 - 3.2.6. REFRESH ............................................31 - 3.2.7. COUNTER ............................................33 - 3.2.8. DECLINECOUNTER .....................................35 - 3.3. Methods for VFREEBUSY Components ..........................37 - 3.3.1. PUBLISH ............................................37 - 3.3.2. REQUEST ............................................40 - 3.3.3. REPLY ..............................................42 - - - -Daboo Standards Track [Page 2] - -RFC 5546 iTIP December 2009 - - - 3.4. Methods for VTODO Components ..............................44 - 3.4.1. PUBLISH ............................................44 - 3.4.2. REQUEST ............................................46 - 3.4.3. REPLY ..............................................51 - 3.4.4. ADD ................................................53 - 3.4.5. CANCEL .............................................55 - 3.4.6. REFRESH ............................................57 - 3.4.7. COUNTER ............................................59 - 3.4.8. DECLINECOUNTER .....................................61 - 3.5. Methods for VJOURNAL Components ...........................62 - 3.5.1. PUBLISH ............................................63 - 3.5.2. ADD ................................................64 - 3.5.3. CANCEL .............................................66 - 3.6. Status Replies ............................................68 - 3.7. Implementation Considerations .............................77 - 3.7.1. Working With Recurrence Instances ..................77 - 3.7.2. Attendee Property Considerations ...................78 - 3.7.3. Extension Tokens ...................................79 - 4. Examples .......................................................79 - 4.1. Published Event Examples ..................................79 - 4.1.1. A Minimal Published Event ..........................80 - 4.1.2. Changing a Published Event .........................80 - 4.1.3. Canceling a Published Event ........................81 - 4.1.4. A Rich Published Event .............................81 - 4.1.5. Anniversaries or Events Attached to Entire Days ....83 - 4.2. Group Event Examples ......................................83 - 4.2.1. A Group Event Request ..............................84 - 4.2.2. Reply to a Group Event Request .....................85 - 4.2.3. Update an Event ....................................85 - 4.2.4. Countering an Event Proposal .......................86 - 4.2.5. Delegating an Event ................................88 - 4.2.6. Delegate Accepts the Meeting .......................90 - 4.2.7. Delegate Declines the Meeting ......................91 - 4.2.8. Forwarding an Event Request ........................92 - 4.2.9. Cancel a Group Event ...............................92 - 4.2.10. Removing Attendees ................................93 - 4.2.11. Replacing the Organizer ...........................95 - 4.3. Busy Time Examples ........................................96 - 4.3.1. Publish Busy Time ..................................96 - 4.3.2. Request Busy Time ..................................96 - 4.3.3. Reply to a Busy Time Request .......................97 - 4.4. Recurring Event and Time Zone Examples ....................98 - 4.4.1. A Recurring Event Spanning Time Zones ..............98 - 4.4.2. Modify a Recurring Instance ........................99 - 4.4.3. Cancel an Instance ................................101 - 4.4.4. Cancel a Recurring Event ..........................101 - 4.4.5. Change All Future Instances .......................102 - 4.4.6. Add a New Instance to a Recurring Event ...........102 - - - -Daboo Standards Track [Page 3] - -RFC 5546 iTIP December 2009 - - - 4.4.7. Add a New Series of Instances to a - Recurring Event ...................................103 - 4.4.8. Refreshing a Recurring Event ......................104 - 4.4.9. Counter an Instance of a Recurring Event ..........106 - 4.4.10. Error Reply to a Request .........................107 - 4.5. Group To-Do Examples .....................................108 - 4.5.1. A VTODO Request ...................................109 - 4.5.2. A VTODO Reply .....................................110 - 4.5.3. A VTODO Request for Updated Status ................110 - 4.5.4. A Reply: Percent-Complete .........................111 - 4.5.5. A Reply: Completed ................................111 - 4.5.6. An Updated VTODO Request ..........................112 - 4.5.7. Recurring VTODOs ..................................112 - 4.6. Journal Examples .........................................113 - 4.7. Other Examples ...........................................114 - 4.7.1. Event Refresh .....................................114 - 4.7.2. Bad RECURRENCE-ID .................................114 - 5. Application Protocol Fallbacks ................................116 - 5.1. Partial Implementation ...................................116 - 5.1.1. Event-Related Fallbacks ...........................117 - 5.1.2. Free/Busy-Related Fallbacks .......................119 - 5.1.3. To-Do-Related Fallbacks ...........................120 - 5.1.4. Journal-Related Fallbacks .........................122 - 5.2. Latency Issues ...........................................123 - 5.2.1. Cancellation of an Unknown Calendar Component .....123 - 5.2.2. Unexpected Reply from an Unknown Delegate .........124 - 5.3. Sequence Number ..........................................124 - 6. Security Considerations .......................................124 - 6.1. Security Threats .........................................124 - 6.1.1. Spoofing the Organizer ............................124 - 6.1.2. Spoofing the Attendee .............................124 - 6.1.3. Unauthorized Replacement of the Organizer .........125 - 6.1.4. Eavesdropping and Data Integrity ..................125 - 6.1.5. Flooding a Calendar ...............................125 - 6.1.6. Unauthorized REFRESH Requests .....................125 - 6.2. Recommendations ..........................................125 - 6.2.1. Securing iTIP transactions ........................125 - 6.2.2. Implementation Controls ...........................126 - 6.2.3. Access Controls and Filtering .....................126 - 6.3. Privacy Issues ...........................................126 - 7. IANA Considerations ...........................................127 - 7.1. Registration Template for REQUEST-STATUS Values ..........127 - 7.2. Additions to iCalendar METHOD Registry ...................127 - 7.3. REQUEST-STATUS Value Registry ............................129 - 8. Acknowledgments ...............................................130 - 9. References ....................................................131 - 9.1. Normative References .....................................131 - 9.2. Informative References ...................................131 - - - -Daboo Standards Track [Page 4] - -RFC 5546 iTIP December 2009 - - - Appendix A. Differences from RFC 2446 ...........................132 - A.1. Changed Restrictions .....................................132 - A.2. Deprecated Features ......................................133 - -1. Introduction and Overview - - This document specifies how calendaring systems use iCalendar - [RFC5545] objects to interoperate with other calendaring systems. In - particular, it specifies how to schedule events, to-dos, or daily - journal entries. It further specifies how to search for available - busy time information. It does so in a general way, without - specifying how communication between different systems actually takes - place. Subsequent documents will specify transport bindings between - systems that use this protocol. - - This protocol is based on messages sent from an originator to one or - more recipients. For certain types of messages, a recipient may - reply in order to update their status and may also return - transaction/request status information. The protocol supports the - ability for the message originator to modify or cancel the original - message. The protocol also supports the ability for recipients to - suggest changes to the originator of a message. The elements of the - protocol also define the user roles for its transactions. - - This specification obsoletes RFC 2446 - a list of important changes - is provided in Appendix A. - -1.1. Formatting Conventions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Calendaring and scheduling roles are referred to in quoted-strings of - text with the first character of each word in upper case. For - example, "Organizer" refers to a role of a "Calendar User" (CU) - within the scheduling protocol. - - Calendar components defined by [RFC5545] are referred to with - capitalized, quoted-strings of text. All calendar components start - with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component, - and "VJOURNAL" refers to the daily journal calendar component. - - - - - - - - -Daboo Standards Track [Page 5] - -RFC 5546 iTIP December 2009 - - - Scheduling methods are referred to with capitalized, quoted-strings - of text. For example, "REQUEST" refers to the method for requesting - a scheduling calendar component be created or modified; "REPLY" - refers to the method a recipient of a request uses to update their - status with the "Organizer" of the calendar component. - - Properties defined by [RFC5545] are referred to with capitalized, - quoted-strings of text, followed by the word "property". For - example, "ATTENDEE" property refers to the iCalendar property used to - convey the calendar address of a "Calendar User". - - Property parameters defined by this specification are referred to - with capitalized, quoted-strings of text, followed by the word - "parameter". For example, "VALUE" parameter refers to the iCalendar - property parameter used to override the default data type for a - property value. - - Enumerated values defined by this specification are referred to with - capitalized text, either alone or followed by the word "value". - - In tables, the quoted-string text is specified without quotes in - order to minimize the table length. - -1.2. Related Documents - - Implementers will need to be familiar with several other - specifications that, along with this one, describe the Internet - calendaring and scheduling standards. The related documents are: - - [RFC5545] - specifies the objects, data types, properties, and - property parameters used in the protocols, along with the methods - for representing and encoding them. - - [iMIP] - specifies an Internet email binding for iTIP. - - This specification does not attempt to repeat the concepts or - definitions from these other specifications. Where possible, - explicit references are made to the other specifications. - -1.3. Roles - - Exchanges of iCalendar objects for the purposes of group calendaring - and scheduling occur between "Calendar Users" (CUs). CUs take on - several roles in iTIP: - - - - - - - -Daboo Standards Track [Page 6] - -RFC 5546 iTIP December 2009 - - - +-----------+-------------------------------------------------------+ - | Role | Description | - +-----------+-------------------------------------------------------+ - | Organizer | The CU who initiates an exchange takes on the role of | - | | Organizer. For example, the CU who proposes a group | - | | meeting is the Organizer. | - | | | - | Attendee | CUs who are included in the scheduling message as | - | | possible recipients of that scheduling message. For | - | | example, the CUs asked to participate in a group | - | | meeting by the Organizer take on the role of | - | | Attendee. | - | | | - | Other CU | A CU that is not explicitly included in a scheduling | - | | message, i.e., not the Organizer or an Attendee. | - +-----------+-------------------------------------------------------+ - - Note that "ROLE" is also a descriptive parameter to the iCalendar - "ATTENDEE" property. Its use is to convey descriptive context about - an "Attendee" -- such as "chair", "required participant", or "non- - required participant" -- and has nothing to do with the calendaring - workflow. - -1.4. Methods - - The iTIP methods are listed below and their usage and semantics are - defined in Section 3 of this document. - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 7] - -RFC 5546 iTIP December 2009 - - - +----------------+--------------------------------------------------+ - | Method | Description | - +----------------+--------------------------------------------------+ - | PUBLISH | Used to publish an iCalendar object to one or | - | | more "Calendar Users". There is no | - | | interactivity between the publisher and any | - | | other "Calendar User". An example might include | - | | a baseball team publishing its schedule to the | - | | public. | - | | | - | REQUEST | Used to schedule an iCalendar object with other | - | | "Calendar Users". Requests are interactive in | - | | that they require the receiver to respond using | - | | the reply methods. Meeting requests, busy-time | - | | requests, and the assignment of tasks to other | - | | "Calendar Users" are all examples. Requests are | - | | also used by the Organizer to update the status | - | | of an iCalendar object. | - | | | - | REPLY | A reply is used in response to a request to | - | | convey Attendee status to the Organizer. | - | | Replies are commonly used to respond to meeting | - | | and task requests. | - | | | - | ADD | Add one or more new instances to an existing | - | | recurring iCalendar object. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | iCalendar object. | - | | | - | REFRESH | Used by an Attendee to request the latest | - | | version of an iCalendar object. | - | | | - | COUNTER | Used by an Attendee to negotiate a change in an | - | | iCalendar object. Examples include the request | - | | to change a proposed event time or change the | - | | due date for a task. | - | | | - | DECLINECOUNTER | Used by the Organizer to decline the proposed | - | | counter proposal. | - +----------------+--------------------------------------------------+ - - - - - - - - - - -Daboo Standards Track [Page 8] - -RFC 5546 iTIP December 2009 - - - Group scheduling in iTIP is accomplished using the set of "request" - and "response" methods described above. The following table shows - the methods broken down by who can send them. - - +------------+------------------------------------------------------+ - | Originator | Methods | - +------------+------------------------------------------------------+ - | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | - | | | - | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when | - | | delegating) | - +------------+------------------------------------------------------+ - - Note that for some calendar component types, the allowable methods - are a subset of the above set. In addition, apart from "VTIMEZONE" - iCalendar components, only one component type is allowed in a single - iTIP message. - -2. Interoperability Models - - There are two distinct protocols relevant to interoperability: an - "application protocol" and a "transport protocol". The application - protocol defines the content of the iCalendar objects sent between - sender and receiver to accomplish the scheduling transactions listed - above. The transport protocol defines how the iCalendar objects are - sent between the sender and receiver. This document focuses on the - application protocol. Binding documents such as [iMIP] focus on the - transport protocol. - - The connection between sender and receiver in the diagram below - refers to the application protocol. The iCalendar objects passed - from the sender to the receiver are presented in Section 3, - "Application Protocol Elements". - - +----------+ +----------+ - | | iTIP | | - | Sender |<-------------->| Receiver | - | | | | - +----------+ +----------+ - - There are several variations of this diagram in which the sender and - receiver take on various roles of a "Calendar User Agent" (CUA) or a - "Calendar Service" (CS). - - The architecture of iTIP is depicted in the diagram below. An - application written to this specification may work with bindings for - the store-and-forward transport, the real-time transport, or both. - Also note that iTIP could be bound to other transports. - - - -Daboo Standards Track [Page 9] - -RFC 5546 iTIP December 2009 - - - +--------------------------------------------------------+ - | iTIP Protocol | - +--------------------------------------------------------+ - | Transport | - + - - - - - + - - - - - - + - - - - - + - | Real-Time | Store-and-Forward | Others | - +-----------------+--------------------+-----------------+ - -2.1. Application Protocol - - In the iTIP model, an iCalendar object is created and managed by an - "Organizer". The "Organizer" interacts with other CUs by sending one - or more of the iTIP messages listed above. "Attendees" use the - "REPLY" method to communicate their status. "Attendees" do not make - direct changes to the master iCalendar object. They can, however, - use the "COUNTER" method to suggest changes to the "Organizer". In - any case, the "Organizer" has complete control over the master - iCalendar object. - -2.1.1. Scheduling State - - There are two distinct states relevant to iCalendar objects used in - scheduling: the overall state of the iCalendar object and the state - associated with an "Attendee" in that iCalendar object. - - The state of an iCalendar object is defined by the "STATUS" property - and is controlled by the "Organizer." There is no default value for - the "STATUS" property. The "Organizer" sets the "STATUS" property to - the appropriate value for each iCalendar object. - - The state of a particular "Attendee" relative to an iCalendar object - used for scheduling is defined by the "PARTSTAT" parameter in the - "ATTENDEE" property for each "Attendee". When an "Organizer" issues - the initial iCalendar object, "Attendee" status is typically unknown. - The "Organizer" specifies this by setting the "PARTSTAT" parameter to - "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property - "PARTSTAT" parameter to an appropriate value as part of a "REPLY" - message sent back to the "Organizer". - -2.1.2. Delegation - - Delegation is defined as the process by which an "Attendee" grants - another CU (or several CUs) the right to attend on their behalf. The - "Organizer" is made aware of this change because the delegating - "Attendee" informs the "Organizer". These steps are detailed in the - "REQUEST" method sections for the appropriate components. - - - - - -Daboo Standards Track [Page 10] - -RFC 5546 iTIP December 2009 - - -2.1.3. Acting on Behalf of Other Calendar Users - - In many organizations, one user will act on behalf of another to - organize and/or respond to meeting requests. iTIP provides two - mechanisms that support these activities. - - First, the "Organizer" is treated as a special entity, separate from - "Attendees". All responses from "Attendees" flow to the "Organizer", - making it easy to separate a "Calendar User" organizing a meeting - from "Calendar Users" attending the meeting. Additionally, iCalendar - provides descriptive roles for each "Attendee". For instance, a role - of "chair" may be ascribed to one or more "Attendees". The "chair" - and the "Organizer" may or may not be the same "Calendar User". This - maps well to scenarios where an assistant may manage meeting - logistics for another individual who chairs a meeting. - - Second, a "SENT-BY" parameter may be specified in either the - "Organizer" or "Attendee" properties. When specified, the "SENT-BY" - parameter indicates that the responding CU acted on behalf of the - specified "Attendee" or "Organizer". - -2.1.4. Component Revisions - - The "SEQUENCE" property is used by the "Organizer" to indicate - revisions to the calendar component. When the "Organizer" makes - changes to one of the following properties, the sequence number MUST - be incremented: - - o "DTSTART" - - o "DTEND" - - o "DURATION" - - o "DUE" - - o "RRULE" - - o "RDATE" - - o "EXDATE" - - o "STATUS" - - In addition, changes made by the "Organizer" to other properties MAY - also require the sequence number to be incremented. The "Organizer" - CUA MUST increment the sequence number whenever it makes changes to - properties in the calendar component that the "Organizer" deems will - - - -Daboo Standards Track [Page 11] - -RFC 5546 iTIP December 2009 - - - jeopardize the validity of the participation status of the - "Attendees". For example, changing the location of a meeting from - one location to another distant location could effectively impact the - participation status of the "Attendees". - - Depending on the "METHOD", the "SEQUENCE" property MUST follow these - rules in the context of iTIP: - - o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property - value is incremented according to the rules stated above. - - o The "SEQUENCE" property value MUST be incremented each time the - "Organizer" uses the "ADD" or "CANCEL" methods. - - o The "SEQUENCE" property value MUST NOT be incremented when using - "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a - delegation "REQUEST". - - In some circumstances, the "Organizer" may not have received - responses to the final revision sent out. In this situation, the - "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE" - for all "Attendees" so that current responses can be collected. - - The value of the "SEQUENCE" property contained in a response from an - "Attendee" may not always match the "Organizer's" revision. - Implementations may choose to have the CUA indicate to the CU that - the response is to an iCalendar object that has been revised, and - allow the CU to decide whether or not to accept the response. - - Whilst a change in sequence number is indicative of a significant - change to a previously scheduled item, "Attendee" CUAs SHOULD NOT - rely solely on a change in sequence number as a means of detecting a - significant change. Instead, CUAs SHOULD compare the old and new - versions of the calendar components, determine the exact nature of - the changes, and make decisions -- possibly based on "Calendar User" - preferences -- as to whether the user needs to be explicitly informed - of the change. - -2.1.5. Message Sequencing - - CUAs that handle the iTIP application protocol must often correlate a - component in a calendar store with a component received in the iTIP - message. For example, an event may be updated with a later revision - of the same event. To accomplish this, a CUA must correlate the - version of the event already in its calendar store with the version - sent in the iTIP message. In addition to this correlation, there are - several factors that can cause iTIP messages to arrive in an - unexpected order. That is, an "Organizer" could receive a reply to - - - -Daboo Standards Track [Page 12] - -RFC 5546 iTIP December 2009 - - - an earlier revision of a component after receiving a reply to a later - revision. - - To maximize interoperability and to handle messages that arrive in an - unexpected order, use the following rules: - - 1. The primary key for referencing a particular iCalendar component - is the "UID" property value. To reference an instance of a - recurring component, the primary key is composed of the "UID" and - the "RECURRENCE-ID" properties. - - 2. The secondary key for referencing a component is the "SEQUENCE" - property value. For components where the "UID" and - "RECURRENCE-ID" property values are the same, the component with - the highest numeric value for the "SEQUENCE" property obsoletes - all other revisions of the component with lower values. - - 3. "Attendees" send "REPLY" messages to the "Organizer". For - replies where the "UID" and "RECURRENCE-ID" property values are - the same, the value of the "SEQUENCE" property indicates the - revision of the component to which the "Attendee" is replying. - The reply with the highest numeric value for the "SEQUENCE" - property obsoletes all other replies with lower values. - - 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE" - property values match, the "DTSTAMP" property is used as the tie- - breaker. The component with the latest "DTSTAMP" overrides all - others. Similarly, for "Attendee" responses where the "UID", - "RECURRENCE-ID", and "SEQUENCE" property values match, the - response with the latest "DTSTAMP" overrides all others. - - Hence, CUAs will need to persist the following component properties - in order to correctly process iTIP messages: "UID", "RECURRENCE-ID", - "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property - of a component, "Organizer" CUAs will need to persist the "SEQUENCE" - and "DTSTAMP" property values associated with the "Attendee's" last - response, so that any earlier responses from an "Attendee" that are - received out of order (e.g., due to a delay in the transport) can be - correctly discarded. - -3. Application Protocol Elements - - iTIP messages are "text/calendar" MIME entities that contain - calendaring and scheduling information. The particular type of - iCalendar message is referred to as the "method type". Each method - type is identified by a "METHOD" property specified as part of the - "text/calendar" content type. The table below shows various - - - - -Daboo Standards Track [Page 13] - -RFC 5546 iTIP December 2009 - - - combinations of calendar components and the method types that this - specification supports. - - +----------------+--------+-------+----------+-----------+ - | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | - +----------------+--------+-------+----------+-----------+ - | PUBLISH | Yes | Yes | Yes | Yes | - | REQUEST | Yes | Yes | No | Yes | - | REFRESH | Yes | Yes | No | No | - | CANCEL | Yes | Yes | Yes | No | - | ADD | Yes | Yes | Yes | No | - | REPLY | Yes | Yes | No | Yes | - | COUNTER | Yes | Yes | No | No | - | DECLINECOUNTER | Yes | Yes | No | No | - +----------------+--------+-------+----------+-----------+ - - Each method type is defined in terms of its associated components and - properties. Some components and properties are required, some are - optional, and others are excluded. The restrictions are expressed in - this document using a simple "restriction table". The first column - indicates the name of a component or property. Properties of the - iCalendar object are not indented. Properties of a component are - indented. The second column (the "Presence" column) indicates - whether or not a component or property should be present and, if - present, how many times it can occur. The third column contains - comments for further clarification. - - The presence column uses the following values to assert whether a - property is required or optional, and the number of times it may - appear in the iCalendar object. - - +----------------+--------------------------------------------------+ - | Presence Value | Description | - +----------------+--------------------------------------------------+ - | 1 | One instance MUST be present. | - | 1+ | At least one instance MUST be present. | - | 0 | Instances of this property MUST NOT be present. | - | 0+ | Multiple instances MAY be present. | - | 0 or 1 | Up to 1 instance of this property MAY be | - | | present. | - +----------------+--------------------------------------------------+ - - The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA- - COMPONENT", and "X-COMPONENT" to show where registered and - experimental property and component extensions can appear. The - tables do not lay out the restrictions of property parameters. Those - restrictions are defined in [RFC5545]. - - - - -Daboo Standards Track [Page 14] - -RFC 5546 iTIP December 2009 - - -3.1. Common Component Restriction Tables - -3.1.1. VCALENDAR - - The restriction table below applies to properties of the iCalendar - object. That is, the properties at the outermost scope. - - +-----------------------------------------------------+ - | Constraints for Properties in a VCALENDAR Component | - +-----------------------------------------------------+ - - +--------------------+----------+--------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+--------------------+ - | CALSCALE | 0 or 1 | | - | PRODID | 1 | | - | VERSION | 1 | Value MUST be 2.0. | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - +--------------------+----------+--------------------+ - -3.1.2. VTIMEZONE - - "VTIMEZONE" components may be referred to by other components via a - "TZID" parameter on a "DATETIME" value type. The property - restrictions in the table below apply to any "VTIMEZONE" component in - an iTIP message. - - +--------------------------------------+ - | Constraints for VTIMEZONE Components | - +--------------------------------------+ - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 15] - -RFC 5546 iTIP December 2009 - - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to timezone. | - | DAYLIGHT | 0+ | MUST be one or more of either | - | | | STANDARD or DAYLIGHT. | - | COMMENT | 0+ | | - | DTSTART | 1 | MUST be local time format. | - | RDATE | 0+ | | - | RRULE | 0 or 1 | | - | TZNAME | 0+ | | - | TZOFFSETFROM | 1 | | - | TZOFFSETTO | 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | LAST-MODIFIED | 0 or 1 | | - | STANDARD | 0+ | MUST be one or more of either | - | | | STANDARD or DAYLIGHT. | - | COMMENT | 0+ | | - | DTSTART | 1 | MUST be local time format. | - | RDATE | 0+ | If present, RRULE MUST NOT be | - | | | present. | - | RRULE | 0 or 1 | If present, RDATE MUST NOT be | - | | | present. | - | TZNAME | 0+ | | - | TZOFFSETFROM | 1 | | - | TZOFFSETTO | 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | TZID | 1 | | - | TZURL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - +--------------------+----------+-----------------------------------+ - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 16] - -RFC 5546 iTIP December 2009 - - -3.1.3. VALARM - - The property restrictions in the table below apply to any "VALARM" - component in an iTIP message. - - +-----------------------------------+ - | Constraints for VALARM Components | - +-----------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | VALARM | 0+ | | - | ACTION | 1 | | - | ATTACH | 0+ | | - | ATTENDEE | 0+ | | - | DESCRIPTION | 0 or 1 | | - | DURATION | 0 or 1 | If present, REPEAT MUST be | - | | | present. | - | REPEAT | 0 or 1 | If present, DURATION MUST be | - | | | present. | - | SUMMARY | 0 or 1 | | - | TRIGGER | 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - +--------------------+----------+-----------------------------------+ - -3.2. Methods for VEVENT Calendar Components - - This section defines the property set restrictions for the method - types that are applicable to the "VEVENT" calendar component. Each - method is defined using a table that clarifies the property - constraints that define the particular method. - - The following summarizes the methods that are defined for the - "VEVENT" calendar component. - - - - - - - - - - - - - - - -Daboo Standards Track [Page 17] - -RFC 5546 iTIP December 2009 - - - +----------------+--------------------------------------------------+ - | Method | Description | - +----------------+--------------------------------------------------+ - | PUBLISH | Post notification of an event. Used primarily | - | | as a method of advertising the existence of an | - | | event. | - | | | - | REQUEST | Make a request for an event. This is an | - | | explicit invitation to one or more Attendees. | - | | Event requests are also used to update or change | - | | an existing event. Clients that cannot handle | - | | REQUEST MAY degrade the event to view it as a | - | | PUBLISH. | - | | | - | REPLY | Reply to an event request. Clients may set | - | | their status (PARTSTAT) to ACCEPTED, DECLINED, | - | | TENTATIVE, or DELEGATED. | - | | | - | ADD | Add one or more instances to an existing event. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | event. | - | | | - | REFRESH | A request is sent to an Organizer by an Attendee | - | | asking for the latest version of an event to be | - | | resent to the requester. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal. | - | | Sent by an Attendee to the Organizer. | - | | | - | DECLINECOUNTER | Decline a counter proposal. Sent to an Attendee | - | | by the Organizer. | - +----------------+--------------------------------------------------+ - -3.2.1. PUBLISH - - The "PUBLISH" method in a "VEVENT" calendar component is an - unsolicited posting of an iCalendar object. Any CU may add published - components to their calendar. The "Organizer" MUST be present in a - published iCalendar component. "Attendees" MUST NOT be present. Its - expected usage is for encapsulating an arbitrary event as an - iCalendar object. 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 "VEVENT" - calendar component. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - -Daboo Standards Track [Page 18] - -RFC 5546 iTIP December 2009 - - - +----------------------------------------------+ - | Constraints for a METHOD:PUBLISH of a VEVENT | - +----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST equal PUBLISH. | - | | | | - | VEVENT | 1+ | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | SUMMARY | 1 | Can be null. | - | UID | 1 | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | SEQUENCE | 0 or 1 | MUST be present if value is | - | | | greater than 0; MAY be present if | - | | | 0. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0 or 1 | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | TENTATIVE/CONFIRMED/CANCELLED. | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - - - -Daboo Standards Track [Page 19] - -RFC 5546 iTIP December 2009 - - - | ATTENDEE | 0 | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTODO | 0 | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - +--------------------+----------+-----------------------------------+ - -3.2.2. REQUEST - - The "REQUEST" method in a "VEVENT" component provides the following - scheduling functions: - - o Invite "Attendees" to an event. - - o Reschedule an existing event. - - o Response to a "REFRESH" request. - - o Update the details of an existing event, without rescheduling it. - - o Update the status of "Attendees" of an existing event, without - rescheduling it. - - o Reconfirm an existing event, without rescheduling it. - - o Forward a "VEVENT" to another uninvited CU. - - o For an existing "VEVENT" calendar component, delegate the role of - "Attendee" to another CU. - - o For an existing "VEVENT" calendar component, change the role of - "Organizer" to another CU. - - The "Organizer" originates the "REQUEST". The recipients of the - "REQUEST" method are the CUs invited to the event, the "Attendees". - "Attendees" use the "REPLY" method to convey attendance status to the - "Organizer". - - - -Daboo Standards Track [Page 20] - -RFC 5546 iTIP December 2009 - - - The "UID" and "SEQUENCE" properties are used to distinguish the - various uses of the "REQUEST" method. If the "UID" property value in - the "REQUEST" is not found on the recipient's calendar, then the - "REQUEST" is for a new "VEVENT" calendar component. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is for a rescheduling, an update, or a reconfirmation of - the "VEVENT" calendar component. - - For the "REQUEST" method, multiple "VEVENT" components in a single - iCalendar object are only permitted for components with the same - "UID" property. That is, a series of recurring events may have - instance-specific information. In this case, multiple "VEVENT" - components are needed to express the entire series. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +----------------------------------------------+ - | Constraints for a METHOD:REQUEST of a VEVENT | - +----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REQUEST. | - | | | | - | VEVENT | 1+ | All components MUST have the same | - | | | UID. | - | ATTENDEE | 1+ | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 0 or 1 | MUST be present if value is | - | | | greater than 0; MAY be present if | - | | | 0. | - | SUMMARY | 1 | Can be null. | - | UID | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - - - - - -Daboo Standards Track [Page 21] - -RFC 5546 iTIP December 2009 - - - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | REQUEST-STATUS | 0 | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | TENTATIVE/CONFIRMED. | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.2.1. Rescheduling an Event - - The "REQUEST" method may be used to reschedule an event. A - rescheduled event involves a change to the existing event in terms of - its time or recurrence intervals and possibly the location or - description. If the recipient CUA of a "REQUEST" method finds that - the "UID" property value already exists on the calendar but that the - "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is - greater than the value for the existing event, then the "REQUEST" - method describes a rescheduling of the event. - - - -Daboo Standards Track [Page 22] - -RFC 5546 iTIP December 2009 - - -3.2.2.2. Updating or Reconfirmation of an Event - - The "REQUEST" method may be used to update or reconfirm an event. An - update to an existing event does not involve changes to the time or - recurrence intervals, and might not involve a change to the location - or description for the event. If the recipient CUA of a "REQUEST" - method finds that the "UID" property value already exists on the - calendar and that the "SEQUENCE" property value in the "REQUEST" is - the same as the value for the existing event, then the "REQUEST" - method describes an update of the event details, but not a - rescheduling of the event. - - The update "REQUEST" method is the appropriate response to a - "REFRESH" method sent from an "Attendee" to the "Organizer" of an - event. - - The "Organizer" of an event may also send unsolicited "REQUEST" - methods. The unsolicited "REQUEST" methods may be used to update the - details of the event without rescheduling it, to update the - "PARTSTAT" parameter of "Attendees", or to reconfirm the event. - -3.2.2.3. Delegating an Event to Another CU - - Some calendar and scheduling systems allow "Attendees" to delegate - their presence at an event to another "Calendar User". iTIP supports - this concept using the following workflow. Any "Attendee" may - delegate their right to participate in a calendar "VEVENT" to another - CU. The implication is that the delegate participates in lieu of the - original "Attendee", NOT in addition to the "Attendee". The - delegator MUST notify the "Organizer" of this action using the steps - outlined below. Implementations may support or restrict delegation - as they see fit. For instance, some implementations may restrict a - delegate from delegating a "REQUEST" to another CU. - - The "Delegator" of an event forwards the existing "REQUEST" to the - "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property - with the calendar address of the "Delegate". The "Delegator" MUST - also send a "REPLY" method to the "Organizer" with the "Delegator's" - "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED". - In addition, the "DELEGATED-TO" parameter MUST be included with the - calendar address of the "Delegate". Also, a new "ATTENDEE" property - for the "Delegate" MUST be included and must specify the calendar - user address set in the "DELEGATED-TO" parameter, as above. - - In response to the request, the "Delegate" MUST send a "REPLY" method - to the "Organizer", and optionally to the "Delegator". The "REPLY" - method SHOULD include the "ATTENDEE" property with the "DELEGATED- - FROM" parameter value of the "Delegator's" calendar address. - - - -Daboo Standards Track [Page 23] - -RFC 5546 iTIP December 2009 - - - The "Delegator" may continue to receive updates to the event even - though they will not be attending. This is accomplished by the - "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in - the "REPLY" to the "Organizer". - -3.2.2.4. Changing the Organizer - - The situation may arise where the "Organizer" of a "VEVENT" is no - longer able to perform the "Organizer" role and abdicates without - passing on the "Organizer" role to someone else. When this occurs, - the "Attendees" of the "VEVENT" may use out-of-band mechanisms to - communicate the situation and agree upon a new "Organizer". The new - "Organizer" should then send out a new "REQUEST" with a modified - version of the "VEVENT" in which the "SEQUENCE" number has been - incremented and the "ORGANIZER" property has been changed to the new - "Organizer". - -3.2.2.5. Sending on Behalf of the Organizer - - There are a number of scenarios that support the need for a "Calendar - User" to act on behalf of the "Organizer" without explicit role - changing. This might be the case if the CU designated as "Organizer" - is sick or unable to perform duties associated with that function. - In these cases, iTIP supports the notion of one CU acting on behalf - of another. Using the "SENT-BY" parameter, a "Calendar User" could - send an updated "VEVENT" "REQUEST". In the case where one CU sends - on behalf of another CU, the "Attendee" responses are still directed - back towards the CU designated as "Organizer". - -3.2.2.6. Forwarding to an Uninvited CU - - An "Attendee" invited to a "VEVENT" calendar component may send the - "VEVENT" calendar component to another new CU not previously - associated with the "VEVENT" calendar component. The current - "Attendee" invited to the "VEVENT" calendar component does this by - forwarding the original "REQUEST" method to the new CU. The new CU - can send a "REPLY" to the "Organizer" of the "VEVENT" calendar - component. The reply contains an "ATTENDEE" property for the new CU. - - The "Organizer" ultimately decides whether or not the new CU becomes - part of the event and is not obligated to do anything with a "REPLY" - from a new (uninvited) CU. If the "Organizer" does not want the new - CU to be part of the event, the new "ATTENDEE" property is not added - to the "VEVENT" calendar component. The "Organizer" MAY send the CU - a "CANCEL" message to indicate that they will not be added to the - event. If the "Organizer" decides to add the new CU, the new - "ATTENDEE" property is added to the "VEVENT" calendar component. - Furthermore, the "Organizer" is free to change any "ATTENDEE" - - - -Daboo Standards Track [Page 24] - -RFC 5546 iTIP December 2009 - - - property parameter from the values supplied by the new CU to - something the "Organizer" considers appropriate. The "Organizer" - SHOULD send the new CU a "REQUEST" message to inform them that they - have been added. - - When forwarding a "REQUEST" to another CU, the forwarding "Attendee" - MUST NOT make changes to the original message. - -3.2.2.7. Updating Attendee Status - - The "Organizer" of an event may also request updated status from one - or more "Attendees". The "Organizer" sends a "REQUEST" method to the - "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The - "SEQUENCE" property for the event is not changed from its previous - value. A recipient will determine that the only change in the - "REQUEST" is that their "RSVP" property parameter indicates a request - for updated status. The recipient SHOULD respond with a "REPLY" - method indicating their current status with respect to the "REQUEST". - -3.2.3. REPLY - - The "REPLY" method in a "VEVENT" calendar component is used to - respond (e.g., accept or decline) to a "REQUEST" or to reply to a - delegation "REQUEST". When used to provide a delegation response, - the "Delegator" SHOULD include the calendar address of the "Delegate" - on the "DELEGATED-TO" property parameter of the "Delegator's" - "ATTENDEE" property. The "Delegate" SHOULD include the calendar - address of the "Delegator" on the "DELEGATED-FROM" property parameter - of the "Delegate's" "ATTENDEE" property. - - The "REPLY" method is also used when processing of a "REQUEST" fails. - Depending on the value of the "REQUEST-STATUS" property, no - scheduling action may have been performed. - - The "Organizer" of an event may receive the "REPLY" method from a CU - not in the original "REQUEST". For example, a "REPLY" may be - received from a "Delegate" to an event. In addition, the "REPLY" - method may be received from an unknown CU (a "Party Crasher"). This - uninvited "Attendee" may be accepted, or the "Organizer" may cancel - the event for the uninvited "Attendee" by sending a "CANCEL" method - to the uninvited "Attendee". - - An "Attendee" MAY include a message to the "Organizer" using the - "COMMENT" property. For example, if the user indicates tentative - acceptance and wants to let the "Organizer" know why, the reason can - be expressed in the "COMMENT" property value. - - - - - -Daboo Standards Track [Page 25] - -RFC 5546 iTIP December 2009 - - - The "Organizer" may also receive a "REPLY" from one CU on behalf of - another. Like the scenario enumerated above for the "Organizer", - "Attendees" may have another CU respond on their behalf. This is - done using the "SENT-BY" parameter. - - The optional properties listed in the table below (those listed as - "0+" or "0 or 1") MUST NOT be changed from those of the original - request. If property changes are desired, the "COUNTER" message must - be used. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +--------------------------------------------+ - | Constraints for a METHOD:REPLY of a VEVENT | - +--------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REPLY. | - | | | | - | VEVENT | 1+ | All components MUST have the same | - | | | UID. | - | ATTENDEE | 1 | MUST be the address of the | - | | | Attendee replying. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | UID | 1 | MUST be the UID of the original | - | | | REQUEST. | - | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence | - | | | number of the original REQUEST. | - | | | MAY be present if 0. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DTSTART | 0 or 1 | | - - - - -Daboo Standards Track [Page 26] - -RFC 5546 iTIP December 2009 - - - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | REQUEST-STATUS | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | | - | SUMMARY | 0 or 1 | | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0 or 1 | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.4. ADD - - The "ADD" method allows the "Organizer" to add one or more new - instances to an existing "VEVENT" using a single iTIP message without - having to send the entire "VEVENT" with all the existing instance - data, as it would have to do if the "REQUEST" method were used. - - The "UID" must be that of the existing event. 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". 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". - - - - -Daboo Standards Track [Page 27] - -RFC 5546 iTIP December 2009 - - - When handling an "ADD" message, the "Attendee" treats each component - in the "ADD" message as if it were referenced via an "RDATE" in the - main component. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +------------------------------------------+ - | Constraints for a METHOD:ADD of a VEVENT | - +------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be ADD. | - | | | | - | VEVENT | 1 | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | MUST be greater than 0. | - | SUMMARY | 1 | Can be null. | - | UID | 1 | MUST match that of the original | - | | | event. | - | ATTACH | 0+ | | - | ATTENDEE | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | STATUS | 0 or 1 | MAY be one of | - | | | TENTATIVE/CONFIRMED. | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - - - -Daboo Standards Track [Page 28] - -RFC 5546 iTIP December 2009 - - - | EXDATE | 0 | | - | RECURRENCE-ID | 0 | | - | REQUEST-STATUS | 0 | | - | RDATE | 0 | | - | RRULE | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.5. CANCEL - - The "CANCEL" method in a "VEVENT" calendar component is used to send - a cancellation notice of an existing event request to the affected - "Attendees". The message is sent by the "Organizer" of the event. - For a recurring event, either the whole event or instances of an - event may be cancelled. 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. 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. - - There are two options for canceling a sequence of instances of a - recurring "VEVENT" calendar component: - - a. The "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - "THISANDFUTURE" to indicate cancellation of the specified - "VEVENT" calendar component and all instances after. - - b. Individual recurrence instances may be cancelled by specifying - multiple "VEVENT" components each with a "RECURRENCE-ID" property - corresponding to one of the instances to be cancelled. - - - - - - -Daboo Standards Track [Page 29] - -RFC 5546 iTIP December 2009 - - - The "Organizer" MUST send a "CANCEL" message to each "Attendee" - affected by the cancellation. This can be done using a single - "CANCEL" message for all "Attendees" or by using multiple messages - with different subsets of the affected "Attendees" in each. - - When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be - incremented as described in Section 2.1.4. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +---------------------------------------------+ - | Constraints for a METHOD:CANCEL of a VEVENT | - +---------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be CANCEL. | - | | | | - | VEVENT | 1+ | All must have the same UID. | - | ATTENDEE | 0+ | MUST include some or all | - | | | Attendees being removed from the | - | | | event. MUST include some or all | - | | | Attendees if the entire event is | - | | | cancelled. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | | - | UID | 1 | MUST be the UID of the original | - | | | REQUEST. | - | COMMENT | 0+ | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DTSTART | 0 or 1 | | - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - - - -Daboo Standards Track [Page 30] - -RFC 5546 iTIP December 2009 - - - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MUST be set to CANCELLED to | - | | | cancel the entire event. If | - | | | uninviting specific Attendees, | - | | | then MUST NOT be included. | - | SUMMARY | 0 or 1 | | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.6. REFRESH - - The "REFRESH" method in a "VEVENT" calendar component is used by - "Attendees" of an existing event to request an updated description - from the event "Organizer". The "REFRESH" method must specify the - "UID" property of the event to update. A recurrence instance of an - event may be requested by specifying the "RECURRENCE-ID" property - corresponding to the associated event. The "Organizer" responds with - the latest description and version of the event. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - -Daboo Standards Track [Page 31] - -RFC 5546 iTIP December 2009 - - - +----------------------------------------------+ - | Constraints for a METHOD:REFRESH of a VEVENT | - +----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REFRESH. | - | | | | - | VEVENT | 1 | | - | ATTENDEE | 1 | MUST be the address of requester. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | UID | 1 | MUST be the UID associated with | - | | | original REQUEST. | - | COMMENT | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | ATTACH | 0 | | - | CATEGORIES | 0 | | - | CLASS | 0 | | - | CONTACT | 0 | | - | CREATED | 0 | | - | DESCRIPTION | 0 | | - | DTEND | 0 | | - | DTSTART | 0 | | - | DURATION | 0 | | - | EXDATE | 0 | | - | GEO | 0 | | - | LAST-MODIFIED | 0 | | - | LOCATION | 0 | | - | PRIORITY | 0 | | - | RDATE | 0 | | - | RELATED-TO | 0 | | - | REQUEST-STATUS | 0 | | - | RESOURCES | 0 | | - | RRULE | 0 | | - | SEQUENCE | 0 | | - | STATUS | 0 | | - | SUMMARY | 0 | | - | TRANSP | 0 | | - | URL | 0 | | - | | | | - - - - -Daboo Standards Track [Page 32] - -RFC 5546 iTIP December 2009 - - - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0+ | | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.7. COUNTER - - The "COUNTER" method for a "VEVENT" calendar component is used by an - "Attendee" of an existing event to submit to the "Organizer" a - counter proposal to the event. The "Attendee" sends this message to - the "Organizer" of the event. - - The counter proposal is an iCalendar object consisting of a "VEVENT" - calendar component that provides the complete description of the - alternate event. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the - counter proposal by rescheduling the event as described in - Section 3.2.2.1, "Rescheduling an Event". The "Organizer's" CUA - SHOULD send a "REQUEST" message to all "Attendees" affected by any - change triggered by an accepted "COUNTER". - - This method type is an iCalendar object that conforms to the - following property constraints: - - +----------------------------------------------+ - | Constraints for a METHOD:COUNTER of a VEVENT | - +----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be COUNTER. | - | | | | - | VEVENT | 1 | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - - - - -Daboo Standards Track [Page 33] - -RFC 5546 iTIP December 2009 - - - | ORGANIZER | 1 | MUST be the Organizer of the | - | | | original event. | - | SEQUENCE | 1 | MUST echo the original SEQUENCE | - | | | number. MUST be present if | - | | | non-zero. MAY be present if | - | | | zero. | - | SUMMARY | 1 | Can be null. | - | UID | 1 | MUST be the UID associated with | - | | | the REQUEST being countered. | - | ATTACH | 0+ | | - | ATTENDEE | 0+ | Can also be used to propose other | - | | | Attendees. | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | REQUEST-STATUS | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | Value must be one of | - | | | CONFIRMED/TENATIVE/CANCELLED. | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - - - -Daboo Standards Track [Page 34] - -RFC 5546 iTIP December 2009 - - - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.2.8. DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VEVENT" calendar component is used - by the "Organizer" of an event to reject a counter proposal submitted - by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" - message to the "Attendee" that sent the "COUNTER" method to the - "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - - +-----------------------------------------------------+ - | Constraints for a METHOD:DECLINECOUNTER of a VEVENT | - +-----------------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be DECLINECOUNTER. | - | | | | - | VEVENT | 1+ | All components MUST have the same | - | | | UID. | - | ATTENDEE | 1+ | MUST for all Attendees. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | MUST echo the original SEQUENCE | - | | | number. | - | UID | 1 | MUST echo original UID. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTSTART | 0 or 1 | | - | DTEND | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - - - -Daboo Standards Track [Page 35] - -RFC 5546 iTIP December 2009 - - - | DURATION | 0 or 1 | If present, DTEND MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | REQUEST-STATUS | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | TENTATIVE/CONFIRMED. | - | SUMMARY | 0 or 1 | Can be null. | - | TRANSP | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VALARM | 0 | | - | VFREEBUSY | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - - - - - - - - - - - - - -Daboo Standards Track [Page 36] - -RFC 5546 iTIP December 2009 - - -3.3. Methods for VFREEBUSY Components - - This section defines the property set for the methods that are - applicable to the "VFREEBUSY" calendar component. Each of the - methods is defined using a restriction table. - - This document only addresses the transfer of busy time information. - Applications desiring free time information MUST infer this from - available busy time information. - - The "FREEBUSY" property value MAY include a list of values, separated - by the COMMA character (US-ASCII decimal 44). Alternately, multiple - busy time periods MAY be specified with multiple instances of the - "FREEBUSY" property. Both forms MUST be supported by implementations - conforming to this document. Duplicate busy time periods SHOULD NOT - be specified in an iCalendar object. However, two different busy - time periods MAY overlap. - - "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. For example, today's busy time - information should appear after yesterday's busy time information. - And the busy time for this half-hour should appear after the busy - time for earlier today. Busy time periods can also span a day - boundary. - - The following summarizes the methods that are defined for the - "VFREEBUSY" calendar component. - - +---------+-------------------------------------+ - | Method | Description | - +---------+-------------------------------------+ - | PUBLISH | Publish unsolicited busy time data. | - | | | - | REQUEST | Request busy time data. | - | | | - | REPLY | Reply to a busy time request. | - +---------+-------------------------------------+ - -3.3.1. PUBLISH - - The "PUBLISH" method in a "VFREEBUSY" calendar component is used to - publish busy time data. The method may be sent from one CU to any - other. The purpose of the method is to provide a way to send - unsolicited busy time data. That is, the busy time data is not being - sent as a "REPLY" to the receipt of a "REQUEST" method. - - - - - -Daboo Standards Track [Page 37] - -RFC 5546 iTIP December 2009 - - - The "ORGANIZER" property MUST be specified in the busy time - information. The value is the CU address of the originator of the - busy time information. - - The busy time information within the iCalendar object MAY be grouped - into more than one "VFREEBUSY" calendar component. This capability - allows busy time periods to be grouped according to some common - periodicity, such as a calendar week, month, or year. In this case, - each "VFREEBUSY" calendar component MUST include the "ORGANIZER", - "DTSTART", and "DTEND" properties in order to specify the source of - the busy time information and the date and time interval over which - the busy time information covers. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 38] - -RFC 5546 iTIP December 2009 - - - +-------------------------------------------------+ - | Constraints for a METHOD:PUBLISH of a VFREEBUSY | - +-------------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be PUBLISH. | - | | | | - | VFREEBUSY | 1+ | | - | DTSTAMP | 1 | | - | DTSTART | 1 | DateTime values must be in UTC. | - | DTEND | 1 | DateTime values must be in UTC. | - | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | - | | | instances are allowed. Multiple | - | | | instances SHOULD be sorted in | - | | | ascending order. | - | ORGANIZER | 1 | MUST contain the address of | - | | | originator of busy time data. | - | UID | 1 | | - | COMMENT | 0+ | | - | CONTACT | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | URL | 0 or 1 | Specifies busy time URL. | - | ATTENDEE | 0 | | - | DURATION | 0 | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTIMEZONE | 0 | | - +--------------------+----------+-----------------------------------+ - - - - - - - - - -Daboo Standards Track [Page 39] - -RFC 5546 iTIP December 2009 - - -3.3.2. REQUEST - - The "REQUEST" method in a "VFREEBUSY" calendar component is used to - ask a "Calendar User" for their busy time information. The request - may be for a busy time information bounded by a specific date and - time interval. - - This message only permits requests for busy time information. The - message is sent from a "Calendar User" requesting the busy time - information of one or more intended recipients. - - 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. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 40] - -RFC 5546 iTIP December 2009 - - - +-------------------------------------------------+ - | Constraints for a METHOD:REQUEST of a VFREEBUSY | - +-------------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REQUEST. | - | | | | - | VFREEBUSY | 1 | | - | ATTENDEE | 1+ | Contains the calendar user | - | | | addresses of the "Calendar Users" | - | | | whose freebusy is being | - | | | requested. | - | DTEND | 1 | DateTime values must be in UTC. | - | DTSTAMP | 1 | | - | DTSTART | 1 | DateTime values must be in UTC. | - | ORGANIZER | 1 | MUST be the request originator's | - | | | address. | - | UID | 1 | | - | COMMENT | 0+ | | - | CONTACT | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | FREEBUSY | 0 | | - | DURATION | 0 | | - | REQUEST-STATUS | 0 | | - | URL | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTIMEZONE | 0 | | - +--------------------+----------+-----------------------------------+ - - - - - - - - - -Daboo Standards Track [Page 41] - -RFC 5546 iTIP December 2009 - - -3.3.3. REPLY - - The "REPLY" method in a "VFREEBUSY" calendar component is used to - respond to a busy time request. The method is sent by the recipient - of a busy time request to the originator of the request. - - 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. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 42] - -RFC 5546 iTIP December 2009 - - - +-----------------------------------------------+ - | Constraints for a METHOD:REPLY of a VFREEBUSY | - +-----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REPLY. | - | | | | - | VFREEBUSY | 1 | | - | ATTENDEE | 1 | MUST be the address of the | - | | | Attendee replying. | - | DTSTAMP | 1 | | - | DTEND | 1 | DateTime values must be in UTC. | - | DTSTART | 1 | DateTime values must be in UTC. | - | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | - | | | instances are allowed. Multiple | - | | | instances SHOULD be sorted in | - | | | ascending order. | - | ORGANIZER | 1 | MUST be the request originator's | - | | | address. | - | UID | 1 | MUST be the UID of the original | - | | | REQUEST. | - | COMMENT | 0+ | | - | CONTACT | 0 or 1 | | - | REQUEST-STATUS | 0+ | | - | URL | 0 or 1 | Specifies busy time URL. | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | DURATION | 0 | | - | SEQUENCE | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VTODO | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VTIMEZONE | 0 | | - +--------------------+----------+-----------------------------------+ - - - - - - -Daboo Standards Track [Page 43] - -RFC 5546 iTIP December 2009 - - -3.4. Methods for VTODO Components - - This section defines the property set for the methods that are - applicable to the "VTODO" calendar component. Each of the methods is - defined using a restriction table that specifies the property - constraints that define the particular method. - - The following summarizes the methods that are defined for the "VTODO" - calendar component. - - +----------------+--------------------------------------------------+ - | Method | Description | - +----------------+--------------------------------------------------+ - | PUBLISH | Post notification of a VTODO. Used primarily as | - | | a method of advertising the existence of a | - | | VTODO. | - | | | - | REQUEST | Assign a VTODO. This is an explicit assignment | - | | to one or more Calendar Users. The REQUEST | - | | method is also used to update or change an | - | | existing VTODO. Clients that cannot handle | - | | REQUEST MAY degrade the method to treat it as a | - | | PUBLISH. | - | | | - | REPLY | Reply to a VTODO request. Attendees MAY set | - | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | - | | DELEGATED, PARTIAL, and COMPLETED. | - | | | - | ADD | Add one or more instances to an existing to-do. | - | | | - | CANCEL | Cancel one or more instances of an existing | - | | to-do. | - | | | - | REFRESH | A request sent to a VTODO Organizer asking for | - | | the latest version of a VTODO. | - | | | - | COUNTER | Counter a REQUEST with an alternative proposal. | - | | | - | DECLINECOUNTER | Decline a counter proposal by an Attendee. | - +----------------+--------------------------------------------------+ - -3.4.1. PUBLISH - - The "PUBLISH" method in a "VTODO" calendar component has no - associated response. It is simply a posting of an iCalendar object - that may be added to a calendar. It MUST have an "Organizer". It - MUST NOT have "Attendees". Its expected usage is for encapsulating - an arbitrary "VTODO" calendar component as an iCalendar object. The - - - -Daboo Standards Track [Page 44] - -RFC 5546 iTIP December 2009 - - - "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. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +---------------------------------------------+ - | Constraints for a METHOD:PUBLISH of a VTODO | - +---------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be PUBLISH. | - | | | | - | VTODO | 1+ | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | PRIORITY | 1 | | - | SEQUENCE | 0 or 1 | MUST be present if value is | - | | | greater than 0; MAY be present if | - | | | 0. | - | SUMMARY | 1 | Can be null. | - | UID | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - - - -Daboo Standards Track [Page 45] - -RFC 5546 iTIP December 2009 - - - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | COMPLETED/NEEDS-ACTION/ | - | | | IN-PROCESS/CANCELLED. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | ATTENDEE | 0 | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VEVENT | 0 | | - | | | | - | VJOURNAL | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.2. REQUEST - - The "REQUEST" method in a "VTODO" calendar component provides the - following scheduling functions: - - o Assign a to-do to one or more "Calendar Users". - - o Reschedule an existing to-do. - - o Update the details of an existing to-do, without rescheduling it. - - o Update the completion status of "Attendees" of an existing to-do, - without rescheduling it. - - o Reconfirm an existing to-do, without rescheduling it. - - o Delegate/reassign an existing to-do to another "Calendar User". - - The assigned "Calendar Users" are identified in the "VTODO" calendar - component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property - value sequences. - - - -Daboo Standards Track [Page 46] - -RFC 5546 iTIP December 2009 - - - Typically, the originator of a "REQUEST" is the "Organizer" of the - to-do, and the recipient of a "REQUEST" is the "Calendar User" - assigned the to-do. The "Attendee" uses the "REPLY" method to convey - their acceptance and completion status to the "Organizer" of the - "REQUEST". - - The "UID", "SEQUENCE", and "DTSTAMP" properties are used to - distinguish the various uses of the "REQUEST" method. If the "UID" - property value in the "REQUEST" is not found on the recipient's - calendar, then the "REQUEST" is for a new to-do. If the "UID" - property value is found on the recipient's calendar, then the - "REQUEST" is a rescheduling, an update, or a reconfirmation of the - "VTODO" calendar object. - - If the "Organizer" of the "REQUEST" method is not authorized to make - a to-do request on the "Attendee's" calendar system, then an - exception is returned in the "REQUEST-STATUS" property of a - subsequent "REPLY" method, but no scheduling action is performed. - - For the "REQUEST" method, multiple "VTODO" components in a single - iCalendar object are only permitted for components with the same - "UID" property. That is, a series of recurring events may have - instance-specific information. In this case, multiple "VTODO" - components are needed to express the entire series. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +---------------------------------------------+ - | Constraints for a METHOD:REQUEST of a VTODO | - +---------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REQUEST. | - | | | | - | VTODO | 1+ | All components must have the same | - | | | UID. | - | ATTENDEE | 1+ | | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | PRIORITY | 1 | | - | SEQUENCE | 0 or 1 | MUST be present if value is | - | | | greater than 0; MAY be present if | - | | | 0. | - | SUMMARY | 1 | Can be null. | - - - -Daboo Standards Track [Page 47] - -RFC 5546 iTIP December 2009 - - - | UID | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | COMPLETED/NEEDS-ACTION/ | - | | | IN-PROCESS. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VJOURNAL | 0 | | - +--------------------+----------+-----------------------------------+ - - - -Daboo Standards Track [Page 48] - -RFC 5546 iTIP December 2009 - - -3.4.2.1. REQUEST for Rescheduling a VTODO - - The "REQUEST" method may be used to reschedule a "VTODO" calendar - component. - - Rescheduling a "VTODO" calendar component involves a change to the - existing "VTODO" calendar component in terms of its start or due - time, recurrence intervals, and possibly the description. If the - recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar but that the "SEQUENCE" property - value in the "REQUEST" is greater than the value for the existing - "VTODO", then the "REQUEST" method describes a rescheduling of the - "VTODO" calendar component. - -3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO - - The "REQUEST" method may be used to update or reconfirm a "VTODO" - calendar component. Reconfirmation is merely an update of "Attendee" - completion status or overall "VTODO" calendar component status. - - An update to an existing "VTODO" calendar component does not involve - changes to the start or due time, recurrence intervals, or - (generally) the description for the "VTODO" calendar component. If - the recipient CUA of a "REQUEST" method finds that the "UID" property - value already exists on the calendar and that the "SEQUENCE" property - value in the "REQUEST" is the same as the value for the existing - event, then the "REQUEST" method describes an update of the "VTODO" - calendar component details, but not a rescheduling of the "VTODO" - calendar component. - - The update "REQUEST" is the appropriate response to a "REFRESH" - method sent from an "Attendee" to the "Organizer" of a "VTODO" - calendar component. - - Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a - "VTODO" calendar component. The unsolicited "REQUEST" methods are - used to update the details of the "VTODO" (without rescheduling it or - updating the completion status of "Attendees") or the "VTODO" - calendar component itself (i.e., reconfirm the "VTODO"). - -3.4.2.3. REQUEST for Delegating a VTODO - - The "REQUEST" method is also used to delegate or reassign ownership - of a "VTODO" calendar component to another "Calendar User". For - example, it may be used to delegate an "Attendee's" role (i.e., - "chair" or "participant") for a "VTODO" calendar component. The - "REQUEST" method is sent by one of the "Attendees" of an existing - "VTODO" calendar component to some other individual. - - - -Daboo Standards Track [Page 49] - -RFC 5546 iTIP December 2009 - - - For the purposes of this description, the "Attendee" delegating the - "VTODO" calendar component is referred to as the "Delegator". The - "Attendee" receiving the delegation request is referred to as the - "Delegate". - - The "Delegator" of a "VTODO" calendar component MUST forward the - existing "REQUEST" method for a "VTODO" calendar component to the - "Delegate". The "VTODO" calendar component description MUST include - the "Delegator's" up-to-date "VTODO" calendar component definition. - The "REQUEST" method MUST also include an "ATTENDEE" property with - the calendar address of the "Delegate". The "Delegator" MUST also - send a "REPLY" method back to the "Organizer" with the "Delegator's" - "Attendee" property "PARTSTAT" parameter value set to "DELEGATED". - In addition, the "DELEGATED-TO" parameter MUST be included with the - calendar address of the "Delegate". A response to the delegation - "REQUEST" is sent from the "Delegate" to the "Organizer", and - optionally to the "Delegator". 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. - - 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". - -3.4.2.4. REQUEST Forwarded to an Uninvited Calendar User - - 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. The current - "Attendee" assigned the "VTODO" calendar component does this by - forwarding the original "REQUEST" method to the new CU. The new CU - can send a "REPLY" to the "Organizer" of the "VTODO" calendar - component. The reply contains an "ATTENDEE" property for the new CU. - - The "Organizer" ultimately decides whether or not the new CU becomes - part of the to-do and is not obligated to do anything with a "REPLY" - from a new (uninvited) CU. If the "Organizer" does not want the new - CU to be part of the to-do, the new "ATTENDEE" property is not added - to the "VTODO" calendar component. The "Organizer" MAY send the CU a - "CANCEL" message to indicate that they will not be added to the to- - do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" - property is added to the "VTODO" calendar component. Furthermore, - the "Organizer" is free to change any "ATTENDEE" property parameter - from the values supplied by the new CU to something the "Organizer" - - - -Daboo Standards Track [Page 50] - -RFC 5546 iTIP December 2009 - - - considers appropriate. The "Organizer" SHOULD send the new - "Attendee" a "REQUEST" message to inform them that they have been - added. - - When forwarding a "REQUEST" to another CU, the forwarding "Attendee" - MUST NOT make changes to the original message. - -3.4.2.5. REQUEST Updated Attendee Status - - An "Organizer" of a "VTODO" may request an updated status from one or - more "Attendees". The "Organizer" sends a "REQUEST" method to the - "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The - "SEQUENCE" property for the "VTODO" is not changed from its previous - value. A recipient determines that the only change in the "REQUEST" - is that their "RSVP" property parameter indicates a request for an - updated status. The recipient SHOULD respond with a "REPLY" method - indicating their current status with respect to the "REQUEST". - -3.4.3. REPLY - - The "REPLY" method in a "VTODO" calendar component is used to respond - (e.g., accept or decline) to a request or to reply to a delegation - request. It is also used by an "Attendee" to update their completion - status. 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. - The "Delegate" MUST include the calendar address of the "Delegator" - on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE" - property. - - The "REPLY" method MAY also be used to respond to an unsuccessful - "VTODO" calendar component "REQUEST" method. Depending on the - "REQUEST-STATUS" value, no scheduling action may have been performed. - - The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" - method from a "Calendar User" not in the original "REQUEST". For - example, a "REPLY" method MAY be received from a "Delegate" of a - "VTODO" calendar component. In addition, the "REPLY" method MAY be - received from an unknown "Calendar User" who has been forwarded the - "REQUEST" by an original "Attendee" of the "VTODO" calendar - component. 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. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - -Daboo Standards Track [Page 51] - -RFC 5546 iTIP December 2009 - - - +-------------------------------------------+ - | Constraints for a METHOD:REPLY of a VTODO | - +-------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REPLY. | - | | | | - | VTODO | 1+ | All components MUST have the same | - | | | UID. | - | ATTENDEE | 1 | MUST be the address of the | - | | | Attendee replying. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | REQUEST-STATUS | 0+ | | - | UID | 1 | MUST be the UID of the original | - | | | REQUEST. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTSTART | 0 or 1 | | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | SEQUENCE | 0 or 1 | MUST be the sequence number of | - | | | the original REQUEST if greater | - | | | than 0. MAY be present if 0. | - - - -Daboo Standards Track [Page 52] - -RFC 5546 iTIP December 2009 - - - | STATUS | 0 or 1 | | - | SUMMARY | 0 or 1 | Can be null. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0 or 1 | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.4. ADD - - The "ADD" method allows the "Organizer" to add one or more new - instances to an existing "VTODO" using a single iTIP message without - having to send the entire "VTODO" with all the existing instance - data, as it would have to do if the "REQUEST" method were used. - - The "UID" must be that of the existing to-do. 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 3.14 and ask for a "REFRESH". - - When handling an "ADD" message, the "Attendee" treats each component - in the "ADD" message as if it were referenced via an "RDATE" in the - main component. - - The "SEQUENCE" property value is incremented since the sequence of - to-dos has changed. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - -Daboo Standards Track [Page 53] - -RFC 5546 iTIP December 2009 - - - +-----------------------------------------+ - | Constraints for a METHOD:ADD of a VTODO | - +-----------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be ADD. | - | | | | - | VTODO | 1 | | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | PRIORITY | 1 | | - | SEQUENCE | 1 | MUST be greater than 0. | - | SUMMARY | 1 | Can be null. | - | UID | 1 | MUST match that of the original | - | | | to-do. | - | ATTACH | 0+ | | - | ATTENDEE | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTSTART | 0 or 1 | | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | STATUS | 0 or 1 | MAY be one of | - | | | COMPLETED/NEEDS-ACTION/ | - | | | IN-PROCESS. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | EXDATE | 0 | | - | RECURRENCE-ID | 0 | | - | REQUEST-STATUS | 0 | | - | RDATE | 0 | | - | RRULE | 0 | | - - - -Daboo Standards Track [Page 54] - -RFC 5546 iTIP December 2009 - - - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VJOURNAL | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.5. CANCEL - - The "CANCEL" method in a "VTODO" calendar component is used to send a - cancellation notice of an existing "VTODO" calendar request to the - affected "Attendees". The message is sent by the "Organizer" of a - "VTODO" calendar component to the "Attendees" of the "VTODO" calendar - component. For a recurring "VTODO" calendar component, either the - whole "VTODO" calendar component or instances of a "VTODO" calendar - component may be cancelled. 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. 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. - - There are two options for canceling a sequence of instances of a - recurring "VTODO" calendar component: - - a. The "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - "THISANDFUTURE" to indicate cancellation of the specified "VTODO" - calendar component and all instances after. - - b. Individual recurrence instances may be cancelled by specifying - multiple "VTODO" components each with a "RECURRENCE-ID" property - corresponding to one of the instances to be cancelled. - - The "Organizer" MUST send a "CANCEL" message to each "Attendee" - affected by the cancellation. This can be done by using either a - single "CANCEL" message for all "Attendees" or multiple messages with - different subsets of the affected "Attendees" in each. - - - -Daboo Standards Track [Page 55] - -RFC 5546 iTIP December 2009 - - - When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be - incremented as described in Section 2.1.4. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +--------------------------------------------+ - | Constraints for a METHOD:CANCEL of a VTODO | - +--------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be CANCEL. | - | | | | - | VTODO | 1+ | | - | ATTENDEE | 0+ | MUST include some or all | - | | | Attendees being removed from the | - | | | to-do. MUST include some or all | - | | | Attendees if the entire to-do is | - | | | cancelled. | - | UID | 1 | MUST echo original UID. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTSTART | 0 or 1 | | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | RDATE | 0+ | | - - - - - - - -Daboo Standards Track [Page 56] - -RFC 5546 iTIP December 2009 - - - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | STATUS | 0 or 1 | MUST be set to CANCELLED to | - | | | cancel the entire VTODO. If | - | | | removing specific Attendees, then | - | | | MUST NOT be included. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0 or 1 | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.6. REFRESH - - The "REFRESH" method in a "VTODO" calendar component is used by - "Attendees" of an existing "VTODO" calendar component to request an - updated description from the "Organizer" of the "VTODO" calendar - component. The "Organizer" of the "VTODO" calendar component MAY use - this method to request an updated status from the "Attendees". The - "REFRESH" method MUST specify the "UID" property corresponding to the - "VTODO" calendar component needing update. - - 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. - - - -Daboo Standards Track [Page 57] - -RFC 5546 iTIP December 2009 - - - This method type is an iCalendar object that conforms to the - following property constraints: - - +---------------------------------------------+ - | Constraints for a METHOD:REFRESH of a VTODO | - +---------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be REFRESH. | - | | | | - | VTODO | 1 | | - | ATTENDEE | 1 | | - | DTSTAMP | 1 | | - | UID | 1 | MUST echo original UID. | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | ATTACH | 0 | | - | CATEGORIES | 0 | | - | CLASS | 0 | | - | COMMENT | 0 | | - | COMPLETED | 0 | | - | CONTACT | 0 | | - | CREATED | 0 | | - | DESCRIPTION | 0 | | - | DTSTART | 0 | | - | DUE | 0 | | - | DURATION | 0 | | - | EXDATE | 0 | | - | GEO | 0 | | - | LAST-MODIFIED | 0 | | - | LOCATION | 0 | | - | ORGANIZER | 0 | | - | PERCENT-COMPLETE | 0 | | - | PRIORITY | 0 | | - | RDATE | 0 | | - | RELATED-TO | 0 | | - | REQUEST-STATUS | 0 | | - | RESOURCES | 0 | | - | RRULE | 0 | | - | SEQUENCE | 0 | | - | STATUS | 0 | | - | URL | 0 | | - - - -Daboo Standards Track [Page 58] - -RFC 5546 iTIP December 2009 - - - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0+ | | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.7. COUNTER - - The "COUNTER" method in a "VTODO" calendar component is used by an - "Attendee" of an existing "VTODO" calendar component to submit to the - "Organizer" a counter proposal for the "VTODO" calendar component. - - The counter proposal is an iCalendar object consisting of a "VTODO" - calendar component that provides the complete description of the - alternate "VTODO" calendar component. - - The "Organizer" rejects the counter proposal by sending the - "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the - counter proposal by rescheduling the to-do as described in - Section 3.4.2.1, "REQUEST for Rescheduling a To-Do". The - "Organizer's" CUA SHOULD send a "REQUEST" message to all "Attendees" - affected by any change triggered by an accepted "COUNTER". - - This method type is an iCalendar object that conforms to the - following property constraints: - - +---------------------------------------------+ - | Constraints for a METHOD:COUNTER of a VTODO | - +---------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be COUNTER. | - | | | | - | VTODO | 1 | | - | ATTENDEE | 1+ | | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | PRIORITY | 1 | | - | SUMMARY | 1 | Can be null. | - - - -Daboo Standards Track [Page 59] - -RFC 5546 iTIP December 2009 - - - | UID | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | Can be null. | - | DTSTART | 0 or 1 | | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | REQUEST-STATUS | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | - | | | number. MUST be present if | - | | | non-zero. MAY be present if | - | | | zero. | - | STATUS | 0 or 1 | MAY be one of | - | | | COMPLETED/NEEDS-ACTION/ | - | | | IN-PROCESS/CANCELLED. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0 or 1 | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - - - - -Daboo Standards Track [Page 60] - -RFC 5546 iTIP December 2009 - - - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.4.8. DECLINECOUNTER - - The "DECLINECOUNTER" method in a "VTODO" calendar component is used - by an "Organizer" of the "VTODO" calendar component to reject a - counter proposal offered by one of the "Attendees". The "Organizer" - sends the message to the "Attendee" that sent the "COUNTER" method to - the "Organizer". - - This method type is an iCalendar object that conforms to the - following property constraints: - - +----------------------------------------------------+ - | Constraints for a METHOD:DECLINECOUNTER of a VTODO | - +----------------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be DECLINECOUNTER. | - | | | | - | VTODO | 1 | | - | ATTENDEE | 1+ | MUST for all ATTENDEEs. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | MUST echo the original SEQUENCE | - | | | number. | - | UID | 1 | MUST echo original UID. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | COMPLETED | 0 or 1 | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTSTART | 0 or 1 | | - | DUE | 0 or 1 | If present, DURATION MUST NOT be | - | | | present. | - | DURATION | 0 or 1 | If present, DUE MUST NOT be | - | | | present. | - | EXDATE | 0+ | | - | GEO | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - - - -Daboo Standards Track [Page 61] - -RFC 5546 iTIP December 2009 - - - | LOCATION | 0 or 1 | | - | PERCENT-COMPLETE | 0 or 1 | | - | PRIORITY | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | REQUEST-STATUS | 0+ | | - | RESOURCES | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be one of | - | | | COMPLETED/NEEDS-ACTION/ | - | | | IN-PROCESS. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - +--------------------+----------+-----------------------------------+ - -3.5. Methods for VJOURNAL Components - - This section defines the property set for the methods that are - applicable to the "VJOURNAL" calendar component. - - The following summarizes the methods that are defined for the - "VJOURNAL" calendar component. - - - - - - - - - - - - -Daboo Standards Track [Page 62] - -RFC 5546 iTIP December 2009 - - - +---------+---------------------------------------------------------+ - | Method | Description | - +---------+---------------------------------------------------------+ - | PUBLISH | Post a journal entry. Used primarily as a method of | - | | advertising the existence of a journal entry. | - | | | - | ADD | Add one or more instances to an existing journal entry. | - | | | - | CANCEL | Cancel one or more instances of an existing journal | - | | entry. | - +---------+---------------------------------------------------------+ - -3.5.1. PUBLISH - - The "PUBLISH" method in a "VJOURNAL" calendar component has no - associated response. It is simply a posting of an iCalendar object - that may be added to a calendar. It MUST have an "Organizer". It - MUST NOT have "Attendees". The expected usage is for encapsulating - an arbitrary journal entry as an iCalendar object. The "Organizer" - MAY subsequently update (with another "PUBLISH" method) or cancel - (with a "CANCEL" method) a previously published journal entry. - - This method type is an iCalendar object that conforms to the - following property constraints: - - +------------------------------------------------+ - | Constraints for a METHOD:PUBLISH of a VJOURNAL | - +------------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be PUBLISH. | - | | | | - | VJOURNAL | 1+ | | - | DESCRIPTION | 1 | Can be null. | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | UID | 1 | | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | EXDATE | 0+ | | - | LAST-MODIFIED | 0 or 1 | | - - - -Daboo Standards Track [Page 63] - -RFC 5546 iTIP December 2009 - - - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | RRULE | 0 or 1 | | - | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY | - | | | be present if zero. | - | STATUS | 0 or 1 | MAY be one of | - | | | DRAFT/FINAL/CANCELLED. | - | SUMMARY | 0 or 1 | Can be null. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | ATTENDEE | 0 | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - -3.5.2. ADD - - The "ADD" method allows the "Organizer" to add one or more new - instances to an existing "VJOURNAL" using a single iTIP message - without having to send the entire "VJOURNAL" with all the existing - instance data, as it would have to do if the "REQUEST" method were - used. - - The "UID" must be that of the existing journal entry. 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". - - When handling an "ADD" message, the "Attendee" treats each component - in the "ADD" message as if it were referenced via an "RDATE" in the - main component. There is no response to the "Organizer". - - - -Daboo Standards Track [Page 64] - -RFC 5546 iTIP December 2009 - - - This method type is an iCalendar object that conforms to the - following property constraints: - - +--------------------------------------------+ - | Constraints for a METHOD:ADD of a VJOURNAL | - +--------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be ADD. | - | | | | - | VJOURNAL | 1 | | - | DESCRIPTION | 1 | Can be null. | - | DTSTAMP | 1 | | - | DTSTART | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | MUST be greater than 0. | - | UID | 1 | MUST match that of the original | - | | | journal. | - | ATTACH | 0+ | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | LAST-MODIFIED | 0 or 1 | | - | RELATED-TO | 0+ | | - | STATUS | 0 or 1 | MAY be one of | - | | | DRAFT/FINAL/CANCELLED. | - | SUMMARY | 0 or 1 | Can be null. | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | ATTENDEE | 0 | | - | EXDATE | 0 | | - | RECURRENCE-ID | 0 | | - | REQUEST-STATUS | 0 | | - | RDATE | 0 | | - | RRULE | 0 | | - | | | | - | VALARM | 0+ | | - | | | | - | VTIMEZONE | 0 or 1 | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - - - -Daboo Standards Track [Page 65] - -RFC 5546 iTIP December 2009 - - - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - -3.5.3. CANCEL - - The "CANCEL" method in a "VJOURNAL" calendar component is used to - send a cancellation notice of an existing journal entry. The message - is sent by the "Organizer" of a journal entry. For a recurring - journal entry, either the whole journal entry or instances of a - journal entry may be cancelled. 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. 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. - - There are two options for canceling a sequence of instances of a - recurring "VJOURNAL" calendar component: - - a. The "RECURRENCE-ID" property for an instance in the sequence MUST - be specified with the "RANGE" property parameter value of - "THISANDFUTURE" to indicate cancellation of the specified - "VJOURNAL" calendar component and all instances after. - - b. Individual recurrence instances may be cancelled by specifying - multiple "VJOURNAL" components each with a "RECURRENCE-ID" - property corresponding to one of the instances to be cancelled. - - When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be - incremented as described in Section 2.1.4. - - This method type is an iCalendar object that conforms to the - following property constraints: - - - - - - - - - - - - - -Daboo Standards Track [Page 66] - -RFC 5546 iTIP December 2009 - - - +-----------------------------------------------+ - | Constraints for a METHOD:CANCEL of a VJOURNAL | - +-----------------------------------------------+ - - +--------------------+----------+-----------------------------------+ - | Component/Property | Presence | Comment | - +--------------------+----------+-----------------------------------+ - | METHOD | 1 | MUST be CANCEL. | - | | | | - | VJOURNAL | 1+ | All MUST have the same UID. | - | DTSTAMP | 1 | | - | ORGANIZER | 1 | | - | SEQUENCE | 1 | | - | UID | 1 | MUST be the UID of the original | - | | | REQUEST. | - | ATTACH | 0+ | | - | ATTENDEE | 0 | | - | CATEGORIES | 0+ | | - | CLASS | 0 or 1 | | - | COMMENT | 0+ | | - | CONTACT | 0+ | | - | CREATED | 0 or 1 | | - | DESCRIPTION | 0 or 1 | | - | DTSTART | 0 or 1 | | - | EXDATE | 0+ | | - | LAST-MODIFIED | 0 or 1 | | - | RDATE | 0+ | | - | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | - | | | of a recurring calendar | - | | | component. Otherwise, it MUST | - | | | NOT be present. | - | RELATED-TO | 0+ | | - | RRULE | 0 or 1 | | - | STATUS | 0 or 1 | MAY be present; MUST be CANCELLED | - | | | if present. | - | SUMMARY | 0 or 1 | | - | URL | 0 or 1 | | - | IANA-PROPERTY | 0+ | | - | X-PROPERTY | 0+ | | - | REQUEST-STATUS | 0 | | - | | | | - | VALARM | 0 | | - | | | | - | VTIMEZONE | 0+ | MUST be present if any date/time | - | | | refers to a timezone. | - | | | | - | IANA-COMPONENT | 0+ | | - | X-COMPONENT | 0+ | | - - - -Daboo Standards Track [Page 67] - -RFC 5546 iTIP December 2009 - - - | | | | - | VEVENT | 0 | | - | | | | - | VFREEBUSY | 0 | | - | | | | - | VTODO | 0 | | - +--------------------+----------+-----------------------------------+ - -3.6. Status Replies - - The "REQUEST-STATUS" property is used to convey status information - about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The - codes listed in the table below SHOULD be used. If the "REQUEST- - STATUS" property is not present in one of these iTIP messages, then a - status code of "2.0" (success) MUST be assumed. - - This specification adds a new IANA registry for "REQUEST-STATUS" - property values, as defined in Section 7, which includes a new - registration template for defining the specific components of the - "REQUEST-STATUS" property value. Additional codes MAY be used, - provided the process described in Section 8.2.1 of [RFC5545] is used - to register them. - - This specification allows for multiple "REQUEST-STATUS" properties to - be returned in iCalendar components in the appropriate iTIP messages. - When multiple "REQUEST-STATUS" properties are present, the following - restrictions apply: - - 1. Within any one component, the "top-level" numeric value of the - "short return status code" MUST be the same for all "REQUEST- - STATUS" properties, i.e., there cannot be a mixture of, e.g., - 2.xx and 5.xx codes within a single component. - - 2. Across all components in the iTIP message, the following applies: - - A. If any one component would have a 5.xx code, then either all - components MUST have a code in that range or "REQUEST-STATUS" - MUST NOT be present in the other components if a 5.xx code is - not appropriate for those components. - - B. Otherwise, if any one component would have a 3.xx code, then - either all components MUST have a code in that range or - "REQUEST-STATUS" MUST NOT be present in the other components - if a 3.xx code is not appropriate for those components. - - C. 2.xx and 4.xx codes can be used in different components, - provided that each component follows the restriction in (1) - above. - - - -Daboo Standards Track [Page 68] - -RFC 5546 iTIP December 2009 - - - The following "REQUEST-STATUS" codes are defined (any "Offending - Data" MAY be specified in the "REQUEST-STATUS" value as the extdata - field): - -3.6.1. Status Code 2.0 - - Status Code: 2.0 - - Status Description: Success. - - Status Exception Data: None. - - Description: iTIP operation succeeded. - -3.6.2. Status Code 2.1 - - Status Code: 2.1 - - Status Description: Success, but fallback taken on one or more - property values. - - Status Exception Data: Property name and value MAY be specified. - - Description: iTIP operation succeeded with fallback on one or more - property values. - -3.6.3. Status Code 2.2 - - Status Code: 2.2 - - Status Description: Success; invalid property ignored. - - Status Exception Data: Property name MAY be specified. - - Description: iTIP operation succeeded but a property was ignored. - -3.6.4. Status Code 2.3 - - Status Code: 2.3 - - Status Description: Success; invalid property parameter ignored. - - Status Exception Data: Property parameter name and value MAY be - specified. - - Description: iTIP operation succeeded but a property parameter was - ignored because it was invalid. - - - - -Daboo Standards Track [Page 69] - -RFC 5546 iTIP December 2009 - - -3.6.5. Status Code 2.4 - - Status Code: 2.4 - - Status Description: Success; unknown, non-standard property ignored. - - Status Exception Data: Non-standard property name MAY be specified. - - Description: iTIP operation succeeded but a property parameter was - ignored because it was unknown. - -3.6.6. Status Code 2.5 - - Status Code: 2.5 - - Status Description: Success; unknown, non-standard property value - ignored. - - Status Exception Data: Property and non-standard value MAY be - specified. - - Description: iTIP operation succeeded but a property was ignored - because its value was unknown. - -3.6.7. Status Code 2.6 - - Status Code: 2.6 - - Status Description: Success; invalid calendar component ignored. - - Status Exception Data: Calendar component sentinel (e.g., BEGIN: - ALARM) MAY be specified. - - Description: iTIP operation succeeded but a component was ignored - because it was invalid. - -3.6.8. Status Code 2.7 - - Status Code: 2.7 - - Status Description: Success; request forwarded to Calendar User. - - Status Exception Data: Original and forwarded calendar user - addresses MAY be specified. - - Description: iTIP operation succeeded, and the request was forwarded - to another Calendar User. - - - - -Daboo Standards Track [Page 70] - -RFC 5546 iTIP December 2009 - - -3.6.9. Status Code 2.8 - - Status Code: 2.8 - - Status Description: Success; repeating event ignored. Scheduled as - a single component. - - Status Exception Data: RRULE or RDATE property name and value MAY be - specified. - - Description: iTIP operation succeeded but a repeating event was - truncated to a single instance. - -3.6.10. Status Code 2.9 - - Status Code: 2.9 - - Status Description: Success; truncated end date time to date - boundary. - - Status Exception Data: DTEND property value MAY be specified. - - Description: iTIP operation succeeded but the end time was truncated - to a date boundary. - -3.6.11. Status Code 2.10 - - Status Code: 2.10 - - Status Description: Success; repeating VTODO ignored. Scheduled as - a single VTODO. - - Status Exception Data: RRULE or RDATE property name and value MAY be - specified. - - Description: iTIP operation succeeded but a repeating to-do was - truncated to a single instance. - - - - - - - - - - - - - - -Daboo Standards Track [Page 71] - -RFC 5546 iTIP December 2009 - - -3.6.12. Status Code 2.11 - - Status Code: 2.11 - - Status Description: Success; unbounded RRULE clipped at some finite - number of instances. - - Status Exception Data: RRULE property name and value MAY be - specified. Number of instances MAY also be specified. - - Description: iTIP operation succeeded but an unbounded repeating - object was clipped to a finite number of instances. - -3.6.13. Status Code 3.0 - - Status Code: 3.0 - - Status Description: Invalid property name. - - Status Exception Data: Property name MAY be specified. - - Description: iTIP operation failed because of an invalid property - name. - -3.6.14. Status Code 3.1 - - Status Code: 3.1 - - Status Description: Invalid property value. - - Status Exception Data: Property name and value MAY be specified. - - Description: iTIP operation failed because of an invalid property - value. - -3.6.15. Status Code 3.2 - - Status Code: 3.2 - - Status Description: Invalid property parameter. - - Status Exception Data: Property parameter name and value MAY be - specified. - - Description: iTIP operation failed because of an invalid property - parameter. - - - - - -Daboo Standards Track [Page 72] - -RFC 5546 iTIP December 2009 - - -3.6.16. Status Code 3.3 - - Status Code: 3.3 - - Status Description: Invalid property parameter value. - - Status Exception Data: Property parameter name and value MAY be - specified. - - Description: iTIP operation failed because of an invalid property - parameter value. - -3.6.17. Status Code 3.4 - - Status Code: 3.4 - - Status Description: Invalid calendar component sequence. - - Status Exception Data: Calendar component sentinel MAY be specified - (e.g., BEGIN:VTIMEZONE). - - Description: iTIP operation failed because of an invalid component. - -3.6.18. Status Code 3.5 - - Status Code: 3.5 - - Status Description: Invalid date or time. - - Status Exception Data: Date/time value(s) MAY be specified. - - Description: iTIP operation failed because of an invalid date or - time property. - -3.6.19. Status Code 3.6 - - Status Code: 3.6 - - Status Description: Invalid rule. - - Status Exception Data: RRULE property value MAY be specified. - - Description: iTIP operation failed because of an invalid rule - property. - - - - - - - -Daboo Standards Track [Page 73] - -RFC 5546 iTIP December 2009 - - -3.6.20. Status Code 3.7 - - Status Code: 3.7 - - Status Description: Invalid Calendar User. - - Status Exception Data: ATTENDEE property value MAY be specified. - - Description: iTIP operation failed because of an invalid ATTENDEE - property. - -3.6.21. Status Code 3.8 - - Status Code: 3.8 - - Status Description: No authority. - - Status Exception Data: METHOD and ATTENDEE property values MAY be - specified. - - Description: iTIP operation failed because an Attendee does not have - suitable privileges for the operation. - -3.6.22. Status Code 3.9 - - Status Code: 3.9 - - Status Description: Unsupported version. - - Status Exception Data: VERSION property name and value MAY be - specified. - - Description: iTIP operation failed because the calendar data version - is not supported. - -3.6.23. Status Code 3.10 - - Status Code: 3.10 - - Status Description: Request entity too large. - - Status Exception Data: None. - - Description: iTIP operation failed because the calendar data was too - large. - - - - - - -Daboo Standards Track [Page 74] - -RFC 5546 iTIP December 2009 - - -3.6.24. Status Code 3.11 - - Status Code: 3.11 - - Status Description: Required component or property missing. - - Status Exception Data: Component or property name MAY be specified. - - Description: iTIP operation failed because the calendar data did not - contain a required property or component. - -3.6.25. Status Code 3.12 - - Status Code: 3.12 - - Status Description: Unknown component or property found. - - Status Exception Data: Component or property name MAY be specified. - - Description: iTIP operation failed because the calendar data - contained an unknown property or component. - -3.6.26. Status Code 3.13 - - Status Code: 3.13 - - Status Description: Unsupported component or property found. - - Status Exception Data: Component or property name MAY be specified. - - Description: iTIP operation failed because the calendar data - contained an unsupported property or component. - -3.6.27. Status Code 3.14 - - Status Code: 3.14 - - Status Description: Unsupported capability. - - Status Exception Data: METHOD or action MAY be specified. - - Description: iTIP operation failed because the operation is not - supported. - - - - - - - - -Daboo Standards Track [Page 75] - -RFC 5546 iTIP December 2009 - - -3.6.28. Status Code 4.0 - - Status Code: 4.0 - - Status Description: Event conflict. Date/time is busy. - - Status Exception Data: DTSTART and DTEND property names and values - MAY be specified. - - Description: iTIP operation failed because the event overlaps the - date and time of another event. - -3.6.29. Status Code 5.0 - - Status Code: 5.0 - - Status Description: Request not supported. - - Status Exception Data: METHOD property value MAY be specified. - - Description: iTIP operation failed because the operation is not - supported. - -3.6.30. Status Code 5.1 - - Status Code: 5.1 - - Status Description: Service unavailable. - - Status Exception Data: ATTENDEE property value MAY be specified. - - Description: iTIP operation failed because scheduling is not active. - -3.6.31. Status Code 5.2 - - Status Code: 5.2 - - Status Description: Invalid calendar service. - - Status Exception Data: ATTENDEE property value MAY be specified. - - Description: iTIP operation failed because there is no scheduling - capability. - - - - - - - - -Daboo Standards Track [Page 76] - -RFC 5546 iTIP December 2009 - - -3.6.32. Status Code 5.3 - - Status Code: 5.3 - - Status Description: No scheduling support for user. - - Status Exception Data: ATTENDEE property value MAY be specified. - - Description: iTIP operation failed because scheduling is not enabled - for an Attendee. - -3.7. Implementation Considerations - -3.7.1. Working With Recurrence Instances - - iCalendar includes a recurrence grammar to represent recurring - events. The benefit of such a grammar is the ability to represent a - number of events in a single object. However, while this simplifies - creation of a recurring event, meeting instances still need to be - referenced. For instance, an "Attendee" may decline the third - instance of a recurring Friday event. Similarly, the "Organizer" may - change the time or location to a single instance of the recurring - event. - - Since implementations may elect to store recurring events as either a - single event object or a collection of discrete, related event - objects, the protocol is designed so that each recurring instance may - be both referenced and versioned. Hence, implementations that choose - to maintain per-instance properties (such as "ATTENDEE" property - "PARTSTAT" parameter) may do so. However, the protocol does not - require per-instance recognition unless the instance itself must be - renegotiated. - - The scenarios for recurrence instance referencing are listed below. - For purposes of simplification, a change to an event refers to a - "trigger property." That is, a property that has a substantive - effect on the meeting itself, such as start time, location, due date - (for "VTODO" calendar components), and possibly description. - - "Organizer"-initiated actions: - - o deletes or changes a single instance of a recurring event - - o makes changes that affect all future instances - - o makes changes that affect all previous instances - - o deletes or modifies a previously changed instance - - - -Daboo Standards Track [Page 77] - -RFC 5546 iTIP December 2009 - - - "Attendee"-initiated actions: - - o changes status for a particular recurrence instance - - o sends a "COUNTER" for a particular recurrence instance - - An instance of a recurring event is assigned a unique identification, - "RECURRENCE-ID" property, when that instance is renegotiated. - Negotiation may be necessary when a substantive change to the event - or to-do has been made (such as changing the start time, end time, - due date, or location). The "Organizer" can identify a specific - recurrence instance using the "RECURRENCE-ID" property. The property - value is equal to the date/time of the instance. If the "Organizer" - wishes to change the "DTSTART", the original, unmodified "DTSTART" - value of the instance is used as the value "RECURRENCE-ID" property, - and the new "DTSTART" and "DTEND" values reflect the change. - -3.7.2. Attendee Property Considerations - - 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. - - Email addresses that correspond to groups of "Calendar Users" could - be specified as a mailto: URI [RFC2368] calendar user address. - Sending email to such an address results in email being sent to - multiple recipients. Such an address may be used as the value of an - "ATTENDEE" property. Thus, it is possible that the recipient of a - "REQUEST" does not appear explicitly in the list. - - It is recommended that the general approach to finding a "Calendar - User" in an "Attendee" list be as follows: - - 1. Search for the "Calendar User" in the "Attendee" list where - "CUTYPE=INDIVIDUAL" - - 2. Failing (1), look for "Attendees" where "CUTYPE=GROUP" or - "CUTYPE=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 - - - -Daboo Standards Track [Page 78] - -RFC 5546 iTIP December 2009 - - - * the "MEMBER" property parameter is set to the name of the - group - - 3. Failing (2), the CUA MAY ignore or accept the request as the - "Calendar User" wishes. - -3.7.3. Extension Tokens - - To make iCalendar objects extensible, new component, property, or - property parameters can be used. Two types of extensions are defined - by [RFC5545]: IANA-registered tokens ("iana-token") and experimental - use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY - use them in replies. A client MAY save "x-name's" and MAY use them - in replies. When delegating or forwarding messages to other CUs, a - client SHOULD include "iana-token's" and "x-names's". - -4. Examples - -4.1. Published Event Examples - - In the calendaring and scheduling context, publication refers to the - one-way transfer of event information. Consumers of published events - simply incorporate the event into a calendar. No reply is expected. - Individual "A" publishes an event. Individual "B" reads the event - and incorporates it into their calendar. Events are published in - several ways, including embedding the event as an object in a web - page, emailing the event to a distribution list, or posting the event - to a newsgroup. - - The table below illustrates the sequence of events between the - publisher and the consumers of a published event. - - +----------------+-----------------------+--------------------------+ - | Action | Organizer | Receiver | - +----------------+-----------------------+--------------------------+ - | Publish an | "A" sends or posts a | "B" reads a published | - | event | PUBLISH message. | event. | - | | | | - | Publish an | "A" sends or posts a | "B" reads the updated | - | updated event | PUBLISH message. | event. | - | | | | - | Cancel a | "A" sends or posts a | "B" reads the canceled | - | published | CANCEL message. | event publication. | - | event | | | - +----------------+-----------------------+--------------------------+ - - - - - - -Daboo Standards Track [Page 79] - -RFC 5546 iTIP December 2009 - - -4.1.1. A Minimal Published Event - - The iCalendar object below describes a single event that begins on - July 1, 1997 at 20:00 UTC. This event contains the minimum set of - properties for a "PUBLISH" for a "VEVENT" calendar component. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTART:19970701T200000Z - DTSTAMP:19970611T190000Z - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - END:VEVENT - END:VCALENDAR - -4.1.2. Changing a Published Event - - The iCalendar object below describes an update to the event described - in Section 4.1.1; the time has been changed, an end time has been - added, and the sequence number has been adjusted. - - BEGIN:VCALENDAR - METHOD:PUBLISH - VERSION:2.0 - PRODID:-//Example/ExampleCalendarClient//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970612T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SEQUENCE:1 - UID:0981234-1234234-23@example.com - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - END:VEVENT - END:VCALENDAR - - The "UID" property is used by the client to identify the event. The - "SEQUENCE" property indicates that this is a change to the event. - The event with a matching "UID" and sequence number 0 is superseded - by this event. - - The "SEQUENCE" property provides a reliable way to distinguish - different versions of the same event. Each time an event is - published, its sequence number is incremented. If a client receives - - - -Daboo Standards Track [Page 80] - -RFC 5546 iTIP December 2009 - - - an event with a sequence number 5 and finds it has the same event - with sequence number 2, the event SHOULD be updated. However, if the - client received an event with sequence number 2 and finds it already - has sequence number 5 of the same event, the event MUST NOT be - updated. - -4.1.3. Canceling a Published Event - - The iCalendar object below cancels the event described in - Section 4.1.1. This cancels the event with "SEQUENCE" property of 0, - 1, and 2. - - BEGIN:VCALENDAR - METHOD:CANCEL - VERSION:2.0 - PRODID:-//Example/ExampleCalendarClient//EN - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - COMMENT:DUKES forfeit the game - SEQUENCE:2 - UID:0981234-1234234-23@example.com - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - -4.1.4. A Rich Published Event - - This example describes the same event as in Section 4.1.1, but in - much greater detail. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:PUBLISH - SCALE:GREGORIAN - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-Chicago - TZURL:http://example.com/tz/America-Chicago - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0500 - TZOFFSETTO:-0600 - TZNAME:CST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - - - -Daboo Standards Track [Page 81] - -RFC 5546 iTIP December 2009 - - - TZOFFSETFROM:-0600 - TZOFFSETTO:-0500 - TZNAME:CDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTACH:http://www.example.com/ - CATEGORIES:SPORTS EVENT,ENTERTAINMENT - CLASS:PRIVATE - DESCRIPTION:MIDWAY STADIUM\n - Big time game. MUST see.\n - Expected duration:2 hours\n - DTEND;TZID=America-Chicago:19970701T180000 - DTSTART;TZID=America-Chicago:19970702T160000 - DTSTAMP:19970614T190000Z - STATUS:CONFIRMED - LOCATION;VALUE=URI:http://stadium.example.com/ - PRIORITY:2 - RESOURCES:SCOREBOARD - SEQUENCE:3 - SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES - UID:0981234-1234234-23@example.com - RELATED-TO:0981234-1234234-14@example.com - BEGIN:VALARM - TRIGGER:-PT2H - ACTION:DISPLAY - DESCRIPTION:You should be leaving for the game now. - END:VALARM - BEGIN:VALARM - TRIGGER:-PT30M - ACTION:AUDIO - END:VALARM - END:VEVENT - END:VCALENDAR - - The "RELATED-TO" field contains the "UID" property of a related - calendar event. The "SEQUENCE" property 3 indicates that this event - supersedes versions 0, 1, and 2. - - - - - - - - - - - - -Daboo Standards Track [Page 82] - -RFC 5546 iTIP December 2009 - - -4.1.5. Anniversaries or Events Attached to Entire Days - - This example demonstrates the use of the "VALUE" parameter to tie a - "VEVENT" to a day rather than a specific time. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:PUBLISH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - DTSTAMP:19970614T190000Z - UID:0981234-1234234-23@example.com - DTSTART;VALUE=DATE:19970714 - RRULE:FREQ=YEARLY;INTERVAL=1 - SUMMARY: Bastille Day - END:VEVENT - END:VCALENDAR - -4.2. Group Event Examples - - Group events are distinguished from published events in that they - have "Attendees" and there is interaction between the "Attendees" and - the "Organizer" with respect to the event. Individual "A" requests a - meeting between individuals "A", "B", "C", and "D". Individual "B" - confirms attendance to the meeting. Individual "C" declines - attendance. Individual "D" tentatively confirms attendance. The - following table illustrates the message flow between these - individuals. "A", the CU scheduling the meeting, is referenced as - the "Organizer". - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 83] - -RFC 5546 iTIP December 2009 - - - +--------------+-----------------------+----------------------------+ - | Action | "Organizer" | Attendee | - +--------------+-----------------------+----------------------------+ - | Initiate a | "A" sends a REQUEST | | - | meeting | message to "B", "C", | | - | request | and "D". | | - | | | | - | Accept the | | "B" sends a REPLY message | - | meeting | | to "A" with its ATTENDEE | - | request | | PARTSTAT parameter set to | - | | | ACCEPTED. | - | | | | - | Decline the | | "C" sends a REPLY message | - | meeting | | to "A" with its ATTENDEE | - | request | | PARTSTAT parameter set to | - | | | DECLINED. | - | | | | - | Tentatively | | "D" sends a REPLY message | - | accept the | | to "A" with its ATTENDEE | - | meeting | | PARTSTAT parameter set to | - | request | | TENTATIVE. | - | | | | - | Confirm | "A" sends a REQUEST | | - | meeting | message to "B" and | | - | status with | "D" with updated | | - | Attendees | information. | | - +--------------+-----------------------+----------------------------+ - -4.2.1. A Group Event Request - - A sample meeting request is sent from "A" to "B", "C", and "D". "E" - is also sent a copy of the request but is not expected to attend and - need not reply. "E" illustrates how CUAs might implement an "FYI"- - type feature. Note the use of the "ROLE" parameter. The default - value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not - be enumerated. In this case, we are using the value "NON- - PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is - not needed on other "Attendees" since "PARTICIPANT" is the default - value. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com - - - -Daboo Standards Track [Page 84] - -RFC 5546 iTIP December 2009 - - - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com - ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T2100000Z - SUMMARY:Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.2. Reply to a Group Event Request - - "Attendee" "B" accepts the meeting. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com - ORGANIZER:mailto:a@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970612T190000Z - END:VEVENT - END:VCALENDAR - - "B" could have declined the meeting or indicated tentative acceptance - by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or - "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in - successful transactions. - -4.2.3. Update an Event - - The event is moved to a different time. The combination of the "UID" - property (unchanged) and the "SEQUENCE" (bumped to 1) properties - indicate the update. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - - - -Daboo Standards Track [Page 85] - -RFC 5546 iTIP December 2009 - - - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; - CUTYPE=ROOM:mailto:conf@example.com - ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com - DTSTART:19970701T180000Z - DTEND:19970701T190000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - DTSTAMP:19970613T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.4. Countering an Event Proposal - - "A" sends a "REQUEST" to "B" and "C". "B" makes a counter proposal - to "A" to change the time and location. - - "A" sends the following "REQUEST": - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com - DTSTART:19970701T190000Z - DTEND:19970701T200000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Green Conference Room - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - DTSTAMP:19970611T190000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - - - - -Daboo Standards Track [Page 86] - -RFC 5546 iTIP December 2009 - - - "B" sends "COUNTER" to "A", requesting changes to time and place. - "B" uses the "COMMENT" property to communicate a rationale for the - change. Note that the "SEQUENCE" property is not incremented on a - "COUNTER". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:COUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com - DTSTART:19970701T160000Z - DTEND:19970701T170000Z - DTSTAMP:19970612T190000Z - SUMMARY:Discuss the Merits of the election results - LOCATION:Blue Conference Room - COMMENT:This time works much better and I think the big conference - room is too big - UID:calsrv.example.com-873970198738777a@example.com - SEQUENCE:0 - END:VEVENT - END:VCALENDAR - - "A" accepts the changes from "B". To accept a counter proposal, the - "Organizer" sends a new event "REQUEST" with an incremented sequence - number. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T160000Z - DTEND:19970701T170000Z - SUMMARY:Discuss the Merits of the election results - changed to - meet B's schedule - LOCATION:Blue Conference Room - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CONFIRMED - - - -Daboo Standards Track [Page 87] - -RFC 5546 iTIP December 2009 - - - END:VEVENT - END:VCALENDAR - - Instead, "A" rejects "B's" counter proposal. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:DECLINECOUNTER - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - COMMENT:Sorry, I cannot change this meeting time - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.5. Delegating an Event - - When delegating an event request to another "Calendar User", the - "Delegator" must both update the "Organizer" with a "REPLY" and send - a request to the "Delegate". There is currently no protocol - limitation to delegation depth. It is possible for the original - delegate to delegate the meeting to someone else, and so on. When a - request is delegated from one CUA to another, there are a number of - responsibilities required of the "Delegator". The "Delegator" MUST: - - o Send a "REPLY" to the "Organizer" with the following updates: - - A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter is - set to "DELEGATED" and the "DELEGATED-TO" parameter is set to - the address of the "Delegate". - - B. Add an additional "ATTENDEE" property for the "Delegate" with - the "DELEGATED-FROM" property parameter set to the - "Delegator". - - C. Indicate whether they want to continue to receive updates when - the "Organizer" sends out updated versions of the event. - Setting the "RSVP" property parameter to "TRUE" will cause the - updates to be sent; setting it to "FALSE" causes no further - updates to be sent. Note that in either case, if the - "Delegate" declines the invitation, the "Delegator" will be - notified. - - - - - -Daboo Standards Track [Page 88] - -RFC 5546 iTIP December 2009 - - - o The "Delegator" MUST also send a copy of the original "REQUEST" - method to the "Delegate", with changes (A) and (B), as detailed - above applied. - - If the "Delegate" declines the meeting, the "Organizer" MUST send an - update "REQUEST" to the "Delegator" so that the "Delegator" may elect - to delegate the "REQUEST" to another CUA. - - +----------------+-----------------+--------------------------------+ - | Action | "Organizer" | Attendee | - +----------------+-----------------+--------------------------------+ - | Initiate a | "A" sends a | | - | meeting | REQUEST message | | - | request | to "B" and "C". | | - | | | | - | Delegate: "C" | | "C" sends a REPLY to "A" with | - | delegates to | | the ATTENDEE PARTSTAT | - | "E" | | parameter set to DELEGATED and | - | | | with a new ATTENDEE property | - | | | for "E". "E's" ATTENDEE | - | | | DELEGATED-FROM parameter is | - | | | set to "C". "C's" ATTENDEE | - | | | DELEGATED-TO parameter is set | - | | | to "E". "C" sends REQUEST | - | | | message to "E" with the | - | | | original meeting request | - | | | information. The PARTSTAT | - | | | property parameter for "C" is | - | | | set to DELEGATED and the | - | | | DELEGATED-TO parameter is set | - | | | to the address of "E". An | - | | | ATTENDEE property is added for | - | | | "E" and the DELEGATED-FROM | - | | | parameter is set to the | - | | | address of "C". | - | | | | - | Confirm | | "E" sends REPLY message to | - | meeting | | "A", and optionally to "C", | - | attendance | | with its PARTSTAT property | - | | | parameter set to ACCEPTED. | - | | | | - | Optional: | "A" sends | | - | Redistribute | REQUEST message | | - | meeting to | to "B", "C", | | - | Attendees | and "E". | | - +----------------+-----------------+--------------------------------+ - - - - - -Daboo Standards Track [Page 89] - -RFC 5546 iTIP December 2009 - - - "C" responds to the "Organizer". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="mailto:e@example.com":mailto:c@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - - "Attendee" "C" delegates presence at the meeting to "E". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- - TO="mailto:e@example.com":mailto:c@example.com - ATTENDEE;RSVP=TRUE; - DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - STATUS:CONFIRMED - DTSTAMP:19970611T190000Z - END:VEVENT - END:VCALENDAR - -4.2.6. Delegate Accepts the Meeting - - To accept a delegated meeting, the delegate, "E", sends the following - message to "A" and "C". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - - - -Daboo Standards Track [Page 90] - -RFC 5546 iTIP December 2009 - - - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- - FROM="mailto:c@example.com":mailto:e@example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="mailto:e@example.com":mailto:c@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - -4.2.7. Delegate Declines the Meeting - - In this example, the "Delegate" declines the meeting request and sets - the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The - "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" - parameter of the "Delegate" set to "DECLINED". This lets the - "Delegator" know that the "Delegate" has declined and provides an - opportunity to the "Delegator" to either accept the request or - delegate it to another CU. - - "E" responds to "A" and "C". Note the use of the "COMMENT" property - "E" uses to indicate why the delegation was declined. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=DELEGATED; - DELEGATED-TO="mailto:e@example.com":mailto:c@example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com - COMMENT:Sorry, I will be out of town at that time. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - REQUEST-STATUS:2.0;Success - DTSTAMP:19970614T190000Z - END:VEVENT - END:VCALENDAR - - "A" resends the "REQUEST" method to "C". "A" may also wish to - express the fact that the item was delegated in the "COMMENT" - property. - - - - -Daboo Standards Track [Page 91] - -RFC 5546 iTIP December 2009 - - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=DECLINED; - DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:0 - SUMMARY:Phone Conference - DTSTART:19970701T180000Z - DTEND:19970701T200000Z - DTSTAMP:19970614T200000Z - COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR - INVITATION - END:VEVENT - END:VCALENDAR - -4.2.8. Forwarding an Event Request - - The protocol does not prevent an "Attendee" from "forwarding" a - "VEVENT" calendar component to other "Calendar Users". Forwarding - differs from delegation in that the forwarded "Calendar User" (often - referred to as a "Party Crasher") does not replace the forwarding - "Calendar User". Implementations are not required to add the "Party - Crasher" to the "Attendee" list, and hence there is no guarantee that - a "Party Crasher" will receive additional updates to the event. The - forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the - "Attendee" list. The "Organizer" MAY add the forwarded "Calendar - User" to the "Attendee" list. - -4.2.9. Cancel a Group Event - - Individual "A" requests a meeting between individuals "A", "B", "C", - and "D". Individual "B" declines attendance to the meeting. - Individual "A" decides to cancel the meeting. The following table - illustrates the sequence of messages that would be exchanged between - these individuals. - - Messages related to a previously canceled event ("SEQUENCE" property - value is less than the "SEQUENCE" property value of the "CANCEL" - message) MUST be ignored. - - - - - - - -Daboo Standards Track [Page 92] - -RFC 5546 iTIP December 2009 - - - +-------------+---------------------+-------------------------------+ - | Action | Organizer | Attendee | - +-------------+---------------------+-------------------------------+ - | Initiate a | "A" sends a REQUEST | | - | meeting | message to "B", | | - | request | "C", and "D". | | - | | | | - | Decline the | | "B" sends a REPLY message to | - | meeting | | "A" with its PARTSTAT | - | request | | parameter set to DECLINED. | - | | | | - | Cancel the | "A" sends a CANCEL | | - | meeting | message to "B", | | - | | "C", and "D". | | - +-------------+---------------------+-------------------------------+ - - This example shows how "A" cancels the event. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com - COMMENT:Mr. B cannot attend. It's raining. Lets cancel. - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:1 - STATUS:CANCELLED - DTSTAMP:19970613T190000Z - END:VEVENT - END:VCALENDAR - -4.2.10. Removing Attendees - - "A" wants to remove "B" from a meeting. This is done by sending a - "CANCEL" to "B" and removing "B" from the "Attendee" list in the - master copy of the event. - - - - - - - - - - -Daboo Standards Track [Page 93] - -RFC 5546 iTIP December 2009 - - - +--------------------+-----------------------------------+----------+ - | Action | Organizer | Attendee | - +--------------------+-----------------------------------+----------+ - | Remove "B" as an | "A" sends a CANCEL message to | | - | Attendee | "B". | | - | | | | - | Update the master | "A" optionally sends the updated | | - | copy of the event | event to the remaining Attendees. | | - +--------------------+-----------------------------------+----------+ - - The original meeting includes "A", "B", "C", and "D". The example - below shows the "CANCEL" that "A" sends to "B". Note that in the - example below, the "STATUS" property is omitted. This is used when - the meeting itself is cancelled and not when the intent is to remove - an "Attendee" from the event. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:CANCEL - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE:mailto:b@example.com - COMMENT:You're off the hook for this meeting - UID:calsrv.example.com-873970198738777@example.com - DTSTAMP:19970613T193000Z - SEQUENCE:1 - END:VEVENT - END:VCALENDAR - - The updated master copy of the event is shown below. The "Organizer" - MAY resend the updated event to the remaining "Attendees". Note that - "B" has been removed. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com - ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com - ATTENDEE;ROLE=NON-PARTICIPANT; - RSVP=FALSE:mailto:e@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - - - -Daboo Standards Track [Page 94] - -RFC 5546 iTIP December 2009 - - - DTEND:19970701T203000Z - SUMMARY:Phone Conference - UID:calsrv.example.com-873970198738777@example.com - SEQUENCE:2 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2.11. Replacing the Organizer - - The scenario for this example begins with "A" as the "Organizer" for - a recurring meeting with "B", "C", and "D". "A" receives a new job - offer in another country and drops out of touch. "A" left no - forwarding address or way to be reached. Using out-of-band - communication, the other "Attendees" eventually learn what has - happened and reach an agreement that "B" should become the new - "Organizer" for the meeting. To do this, "B" sends out a new version - of the event and the other "Attendees" agree to accept "B" as the new - "Organizer". "B" also removes "A" from the event. - - When the "Organizer" is replaced, the "SEQUENCE" property value MUST - be incremented. - - This is the message "B" sends to "C" and "D". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:b@example.com - ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com - ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T200000Z - DTEND:19970701T203000Z - RRULE:FREQ=WEEKLY - SUMMARY:Phone Conference - UID:123456@example.com - SEQUENCE:1 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - - - - -Daboo Standards Track [Page 95] - -RFC 5546 iTIP December 2009 - - -4.3. Busy Time Examples - - Busy time objects can be used in several ways. First, a CU may - request busy time from another CU for a specific range of time. That - request can be answered with a busy time "REPLY". Additionally, a CU - may simply publish their busy time for a given interval and point - other CUs to the published location. The following examples outline - both scenarios. - -4.3.1. Publish Busy Time - - Individual "A" publishes busy time for one week. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - METHOD:PUBLISH - BEGIN:VFREEBUSY - DTSTAMP:19980101T124100Z - ORGANIZER:mailto:a@example.com - DTSTART:19980101T124200Z - DTEND:19980108T124200Z - FREEBUSY:19980101T180000Z/19980101T190000Z - FREEBUSY:19980103T020000Z/19980103T050000Z - FREEBUSY:19980107T020000Z/19980107T050000Z - FREEBUSY:19980113T000000Z/19980113T010000Z - FREEBUSY:19980115T190000Z/19980115T200000Z - FREEBUSY:19980115T220000Z/19980115T230000Z - FREEBUSY:19980116T013000Z/19980116T043000Z - END:VFREEBUSY - END:VCALENDAR - -4.3.2. Request Busy Time - - Individual "A" requests busy time from individuals "B" and "C". - Individuals "B" and "C" reply with busy time data to individual "A". - The following table illustrates the sequence of messages that would - be exchanged between these individuals. - - - - - - - - - - - - - -Daboo Standards Track [Page 96] - -RFC 5546 iTIP December 2009 - - - +---------------------+--------------------+------------------------+ - | Action | Organizer | Attendee | - +---------------------+--------------------+------------------------+ - | Initiate a busy | "A" sends REQUEST | | - | time request | message to "B" and | | - | | "C". | | - | | | | - | Reply to the BUSY | | "B" sends a REPLY | - | request with BUSY | | message to "A" with | - | time data | | busy time data. | - +---------------------+--------------------+------------------------+ - - "A" sends a "REQUEST" to "B" and "C" for busy time. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - DTSTAMP:19970613T190000Z - DTSTART:19970701T080000Z - DTEND:19970701T200000 - UID:calsrv.example.com-873970198738777@example.com - END:VFREEBUSY - END:VCALENDAR - -4.3.3. Reply to a Busy Time Request - - "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component - to "A". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VFREEBUSY - ORGANIZER:mailto:a@example.com - ATTENDEE:mailto:b@example.com - DTSTART:19970701T080000Z - DTEND:19970701T200000Z - UID:calsrv.example.com-873970198738777@example.com - FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M - DTSTAMP:19970613T190030Z - END:VFREEBUSY - - - -Daboo Standards Track [Page 97] - -RFC 5546 iTIP December 2009 - - - END:VCALENDAR - - "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. - -4.4. Recurring Event and Time Zone Examples - -4.4.1. A Recurring Event Spanning Time Zones - - This event describes a weekly phone conference. The "Attendees" are - each in a different time zone. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTIMEZONE - TZID:America-SanJose - TZURL:http://example.com/tz/America-SanJose - BEGIN:STANDARD - DTSTART:19671029T020000 - RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 - TZOFFSETFROM:-0700 - TZOFFSETTO:-0800 - TZNAME:PST - END:STANDARD - BEGIN:DAYLIGHT - DTSTART:19870405T020000 - RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 - TZOFFSETFROM:-0800 - TZOFFSETTO:-0700 - TZNAME:PDT - END:DAYLIGHT - END:VTIMEZONE - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; - CUTYPE=INDIVIDUAL:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp - DTSTAMP:19970613T190030Z - DTSTART;TZID=America-SanJose:19970701T140000 - DTEND;TZID=America-SanJose:19970701T150000 - RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU - RDATE;TZID=America-SanJose:19970910T140000 - EXDATE;TZID=America-SanJose:19970909T140000 - EXDATE;TZID=America-SanJose:19971028T140000 - SUMMARY:Weekly Phone Conference - UID:calsrv.example.com-873970198738777@example.com - - - -Daboo Standards Track [Page 98] - -RFC 5546 iTIP December 2009 - - - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The first component of this iCalendar object is the time zone - component. The "DTSTART" date coincides with the first instance of - the "RRULE" property. - - The recurring meeting is defined in a particular time zone, - presumably that of the originator. The client for each "Attendee" - has the responsibility of determining the recurrence time in the - "Attendee's" time zone. - - The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT - (UTC-7). "Attendee" B@example.fr is in France, where the local time - on this date is 9 hours ahead of PDT, or 23:00 CEST (UTC+2). - "Attendee" C@example.jp is in Japan, where local time is 16 hours - ahead of PDT, or Wednesday, July 2 at 06:00 JST (UTC+9). The event - repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property - results in 20 instances. The last instance falls on Tuesday, - November 11, 1997 2:00pm PST. The "RDATE" property adds another - instance: WED, 10-SEP-1997 2:00 PM PDT. - - There are also two exception dates to the recurrence rule. The first - one is: - - o TUE, 09-SEP-1997 14:00 PDT (UTC-7) - - o TUE, 09-SEP-1997 23:00 CEST (UTC+2) - - o WED, 10-SEP-1997 06:00 JST (UTC+9) - - - and the second is: - - o TUE, 28-OCT-1997 14:00 PST (UTC-8) - - o TUE, 28-OCT-1997 23:00 CET (UTC+1) - - o WED, 29-OCT-1997 07:00 JST (UTC+9) - -4.4.2. Modify a Recurring Instance - - In this example, the "Organizer" issues a recurring meeting. Later, - the "Organizer" changes an instance of the event by changing the - "DTSTART" property. Note the use of "RECURRENCE-ID" property and - "SEQUENCE" property in the second request. - - - -Daboo Standards Track [Page 99] - -RFC 5546 iTIP December 2009 - - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - ATTENDEE:mailto:d@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - DTEND:19970601T220000Z - LOCATION:Conference Call - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The event request below is to change the time of a specific instance. - This changes the July 1st instance to July 3rd. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - RECURRENCE-ID:19970701T210000Z - SEQUENCE:1 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - ATTENDEE:mailto:d@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970703T210000Z - DTEND:19970703T220000Z - LOCATION:Conference Call - - - -Daboo Standards Track [Page 100] - -RFC 5546 iTIP December 2009 - - - DTSTAMP:19970626T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.3. Cancel an Instance - - In this example, the "Organizer" of a recurring event deletes the - August 1st instance. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - ATTENDEE:mailto:d@example.com - RECURRENCE-ID:19970801T210000Z - SEQUENCE:2 - STATUS:CANCELLED - DTSTAMP:19970721T093000Z - END:VEVENT - END:VCALENDAR - -4.4.4. Cancel a Recurring Event - - In this example, the "Organizer" wishes to cancel the entire - recurring event and any exceptions. - - BEGIN:VCALENDAR - METHOD:CANCEL - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - ATTENDEE:mailto:d@example.com - DTSTAMP:19970721T103000Z - STATUS:CANCELLED - SEQUENCE:3 - END:VEVENT - - - -Daboo Standards Track [Page 101] - -RFC 5546 iTIP December 2009 - - - END:VCALENDAR - -4.4.5. Change All Future Instances - - This example changes the meeting location from a conference call to - Seattle, starting September 1 and extending to all future instances. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - RECURRENCE-ID;THISANDFUTURE:19970901T210000Z - SEQUENCE:3 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - ATTENDEE;RSVP=TRUE:mailto:d@example.com - DESCRIPTION:IETF-C&S Discussion - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970901T210000Z - DTEND:19970901T220000Z - LOCATION:Building 32, Microsoft, Seattle, WA - DTSTAMP:19970526T083000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.6. Add a New Instance to a Recurring Event - - This example adds a one-time additional instance to the recurring - event. "Organizer" adds a second July meeting on the 15th. - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:4 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - ATTENDEE;RSVP=TRUE:mailto:d@example.com - - - -Daboo Standards Track [Page 102] - -RFC 5546 iTIP December 2009 - - - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T210000Z - DTEND:19970715T220000Z - LOCATION:Conference Call - DTSTAMP:19970629T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.7. Add a New Series of Instances to a Recurring Event - - The scenario for this example involves an ongoing meeting, originally - set up to occur every Tuesday. The "Organizer" later decides that - the meetings need to be on Tuesdays and Thursdays. - - The original event: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:0 - RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - LOCATION:The White Room - DTSTAMP:19980301T093000Z - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - The entire event can be rescheduled using a "REQUEST". This is done - by using the "UID" of the event to reschedule and including the - modified "RRULE". Note that since this is an entire rescheduling of - the event, any instance-specific information will be lost, unless - explicitly included with the update "REQUEST". - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - - - -Daboo Standards Track [Page 103] - -RFC 5546 iTIP December 2009 - - - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:7 - RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980303T210000Z - DTEND:19980303T220000Z - DTSTAMP:19980303T193000Z - LOCATION:The White Room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.8. Refreshing a Recurring Event - - The next series of examples illustrate how an "Organizer" would - respond to a "REFRESH" submitted by an "Attendee" after a series of - instance-specific modifications. To convey all instance-specific - changes, the "Organizer" must provide the latest event description - and the relevant instances. The first three examples show the - history, including the initial "VEVENT" request and subsequent - instance changes, and finally the "REFRESH". - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:0 - RDATE:19980304T180000Z - RDATE:19980311T180000Z - RDATE:19980318T180000Z - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - - - -Daboo Standards Track [Page 104] - -RFC 5546 iTIP December 2009 - - - END:VEVENT - END:VCALENDAR - - Organizer changes 2nd instance location and time: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:1 - RECURRENCE-ID:19980311T180000Z - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980311T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - Organizer adds a 4th instance of the meeting using the "ADD" method. - - BEGIN:VCALENDAR - METHOD:ADD - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:2 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980315T180000Z - DTEND:19980315T200000Z - DTSTAMP:19980307T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - - - -Daboo Standards Track [Page 105] - -RFC 5546 iTIP December 2009 - - - If "B" requests a "REFRESH", "A" responds with the following to - capture all instance-specific data. In this case, both the initial - request and an additional "VEVENT" that specifies the instance- - specific data are included. Because these are both of the same type - (they are both "VEVENTS"), they can be conveyed in the same iCalendar - object. - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:123456789@example.com - SEQUENCE:2 - RDATE:19980304T180000Z - RDATE:19980311T160000Z - RDATE:19980315T180000Z - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980304T180000Z - DTEND:19980304T200000Z - DTSTAMP:19980303T193000Z - LOCATION:Conference Room A - STATUS:CONFIRMED - END:VEVENT - BEGIN:VEVENT - SEQUENCE:2 - UID:123456789@example.com - RECURRENCE-ID:19980311T160000Z - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - SUMMARY:Review Accounts - DTSTART:19980311T160000Z - DTEND:19980304T180000Z - DTSTAMP:19980306T193000Z - LOCATION:The Small conference room - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.4.9. Counter an Instance of a Recurring Event - - In this example, one of the "Attendees" counters the "DTSTART" - property of the proposed second July meeting. - - - - - -Daboo Standards Track [Page 106] - -RFC 5546 iTIP December 2009 - - - BEGIN:VCALENDAR - METHOD:COUNTER - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - RECURRENCE-ID:19970715T210000Z - SEQUENCE:4 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - ATTENDEE;RSVP=TRUE:mailto:d@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970715T220000Z - DTEND:19970715T230000Z - LOCATION:Conference Call - COMMENT:May we bump this by an hour? I have a conflict - DTSTAMP:19970629T094000Z - END:VEVENT - END:VCALENDAR - -4.4.10. Error Reply to a Request - - The following example illustrates a scenario where a meeting is - proposed containing an unsupported property and a bad property. - - Original Request: - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:guid-1@example.com - SEQUENCE:0 - RRULE:FREQ=MONTHLY;BYMONTHDAY=1 - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - ATTENDEE;RSVP=TRUE:mailto:d@example.com - DESCRIPTION:IETF-C&S Conference Call - CLASS:PUBLIC - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970601T210000Z - - - -Daboo Standards Track [Page 107] - -RFC 5546 iTIP December 2009 - - - DTEND:19970601T220000Z - DTSTAMP:19970602T094000Z - LOCATION:Conference Call - STATUS:CONFIRMED - FOO:BAR - END:VEVENT - END:VCALENDAR - - "B" responds to indicate that "RRULE" is not supported and that an - unrecognized property was encountered. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE:mailto:b@example.com - REQUEST-STATUS:3.0;Invalid Property Name;FOO - UID:guid-1@example.com - SEQUENCE:0 - DTSTAMP:19970603T094000Z - END:VEVENT - END:VCALENDAR - -4.5. Group To-Do Examples - - Individual "A" creates a group task in which individuals "A", "B", - "C", and "D" will participate. Individual "B" confirms acceptance of - the task. Individual "C" declines the task. Individual "D" - tentatively accepts the task. The following table illustrates the - sequence of messages that would be exchanged between these - individuals. Individual "A" then issues a "REQUEST" method to obtain - the status of the to-do from each participant. The response - indicates the individual "Attendee's" completion status. The table - below illustrates the message flow. - - - - - - - - - - - - - - - -Daboo Standards Track [Page 108] - -RFC 5546 iTIP December 2009 - - - +--------------+------------------------+---------------------------+ - | Action | Organizer | Attendee | - +--------------+------------------------+---------------------------+ - | Initiate a | "A" sends a REQUEST | | - | to-do | message to "B", "C", | | - | request | and "D". | | - | | | | - | Accept the | | "B" sends a REPLY message | - | to-do | | to "A" with its PARTSTAT | - | request | | parameter set to | - | | | ACCEPTED. | - | | | | - | Decline the | | "C" sends a REPLY message | - | to-do | | to "A" with its PARTSTAT | - | request | | parameter set to | - | | | DECLINED. | - | | | | - | Tentatively | | "D" sends a REPLY message | - | accept the | | to "A" with its PARTSTAT | - | to-do | | parameter set to | - | request | | TENTATIVE. | - | | | | - | Check | "A" sends a REQUEST | | - | Attendee | message to "B" and "D" | | - | completion | with current | | - | status | information. | | - | | | | - | Attendee | | "B" sends a REPLY message | - | indicates | | indicating percent | - | percent | | complete. | - | complete | | | - | | | | - | Attendee | | "D" sends a REPLY message | - | indicates | | indicating completion. | - | completion | | | - +--------------+------------------------+---------------------------+ - -4.5.1. A VTODO Request - - A sample "REQUEST" for a "VTODO" calendar component that "A" sends to - "B", "C", and "D". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - - - -Daboo Standards Track [Page 109] - -RFC 5546 iTIP December 2009 - - - ATTENDEE;ROLE=CHAIR:mailto:a@example.com - ATTENDEE;RSVP=TRUE:mailto:b@example.com - ATTENDEE;RSVP=TRUE:mailto:c@example.com - ATTENDEE;RSVP=TRUE:mailto:d@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:NEEDS-ACTION - END:VTODO - END:VCALENDAR - -4.5.2. A VTODO Reply - - "B" accepts the to-do. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com - UID:calsrv.example.com-873970198738777-00@example.com - COMMENT:I'll send you my input by email - SEQUENCE:0 - DTSTAMP:19970717T203000Z - REQUEST-STATUS:2.0;Success - END:VTODO - END:VCALENDAR - - "B" could have declined the "VTODO" or indicated tentative acceptance - by setting the "PARTSTAT" property parameter sequence to "DECLINED" - or "TENTATIVE", respectively. - -4.5.3. A VTODO Request for Updated Status - - "A" requests status from all "Attendees". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - - - -Daboo Standards Track [Page 110] - -RFC 5546 iTIP December 2009 - - - ATTENDEE;ROLE=CHAIR:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com - UID:calsrv.example.com-873970198738777-00@example.com - SUMMARY:Create the requirements document - PRIORITY:1 - SEQUENCE:0 - STATUS:IN-PROCESS - DTSTART:19970701T170000Z - DTSTAMP:19970717T230000Z - END:VTODO - END:VCALENDAR - -4.5.4. A Reply: Percent-Complete - - A reply indicating the task being worked on and that "B" is 75% - complete with "B's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - -4.5.5. A Reply: Completed - - A reply indicating that "D" completed "D's" part of the assignment. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - SEQUENCE:0 - END:VTODO - END:VCALENDAR - - - -Daboo Standards Track [Page 111] - -RFC 5546 iTIP December 2009 - - -4.5.6. An Updated VTODO Request - - "Organizer" "A" resends the "VTODO" calendar component. "A" sets the - overall completion for the to-do at 40%. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com - DTSTART:19970701T170000Z - DUE:19970722T170000Z - PRIORITY:1 - SUMMARY:Create the requirements document - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:1 - DTSTAMP:19970718T100000Z - STATUS:IN-PROCESS - PERCENT-COMPLETE:40 - END:VTODO - END:VCALENDAR - -4.5.7. Recurring VTODOs - - The following examples relate to recurring "VTODO" calendar - components. - -4.5.7.1. Request for a Recurring VTODO - - In this example, "A" sends a recurring "VTODO" calendar component to - "B" and "D". - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR:mailto:a@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com - ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com - RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR - DTSTART:19980101T100000Z - DUE:19980103T100000Z - - - -Daboo Standards Track [Page 112] - -RFC 5546 iTIP December 2009 - - - SUMMARY:Send Status Reports to Area Managers - UID:calsrv.example.com-873970198738777-00@example.com - SEQUENCE:0 - DTSTAMP:19970717T200000Z - STATUS:NEEDS-ACTION - PRIORITY:1 - END:VTODO - END:VCALENDAR - -4.5.7.2. Replying to an Instance of a Recurring VTODO - - In this example, "B" updates "A" on a single instance of the "VTODO" - calendar component. - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REPLY - VERSION:2.0 - BEGIN:VTODO - ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com - PERCENT-COMPLETE:75 - UID:calsrv.example.com-873970198738777-00@example.com - DTSTAMP:19970717T233000Z - RECURRENCE-ID:19980101T170000Z - SEQUENCE:1 - END:VTODO - END:VCALENDAR - -4.6. Journal Examples - - The iCalendar object below describes a single journal entry for - October 2, 1997. The "RELATED-TO" property references the phone - conference event for which minutes were taken. - - BEGIN:VCALENDAR - METHOD:PUBLISH - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VJOURNAL - DTSTART:19971002T200000Z - DTSTAMP:19970717T233100Z - ORGANIZER:mailto:a@example.com - SUMMARY:Phone conference minutes - DESCRIPTION:The editors meeting was held on October 1, 1997. - Details are in the attached document. - UID:0981234-1234234-2410@example.com - RELATED-TO:0981234-1234234-2402-35@example.com - ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt - - - -Daboo Standards Track [Page 113] - -RFC 5546 iTIP December 2009 - - - END:VJOURNAL - END:VCALENDAR - -4.7. Other Examples - -4.7.1. Event Refresh - - Refresh the event with a "UID" property value of - "guid-1-12345@example.com": - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - ATTENDEE:mailto:c@example.com - ATTENDEE:mailto:d@example.com - UID:guid-1-12345@example.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -4.7.2. Bad RECURRENCE-ID - - Component instances are identified by the combination of "UID", - "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP - message to an "Attendee", there are three cases in which an instance - cannot be found. They are: - - 1. The component with the referenced "UID" and "RECURRENCE-ID" has - been found but the "SEQUENCE" number in the calendar store does - not match that of the iTIP message. - - 2. The component with the referenced "UID" has been found, the - "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be - found. - - 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not - support recurrences. - - In case (1), two things can happen. If the "SEQUENCE" number of the - "Attendee's" instance is larger than that in the "Organizer's" - message, then the "Attendee" is receiving an out-of-sequence message - and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" - instance is smaller, then the "Organizer" is sending out a newer - - - -Daboo Standards Track [Page 114] - -RFC 5546 iTIP December 2009 - - - version of the component and the "Attendee's" version needs to be - updated. Since one or more updates have been missed, the "Attendee" - SHOULD send a "REFRESH" message to the "Organizer" to get an updated - version of the event. - - In case (2), something has gone wrong. Both the "Organizer" and the - "Attendee" should have the same instances, but the "Attendee" does - not have the referenced instance. In this case, the "Attendee" - SHOULD send a "REFRESH" to the "Organizer" to get an updated version - of the event. - - In case (3), the limitations of the "Attendee's" CUA makes it - impossible to match an instance other than the single instance - scheduled. In this case, the "Attendee" need not send a "REFRESH" to - the "Organizer". - - The example below shows a sequence in which an "Attendee" sends a - "REFRESH" to the "Organizer". - - +-------------------------+--------------------+--------------------+ - | Action | Organizer | Attendee | - +-------------------------+--------------------+--------------------+ - | Update an instance | "A" sends REQUEST | | - | request | message to "B". | | - | | | | - | Attendee requests | | "B" sends a | - | refresh because | | REFRESH message to | - | RECURRENCE-ID was not | | "A". | - | found | | | - | | | | - | Refresh the entire | "A" sends the | | - | event | latest copy of the | | - | | event to "B" | | - | | | | - | Attendee handles the | | "B" updates to the | - | request and updates the | | latest copy of the | - | instance | | meeting. | - +-------------------------+--------------------+--------------------+ - - Request from "A": - - BEGIN:VCALENDAR - METHOD:REQUEST - PRODID:-//Example/ExampleCalendarClient//EN - VERSION:2.0 - BEGIN:VEVENT - UID:example-12345@example.com - SEQUENCE:3 - - - -Daboo Standards Track [Page 115] - -RFC 5546 iTIP December 2009 - - - RRULE:FREQ=WEEKLY - RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z - ORGANIZER:mailto:a@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com - ATTENDEE:mailto:b@example.com - DESCRIPTION:IETF-C&S Conference Call - SUMMARY:IETF Calendaring Working Group Meeting - DTSTART:19970801T210000Z - DTEND:19970801T220000Z - RECURRENCE-ID:19970809T210000Z - DTSTAMP:19970726T083000 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - "B" has the event with "UID" property "example-12345@example.com", - but "B's" "SEQUENCE" property value is "1" and the event does not - have an instance at the specified recurrence time. This means that - "B" has missed at least one update and needs a new copy of the event. - "B" requests the latest copy of the event with the following refresh - message: - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REFRESH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:a@example.com - ATTENDEE:mailto:b@example.com - UID:example-12345@example.com - DTSTAMP:19970603T094000 - END:VEVENT - END:VCALENDAR - -5. Application Protocol Fallbacks - -5.1. Partial Implementation - - Applications that support this specification 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. If a method or property is not addressed in this - section, it may be ignored. - - - - - - - - -Daboo Standards Track [Page 116] - -RFC 5546 iTIP December 2009 - - -5.1.1. Event-Related Fallbacks - - +----------------+--------------------------------------------------+ - | Method | Fallback | - +----------------+--------------------------------------------------+ - | PUBLISH | Required | - | REQUEST | PUBLISH | - | REPLY | Required | - | ADD | Required if recurrences supported; otherwise, | - | | reply with a REQUEST-STATUS "2.8; Success, | - | | repeating event ignored. Scheduled as a single | - | | component", and schedule as a single component. | - | CANCEL | Required | - | REFRESH | Required | - | COUNTER | Reply with "Not Supported". | - | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs; | - | | otherwise, reply with "Not Supported". | - +----------------+--------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | iCalendar | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | CALSCALE | Ignore - assume GREGORIAN. | - | PRODID | Ignore | - | METHOD | Required as described in the Method list above. | - | VERSION | Ignore | - +-----------------+-------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | Event-Related | Fallback | - | Components | | - +-----------------+-------------------------------------------------+ - | VALARM | Reply with "Not Supported". | - | VTIMEZONE | Required if any DateTime value refers to a time | - | | zone. | - +-----------------+-------------------------------------------------+ - - - - - - - - - - - - - - -Daboo Standards Track [Page 117] - -RFC 5546 iTIP December 2009 - - - +-----------------+-------------------------------------------------+ - | Component | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | ATTACH | Ignore | - | ATTENDEE | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | CATEGORIES | Ignore | - | CLASS | Ignore | - | COMMENT | Ignore | - | COMPLETED | Ignore | - | CONTACT | Ignore | - | CREATED | Ignore | - | DESCRIPTION | Ignore | - | DURATION | Required | - | DTSTAMP | Required | - | DTSTART | Required | - | DTEND | Required | - | EXDATE | Ignore | - | GEO | Ignore | - | LAST-MODIFIED | Ignore | - | LOCATION | Required | - | ORGANIZER | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | PRIORITY | Ignore | - | RELATED-TO | Ignore | - | RDATE | Ignore | - | RRULE | Ignore - assume the first instance occurs on | - | | the DTSTART property. If implemented, | - | | VTIMEZONE MUST also be implemented. | - | RECURRENCE-ID | Required if RRULE is implemented; otherwise, | - | | ignore. | - | REQUEST-STATUS | Required | - | RESOURCES | Ignore | - | SEQUENCE | Required | - | STATUS | Ignore | - | SUMMARY | Ignore | - | TRANSP | Required if FREEBUSY is implemented; otherwise, | - | | ignore. | - | URL | Ignore | - | UID | Required | - | X- | Ignore | - +-----------------+-------------------------------------------------+ - - - - - - - - -Daboo Standards Track [Page 118] - -RFC 5546 iTIP December 2009 - - -5.1.2. Free/Busy-Related Fallbacks - - +---------+---------------------------------------------------------+ - | Method | Fallback | - +---------+---------------------------------------------------------+ - | PUBLISH | Required if freebusy lookups are supported; otherwise, | - | | reply with a REQUEST-STATUS "3.14; Unsupported | - | | capability". | - | REQUEST | Required if freebusy lookups are supported; otherwise, | - | | reply with a REQUEST-STATUS "3.14; Unsupported | - | | capability". | - | REPLY | Required if freebusy lookups are supported; otherwise, | - | | reply with a REQUEST-STATUS "3.14; Unsupported | - | | capability". | - +---------+---------------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | iCalendar | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | CALSCALE | Ignore - assume GREGORIAN. | - | PRODID | Ignore | - | METHOD | Required as described in the Method list above. | - | VERSION | Ignore | - +-----------------+-------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | Component | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | ATTENDEE | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | COMMENT | Ignore | - | CONTACT | Ignore | - | DTEND | Required | - | DTSTAMP | Required | - | DTSTART | Required | - | DURATION | Ignore | - | FREEBUSY | Required | - | ORGANIZER | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | REQUEST-STATUS | Ignore | - | UID | Required | - | URL | Ignore | - | X- | Ignore | - +-----------------+-------------------------------------------------+ - - - - - -Daboo Standards Track [Page 119] - -RFC 5546 iTIP December 2009 - - -5.1.3. To-Do-Related Fallbacks - - +----------------+--------------------------------------------------+ - | Method | Fallback | - +----------------+--------------------------------------------------+ - | PUBLISH | Required | - | REQUEST | PUBLISH | - | REPLY | Required | - | ADD | Required if recurrences supported; otherwise, | - | | reply with a REQUEST-STATUS "2.8; Success, | - | | repeating event ignored. Scheduled as a single | - | | component", and schedule as a single component. | - | CANCEL | Required | - | REFRESH | Required | - | COUNTER | Reply with "Not Supported". | - | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented; | - | | otherwise, reply with "Not Supported". | - +----------------+--------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | iCalendar | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | CALSCALE | Ignore - assume GREGORIAN. | - | PRODID | Ignore | - | METHOD | Required as described in the Method list above. | - | VERSION | Ignore | - +-----------------+-------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | To-Do-Related | Fallback | - | Components | | - +-----------------+-------------------------------------------------+ - | VALARM | Reply with "Not Supported". | - | VTIMEZONE | Required if any DateTime value refers to a time | - | | zone. | - +-----------------+-------------------------------------------------+ - - - - - - - - - - - - - - -Daboo Standards Track [Page 120] - -RFC 5546 iTIP December 2009 - - - +------------------+------------------------------------------------+ - | Component | Fallback | - | Property | | - +------------------+------------------------------------------------+ - | ATTACH | Ignore | - | ATTENDEE | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | CATEGORIES | Ignore | - | CLASS | Ignore | - | COMMENT | Ignore | - | COMPLETED | Required | - | CONTACT | Ignore | - | CREATED | Ignore | - | DESCRIPTION | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | DUE | Required | - | DURATION | Required | - | DTSTAMP | Required | - | DTSTART | Required | - | EXDATE | Ignore - reply with "Not Supported". | - | LAST-MODIFIED | Ignore | - | LOCATION | Ignore | - | ORGANIZER | Required if METHOD is REQUEST; otherwise, | - | | ignore. | - | PERCENT-COMPLETE | Ignore | - | PRIORITY | Required | - | RECURRENCE-ID | Required if RRULE is implemented; otherwise, | - | | ignore. | - | RELATED-TO | Ignore | - | REQUEST-STATUS | Ignore | - | RDATE | Ignore | - | RRULE | Ignore - assume the first instance occurs on | - | | the DTSTART property. If implemented, | - | | VTIMEZONE MUST also be implemented. | - | RESOURCES | Ignore | - | SEQUENCE | Required | - | STATUS | Required | - | SUMMARY | Ignore | - | URL | Ignore | - | UID | Required | - | X- | Ignore | - +------------------+------------------------------------------------+ - - - - - - - - - -Daboo Standards Track [Page 121] - -RFC 5546 iTIP December 2009 - - -5.1.4. Journal-Related Fallbacks - - +---------+---------------------------------------------------------+ - | Method | Fallback | - +---------+---------------------------------------------------------+ - | PUBLISH | Implementations MAY ignore the METHOD type. The | - | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | - | | returned. | - | ADD | Implementations MAY ignore the METHOD type. The | - | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | - | | returned. | - | CANCEL | Implementations MAY ignore the METHOD type. The | - | | REQUEST-STATUS "3.14; Unsupported capability" MUST be | - | | returned. | - +---------+---------------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | iCalendar | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | CALSCALE | Ignore - assume GREGORIAN. | - | PRODID | Ignore | - | METHOD | Required as described in the Method list above. | - | VERSION | Ignore | - +-----------------+-------------------------------------------------+ - - +-----------------+-------------------------------------------------+ - | Journal-Related | Fallback | - | Components | | - +-----------------+-------------------------------------------------+ - | VTIMEZONE | Required if any DateTime value refers to a time | - | | zone. | - +-----------------+-------------------------------------------------+ - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 122] - -RFC 5546 iTIP December 2009 - - - +-----------------+-------------------------------------------------+ - | Component | Fallback | - | Property | | - +-----------------+-------------------------------------------------+ - | ATTACH | Ignore | - | ATTENDEE | Ignore | - | CATEGORIES | Ignore | - | CLASS | Ignore | - | COMMENT | Ignore | - | CONTACT | Ignore | - | CREATED | Ignore | - | DESCRIPTION | Ignore | - | DTSTAMP | Required | - | DTSTART | Required | - | EXDATE | Ignore | - | LAST-MODIFIED | Ignore | - | ORGANIZER | Ignore | - | RECURRENCE-ID | Required if RRULE is implemented; otherwise, | - | | ignore. | - | RELATED-TO | Ignore | - | RDATE | Ignore | - | RRULE | Ignore - assume the first instance occurs on | - | | the DTSTART property. If implemented, | - | | VTIMEZONE MUST also be implemented. | - | SEQUENCE | Required | - | STATUS | Ignore | - | SUMMARY | Required | - | URL | Ignore | - | UID | Required | - | X- | Ignore | - +-----------------+-------------------------------------------------+ - -5.2. Latency Issues - - With a store-and-forward transport, it is possible for events to - arrive out of sequence. That is, a "CANCEL" method may be received - prior to receiving the associated "REQUEST" for the calendar - component. This section discusses a few of these scenarios. - -5.2.1. Cancellation of an Unknown Calendar Component - - When a "CANCEL" method is received before the original "REQUEST" - method, the calendar will be unable to correlate the "UID" property - of the cancellation with an existing calendar component. It is - suggested that messages that cannot be correlated and that also - contain non-zero sequence numbers be held and not discarded. - Implementations MAY age them out if no other messages arrive with the - same "UID" property value and a lower sequence number. - - - -Daboo Standards Track [Page 123] - -RFC 5546 iTIP December 2009 - - -5.2.2. Unexpected Reply from an Unknown Delegate - - When an "Attendee" delegates an item to another CU, they MUST send a - "REPLY" method to the "Organizer" using the "ATTENDEE" properties to - indicate that the request was delegated and to whom. Hence, it is - possible for an "Organizer" to receive a "REPLY" from a CU not listed - as one of the original "Attendees". The resolution is left to the - implementation, but it is expected that the calendaring software will - either accept the reply or hold it until the related "REPLY" method - is received from the "Delegator". If the version of the "REPLY" - method is out of date, the "Organizer" SHOULD treat the message as a - "REFRESH" message and update the "Delegate" with the correct version, - provided that delegation to that delegate is acceptable. - -5.3. Sequence Number - - Under some conditions, a CUA may receive requests and replies with - the same "SEQUENCE" property value. The "DTSTAMP" property is - utilized as a tie-breaker when two items with the same "SEQUENCE" - property value are evaluated. - -6. Security Considerations - - iTIP is an abstract transport protocol that will be bound to a real- - time transport, a store-and-forward transport, and perhaps other - transports. The transport protocol will be responsible for providing - facilities for authentication and encryption using standard Internet - mechanisms that are mutually understood between the sender and - receiver. - -6.1. Security Threats - -6.1.1. Spoofing the Organizer - - In iTIP, the "Organizer" (or someone working on the "Organizer's" - behalf) is the only person authorized to make changes to an existing - "VEVENT", "VTODO", or "VJOURNAL" calendar component and republish it - or redistribute updates to the "Attendees". An iCalendar object that - maliciously changes or cancels an existing "VEVENT", "VTODO", or - "VJOURNAL" calendar component may be constructed by someone other - than the "Organizer" and republished or sent to the "Attendees". - -6.1.2. Spoofing the Attendee - - In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component - (or someone working on the "Attendee's" behalf) is the only person - authorized to update any parameter associated with their "ATTENDEE" - - - - -Daboo Standards Track [Page 124] - -RFC 5546 iTIP December 2009 - - - property and send it to the "Organizer". An iCalendar object that - maliciously changes the "ATTENDEE" parameters may be constructed by - someone other than the real "Attendee" and sent to the "Organizer". - -6.1.3. Unauthorized Replacement of the Organizer - - There will be circumstances when "Attendees" of an event or to-do - decide, using out-of-band mechanisms, that the "Organizer" must be - replaced. When the new "Organizer" sends out the updated "VEVENT" or - "VTODO", the "Attendee's" CUA will detect that the "Organizer" has - been changed, but it has no way of knowing whether or not the change - was mutually agreed upon. - -6.1.4. Eavesdropping and Data Integrity - - The iCalendar object is constructed with human-readable clear text. - Any information contained in an iCalendar object may be read and/or - changed by unauthorized persons while the object is in transit. - -6.1.5. Flooding a Calendar - - Implementations could provide a means to automatically incorporate - "REQUEST" methods into a calendar. This presents the opportunity for - a calendar to be flooded with requests, which effectively blocks all - the calendar's free time. - -6.1.6. Unauthorized REFRESH Requests - - It is possible for an "Organizer" to receive a "REFRESH" request from - someone who is not an "Attendee" of an event or to-do. Only - "Attendees" of an event or to-do are authorized to receive replies to - "REFRESH" requests. Replying to such requests to anyone who is not - an "Attendee" may be a security problem. - -6.2. Recommendations - - For an application where the information is sensitive or critical and - the network is subject to a high probability of attack, iTIP - transactions SHOULD be encrypted and authenticated. This helps - mitigate the threats of spoofing, eavesdropping, and malicious - changes in transit. - -6.2.1. Securing iTIP transactions - - iTIP transport bindings MUST provide a mechanism to enable - authentication of the sender's identity as well as privacy and - integrity of the data being transmitted. This allows the receiver of - a signed iCalendar object to verify the identity of the sender. This - - - -Daboo Standards Track [Page 125] - -RFC 5546 iTIP December 2009 - - - sender may then be correlated to an "ATTENDEE" property in the - iCalendar object. If the correlation is made and the sender is - authorized to make the requested change or update, then the operation - may proceed. It also allows the message to be encrypted to prevent - unauthorized reading of the message contents in transit. iTIP - transport binding documents describe this process in detail. - -6.2.2. Implementation Controls - - The threat of unauthorized replacement of the "Organizer" SHOULD be - mitigated by a calendar system that uses this protocol by providing - controls or alerts that make "Calendar Users" aware of such - "Organizer" changes and allowing them to decide whether or not the - request should be honored. - - The threat of flooding a calendar SHOULD be mitigated by a calendar - system that uses this protocol by providing controls that may be used - to limit the acceptable sources for iTIP transactions, and perhaps - the size of messages and volume of traffic, by source. - - The threat of unauthorized "REFRESH" requests SHOULD be mitigated by - a calendar system that uses this protocol by providing controls or - alerts that allow "Calendar Users" to decide whether or not the - request should be honored. An implementation MAY decide to maintain, - for audit or historical purposes, "Calendar Users" who were part of - an "Attendee" list and who were subsequently uninvited. Similar - controls or alerts should be provided when a "REFRESH" request is - received from these "Calendar Users" as well. - -6.2.3. Access Controls and Filtering - - In many environments, there could be restrictions on who is allowed - to schedule with whom and who the allowed delegates are for - particular "Calendar Users". - - iTIP transport bindings SHOULD provide mechanisms for implementing - access controls or filtering to ensure iTIP transactions only take - place between authorized "Calendar Users". That would include - preventing one "Calendar User" from scheduling with another or one - "Calendar User" delegating to another. - -6.3. Privacy Issues - - The "Organizer" might want to keep "Attendees" from knowing which - other "Attendees" are participating in an event or to-do. The - "Organizer" has the choice of sending single iTIP messages with a - full list of "Attendees" or sending iTIP messages to each "Attendee" - with only that "Attendee" listed. - - - -Daboo Standards Track [Page 126] - -RFC 5546 iTIP December 2009 - - -7. IANA Considerations - -7.1. Registration Template for REQUEST-STATUS Values - - This specification updates [RFC5545] by adding a "REQUEST-STATUS" - value registry to the iCalendar Elements registry. - - A "REQUEST-STATUS" value is defined by completing the following - template. - - Status Code: Hierarchical, numeric return status code, following - the rules defined in Section 3.8.8.3 of [RFC5545]. - - Status Description: Textual status description. A short but - clear description of the error. - - Status Exception Data: Textual exception data. A short but clear - description of what might appear in this field. - - Description: Describe the underlying cause for this status code - value. - -7.2. Additions to iCalendar METHOD Registry - - This document defines the following values for the iCalendar "METHOD" - property, using the values template from Section 8.2.6 of [RFC5545]. - These should be added to the Methods Registry defined in Section - 8.3.12 of [RFC5545]: - -7.2.1. METHOD:PUBLISH - - Value: PUBLISH - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.2.2. METHOD:REQUEST - - Value: REQUEST - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - - - -Daboo Standards Track [Page 127] - -RFC 5546 iTIP December 2009 - - -7.2.3. METHOD:REPLY - - Value: REPLY - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.2.4. METHOD:ADD - - Value: ADD - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.2.5. METHOD:CANCEL - - Value: CANCEL - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.2.6. METHOD:REFRESH - - Value: REFRESH - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.2.7. METHOD:COUNTER - - Value: COUNTER - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - - - -Daboo Standards Track [Page 128] - -RFC 5546 iTIP December 2009 - - - Examples: See this RFC. - -7.2.8. METHOD:DECLINECOUNTER - - Value: DECLINECOUNTER - - Purpose: Standard iTIP "METHOD" value. - - Conformance: Only used with the "METHOD" property. - - Examples: See this RFC. - -7.3. REQUEST-STATUS Value Registry - - New "REQUEST-STATUS" values can be registered using the process - described in Section 8.2.1 of [RFC5545]. - - The following table is to be used to initialize the "REQUEST-STATUS" - value registry. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 129] - -RFC 5546 iTIP December 2009 - - - +-------------+---------+--------------------------+ - | Status Code | Status | Reference | - +-------------+---------+--------------------------+ - | 2.0 | Current | RFC 5546, Section 3.6.1 | - | 2.1 | Current | RFC 5546, Section 3.6.2 | - | 2.2 | Current | RFC 5546, Section 3.6.3 | - | 2.3 | Current | RFC 5546, Section 3.6.4 | - | 2.4 | Current | RFC 5546, Section 3.6.5 | - | 2.5 | Current | RFC 5546, Section 3.6.6 | - | 2.6 | Current | RFC 5546, Section 3.6.7 | - | 2.7 | Current | RFC 5546, Section 3.6.8 | - | 2.8 | Current | RFC 5546, Section 3.6.9 | - | 2.9 | Current | RFC 5546, Section 3.6.10 | - | 2.10 | Current | RFC 5546, Section 3.6.11 | - | 2.11 | Current | RFC 5546, Section 3.6.12 | - | 3.0 | Current | RFC 5546, Section 3.6.13 | - | 3.1 | Current | RFC 5546, Section 3.6.14 | - | 3.2 | Current | RFC 5546, Section 3.6.15 | - | 3.3 | Current | RFC 5546, Section 3.6.16 | - | 3.4 | Current | RFC 5546, Section 3.6.17 | - | 3.5 | Current | RFC 5546, Section 3.6.18 | - | 3.6 | Current | RFC 5546, Section 3.6.19 | - | 3.7 | Current | RFC 5546, Section 3.6.20 | - | 3.8 | Current | RFC 5546, Section 3.6.21 | - | 3.9 | Current | RFC 5546, Section 3.6.22 | - | 3.10 | Current | RFC 5546, Section 3.6.23 | - | 3.11 | Current | RFC 5546, Section 3.6.24 | - | 3.12 | Current | RFC 5546, Section 3.6.25 | - | 3.13 | Current | RFC 5546, Section 3.6.26 | - | 3.14 | Current | RFC 5546, Section 3.6.27 | - | 4.0 | Current | RFC 5546, Section 3.6.28 | - | 5.0 | Current | RFC 5546, Section 3.6.29 | - | 5.1 | Current | RFC 5546, Section 3.6.30 | - | 5.2 | Current | RFC 5546, Section 3.6.31 | - | 5.3 | Current | RFC 5546, Section 3.6.32 | - +-------------+---------+--------------------------+ - -8. Acknowledgments - - This is an update to the original iTIP document authored by S. - Silverberg, S. Mansour, F. Dawson, and R. Hopson. - - This revision is the product of the Calsify IETF Working Group, and - several participants have made important contributions to this - specification, including Oliver Block, Bernard Desruisseaux, Mike - Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot - Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg - II, Robert Ransdell, and Caleb Richardson. - - - -Daboo Standards Track [Page 130] - -RFC 5546 iTIP December 2009 - - -9. References - -9.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto - URL scheme", RFC 2368, July 1998. - - [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling - Core Object Specification (iCalendar)", RFC 5545, - September 2009. - -9.2. Informative References - - [iMIP] Melnikov, A., Ed., "iCalendar Message-Based - Interoperability Protocol (iMIP)", Work in Progress, - October 2009. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 131] - -RFC 5546 iTIP December 2009 - - -Appendix A. Differences from RFC 2446 - -A.1. Changed Restrictions - - This specification now defines an allowed combination of "REQUEST- - STATUS" codes when multiple iCalendar components are included in an - iTIP message. - - This specification now restricts "RECURRENCE-ID" to only a single - occurrence in any one iCalendar component in an iTIP message, as - required by [RFC5545]. - - Changed the "RECURRENCE-ID" entry in the component restriction table - to "0 or 1" from "0+", to fall in line with [RFC5545]. - - Changed the "FREEBUSY" entry in the "VFREEBUSY", "PUBLISH", and - "REPLY" restriction tables to "0+" from "1+", to fall in line with - [RFC5545]. - - Changed the "FREEBUSY" description in the "VFREEBUSY" and "REPLY" - restriction tables to indicate that different "FBTYPE" ranges MUST - NOT overlap. - - Changed the "TZNAME" entry in the "VTIMEZONE" restriction table to - "0+" from "0 or 1", to fall in line with [RFC5545]. - - Changed the "COMMENT" entry in the component restriction tables to - "0+" from "0 or 1", to fall in line with [RFC5545]. - - Added the "ATTENDEE" entry in the "VALARM" restriction table to match - the email alarm type in [RFC5545]. - - Changed the "CATEGORIES" entry in the component restriction tables to - "0+" from "0 or 1", to fall in line with [RFC5545]. - - Changed the "RESOURCES" entry in the component restriction tables to - "0+" from "0 or 1", to fall in line with [RFC5545]. - - Changed the "CONTACT" entry in the "VFREEBUSY" restriction table to - "0 or 1" from "0+", to fall in line with [RFC5545]. - - Changed the "UID" entry in the "VFREEBUSY" and "PUBLISH" restriction - tables to "1" from "0", to fall in line with [RFC5545]. - - Added the "COMPLETED" entry in the "VTODO" restriction tables to fall - in line with [RFC5545]. - - - - - -Daboo Standards Track [Page 132] - -RFC 5546 iTIP December 2009 - - - Added the "REQUEST-STATUS" entry in the "VJOURNAL" restriction tables - to fall in line with [RFC5545]. - -A.2. Deprecated Features - - The "EXRULE" property was removed in [RFC5545] and references to that - have been removed in this document too. - - The "PROCEDURE" value for the "ACTION" property was removed in - [RFC5545] and references to that have been removed in this document - too. - - The "THISANDPRIOR" option for the "RANGE" parameter was removed in - [RFC5545] and references to that have been removed in this document - too. - -Author's Address - - Cyrus Daboo (editor) - Apple Inc. - 1 Infinite Loop - Cupertino, CA 95014 - USA - - EMail: cyrus@daboo.name - URI: http://www.apple.com/ - - - - - - - - - - - - - - - - - - - - - - - - - -Daboo Standards Track [Page 133] - diff --git a/specifications/calendar/rfc6047.txt b/specifications/calendar/rfc6047.txt deleted file mode 100644 index c839c8ed..00000000 --- a/specifications/calendar/rfc6047.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) A. Melnikov, Ed. -Request for Comments: 6047 Isode Ltd -Obsoletes: 2447 December 2010 -Category: Standards Track -ISSN: 2070-1721 - - - iCalendar Message-Based Interoperability Protocol (iMIP) - -Abstract - - This document, "iCalendar Message-Based Interoperability Protocol - (iMIP)", specifies a binding from the iCalendar Transport-independent - Interoperability Protocol (iTIP) to Internet email-based transports. - Calendaring entries defined by the iCalendar Object Model (iCalendar) - are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC - 2046, RFC 2047, and RFC 2049), and then transported over SMTP. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 5741. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - http://www.rfc-editor.org/info/rfc6047. - -Copyright Notice - - Copyright (c) 2010 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - - -Melnikov Standards Track [Page 1] - -RFC 6047 iMIP December 2010 - - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Related Memos ..............................................3 - 1.2. Formatting Conventions .....................................3 - 1.3. Terminology ................................................4 - 2. MIME Message Format Binding .....................................4 - 2.1. MIME Media Type ............................................4 - 2.2. Security ...................................................5 - 2.2.1. Authorization .......................................5 - 2.2.2. Authentication ......................................5 - 2.2.3. Confidentiality .....................................5 - 2.3. Email Addresses ............................................6 - 2.4. Content-Type Header Field ..................................6 - 2.5. Content-Transfer-Encoding Header Field .....................7 - 2.6. Content-Disposition Header Field ...........................8 - 3. Security Considerations .........................................8 - 4. Examples .......................................................11 - 4.1. Single Component with an ATTACH Property ..................11 - 4.2. Using multipart/alternative for Low-Fidelity Clients ......11 - 4.3. Single Component with an ATTACH Property and - Inline Attachment .........................................12 - 4.4. Multiple Similar Components ...............................14 - 4.5. Multiple Mixed Components .................................15 - 4.6. Detailed Components with an ATTACH Property ...............16 - 5. Recommended Practices ..........................................18 - 5.1. Use of Content and Message IDs ............................18 - 6. IANA Considerations ............................................18 - 7. References .....................................................19 - 7.1. Normative References ......................................19 - 7.2. Informative References ....................................20 - Appendix A. Changes since RFC 2447 ................................21 - Appendix B. Acknowledgements ......................................22 - - - - - - -Melnikov Standards Track [Page 2] - -RFC 6047 iMIP December 2010 - - -1. Introduction - - This document provides the transport-specific information ("binding") - necessary to convey iCalendar Transport-independent Interoperability - Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in - [RFC5322] and [RFC2045]. Therefore, this document defines the - iCalendar Message-Based Interoperability Protocol (iMIP). - -1.1. Related Memos - - Implementers will need to be familiar with several other memos that, - along with this memo, form a framework for Internet calendaring and - scheduling standards. - - This document specifies an Internet email binding for iTIP. - - [iCAL] specifies a core specification of objects, data types, - properties, and property parameters. - - [iTIP] specifies an interoperability protocol for scheduling between - different implementations. - - This memo does not attempt to repeat the specification of concepts or - definitions from these other memos. Where possible, references are - made to the memo that provides for the specification of these - concepts or definitions. - -1.2. Formatting Conventions - - The mechanisms defined in this memo are defined in prose. In order - to refer to elements of the calendaring and scheduling model, core - object, or interoperability protocol defined in [iCAL] and [iTIP], - some formatting conventions have been used. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - - Calendaring and scheduling roles are referred to in quoted strings of - text with the first character of each word in uppercase. For - example, "Organizer" refers to a role of a "Calendar User" within the - scheduling protocol defined by [iTIP]. - - Calendar components defined by [iCAL] are referred to with - capitalized, quoted strings of text. All calendar components start - with the letter "V". For example, "VEVENT" refers to the event - calendar component, "VTODO" refers to the to-do calendar component, - and "VJOURNAL" refers to the daily journal calendar component. - - - -Melnikov Standards Track [Page 3] - -RFC 6047 iMIP December 2010 - - - Scheduling methods defined by [iTIP] are referred to with - capitalized, quoted strings of text. For example, "REQUEST" refers - to the method for requesting a scheduling calendar component be - created or modified; "REPLY" refers to the method a recipient of a - request uses to update their status with the "Organizer" of the - calendar component. - - Properties defined by [iCAL] are referred to with capitalized, quoted - strings of text, followed by the word "property". For example, - "ATTENDEE" property refers to the iCalendar property used to convey - the calendar address of a "Calendar User". - - Property parameters defined by [iCAL] are referred to with lowercase, - quoted strings of text, followed by the word "parameter". For - example, "value" parameter refers to the iCalendar property parameter - used to override the default data type for a property value. - -1.3. Terminology - - The email terms used in this memo are defined in [RFC5322] and - [RFC2045]. The calendaring and scheduling terms used in this memo - are defined in [iCAL] and [iTIP]. - -2. MIME Message Format Binding - - This section defines the message binding to the MIME electronic mail - transport. - - The sections below refer to the "originator" and the "recipient" of - an iMIP message. In the case of a "request" method, the originator - is the "Organizer" and the recipient is an "Attendee" of the event. - In the case of a "response" method, the originator is an "Attendee" - and the recipient is the "Organizer" of the event. - - The [RFC5322] "Reply-To" header field typically contains the email - address of the originator of the scheduling message. However, this - cannot be guaranteed because the sender of the iMIP message might not - be the originator of the scheduling message and the sender's "Mail - User Agent" (MUA) might not enforce iMIP semantics by translating the - originator's address into the "Reply-To" email header field. - -2.1. MIME Media Type - - A MIME entity containing content information formatted according to - this document will be referenced as a "text/calendar" content type - [iCAL]. It is assumed that this content type will be transported - through a MIME electronic mail transport. - - - - -Melnikov Standards Track [Page 4] - -RFC 6047 iMIP December 2010 - - -2.2. Security - - This section addresses several aspects of security including - authentication, authorization, and confidentiality. Authentication - and confidentiality can be achieved using Secure/MIME (S/MIME) - [RFC5750] [RFC5751], which uses the Security Multiparts framework for - MIME [RFC1847]. - -2.2.1. Authorization - - In iTIP messages [iTIP], only the "Organizer" is authorized to modify - or cancel calendar entries she organizes. That is, - spoof@xyz.example.net is not allowed to modify or cancel a meeting - that was organized by a@example.com. Furthermore, only the - respondent has the authorization to indicate their status to the - "Organizer". That is, the "Organizer" MUST ignore an iTIP message - from spoof@xyz.example.net that declines a meeting invitation for - b@example.com. - - Implementations of iMIP SHOULD verify the authenticity of the creator - of an iCalendar object before taking any action. Methods for doing - this are presented later in this document. - - [RFC1847] message flow in iTIP supports someone working on behalf of - a "Calendar User" through use of the "sent-by" parameter that is - associated with the "ATTENDEE" and "ORGANIZER" properties. However, - there is no mechanism to verify whether or not a "Calendar User" has - authorized someone to work on their behalf. It is left to - implementations to provide mechanisms for the "Calendar Users" to - make that decision. - -2.2.2. Authentication - - Authentication MUST be performed using S/MIME [RFC5750] [RFC5751]. - Authentication is possible only on messages that have been signed. - Unauthenticated messages (i.e., unsigned messages) may not be - trusted. - -2.2.3. Confidentiality - - To ensure confidentiality using iMIP, implementations SHOULD utilize - encryption specified in S/MIME [RFC5750] [RFC5751]. iMIP does not - restrict a "Calendar User Agent" (CUA) from forwarding iCalendar - objects to other users or agents. - - - - - - - -Melnikov Standards Track [Page 5] - -RFC 6047 iMIP December 2010 - - -2.3. Email Addresses - - The calendar address specified within the "ORGANIZER" and "ATTENDEE" - properties in an iCalendar object sent using iMIP MUST be a proper - "mailto:" [MAILTO] URI specification for the corresponding - "Organizer" or "Attendee" of the "VEVENT" or "VTODO". - - Because [iTIP] does not preclude "Attendees" from forwarding - "VEVENT"s or "VTODO"s to others, the [RFC5322] "Sender" value may not - equal that of the "Organizer". Additionally, the "Organizer" or - "Attendee" cannot be reliably inferred by the [RFC5322] "Sender" or - "Reply-To" header field values of an iMIP message. The relevant - address MUST be ascertained by opening the "text/calendar" MIME body - part and examining the "ATTENDEE" and "ORGANIZER" properties. - -2.4. Content-Type Header Field - - A MIME body part containing content information that conforms to this - document MUST have an [RFC2045] "Content-Type" value of - "text/calendar". The [RFC2045] "Content-Type" header field MUST also - include the MIME parameter "method". The value MUST be the same - (ignoring case) as the value of the "METHOD" property within the - iCalendar object. - - Note 1: A MIME message containing multiple iCalendar objects with - different "method" values MUST be further encapsulated with a - "multipart/mixed" MIME entity [RFC2046]. This will allow each of - the iCalendar objects to be encapsulated within their own - "text/calendar" MIME entity. - - Note 2: A MIME body part with a "Content-Type" value of - "text/calendar" that lacks the "method" parameter is not - considered to be an iMIP body part and thus is not subject to the - requirements specified in this document. - - Note that according to [iCAL] the default character set for iCalendar - objects is UTF-8 [UTF-8]. However, the default character set for a - "text/*" MIME entity according to [RFC2046] is US-ASCII. Thus, a - "charset" MIME parameter MUST be present if the iCalendar object - contains characters that can't be represented in the US-ASCII - character set and, as specified in [iCAL], it MUST have the value - "UTF-8". - - The optional "component" MIME parameter defines the iCalendar - component type contained within the iCalendar object. - - - - - - -Melnikov Standards Track [Page 6] - -RFC 6047 iMIP December 2010 - - - The following is an example of this header field with a value that - indicates an event message. - - Content-Type: text/calendar; method=REQUEST; charset=UTF-8; - component=vevent - - The "text/calendar" content type allows for the scheduling message - type to be included in a MIME message with other content information - (i.e., "multipart/mixed") or included in a MIME message with a clear- - text, human-readable form of the scheduling message (i.e., - "multipart/alternative" [RFC2046]). - - In order to permit the information in the scheduling message to be - understood by MIME User Agents (UAs) that do not support the - "text/calendar" content type, scheduling messages SHOULD be sent with - an alternative, human-readable form of the information. - - Note that "multipart/alternative" MUST NOT be used to represent two - slightly different iCalendar objects, for example, two "VEVENT"s with - alternative starting times. - - CUAs can use other MIME parameters of the "Content-Type" header - field, as well as a language specified in the Content-Language header - field [RFC3282], to pick a "text/calendar" part for processing if a - "multipart/alternative" MIME message contains more than one - "text/calendar" part. - - Any receiving UA compliant with this specification MUST be able to - process "text/calendar" body parts enclosed within "multipart/*". - Note that a "multipart/mixed" MIME message can include multiple - "text/calendar" components. The receiving UA MUST be able to process - all of them. - -2.5. Content-Transfer-Encoding Header Field - - Unless an iMIP message is transported over 8-bit clean transport - (such as SMTP [8BITMIME]), a transfer encoding such as quoted- - printable or base64 [RFC2045] MUST be used for iCalendar objects - containing any characters that can't be represented in the US-ASCII - character set. For example: - - - - - - - - - - - -Melnikov Standards Track [Page 7] - -RFC 6047 iMIP December 2010 - - - From: user1@example.com - To: user2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Date: Wed, 07 May 2008 21:30:25 +0400 - Message-ID: <4821E731.5040506@laptop1.example.com> - Content-Type: text/calendar; method=REQUEST; charset=UTF-8 - Content-Transfer-Encoding: quoted-printable - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:user1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com - DTSTAMP:20080507T170000Z - DTSTART:20080701T160000Z - DTEND:20080701T163000Z - SUMMARY:Phone call to discuss your last visit - DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0= - =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0 - =BE=D0=B9? - UID:calsvr.example.com-8739701987387998 - SEQUENCE:0 - STATUS:TENTATIVE - END:VEVENT - END:VCALENDAR - -2.6. Content-Disposition Header Field - - Implementations MAY include a "Content-Disposition" header field to - define a file name for an iCalendar object. However, the handling of - a MIME part MUST be based on its [RFC2045] "Content-Type" and not on - the extension specified in the "Content-Disposition", as different - email malware is known to trick User Agents into misinterpreting - content of messages by specifying a file extension in the Content- - Disposition header field that doesn't correspond to the value of the - "Content-Type" header field. - -3. Security Considerations - - The security threats that applications must address when implementing - iTIP are detailed in [iTIP]. In particular, two spoofing threats are - identified in Section 6.1 of [iTIP]: spoofing the "Organizer", and - spoofing an "Attendee". To address these threats, the originator of - an iCalendar object must be authenticated by a recipient. Once - - - -Melnikov Standards Track [Page 8] - -RFC 6047 iMIP December 2010 - - - authenticated, a determination can be made as to whether or not the - originator is authorized to perform the requested operation. - Compliant applications MUST support signing and encrypting - "text/calendar" body parts using a mechanism based on S/MIME - [RFC5750] [RFC5751] in order to facilitate the authentication of the - originator of the iCalendar object (see Sections 2.2.2 and 2.2.3). - The steps for processing a signed iMIP message are described below: - - 1. Using S/MIME, determine who signed the "text/calendar" body part - containing the iCalendar object. This is the "signer". (Note - that the email address of the signer MUST be specified in the - rfc822Name field of the "subject alternative name" extension of - the signer certificate, as specified in [RFC5280], - Section 4.1.2.6.) Note that the signer is not necessarily the - person sending an e-mail message, since an e-mail message can be - forwarded. - - 2. Correlate the signer to either an "ATTENDEE" property or to the - "ORGANIZER" property in the iCalendar object, based on the method - and the calendar component specified in the iCalendar object, as - defined in Section 1.4 of [iTIP]. If the signer cannot be - correlated to an "ATTENDEE"/"ORGANIZER" property, then actively - warn the user controlling the "Calendar User Agent" that the - iCalendar object is untrusted, and encourage the user to ignore - the message, but give advanced users the option to (a) view the - certificate of the signer and the entire certificate chain (if - any) in order to help decide if the signer should be trusted to - send the message, and then (b) allow the CUA to accept and process - the iCalendar object. - - 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized - to perform the operation as defined by [iTIP]. If the conditions - are not met, ignore the message. - - 4. If all the above conditions are met, the message can be processed. - - S/MIME signing also protects against malicious changes to messages in - transit. - - If calendar confidentiality is required by the sender, signed iMIP - messages SHOULD be encrypted by a mechanism based on S/MIME [RFC5750] - [RFC5751]. If iMIP is used within a single ADministrative Management - Domain (ADMD) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together with - STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY alternatively be used to - provide calendar confidentiality. - - - - - - -Melnikov Standards Track [Page 9] - -RFC 6047 iMIP December 2010 - - - Once a signed and/or encrypted iMIP message is received and - successfully verified (as detailed above) by a CUA, the CUA SHOULD - remember whether the sender of the message is using signing and/or - encrypting. If an unsigned iMIP message is received from the same - sender later on, the receiving CUA SHOULD warn the receiving user - about a possible man-in-the-middle attack and SHOULD ignore the - message, unless explicitly overridden by the user. - - Implementations MAY provide means for users to disable signing and - encrypting. - - It is possible to receive iMIP messages sent by someone working on - behalf of another "Calendar User". This is determined by examining - the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" - property. [iCAL] and [iTIP] provide no mechanism to verify that a - "Calendar User" has authorized someone else to work on their behalf. - To address this security issue, implementations MUST provide - mechanisms for the "Calendar Users" to make that decision before - applying changes from someone working on behalf of a "Calendar User". - One way to achieve this is to reject iMIP messages sent by users - other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the - receiver could have a list of trusted proxies in - its local security policy. And yet another way is to prompt the user - for confirmation. - - iMIP-based calendaring is frequently deployed within a single ADMD, - with boundary filtering employed to restrict email calendaring flows - to be inside the ADMD. This can help in minimizing malicious changes - to calendaring messages in transit, as well as in making - authorization decisions less risky. - - A security consideration associated with the use of the Content- - Disposition header field is described in Section 2.6. - - Use of S/MIME makes the security considerations discussed in - [RFC5750] [RFC5751] relevant to this document. For additional - security considerations regarding certificate and Certificate - Revocation List (CRL) verification, please see [RFC5280]. - - - - - - - - - - - - - -Melnikov Standards Track [Page 10] - -RFC 6047 iMIP December 2010 - - -4. Examples - -4.1. Single Component with an ATTACH Property - - This minimal message shows how an iCalendar object references an - attachment. The attachment is accessible via its URL. - - From: sman@netscape.example.com - To: stevesil@microsoft.example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:man@netscape.example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com - ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SUMMARY:Phone Conference - DESCRIPTION:Please review the attached document. - UID:calsvr.example.com-873970198738777 - ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - -4.2. Using multipart/alternative for Low-Fidelity Clients - - This example shows how a client can emit a multipart message that - includes both a plain text version and the full iCalendar object. - Clients that do not support "text/calendar" will still be capable of - rendering the plain text representation. - - - - - - - - - - - - -Melnikov Standards Track [Page 11] - -RFC 6047 iMIP December 2010 - - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360" - - --01BD3665.3AF0D360 - Content-Type: text/plain; charset=us-ascii - Content-Transfer-Encoding: 7bit - - This is an alternative representation of a "text/calendar" - MIME object. - - When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT - Where: - Organizer: foo1@example.com - Summary: Phone Conference - - --01BD3665.3AF0D360 - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T170000Z - DTEND:19970701T173000Z - SUMMARY:Phone Conference - UID:calsvr.example.com-8739701987387771 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - --01BD3665.3AF0D360 - -4.3. Single Component with an ATTACH Property and Inline Attachment - - This example shows how a message containing an iCalendar object - references an attached document. The reference is made using a - Content-ID (CID). Thus, the iCalendar object and the document are - packaged in a "multipart/related" encapsulation. - - - -Melnikov Standards Track [Page 12] - -RFC 6047 iMIP December 2010 - - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: multipart/related; boundary="boundary-example-1" - - --boundary-example-1 - - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.ics" - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T180000Z - DTEND:19970701T183000Z - SUMMARY:Phone Conference - UID:calsvr.example.com-8739701987387771 - ATTACH:cid:123456789@example.com - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - --boundary-example-1 - Content-Type: application/msword; name="FieldReport.doc" - Content-Transfer-Encoding: base64 - Content-Disposition: inline; filename="FieldReport.doc" - Content-ID: <123456789@example.com> - - 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA - AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD///////////////////////////////// - ... - - --boundary-example-1-- - - - - - - - - - -Melnikov Standards Track [Page 13] - -RFC 6047 iMIP December 2010 - - -4.4. Multiple Similar Components - - Multiple iCalendar components of the same type can be included in the - iCalendar object when the "METHOD" is the same for each component. - - From: foo1@example.com - To: foo2@example.com - Subject: Summer Company Holidays - Mime-Version: 1.0 - Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.ics" - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:PUBLISH - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - DTSTAMP:19970611T150000Z - DTSTART:19970701T150000Z - DTEND:19970701T230000Z - SUMMARY:Company Picnic - DESCRIPTION:Food and drink will be provided - UID:calsvr.example.com-873970198738777-1 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970715T150000Z - DTEND:19970715T230000Z - SUMMARY:Company Bowling Tournament - DESCRIPTION:We have 10 lanes reserved - UID:calsvr.example.com-873970198738777-2 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - - - - - - - - -Melnikov Standards Track [Page 14] - -RFC 6047 iMIP December 2010 - - -4.5. Multiple Mixed Components - - Different component types must be encapsulated in separate iCalendar - objects. - - From: foo1@example.com - To: foo2@example.com - Subject: Phone Conference - Mime-Version: 1.0 - Content-Type: multipart/mixed; - boundary="--FEE3790DC7E35189CA67CE2C" - - This is a multi-part message in MIME format. - - ----FEE3790DC7E35189CA67CE2C - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event1.ics" - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970701T210000Z - DTEND:19970701T230000Z - SUMMARY:Phone Conference - DESCRIPTION:Discuss what happened at the last meeting - UID:calsvr.example.com-8739701987387772 - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - - - - - - - - - - - - - -Melnikov Standards Track [Page 15] - -RFC 6047 iMIP December 2010 - - - ----FEE3790DC7E35189CA67CE2C - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="todo1.ics" - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VTODO - DUE:19970701T160000Z - ORGANIZER:mailto:foo1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com - ATTENDEE;RSVP=YES:mailto:foo2@example.com - SUMMARY:Phone Conference - DESCRIPTION:Discuss a new location for the company picnic - UID:calsvr.example.com-td-8739701987387773 - SEQUENCE:0 - STATUS:NEEDS-ACTION - END:VEVENT - END:VCALENDAR - - ----FEE3790DC7E35189CA67CE2C - -4.6. Detailed Components with an ATTACH Property - - This example shows the format of a message containing a group meeting - between three individuals. The "multipart/related" encapsulation is - used because the iCalendar object contains an ATTACH property that - uses a CID to reference the attachment. - - From: foo1@example.com - MIME-Version: 1.0 - To: foo2@example.com,foo3@example.com - Subject: REQUEST - Phone Conference - Content-Type: multipart/related; - boundary="--FEE3790DC7E35189CA67CE2C" - - ----FEE3790DC7E35189CA67CE2C - Content-Type: multipart/alternative; - boundary="--00FEE3790DC7E35189CA67CE2C00" - - - - - - - - - - -Melnikov Standards Track [Page 16] - -RFC 6047 iMIP December 2010 - - - ----00FEE3790DC7E35189CA67CE2C00 - Content-Type: text/plain; charset=us-ascii - Content-Transfer-Encoding: 7bit - - When: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT - Where: - Organizer: foo1@example.com - Summary: Let's discuss the attached document - - ----00FEE3790DC7E35189CA67CE2C00 - - Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; - Component=vevent - Content-Transfer-Encoding: 7bit - Content-Disposition: attachment; filename="event.ics" - - BEGIN:VCALENDAR - PRODID:-//Example/ExampleCalendarClient//EN - METHOD:REQUEST - VERSION:2.0 - BEGIN:VEVENT - ORGANIZER:foo1@example.com - ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com - ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com - DTSTAMP:19970611T190000Z - DTSTART:19970621T170000Z - DTEND:199706211T173000Z - SUMMARY:Let's discuss the attached document - UID:calsvr.example.com-873970198738777-8aa - ATTACH:cid:calsvr.example.com-12345aaa - SEQUENCE:0 - STATUS:CONFIRMED - END:VEVENT - END:VCALENDAR - - ----00FEE3790DC7E35189CA67CE2C00 - - - - - - - - - - - - - - -Melnikov Standards Track [Page 17] - -RFC 6047 iMIP December 2010 - - - ----FEE3790DC7E35189CA67CE2C - Content-Type: application/msword; name="FieldReport.doc" - Content-Transfer-Encoding: base64 - Content-Disposition: inline; filename="FieldReport.doc" - Content-ID: - - R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq - AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd - riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i - ZnJY6J - ... - - ----FEE3790DC7E35189CA67CE2C - -5. Recommended Practices - - This section outlines a series of recommended practices when using a - messaging transport to exchange iCalendar objects. - -5.1. Use of Content and Message IDs - - The [iCAL] specification makes frequent use of the URI for data types - in properties such as "DESCRIPTION", "ATTACH", "CONTACT", and others. - Two forms of URIs are the Message ID (MID) and the Content-ID (CID). - These are defined in [RFC2392]. Although [RFC2392] allows - referencing messages or MIME body parts in other MIME entities or - stores, it is strongly RECOMMENDED that iMIP implementations include - all referenced messages and body parts in a single MIME entity. - Simply put, if an iCalendar object contains CID or MID references to - other messages or body parts, implementations should ensure that - these messages and/or body parts are transmitted with the iCalendar - object. If they are not, there is no guarantee that the receiving - CUA will have the access or the authorization to view those objects. - -6. IANA Considerations - - The "text/calendar" MIME media type was registered in [iCAL]. - - - - - - - - - - - - - - -Melnikov Standards Track [Page 18] - -RFC 6047 iMIP December 2010 - - -7. References - -7.1. Normative References - - [iCAL] Desruisseaux, B., Ed., "Internet Calendaring and - Scheduling Core Object Specification (iCalendar)", - RFC 5545, September 2009. - - [iTIP] Daboo, C., Ed., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", RFC 5546, December - 2009. - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - October 2008. - - [MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' - URI Scheme", RFC 6068, October 2010. - - [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, - "Security Multiparts for MIME: Multipart/Signed and - Multipart/Encrypted", RFC 1847, October 1995. - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, - November 1996. - - [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource - Locators", RFC 2392, August 1998. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over - Transport Layer Security", RFC 3207, February 2002. - - [IMAP-POP-TLS] - Newman, C., "Using TLS with IMAP, POP3 and ACAP", - RFC 2595, June 1999. - - - - - - -Melnikov Standards Track [Page 19] - -RFC 6047 iMIP December 2010 - - - [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Certificate - Handling", RFC 5750, January 2010. - - [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Message - Specification", RFC 5751, January 2010. - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation - List (CRL) Profile", RFC 5280, May 2008. - -7.2. Informative References - - [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. - Crocker, "SMTP Service Extension for 8bit-MIMEtransport", - RFC 1652, July 1994. - - [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July - 2009. - - [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May - 2002. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Melnikov Standards Track [Page 20] - -RFC 6047 iMIP December 2010 - - -Appendix A. Changes since RFC 2447 - - Updated references. Split them into Normative and Informative. - - Updated examples to use example.com/example.net domains. - - Corrected usage of RFC 2119 language. - - Clarified that charset=UTF-8 is required, unless the calendar can be - entirely represented in US-ASCII. - - Clarified that 7-bit content transfer encodings should be used unless - the calendar object is known to be transferred over 8-bit clean - transport. - - Clarified that file extension specified in the Content-Disposition - header field is not to be used to override the "Content-Type" MIME - type. - - Disallowed use of "multipart/alternative" for slightly different - representations of the same calendar. - - Clarified handling of the "method" MIME parameter of the "Content- - Type" header field. - - Clarified that in an iMIP message an ORGANIZER/ATTENDEE property - contains a mailto: URI. - - Fixed examples with ATTENDEE property to use "CUTYPE=" instead of - "TYPE=". - - Clarified that message integrity/confidentiality should be achieved - using S/MIME. - - Provided additional examples. - - Improved the Security Considerations section. - - Made multiple editorial changes to different sections of the - document. - - - - - - - - - - - -Melnikov Standards Track [Page 21] - -RFC 6047 iMIP December 2010 - - -Appendix B. Acknowledgements - - The editor of this document wishes to thank Frank Dawson, Steve - Mansour, and Steve Silverberg, the original authors of RFC 2447, as - well as the following individuals who have participated in the - drafting, review, and discussion of this memo: - - Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, - and Peter Saint-Andre. - -Author's Address - - Alexey Melnikov (editor) - Isode Ltd - 5 Castle Business Village - 36 Station Road - Hampton, Middlesex TW12 2BX - UK - - EMail: Alexey.Melnikov@isode.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Melnikov Standards Track [Page 22] - diff --git a/specifications/calendar/rfc8984.pdf b/specifications/calendar/rfc8984.pdf deleted file mode 100644 index 71318d7d..00000000 Binary files a/specifications/calendar/rfc8984.pdf and /dev/null differ diff --git a/specifications/calendar/rfc8984.txt b/specifications/calendar/rfc8984.txt deleted file mode 100644 index 565277cc..00000000 --- a/specifications/calendar/rfc8984.txt +++ /dev/null @@ -1,3987 +0,0 @@ - - - - -Internet Engineering Task Force (IETF) N. Jenkins -Request for Comments: 8984 R. Stepanek -Category: Standards Track Fastmail -ISSN: 2070-1721 July 2021 - - - JSCalendar: A JSON Representation of Calendar Data - -Abstract - - This specification defines a data model and JSON representation of - calendar data that can be used for storage and data exchange in a - calendaring and scheduling environment. It aims to be an alternative - and, over time, successor to the widely deployed iCalendar data - format. It also aims to be unambiguous, extendable, and simple to - process. In contrast to the jCal format, which is also based on - JSON, JSCalendar is not a direct mapping from iCalendar but defines - the data model independently and expands semantics where appropriate. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc8984. - -Copyright Notice - - Copyright (c) 2021 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - -Table of Contents - - 1. Introduction - 1.1. Motivation and Relation to iCalendar and jCal - 1.2. Notational Conventions - 1.3. Type Signatures - 1.4. Data Types - 1.4.1. Id - 1.4.2. Int - 1.4.3. UnsignedInt - 1.4.4. UTCDateTime - 1.4.5. LocalDateTime - 1.4.6. Duration - 1.4.7. SignedDuration - 1.4.8. TimeZoneId - 1.4.9. PatchObject - 1.4.10. Relation - 1.4.11. Link - 2. JSCalendar Objects - 2.1. Event - 2.2. Task - 2.3. Group - 3. Structure of JSCalendar Objects - 3.1. Object Type - 3.2. Normalization and Equivalence - 3.3. Vendor-Specific Property Extensions, Values, and Types - 4. Common JSCalendar Properties - 4.1. Metadata Properties - 4.1.1. @type - 4.1.2. uid - 4.1.3. relatedTo - 4.1.4. prodId - 4.1.5. created - 4.1.6. updated - 4.1.7. sequence - 4.1.8. method - 4.2. What and Where Properties - 4.2.1. title - 4.2.2. description - 4.2.3. descriptionContentType - 4.2.4. showWithoutTime - 4.2.5. locations - 4.2.6. virtualLocations - 4.2.7. links - 4.2.8. locale - 4.2.9. keywords - 4.2.10. categories - 4.2.11. color - 4.3. Recurrence Properties - 4.3.1. recurrenceId - 4.3.2. recurrenceIdTimeZone - 4.3.3. recurrenceRules - 4.3.4. excludedRecurrenceRules - 4.3.5. recurrenceOverrides - 4.3.6. excluded - 4.4. Sharing and Scheduling Properties - 4.4.1. priority - 4.4.2. freeBusyStatus - 4.4.3. privacy - 4.4.4. replyTo - 4.4.5. sentBy - 4.4.6. participants - 4.4.7. requestStatus - 4.5. Alerts Properties - 4.5.1. useDefaultAlerts - 4.5.2. alerts - 4.6. Multilingual Properties - 4.6.1. localizations - 4.7. Time Zone Properties - 4.7.1. timeZone - 4.7.2. timeZones - 5. Type-Specific JSCalendar Properties - 5.1. Event Properties - 5.1.1. start - 5.1.2. duration - 5.1.3. status - 5.2. Task Properties - 5.2.1. due - 5.2.2. start - 5.2.3. estimatedDuration - 5.2.4. percentComplete - 5.2.5. progress - 5.2.6. progressUpdated - 5.3. Group Properties - 5.3.1. entries - 5.3.2. source - 6. Examples - 6.1. Simple Event - 6.2. Simple Task - 6.3. Simple Group - 6.4. All-Day Event - 6.5. Task with a Due Date - 6.6. Event with End Time Zone - 6.7. Floating-Time Event (with Recurrence) - 6.8. Event with Multiple Locations and Localization - 6.9. Recurring Event with Overrides - 6.10. Recurring Event with Participants - 7. Security Considerations - 7.1. Expanding Recurrences - 7.2. JSON Parsing - 7.3. URI Values - 7.4. Spam - 7.5. Duplication - 7.6. Time Zones - 8. IANA Considerations - 8.1. Media Type Registration - 8.2. Creation of the "JSCalendar Properties" Registry - 8.2.1. Preliminary Community Review - 8.2.2. Submit Request to IANA - 8.2.3. Designated Expert Review - 8.2.4. Change Procedures - 8.2.5. "JSCalendar Properties" Registry Template - 8.2.6. Initial Contents for the "JSCalendar Properties" - Registry - 8.3. Creation of the "JSCalendar Types" Registry - 8.3.1. "JSCalendar Types" Registry Template - 8.3.2. Initial Contents for the "JSCalendar Types" Registry - 8.4. Creation of the "JSCalendar Enum Values" Registry - 8.4.1. "JSCalendar Enum Values" Registry Property Template - 8.4.2. "JSCalendar Enum Values" Registry Value Template - 8.4.3. Initial Contents for the "JSCalendar Enum Values" - Registry - 9. References - 9.1. Normative References - 9.2. Informative References - Acknowledgments - Authors' Addresses - -1. Introduction - - This document defines a data model for calendar event and task - objects, or groups of such objects, in electronic calendar - applications and systems. The format aims to be unambiguous, - extendable, and simple to process. - - The key design considerations for this data model are as follows: - - * The attributes of the calendar entry represented must be described - as simple key-value pairs. Simple events are simple to represent; - complex events can be modeled accurately. - - * Wherever possible, there should be only one way to express the - desired semantics, reducing complexity. - - * The data model should avoid ambiguities, which often lead to - interoperability issues between implementations. - - * The data model should be generally compatible with the iCalendar - data format [RFC5545] [RFC7986] and extensions, but the - specification should add new attributes where the iCalendar format - currently lacks expressivity, and drop seldom-used, obsolete, or - redundant properties. This means translation with no loss of - semantics should be easy with most common iCalendar files. - - * Extensions, such as new properties and components, should not - require updates to this document. - - The representation of this data model is defined in the Internet JSON - (I-JSON) format [RFC7493], which is a strict subset of the JSON data - interchange format [RFC8259]. Using JSON is mostly a pragmatic - choice: its widespread use makes JSCalendar easier to adopt and the - ready availability of production-ready JSON implementations - eliminates a whole category of parser-related interoperability - issues, which iCalendar has often suffered from. - -1.1. Motivation and Relation to iCalendar and jCal - - The iCalendar data format [RFC5545], a widely deployed interchange - format for calendaring and scheduling data, has served calendaring - vendors for a long time but contains some ambiguities and pitfalls - that cannot be overcome without backward-incompatible changes. - - Sources of implementation errors include the following: - - * iCalendar defines various formats for local times, UTC, and dates. - - * iCalendar requires custom time zone definitions within a single - calendar component. - - * iCalendar's definition of recurrence rules is ambiguous and has - resulted in differing interpretations, even between experienced - calendar developers. - - * The iCalendar format itself causes interoperability issues due to - misuse of CRLF-terminated strings, line continuations, and subtle - differences among iCalendar parsers. - - In recent years, many new products and services have appeared that - wish to use a JSON representation of calendar data within their APIs. - The JSON format for iCalendar data, jCal [RFC7265], is a direct - mapping between iCalendar and JSON. In its effort to represent full - iCalendar semantics, it inherits all the same pitfalls and uses a - complicated JSON structure. - - As a consequence, since the standardization of jCal, the majority of - implementations and service providers either kept using iCalendar or - came up with their own proprietary JSON representations, which are - incompatible with each other and often suffer from common pitfalls, - such as storing event start times in UTC (which become incorrect if - the time zone's rules change in the future). JSCalendar meets the - demand for JSON-formatted calendar data that is free of such known - problems and provides a standard representation as an alternative to - the proprietary formats. - -1.2. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - The underlying format used for this specification is JSON. - Consequently, the terms "object" and "array" as well as the four - primitive types (strings, numbers, booleans, and null) are to be - interpreted as described in Section 1 of [RFC8259]. - - Some examples in this document contain "partial" JSON documents used - for illustrative purposes. In these examples, an ellipsis "..." is - used to indicate a portion of the document that has been removed for - compactness. - -1.3. Type Signatures - - Type signatures are given for all JSON values in this document. The - following conventions are used: - - "*": The type is undefined (the value could be any type, although - permitted values may be constrained by the context of this value). - - "String": This is the JSON string type. - - "Number": This is the JSON number type. - - "Boolean": This is the JSON boolean type. - - "A[B]": The keys are all of type "A" and the values are all of type - "B" for a JSON object. - - "A[]": There is an array of values of type "A" - - "A|B": The value is either of type "A" or of type "B". - - Other types may also be given; their representations are defined - elsewhere in this document. - -1.4. Data Types - - In addition to the standard JSON data types, the following data types - are used in this specification: - -1.4.1. Id - - Where "Id" is given as a data type, it means a "String" of at least 1 - and a maximum of 255 octets in size, and it MUST only contain - characters from the "URL and Filename Safe" base64url alphabet, as - defined in Section 5 of [RFC4648], excluding the pad character ("="). - This means the allowed characters are the ASCII alphanumeric - characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). - - In many places in JSCalendar, a JSON map is used where the map keys - are of type Id and the map values are all the same type of object. - This construction represents an unordered set of objects, with the - added advantage that each entry has a name (the corresponding map - key). This allows for more concise patching of objects, and, when - applicable, for the objects in question to be referenced from other - objects within the JSCalendar object. - - Unless otherwise specified for a particular property, there are no - uniqueness constraints on an Id value (other than, of course, the - requirement that you cannot have two values with the same key within - a single JSON map). For example, two Event objects might use the - same Ids in their respective "links" properties or, within the same - Event object, the same Id could appear in the "participants" and - "alerts" properties. These situations do not imply any semantic - connections among the objects. - -1.4.2. Int - - Where "Int" is given as a data type, it means an integer in the range - -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a - floating-point double, represented as a JSON "Number". - -1.4.3. UnsignedInt - - Where "UnsignedInt" is given as a data type, it means an integer in - the range 0 <= value <= 2^53-1, represented as a JSON "Number". - -1.4.4. UTCDateTime - - This is a string in the "date-time" [RFC3339] format, with the - further restrictions that any letters MUST be in uppercase, and the - time offset MUST be the character "Z". Fractional second values MUST - NOT be included unless non-zero and MUST NOT have trailing zeros, to - ensure there is only a single representation for each date-time. - - For example, "2010-10-10T10:10:10.003Z" is conformant, but - "2010-10-10T10:10:10.000Z" is invalid and is correctly encoded as - "2010-10-10T10:10:10Z". - -1.4.5. LocalDateTime - - This is a date-time string with no time zone/offset information. It - is otherwise in the same format as UTCDateTime, including fractional - seconds. For example, "2006-01-02T15:04:05" and - "2006-01-02T15:04:05.003" are both valid. The time zone to associate - with the LocalDateTime comes from the "timeZone" property of the - JSCalendar object (see Section 4.7.1). If no time zone is specified, - the LocalDateTime is "floating". Floating date-times are not tied to - any specific time zone. Instead, they occur in each time zone at the - given wall-clock time (as opposed to the same instant point in time). - - A time zone may have a period of discontinuity, for example, a change - from standard time to daylight savings time. When converting local - date-times that fall in the discontinuity to UTC, the offset before - the transition MUST be used. - - For example, in the America/Los_Angeles time zone, the date-time - 2020-11-01T01:30:00 occurs twice: before the daylight savings time - (DST) transition with a UTC offset of -07:00 and again after the - transition with an offset of -08:00. When converting to UTC, we - therefore use the offset before the transition (-07:00), so it - becomes 2020-11-01T08:30:00Z. - - Similarly, in the Australia/Melbourne time zone, the date-time - 2020-10-04T02:30:00 does not exist; the clocks are moved forward one - hour for DST on that day at 02:00. However, such a value may appear - during calculations (see duration semantics in Section 1.4.6) or due - to a change in time zone rules (so it was valid when the event was - first created). Again, it is interpreted as though the offset before - the transition is in effect (+10:00); therefore, when converted to - UTC, we get 2020-10-03T16:30:00Z. - -1.4.6. Duration - - Where Duration is given as a type, it means a length of time - represented by a subset of the ISO 8601 duration format, as specified - by the following ABNF [RFC5234]: - - dur-secfrac = "." 1*DIGIT - dur-second = 1*DIGIT [dur-secfrac] "S" - dur-minute = 1*DIGIT "M" [dur-second] - dur-hour = 1*DIGIT "H" [dur-minute] - dur-time = "T" (dur-hour / dur-minute / dur-second) - dur-day = 1*DIGIT "D" - dur-week = 1*DIGIT "W" - dur-cal = (dur-week [dur-day] / dur-day) - - duration = "P" (dur-cal [dur-time] / dur-time) - - In addition, the duration MUST NOT include fractional second values - unless the fraction is non-zero. Fractional second values MUST NOT - have trailing zeros to ensure there is only a single representation - for each duration. - - A duration specifies an abstract number of weeks, days, hours, - minutes, and/or seconds. A duration specified using weeks or days - does not always correspond to an exact multiple of 24 hours. The - number of hours/minutes/seconds may vary if it overlaps a period of - discontinuity in the event's time zone, for example, a change from - standard time to daylight savings time. Leap seconds MUST NOT be - considered when adding or subtracting a duration to/from a - LocalDateTime. - - To add a duration to a LocalDateTime: - - 1. Add any week or day components of the duration to the date. A - week is always the same as seven days. - - 2. If a time zone applies to the LocalDateTime, convert it to a - UTCDateTime following the semantics in Section 1.4.5. - - 3. Add any hour, minute, or second components of the duration (in - absolute time). - - 4. Convert the resulting UTCDateTime back to a LocalDateTime in the - time zone that applies. - - To subtract a duration from a LocalDateTime, the steps apply in - reverse: - - 1. If a time zone applies to the LocalDateTime, convert it to UTC - following the semantics in Section 1.4.5. - - 2. Subtract any hour, minute, or second components of the duration - (in absolute time). - - 3. Convert the resulting UTCDateTime back to LocalDateTime in the - time zone that applies. - - 4. Subtract any week or day components of the duration from the - date. - - 5. If the resulting time does not exist on the date due to a - discontinuity in the time zone, use the semantics in - Section 1.4.5 to convert to UTC and back to get a valid - LocalDateTime. - - These semantics match the iCalendar DURATION value type ([RFC5545], - Section 3.3.6). - -1.4.7. SignedDuration - - A SignedDuration represents a length of time that may be positive or - negative and is typically used to express the offset of a point in - time relative to an associated time. It is represented as a - Duration, optionally preceded by a sign character. It is specified - by the following ABNF: - - signed-duration = ["+" / "-"] duration - - A negative sign indicates a point in time at or before the associated - time; a positive or no sign indicates a time at or after the - associated time. - -1.4.8. TimeZoneId - - Where "TimeZoneId" is given as a data type, it means a "String" that - is either a time zone name in the IANA Time Zone Database [TZDB] or a - custom time zone identifier defined in the "timeZones" property (see - Section 4.7.2). - - Where an IANA time zone is specified, the zone rules of the - respective zone records apply. Custom time zones are interpreted as - described in Section 4.7.2. - -1.4.9. PatchObject - - A PatchObject is of type "String[*]" and represents an unordered set - of patches on a JSON object. Each key is a path represented in a - subset of the JSON Pointer format [RFC6901]. The paths have an - implicit leading "/", so each key is prefixed with "/" before - applying the JSON Pointer evaluation algorithm. - - A patch within a PatchObject is only valid if all of the following - conditions apply: - - 1. The pointer MUST NOT reference inside an array (i.e., you MUST - NOT insert/delete from an array; the array MUST be replaced in - its entirety instead). - - 2. All parts prior to the last (i.e., the value after the final - slash) MUST already exist on the object being patched. - - 3. There MUST NOT be two patches in the PatchObject where the - pointer of one is the prefix of the pointer of the other, e.g., - "alerts/1/offset" and "alerts". - - 4. The value for the patch MUST be valid for the property being set - (of the correct type and obeying any other applicable - restrictions), or, if null, the property MUST be optional. - - The value associated with each pointer determines how to apply that - patch: - - * If null, remove the property from the patched object. If the key - is not present in the parent, this a no-op. - - * If non-null, set the value given as the value for this property - (this may be a replacement or addition to the object being - patched). - - A PatchObject does not define its own "@type" property (see - Section 4.1.1). An "@type" property in a patch MUST be handled as - any other patched property value. - - Implementations MUST reject a PatchObject in its entirety if any of - its patches are invalid. Implementations MUST NOT apply partial - patches. - - The PatchObject format is used to significantly reduce file size and - duplicated content when specifying variations to a common object, - such as with recurring events or when translating the data into - multiple languages. It can also better preserve semantic intent if - only the properties that should differ between the two objects are - patched. For example, if one person is not going to a particular - instance of a regularly scheduled event, in iCalendar, you would have - to duplicate the entire event in the override. In JSCalendar, this - is a small patch to show the difference. As only this property is - patched, if the location of the event is changed, the occurrence will - automatically still inherit this. - -1.4.10. Relation - - A Relation object defines the relation to other objects, using a - possibly empty set of relation types. The object that defines this - relation is the linking object, while the other object is the linked - object. A Relation object has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "Relation". - - relation: "String[Boolean]" (optional, default: empty Object) - This describes how the linked object is related to the linking - object. The relation is defined as a set of relation types. If - empty, the relationship between the two objects is unspecified. - - Keys in the set MUST be one of the following values, specified in - the property definition where the Relation object is used, a value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "first": The linked object is the first in a series the linking - object is part of. - - "next": The linked object is next in a series the linking object - is part of. - - "child": The linked object is a subpart of the linking object. - - "parent": The linking object is a subpart of the linked object. - - The value for each key in the map MUST be true. - -1.4.11. Link - - A Link object represents an external resource associated with the - linking object. It has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "Link". - - href: "String" (mandatory) - This is a URI [RFC3986] from which the resource may be fetched. - - This MAY be a "data:" URL [RFC2397], but it is recommended that - the file be hosted on a server to avoid embedding arbitrarily - large data in JSCalendar object instances. - - cid: "String" (optional) - This MUST be a valid "content-id" value according to the - definition of Section 2 of [RFC2392]. The value MUST be unique - within this Link object but has no meaning beyond that. It MAY be - different from the link id for this Link object. - - contentType: "String" (optional) - This is the media type [RFC6838] of the resource, if known. - - size: "UnsignedInt" (optional) - This is the size, in octets, of the resource when fully decoded - (i.e., the number of octets in the file the user would download), - if known. Note that this is an informational estimate, and - implementations must be prepared to handle the actual size being - quite different when the resource is fetched. - - rel: "String" (optional) - This identifies the relation of the linked resource to the object. - If set, the value MUST be a relation type from the IANA "Link - Relations" registry [LINKRELS], as established in [RFC8288]. - - display: "String" (optional) - This describes the intended purpose of a link to an image. If - set, the "rel" property MUST be set to "icon". The value MUST be - one of the following values, another value registered in the IANA - "JSCalendar Enum Values" registry, or a vendor-specific value (see - Section 3.3): - - "badge": an image meant to be displayed alongside the title of - the object - - "graphic": a full image replacement for the object itself - - "fullsize": an image that is used to enhance the object - - "thumbnail": a smaller variant of "fullsize" to be used when - space for the image is constrained - - title: "String" (optional) - This is a human-readable, plain-text description of the resource. - -2. JSCalendar Objects - - This section describes the calendar object types specified by - JSCalendar. - -2.1. Event - - Media type: "application/jscalendar+json;type=event" - - An Event represents a scheduled amount of time on a calendar, - typically a meeting, appointment, reminder, or anniversary. It is - required to start at a certain point in time and typically has a non- - zero duration. Multiple participants may partake in the event at - multiple locations. - - The @type (Section 4.1.1) property value MUST be "Event". - -2.2. Task - - Media type: "application/jscalendar+json;type=task" - - A Task represents an action item, assignment, to-do item, or work - item. It may start and be due at certain points in time, take some - estimated time to complete, and recur, none of which is required. - - The @type (Section 4.1.1) property value MUST be "Task". - -2.3. Group - - Media type: "application/jscalendar+json;type=group" - - A Group is a collection of Event (Section 2.1) and/or Task - (Section 2.2) objects. Typically, objects are grouped by topic - (e.g., by keywords) or calendar membership. - - The @type (Section 4.1.1) property value MUST be "Group". - -3. Structure of JSCalendar Objects - - A JSCalendar object is a JSON object [RFC8259], which MUST be valid - I-JSON (a stricter subset of JSON) [RFC7493]. Property names and - values are case sensitive. - - The object has a collection of properties, as specified in the - following sections. Properties are specified as being either - mandatory or optional. Optional properties may have a default value - if explicitly specified in the property definition. - -3.1. Object Type - - JSCalendar objects MUST name their type in the "@type" property if - not explicitly specified otherwise for the respective object type. A - notable exception to this rule is the PatchObject (Section 1.4.9). - -3.2. Normalization and Equivalence - - JSCalendar aims to provide unambiguous definitions for value types - and properties but does not define a general normalization or - equivalence method for JSCalendar objects and types. This is because - the notion of equivalence might range from byte-level equivalence to - semantic equivalence, depending on the respective use case. - Normalization of JSCalendar objects is hindered because of the - following reasons: - - * Custom JSCalendar properties may contain arbitrary JSON values, - including arrays. However, equivalence of arrays might or might - not depend on the order of elements, depending on the respective - property definition. - - * Several JSCalendar property values are defined as URIs and media - types, but normalization of these types is inherently protocol and - scheme specific, depending on the use case of the equivalence - definition (see Section 6 of [RFC3986]). - - Considering this, the definition of equivalence and normalization is - left to client and server implementations and to be negotiated by a - calendar exchange protocol or defined elsewhere. - -3.3. Vendor-Specific Property Extensions, Values, and Types - - Vendors MAY add additional properties to the calendar object to - support their custom features. To avoid conflict, the names of these - properties MUST be prefixed by a domain name controlled by the vendor - followed by a colon, e.g., "example.com:customprop". If the value is - a new JSCalendar object, it either MUST include an "@type" property, - or it MUST explicitly be specified to not require a type designator. - The type name MUST be prefixed with a domain name controlled by the - vendor. - - Some JSCalendar properties allow vendor-specific value extensions. - Such vendor-specific values MUST be prefixed by a domain name - controlled by the vendor followed by a colon, e.g., - "example.com:customrel". - - Vendors are strongly encouraged to register any new property values - or extensions that are useful to other systems as well, rather than - use a vendor-specific prefix. - -4. Common JSCalendar Properties - - This section describes the properties that are common to the various - JSCalendar object types. Specific JSCalendar object types may only - support a subset of these properties. The object type definitions in - Section 5 describe the set of supported properties per type. - -4.1. Metadata Properties - -4.1.1. @type - - Type: "String" (mandatory) - - This specifies the type that this object represents. The allowed - value differs by object type and is defined in Sections 2.1, 2.2, and - 2.3. - -4.1.2. uid - - Type: "String" (mandatory) - - This is a globally unique identifier used to associate objects - representing the same event, task, group, or other object across - different systems, calendars, and views. For recurring events and - tasks, the UID is associated with the base object and therefore is - the same for all occurrences; the combination of the UID with a - "recurrenceId" identifies a particular instance. - - The generator of the identifier MUST guarantee that the identifier is - unique. [RFC4122] describes a range of established algorithms to - generate universally unique identifiers (UUIDs). UUID version 4, - described in Section 4.4 of [RFC4122], is RECOMMENDED. - - For compatibility with UIDs [RFC5545], implementations MUST be able - to receive and persist values of at least 255 octets for this - property, but they MUST NOT truncate values in the middle of a UTF-8 - multi-octet sequence. - -4.1.3. relatedTo - - Type: "String[Relation]" (optional) - - This relates the object to other JSCalendar objects. This is - represented as a map of the UIDs of the related objects to - information about the relation. - - If an object is split to make a "this and future" change to a - recurrence, the original object MUST be truncated to end at the - previous occurrence before this split, and a new object is created to - represent all the occurrences after the split. A "next" relation - MUST be set on the original object's "relatedTo" property for the UID - of the new object. A "first" relation for the UID of the first - object in the series MUST be set on the new object. Clients can then - follow these UIDs to get the complete set of objects if the user - wishes to modify them all at once. - -4.1.4. prodId - - Type: "String" (optional) - - This is the identifier for the product that last updated the - JSCalendar object. This should be set whenever the data in the - object is modified (i.e., whenever the "updated" property is set). - - The vendor of the implementation MUST ensure that this is a globally - unique identifier, using some technique such as a Formal Public - Identifier (FPI) value, as defined in [ISO.9070.1991]. - - This property SHOULD NOT be used to alter the interpretation of a - JSCalendar object beyond the semantics specified in this document. - For example, it is not to be used to further the understanding of - nonstandard properties, a practice that is known to cause long-term - interoperability problems. - -4.1.5. created - - Type: "UTCDateTime" (optional) - - This is the date and time this object was initially created. - -4.1.6. updated - - Type: "UTCDateTime" (mandatory) - - This is the date and time the data in this object was last modified - (or its creation date/time if not modified since). - -4.1.7. sequence - - Type: "UnsignedInt" (optional, default: 0) - - Initially zero, this MUST be incremented by one every time a change - is made to the object, except if the change only modifies the - "participants" property (see Section 4.4.6). - - This is used as part of the iCalendar Transport-independent - Interoperability Protocol (iTIP) [RFC5546] to know which version of - the object a scheduling message relates to. - -4.1.8. method - - Type: "String" (optional) - - This is the iTIP [RFC5546] method, in lowercase. This MUST only be - present if the JSCalendar object represents an iTIP scheduling - message. - -4.2. What and Where Properties - -4.2.1. title - - Type: "String" (optional, default: empty String) - - This is a short summary of the object. - -4.2.2. description - - Type: "String" (optional, default: empty String) - - This is a longer-form text description of the object. The content is - formatted according to the "descriptionContentType" property. - -4.2.3. descriptionContentType - - Type: "String" (optional, default: "text/plain") - - This describes the media type [RFC6838] of the contents of the - "description" property. Media types MUST be subtypes of type "text" - and SHOULD be "text/plain" or "text/html" [MEDIATYPES]. They MAY - include parameters, and the "charset" parameter value MUST be "utf- - 8", if specified. Descriptions of type "text/html" MAY contain "cid" - URLs [RFC2392] to reference links in the calendar object by use of - the "cid" property of the Link object. - -4.2.4. showWithoutTime - - Type: "Boolean" (optional, default: false) - - This indicates that the time is not important to display to the user - when rendering this calendar object. An example of this is an event - that conceptually occurs all day or across multiple days, such as - "New Year's Day" or "Italy Vacation". While the time component is - important for free-busy calculations and checking for scheduling - clashes, calendars may choose to omit displaying it and/or display - the object separately to other objects to enhance the user's view of - their schedule. - - Such events are also commonly known as "all-day" events. - -4.2.5. locations - - Type: "Id[Location]" (optional) - - This is a map of location ids to Location objects, representing - locations associated with the object. - - A Location object has the following properties. It MUST have at - least one property other than the "relativeTo" property. - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "Location". - - name: "String" (optional) - This is the human-readable name of the location. - - description: "String" (optional) - This is the human-readable, plain-text instructions for accessing - this location. This may be an address, set of directions, door - access code, etc. - - locationTypes: "String[Boolean]" (optional) - This is a set of one or more location types that describe this - location. All types MUST be from the "Location Types Registry" - [LOCATIONTYPES], as defined in [RFC4589]. The set is represented - as a map, with the keys being the location types. The value for - each key in the map MUST be true. - - relativeTo: "String" (optional) - This specifies the relation between this location and the time of - the JSCalendar object. This is primarily to allow events - representing travel to specify the location of departure (at the - start of the event) and location of arrival (at the end); this is - particularly important if these locations are in different time - zones, as a client may wish to highlight this information for the - user. - - This MUST be one of the following values, another value registered - in the IANA "JSCalendar Enum Values" registry, or a vendor- - specific value (see Section 3.3). Any value the client or server - doesn't understand should be treated the same as if this property - is omitted. - - "start": The event/task described by this JSCalendar object - occurs at this location at the time the event/task starts. - - "end": The event/task described by this JSCalendar object occurs - at this location at the time the event/task ends. - - timeZone: "TimeZoneId" (optional) - This is a time zone for this location. - - coordinates: "String" (optional) - This is a "geo:" URI [RFC5870] for the location. - - links: "Id[Link]" (optional) - This is a map of link ids to Link objects, representing external - resources associated with this location, for example, a vCard or - image. If there are no links, this MUST be omitted (rather than - specified as an empty set). - -4.2.6. virtualLocations - - Type: "Id[VirtualLocation]" (optional) - - This is a map of virtual location ids to VirtualLocation objects, - representing virtual locations, such as video conferences or chat - rooms, associated with the object. - - A VirtualLocation object has the following properties. - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "VirtualLocation". - - name: "String" (optional, default: empty String) - This is the human-readable name of the virtual location. - - description: "String" (optional) - These are human-readable plain-text instructions for accessing - this virtual location. This may be a conference access code, etc. - - uri: "String" (mandatory) - This is a URI [RFC3986] that represents how to connect to this - virtual location. - - This may be a telephone number (represented using the "tel:" - scheme, e.g., "tel:+1-555-555-5555") for a teleconference, a web - address for online chat, or any custom URI. - - features: "String[Boolean]" (optional) - A set of features supported by this virtual location. The set is - represented as a map, with the keys being the feature. The value - for each key in the map MUST be true. - - The feature MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3). Any value the client or - server doesn't understand should be treated the same as if this - feature is omitted. - - audio: Audio conferencing - - chat: Chat or instant messaging - - feed: Blog or atom feed - - moderator: Provides moderator-specific features - - phone: Phone conferencing - - screen: Screen sharing - - video: Video conferencing - -4.2.7. links - - Type: "Id[Link]" (optional) - - This is a map of link ids to Link objects, representing external - resources associated with the object. - - Links with a rel of "enclosure" MUST be considered by the client to - be attachments for download. - - Links with a rel of "describedby" MUST be considered by the client to - be alternative representations of the description. - - Links with a rel of "icon" MUST be considered by the client to be - images that it may use when presenting the calendar data to a user. - The "display" property may be set to indicate the purpose of this - image. - -4.2.8. locale - - Type: "String" (optional) - - This is the language tag, as defined in [RFC5646], that best - describes the locale used for the text in the calendar object, if - known. - -4.2.9. keywords - - Type: "String[Boolean]" (optional) - - This is a set of keywords or tags that relate to the object. The set - is represented as a map, with the keys being the keywords. The value - for each key in the map MUST be true. - -4.2.10. categories - - Type: "String[Boolean]" (optional) - - This is a set of categories that relate to the calendar object. The - set is represented as a map, with the keys being the categories - specified as URIs. The value for each key in the map MUST be true. - - In contrast to keywords, categories are typically structured. For - example, a vendor owning the domain "example.com" might define the - categories "http://example.com/categories/sports/american-football" - and "http://example.com/categories/music/r-b". - -4.2.11. color - - Type: "String" (optional) - - This is a color clients MAY use when displaying this calendar object. - The value is a color name taken from the set of names defined in - Section 4.3 of CSS Color Module Level 3 [COLORS] or an RGB value in - hexadecimal notation, as defined in Section 4.2.1 of CSS Color Module - Level 3. - -4.3. Recurrence Properties - - Some events and tasks occur at regular or irregular intervals. - Rather than having to copy the data for every occurrence, there can - be a base event with rules to generate recurrences and/or overrides - that add extra dates or exceptions to the rules. - - The recurrence set is the complete set of instances for an object. - It is generated by considering the following properties in order, all - of which are optional: - - 1. The "recurrenceRules" property (Section 4.3.3) generates a set of - extra date-times on which the object occurs. - - 2. The "excludedRecurrenceRules" property (Section 4.3.4) generates - a set of date-times that are to be removed from the previously - generated set of date-times on which the object occurs. - - 3. The "recurrenceOverrides" property (Section 4.3.5) defines date- - times that are added or excluded to form the final set. (This - property may also contain changes to the object to apply to - particular instances.) - -4.3.1. recurrenceId - - Type: "LocalDateTime" (optional) - - If present, this JSCalendar object represents one occurrence of a - recurring JSCalendar object. If present, the "recurrenceRules" and - "recurrenceOverrides" properties MUST NOT be present. - - The value is a date-time either produced by the "recurrenceRules" of - the base event or added as a key to the "recurrenceOverrides" - property of the base event. - -4.3.2. recurrenceIdTimeZone - - Type: "TimeZoneId|null" (optional, default: null) - - Identifies the time zone of the main JSCalendar object, of which this - JSCalendar object is a recurrence instance. This property MUST be - set if the "recurrenceId" property is set. It MUST NOT be set if the - "recurrenceId" property is not set. - -4.3.3. recurrenceRules - - Type: "RecurrenceRule[]" (optional) - - This defines a set of recurrence rules (repeating patterns) for - recurring calendar objects. - - An Event recurs by applying the recurrence rules to the "start" date- - time. - - A Task recurs by applying the recurrence rules to the "start" date- - time, if defined; otherwise, it recurs by the "due" date-time, if - defined. If the task defines neither a "start" nor "due" date-time, - it MUST NOT define a "recurrenceRules" property. - - If multiple recurrence rules are given, each rule is to be applied, - and then the union of the results are used, ignoring any duplicates. - - A RecurrenceRule object is a JSON object mapping of a RECUR value - type in iCalendar [RFC5545] [RFC7529] and has the same semantics. It - has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "RecurrenceRule". - - frequency: "String" (mandatory) - This is the time span covered by each iteration of this recurrence - rule (see Section 4.3.3.1 for full semantics). This MUST be one - of the following values: - - * "yearly" - - * "monthly" - - * "weekly" - - * "daily" - - * "hourly" - - * "minutely" - - * "secondly" - - This is the FREQ part from iCalendar, converted to lowercase. - - interval: "UnsignedInt" (optional, default: 1) - This is the interval of iteration periods at which the recurrence - repeats. If included, it MUST be an integer >= 1. - - This is the INTERVAL part from iCalendar. - - rscale: "String" (optional, default: "gregorian") - This is the calendar system in which this recurrence rule - operates, in lowercase. This MUST be either a CLDR-registered - calendar system name [CLDR] or a vendor-specific value (see - Section 3.3). - - This is the RSCALE part from iCalendar RSCALE [RFC7529], converted - to lowercase. - - skip: "String" (optional, default: "omit") - This is the behavior to use when the expansion of the recurrence - produces invalid dates. This property only has an effect if the - frequency is "yearly" or "monthly". It MUST be one of the - following values: - - * "omit" - - * "backward" - - * "forward" - - This is the SKIP part from iCalendar RSCALE [RFC7529], converted - to lowercase. - - firstDayOfWeek: "String" (optional, default: "mo") - This is the day on which the week is considered to start, - represented as a lowercase, abbreviated, and two-letter English - day of the week. If included, it MUST be one of the following - values: - - * "mo" - - * "tu" - - * "we" - - * "th" - - * "fr" - - * "sa" - - * "su" - - This is the WKST part from iCalendar. - - byDay: "NDay[]" (optional) - These are days of the week on which to repeat. An "NDay" object - has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "NDay". - - day: "String" (mandatory) - This is a day of the week on which to repeat; the allowed - values are the same as for the "firstDayOfWeek" recurrenceRule - property. - - This is the day of the week of the BYDAY part in iCalendar, - converted to lowercase. - - nthOfPeriod: "Int" (optional) - If present, rather than representing every occurrence of the - weekday defined in the "day" property, it represents only a - specific instance within the recurrence period. The value can - be positive or negative but MUST NOT be zero. A negative - integer means the nth-last occurrence within that period (i.e., - -1 is the last occurrence, -2 the one before that, etc.). - - This is the ordinal part of the BYDAY value in iCalendar (e.g., - 1 or -3). - - byMonthDay: "Int[]" (optional) - These are the days of the month on which to repeat. Valid values - are between 1 and the maximum number of days any month may have in - the calendar given by the "rscale" property and the negative - values of these numbers. For example, in the Gregorian calendar, - valid values are 1 to 31 and -31 to -1. Negative values offset - from the end of the month. The array MUST have at least one entry - if included. - - This is the BYMONTHDAY part in iCalendar. - - byMonth: "String[]" (optional) - These are the months in which to repeat. Each entry is a string - representation of a number, starting from "1" for the first month - in the calendar (e.g., "1" means January with the Gregorian - calendar), with an optional "L" suffix (see [RFC7529]) for leap - months (this MUST be uppercase, e.g., "3L"). The array MUST have - at least one entry if included. - - This is the BYMONTH part from iCalendar. - - byYearDay: "Int[]" (optional) - These are the days of the year on which to repeat. Valid values - are between 1 and the maximum number of days any year may have in - the calendar given by the "rscale" property and the negative - values of these numbers. For example, in the Gregorian calendar, - valid values are 1 to 366 and -366 to -1. Negative values offset - from the end of the year. The array MUST have at least one entry - if included. - - This is the BYYEARDAY part from iCalendar. - - byWeekNo: "Int[]" (optional) - These are the weeks of the year in which to repeat. Valid values - are between 1 and the maximum number of weeks any year may have in - the calendar given by the "rscale" property and the negative - values of these numbers. For example, in the Gregorian calendar, - valid values are 1 to 53 and -53 to -1. The array MUST have at - least one entry if included. - - This is the BYWEEKNO part from iCalendar. - - byHour: "UnsignedInt[]" (optional) - These are the hours of the day in which to repeat. Valid values - are 0 to 23. The array MUST have at least one entry if included. - This is the BYHOUR part from iCalendar. - - byMinute: "UnsignedInt[]" (optional) - These are the minutes of the hour in which to repeat. Valid - values are 0 to 59. The array MUST have at least one entry if - included. - - This is the BYMINUTE part from iCalendar. - - bySecond: "UnsignedInt[]" (optional) - These are the seconds of the minute in which to repeat. Valid - values are 0 to 60. The array MUST have at least one entry if - included. - - This is the BYSECOND part from iCalendar. - - bySetPosition: "Int[]" (optional) - These are the occurrences within the recurrence interval to - include in the final results. Negative values offset from the end - of the list of occurrences. The array MUST have at least one - entry if included. This is the BYSETPOS part from iCalendar. - - count: "UnsignedInt" (optional) - These are the number of occurrences at which to range-bound the - recurrence. This MUST NOT be included if an "until" property is - specified. - - This is the COUNT part from iCalendar. - - until: "LocalDateTime" (optional) - These are the date-time at which to finish recurring. The last - occurrence is on or before this date-time. This MUST NOT be - included if a "count" property is specified. Note that if not - specified otherwise for a specific JSCalendar object, this date is - to be interpreted in the time zone specified in the JSCalendar - object's "timeZone" property. - - This is the UNTIL part from iCalendar. - -4.3.3.1. Interpreting Recurrence Rules - - A recurrence rule specifies a set of date-times for recurring - calendar objects. A recurrence rule has the following semantics. - Note that wherever "year", "month", or "day of month" is used, this - is within the calendar system given by the "rscale" property, which - defaults to "gregorian" if omitted. - - 1. A set of candidates is generated. This is every second within a - period defined by the "frequency" property value: - - "yearly": every second from midnight on the first day of a year - (inclusive) to midnight the first day of the following year - (exclusive). - - If skip is not "omit", the calendar system has leap months, - and there is a "byMonth" property, generate candidates for the - leap months, even if they don't occur in this year. - - If skip is not "omit" and there is a "byMonthDay" property, - presume each month has the maximum number of days any month - may have in this calendar system when generating candidates, - even if it's more than this month actually has. - - "monthly": every second from midnight on the first day of a - month (inclusive) to midnight on the first of the following - month (exclusive). - - If skip is not "omit" and there is a "byMonthDay" property, - presume the month has the maximum number of days any month may - have in this calendar system when generating candidates, even - if it's more than this month actually has. - - "weekly": every second from midnight (inclusive) on the first - day of the week (as defined by the "firstDayOfWeek" property - or Monday if omitted) to midnight seven days later - (exclusive). - - "daily": every second from midnight at the start of the day - (inclusive) to midnight at the end of the day (exclusive). - - "hourly": every second from the beginning of the hour - (inclusive) to the beginning of the next hour (exclusive). - - "minutely": every second from the beginning of the minute - (inclusive) to the beginning of the next minute (exclusive). - - "secondly": only the second itself. - - 2. Each date-time candidate is compared against all of the byX - properties of the rule except bySetPosition. If any property in - the rule does not match the date-time, the date-time is - eliminated. Each byX property is an array; the date-time matches - the property if it matches any of the values in the array. The - properties have the following semantics: - - byMonth: The date-time is in the given month. - - byWeekNo: The date-time is in the nth week of the year. - Negative numbers mean the nth last week of the year. This - corresponds to weeks according to week numbering, as defined - in ISO.8601.2004, with a week defined as a seven-day period, - starting on the "firstDayOfWeek" property value or Monday if - omitted. Week number one of the calendar year is the first - week that contains at least four days in that calendar year. - - If the date-time is not valid (this may happen when generating - candidates with a "skip" property in effect), it is always - eliminated by this property. - - byYearDay: The date-time is on the nth day of year. Negative - numbers mean the nth last day of the year. - - If the date-time is not valid (this may happen when generating - candidates with a "skip" property in effect), it is always - eliminated by this property. - - byMonthDay: The date-time is on the given day of the month. - Negative numbers mean the nth last day of the month. - - byDay: The date-time is on the given day of the week. If the - day is prefixed by a number, it is the nth occurrence of that - day of the week within the month (if frequency is monthly) or - year (if frequency is yearly). Negative numbers mean the nth - last occurrence within that period. - - byHour: The date-time has the given hour value. - - byMinute: The date-time has the given minute value. - - bySecond: The date-time has the given second value. - - If a "skip" property is defined and is not "omit", there may be - candidates that do not correspond to valid dates (e.g., February - 31st in the Gregorian calendar). In this case, the properties - MUST be considered in the order above, and: - - 1. After applying the byMonth filter, if the candidate's month - is invalid for the given year, increment it (if skip is - "forward") or decrement it (if skip is "backward") until a - valid month is found, incrementing/decrementing the year as - well if passing through the beginning/end of the year. This - only applies to calendar systems with leap months. - - 2. After applying the byMonthDay filter, if the day of the month - is invalid for the given month and year, change the date to - the first day of the next month (if skip is "forward") or the - last day of the current month (if skip is "backward"). - - 3. If any valid date produced after applying the skip is already - a candidate, eliminate the duplicate. (For example, after - adjusting, February 30th and February 31st would both become - the same "real" date, so one is eliminated as a duplicate.) - - 3. If a "bySetPosition" property is included, this is now applied to - the ordered list of remaining dates. This property specifies the - indexes of date-times to keep; all others should be eliminated. - Negative numbers are indexed from the end of the list, with -1 - being the last item, -2 the second from last, etc. - - 4. Any date-times before the start date of the event are eliminated - (see below for why this might be needed). - - 5. If a "skip" property is included and is not "omit", eliminate any - date-times that have already been produced by previous iterations - of the algorithm. (This is not possible if skip is "omit".) - - 6. If further dates are required (we have not reached the until date - or count limit), skip the next (interval - 1) sets of candidates, - then continue from step 1. - - When determining the set of occurrence dates for an event or task, - the following extra rules must be applied: - - 1. The initial date-time to which the rule is applied (the "start" - date-time for events or the "start" or "due" date-time for tasks) - is always the first occurrence in the expansion (and is counted - if the recurrence is limited by a "count" property), even if it - would normally not match the rule. - - 2. The first set of candidates to consider is that which would - contain the initial date-time. This means the first set may - include candidates before the initial date-time; such candidates - are eliminated from the results in step 4 of the list above. - - 3. The following properties MUST be implicitly added to the rule - under the given conditions: - - * If frequency is not "secondly" and there is no "bySecond" - property, add a "bySecond" property with the sole value being - the seconds value of the initial date-time. - - * If frequency is not "secondly" or "minutely" and there is no - "byMinute" property, add a "byMinute" property with the sole - value being the minutes value of the initial date-time. - - * If frequency is not "secondly", "minutely", or "hourly" and - there is no "byHour" property, add a "byHour" property with - the sole value being the hours value of the initial date-time. - - * If frequency is "weekly" and there is no "byDay" property, add - a "byDay" property with the sole value being the day of the - week of the initial date-time. - - * If frequency is "monthly" and there is no "byDay" property and - no "byMonthDay" property, add a "byMonthDay" property with the - sole value being the day of the month of the initial date- - time. - - * If frequency is "yearly" and there is no "byYearDay" property: - - - If there are no "byMonth" or "byWeekNo" properties, and - either there is a "byMonthDay" property or there is no - "byDay" property, add a "byMonth" property with the sole - value being the month of the initial date-time. - - - If there are no "byMonthDay", "byWeekNo", or "byDay" - properties, add a "byMonthDay" property with the sole value - being the day of the month of the initial date-time. - - - If there is a "byWeekNo" property and no "byMonthDay" or - "byDay" properties, add a "byDay" property with the sole - value being the day of the week of the initial date-time. - -4.3.4. excludedRecurrenceRules - - Type: "RecurrenceRule[]" (optional) - - This defines a set of recurrence rules (repeating patterns) for date- - times on which the object will not occur. The rules are interpreted - the same as for the "recurrenceRules" property (see Section 4.3.3), - with the exception that the initial date-time to which the rule is - applied (the "start" date-time for events or the "start" or "due" - date-time for tasks) is only considered part of the expansion if it - matches the rule. The resulting set of date-times is then removed - from those generated by the "recurrenceRules" property, as described - in Section 4.3. - -4.3.5. recurrenceOverrides - - Type: "LocalDateTime[PatchObject]" (optional) - - Maps recurrence ids (the date-time produced by the recurrence rule) - to the overridden properties of the recurrence instance. - - If the recurrence id does not match a date-time from the recurrence - rule (or no rule is specified), it is to be treated as an additional - occurrence (like an RDATE from iCalendar). The patch object may - often be empty in this case. - - If the patch object defines the "excluded" property of an occurrence - to be true, this occurrence is omitted from the final set of - recurrences for the calendar object (like an EXDATE from iCalendar). - Such a patch object MUST NOT patch any other property. - - By default, an occurrence inherits all properties from the main - object except the start (or due) date-time, which is shifted to match - the recurrence id LocalDateTime. However, individual properties of - the occurrence can be modified by a patch or multiple patches. It is - valid to patch the "start" property value, and this patch takes - precedence over the value generated from the recurrence id. Both the - recurrence id as well as the patched "start" date-time may occur - before the original JSCalendar object's "start" or "due" date. - - A pointer in the PatchObject MUST be ignored if it starts with one of - the following prefixes: - - * @type - - * excludedRecurrenceRules - - * method - - * privacy - - * prodId - - * recurrenceId - - * recurrenceIdTimeZone - - * recurrenceOverrides - - * recurrenceRules - - * relatedTo - - * replyTo - - * sentBy - - * timeZones - - * uid - -4.3.6. excluded - - Type: "Boolean" (optional, default: false) - - This defines if this object is an overridden, excluded instance of a - recurring JSCalendar object (see Section 4.3.5). If this property - value is true, this calendar object instance MUST be removed from the - occurrence expansion. The absence of this property, or the presence - of its default value as false, indicates that this instance MUST be - included in the occurrence expansion. - -4.4. Sharing and Scheduling Properties - -4.4.1. priority - - Type: "Int" (optional, default: 0) - - This specifies a priority for the calendar object. This may be used - as part of scheduling systems to help resolve conflicts for a time - period. - - The priority is specified as an integer in the range 0 to 9. A value - of 0 specifies an undefined priority, for which the treatment will - vary by situation. A value of 1 is the highest priority. A value of - 2 is the second highest priority. Subsequent numbers specify a - decreasing ordinal priority. A value of 9 is the lowest priority. - Other integer values are reserved for future use. - -4.4.2. freeBusyStatus - - Type: "String" (optional, default: "busy") - - This specifies how this calendar object should be treated when - calculating free-busy state. This MUST be one of the following - values, another value registered in the IANA "JSCalendar Enum Values" - registry, or a vendor-specific value (see Section 3.3): - - "free": The object should be ignored when calculating whether the - user is busy. - - "busy": The object should be included when calculating whether the - user is busy. - -4.4.3. privacy - - Type: "String" (optional, default: "public") - - Calendar objects are normally collected together and may be shared - with other users. The privacy property allows the object owner to - indicate that it should not be shared or should only have the time - information shared but the details withheld. Enforcement of the - restrictions indicated by this property is up to the API via which - this object is accessed. - - This property MUST NOT affect the information sent to scheduled - participants; it is only interpreted by protocols that share the - calendar objects belonging to one user with other users. - - The value MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3). Any value the client or - server doesn't understand should be preserved but treated as - equivalent to "private". - - "public": The full details of the object are visible to those whom - the object's calendar is shared with. - - "private": The details of the object are hidden; only the basic time - and metadata are shared. The following properties MAY be shared; - any other properties MUST NOT be shared: - - * @type - - * created - - * due - - * duration - - * estimatedDuration - - * freeBusyStatus - - * privacy - - * recurrenceOverrides (Only patches that apply to another - permissible property are allowed to be shared.) - - * sequence - - * showWithoutTime - - * start - - * timeZone - - * timeZones - - * uid - - * updated - - "secret": The object is hidden completely (as though it did not - exist) when the calendar this object is in is shared. - -4.4.4. replyTo - - Type: "String[String]" (optional) - - This represents methods by which participants may submit their - response to the organizer of the calendar object. The keys in the - property value are the available methods and MUST only contain ASCII - alphanumeric characters (A-Za-z0-9). The value is a URI for the - method specified in the key. Future methods may be defined in future - specifications and registered with IANA; a calendar client MUST - ignore any method it does not understand but MUST preserve the method - key and URI. This property MUST be omitted if no method is defined - (rather than being specified as an empty object). - - The following methods are defined: - - "imip": The organizer accepts an iCalendar Message-Based - Interoperability Protocol (iMIP) [RFC6047] response at this email - address. The value MUST be a "mailto:" URI. - - "web": Opening this URI in a web browser will provide the user with - a page where they can submit a reply to the organizer. The value - MUST be a URL using the "https:" scheme. - - "other": The organizer is identified by this URI, but the method for - submitting the response is undefined. - -4.4.5. sentBy - - Type: "String" (optional) - - This is the email address in the "From" header of the email in which - this calendar object was received. This is only relevant if the - calendar object is received via iMIP or as an attachment to a - message. If set, the value MUST be a valid "addr-spec" value as - defined in Section 3.4.1 of [RFC5322]. - -4.4.6. participants - - Type: "Id[Participant]" (optional) - - This is a map of participant ids to participants, describing their - participation in the calendar object. - - If this property is set and any participant has a "sendTo" property, - then the "replyTo" property of this calendar object MUST define at - least one reply method. - - A Participant object has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "Participant". - - name: "String" (optional) - This is the display name of the participant (e.g., "Joe Bloggs"). - - email: "String" (optional) - This is the email address to use to contact the participant or, - for example, match with an address book entry. If set, the value - MUST be a valid "addr-spec" value as defined in Section 3.4.1 of - [RFC5322]. - - description: "String" (optional) - This is a plain-text description of this participant. For - example, this may include more information about their role in the - event or how best to contact them. - - sendTo: "String[String]" (optional) - This represents methods by which the participant may receive the - invitation and updates to the calendar object. - - The keys in the property value are the available methods and MUST - only contain ASCII alphanumeric characters (A-Za-z0-9). The value - is a URI for the method specified in the key. Future methods may - be defined in future specifications and registered with IANA; a - calendar client MUST ignore any method it does not understand but - MUST preserve the method key and URI. This property MUST be - omitted if no method is defined (rather than being specified as an - empty object). - - The following methods are defined: - - "imip": The participant accepts an iMIP [RFC6047] request at this - email address. The value MUST be a "mailto:" URI. It MAY be - different from the value of the participant's "email" property. - - "other": The participant is identified by this URI, but the - method for submitting the invitation is undefined. - - kind: "String" (optional) - This is what kind of entity this participant is, if known. - - This MUST be one of the following values, another value registered - in the IANA "JSCalendar Enum Values" registry, or a vendor- - specific value (see Section 3.3). Any value the client or server - doesn't understand should be treated the same as if this property - is omitted. - - "individual": a single person - - "group": a collection of people invited as a whole - - "location": a physical location that needs to be scheduled, e.g., - a conference room - - "resource": a non-human resource other than a location, such as a - projector - - roles: "String[Boolean]" (mandatory) - This is a set of roles that this participant fulfills. - - At least one role MUST be specified for the participant. The keys - in the set MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "owner": The participant is an owner of the object. This - signifies they have permission to make changes to it that - affect the other participants. Nonowner participants may only - change properties that affect only themselves (for example, - setting their own alerts or changing their RSVP status). - - "attendee": The participant is expected to be present at the - event. - - "optional": The participant's involvement with the event is - optional. This is expected to be primarily combined with the - "attendee" role. - - "informational": The participant is copied for informational - reasons and is not expected to attend. - - "chair": The participant is in charge of the event/task when it - occurs. - - "contact": The participant is someone that may be contacted for - information about the event. - - The value for each key in the map MUST be true. It is expected - that no more than one of the roles "attendee" and "informational" - be present; if more than one are given, "attendee" takes - precedence over "informational". Roles that are unknown to the - implementation MUST be preserved. - - locationId: "Id" (optional) - This is the location at which this participant is expected to be - attending. - - If the value does not correspond to any location id in the - "locations" property of the JSCalendar object, this MUST be - treated the same as if the participant's locationId were omitted. - - language: "String" (optional) - This is the language tag, as defined in [RFC5646], that best - describes the participant's preferred language, if known. - - participationStatus: "String" (optional, default: "needs-action") - This is the participation status, if any, of this participant. - - The value MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "needs-action": No status has yet been set by the participant. - - "accepted": The invited participant will participate. - - "declined": The invited participant will not participate. - - "tentative": The invited participant may participate. - - "delegated": The invited participant has delegated their - attendance to another participant, as specified in the - "delegatedTo" property. - - participationComment: "String" (optional) - This is a note from the participant to explain their participation - status. - - expectReply: "Boolean" (optional, default: false) - If true, the organizer is expecting the participant to notify them - of their participation status. - - scheduleAgent: "String" (optional, default: "server") - This is who is responsible for sending scheduling messages with - this calendar object to the participant. - - The value MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "server": The calendar server will send the scheduling messages. - - "client": The calendar client will send the scheduling messages. - - "none": No scheduling messages are to be sent to this - participant. - - scheduleForceSend: "Boolean" (optional, default: false) - A client may set the property on a participant to true to request - that the server send a scheduling message to the participant when - it would not normally do so (e.g., if no significant change is - made the object or the scheduleAgent is set to client). The - property MUST NOT be stored in the JSCalendar object on the server - or appear in a scheduling message. - - scheduleSequence: "UnsignedInt" (optional, default: 0) - This is the sequence number of the last response from the - participant. If defined, this MUST be a nonnegative integer. - - This can be used to determine whether the participant has sent a - new response following significant changes to the calendar object - and to determine if future responses are responding to a current - or older view of the data. - - scheduleStatus: "String[]" (optional) - This is a list of status codes, returned from the processing of - the most recent scheduling message sent to this participant. The - status codes MUST be valid "statcode" values as defined in the - ABNF in Section 3.8.8.3 of [RFC5545]. - - Servers MUST only add or change this property when they send a - scheduling message to the participant. Clients SHOULD NOT change - or remove this property if it was provided by the server. Clients - MAY add, change, or remove the property for participants where the - client is handling the scheduling. - - This property MUST NOT be included in scheduling messages. - - scheduleUpdated: "UTCDateTime" (optional) - This is the timestamp for the most recent response from this - participant. - - This is the "updated" property of the last response when using - iTIP. It can be compared to the "updated" property in future - responses to detect and discard older responses delivered out of - order. - - sentBy: "String" (optional) - This is the email address in the "From" header of the email that - last updated this participant via iMIP. This SHOULD only be set - if the email address is different to that in the mailto URI of - this participant's "imip" method in the "sendTo" property (i.e., - the response was received from a different address to that which - the invitation was sent to). If set, the value MUST be a valid - "addr-spec" value as defined in Section 3.4.1 of [RFC5322]. - - invitedBy: "Id" (optional) - This is the id of the participant who added this participant to - the event/task, if known. - - delegatedTo: "Id[Boolean]" (optional) - This is set of participant ids that this participant has delegated - their participation to. Each key in the set MUST be the id of a - participant. The value for each key in the map MUST be true. If - there are no delegates, this MUST be omitted (rather than - specified as an empty set). - - delegatedFrom: "Id[Boolean]" (optional) - This is a set of participant ids that this participant is acting - as a delegate for. Each key in the set MUST be the id of a - participant. The value for each key in the map MUST be true. If - there are no delegators, this MUST be omitted (rather than - specified as an empty set). - - memberOf: "Id[Boolean]" (optional) - This is a set of group participants that were invited to this - calendar object, which caused this participant to be invited due - to their membership in the group(s). Each key in the set MUST be - the id of a participant. The value for each key in the map MUST - be true. If there are no groups, this MUST be omitted (rather - than specified as an empty set). - - links: "Id[Link]" (optional) - This is a map of link ids to Link objects, representing external - resources associated with this participant, for example, a vCard - or image. If there are no links, this MUST be omitted (rather - than specified as an empty set). - - progress: "String" (optional; only allowed for participants of a - Task) - This represents the progress of the participant for this task. It - MUST NOT be set if the "participationStatus" of this participant - is any value other than "accepted". See Section 5.2.5 for allowed - values and semantics. - - progressUpdated: "UTCDateTime" (optional; only allowed for - participants of a Task) - This specifies the date-time the "progress" property was last set - on this participant. See Section 5.2.6 for allowed values and - semantics. - - percentComplete: "UnsignedInt" (optional; only allowed for - participants of a Task) - This represents the percent completion of the participant for this - task. The property value MUST be a positive integer between 0 and - 100. - -4.4.7. requestStatus - - Type: "String" (optional) - - A request status as returned from processing the most recent - scheduling request for this JSCalendar object. The allowed values - are defined by the ABNF definitions of "statcode", "statdesc" and - "extdata" in Section 3.8.8.3 of [RFC5545] and the following ABNF - [RFC5234]: - - reqstatus = statcode ";" statdesc [";" extdata] - - Servers MUST only add or change this property when they performe a - scheduling action. Clients SHOULD NOT change or remove this property - if it was provided by the server. Clients MAY add, change, or remove - the property when the client is handling the scheduling. - - This property MUST only be included in scheduling messages according - to the rules defined for the REQUEST-STATUS iCalendar property in - [RFC5546]. - -4.5. Alerts Properties - -4.5.1. useDefaultAlerts - - Type: "Boolean" (optional, default: false) - - If true, use the user's default alerts and ignore the value of the - "alerts" property. Fetching user defaults is dependent on the API - from which this JSCalendar object is being fetched and is not defined - in this specification. If an implementation cannot determine the - user's default alerts, or none are set, it MUST process the "alerts" - property as if "useDefaultAlerts" is set to false. - -4.5.2. alerts - - Type: "Id[Alert]" (optional) - - This is a map of alert ids to Alert objects, representing alerts/ - reminders to display or send to the user for this calendar object. - - An Alert object has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "Alert". - - trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" - (mandatory) - This defines when to trigger the alert. New types may be defined - in future documents. - - An "OffsetTrigger" object has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "OffsetTrigger". - - offset: "SignedDuration" (mandatory) - This defines the offset at which to trigger the alert relative - to the time property defined in the "relativeTo" property of - the alert. Negative durations signify alerts before the time - property; positive durations signify alerts after the time - property. - - relativeTo: "String" (optional, default: "start") - This specifies the time property that the alert offset is - relative to. The value MUST be one of the following: - - "start": triggers the alert relative to the start of the - calendar object - - "end": triggers the alert relative to the end/due time of the - calendar object - - An "AbsoluteTrigger" object has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "AbsoluteTrigger". - - when: "UTCDateTime" (mandatory) - This defines a specific UTC date-time when the alert is - triggered. - - An "UnknownTrigger" object is an object that contains an "@type" - property whose value is not recognized (i.e., not "OffsetTrigger" - or "AbsoluteTrigger") plus zero or more other properties. This is - for compatibility with client extensions and future - specifications. Implementations SHOULD NOT trigger for trigger - types they do not understand but MUST preserve them. - - acknowledged: "UTCDateTime" (optional) - This records when an alert was last acknowledged. This is set - when the user has dismissed the alert; other clients that sync - this property SHOULD automatically dismiss or suppress duplicate - alerts (alerts with the same alert id that triggered on or before - this date-time). - - For a recurring calendar object, setting the "acknowledged" - property MUST NOT add a new override to the "recurrenceOverrides" - property. If the alert is not already overridden, the - "acknowledged" property MUST be set on the alert in the base - event/task. - - Certain kinds of alert action may not provide feedback as to when - the user sees them, for example, email-based alerts. For those - kinds of alerts, this property MUST be set immediately when the - alert is triggered and the action is successfully carried out. - - relatedTo: "String[Relation]" (optional) - This relates this alert to other alerts in the same JSCalendar - object. If the user wishes to snooze an alert, the application - MUST create an alert to trigger after snoozing. This new snooze - alert MUST set a parent relation to the identifier of the original - alert. - - action: "String" (optional, default: "display") - This describes how to alert the user. - - The value MUST be at most one of the following values, a value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "display": The alert should be displayed as appropriate for the - current device and user context. - - "email": The alert should trigger an email sent out to the user, - notifying them of the alert. This action is typically only - appropriate for server implementations. - -4.6. Multilingual Properties - -4.6.1. localizations - - Type: "String[PatchObject]" (optional) - - A map where each key is a language tag [RFC5646], and the - corresponding value is a set of patches to apply to the calendar - object in order to localize it into that locale. - - See the description of PatchObject (Section 1.4.9) for the structure - of the PatchObject. The patches are applied to the top-level - calendar object. In addition, the "locale" property of the patched - object is set to the language tag. All pointers for patches MUST end - with one of the following suffixes; any patch that does not follow - this MUST be ignored unless otherwise specified in a future RFC: - - * title - - * description - - * name - - A patch MUST NOT have the prefix "recurrenceOverrides"; any - localization of the override MUST be a patch to the "localizations" - property inside the override instead. For example, a patch to - "locations/abcd1234/title" is permissible, but a patch to "uid" or - "recurrenceOverrides/2020-01-05T14:00:00/title" is not. - - Note that this specification does not define how to maintain validity - of localized content. For example, a client application changing a - JSCalendar object's "title" property might also need to update any - localizations of this property. Client implementations SHOULD - provide the means to manage localizations, but how to achieve this is - specific to the application's workflow and requirements. - -4.7. Time Zone Properties - -4.7.1. timeZone - - Type: "TimeZoneId|null" (optional, default: null) - - This identifies the time zone the object is scheduled in or is null - for floating time. This is either a name from the IANA Time Zone - Database [TZDB] or the TimeZoneId of a custom time zone from the - "timeZones" property (Section 4.7.2). If omitted, this MUST be - presumed to be null (i.e., floating time). - -4.7.2. timeZones - - Type: "TimeZoneId[TimeZone]" (optional) - - This maps identifiers of custom time zones to their time zone - definitions. The following restrictions apply for each key in the - map: - - * To avoid conflict with names in the IANA Time Zone Database - [TZDB], it MUST start with the "/" character. - - * It MUST be a valid "paramtext" value, as specified in Section 3.1 - of [RFC5545]. - - * At least one other property in the same JSCalendar object MUST - reference a time zone using this identifier (i.e., orphaned time - zones are not allowed). - - An identifier need only be unique to this JSCalendar object. It MAY - differ from the "tzId" property value of the TimeZone object it maps - to. - - A JSCalendar object may be part of a hierarchy of other JSCalendar - objects (say, an Event is an entry in a Group). In this case, the - set of time zones is the sum of the time zone definitions of this - object and its parent objects. If multiple time zones with the same - identifier exist, then the definition closest to the calendar object - in relation to its parents MUST be used. (In context of Event, a - time zone definition in its "timeZones" property has precedence over - a definition of the same id in the Group). Time zone definitions in - any children of the calendar object MUST be ignored. - - A TimeZone object maps a VTIMEZONE component from iCalendar, and the - semantics are as defined in [RFC5545]. A valid time zone MUST define - at least one transition rule in the "standard" or "daylight" - property. Its properties are: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be "TimeZone". - - tzId: "String" (mandatory) - This is the TZID property from iCalendar. Note that this implies - that the value MUST be a valid "paramtext" value as specified in - Section 3.1. of [RFC5545]. - - updated: "UTCDateTime" (optional) - This is the LAST-MODIFIED property from iCalendar. - - url: "String" (optional) - This is the TZURL property from iCalendar. - - validUntil: "UTCDateTime" (optional) - This is the TZUNTIL property from iCalendar, specified in - [RFC7808]. - - aliases: "String[Boolean]" (optional) - This maps the TZID-ALIAS-OF properties from iCalendar, specified - in [RFC7808], to a JSON set of aliases. The set is represented as - an object, with the keys being the aliases. The value for each - key in the map MUST be true. - - standard: "TimeZoneRule[]" (optional) - This the STANDARD sub-components from iCalendar. The order MUST - be preserved during conversion. - - daylight: "TimeZoneRule[]" (optional) - This the DAYLIGHT sub-components from iCalendar. The order MUST - be preserved during conversion. - - A TimeZoneRule object maps a STANDARD or DAYLIGHT sub-component from - iCalendar, with the restriction that, at most, one recurrence rule is - allowed per rule. It has the following properties: - - @type: "String" (mandatory) - This specifies the type of this object. This MUST be - "TimeZoneRule". - - start: "LocalDateTime" (mandatory) - This is the DTSTART property from iCalendar. - - offsetFrom: "String" (mandatory) - This is the TZOFFSETFROM property from iCalendar. - - offsetTo: "String" (mandatory) - This is the TZOFFSETTO property from iCalendar. - - recurrenceRules: "RecurrenceRule[]" (optional) - This is the RRULE property mapped, as specified in Section 4.3.3. - During recurrence rule evaluation, the "until" property value MUST - be interpreted as a local time in the UTC time zone. - - recurrenceOverrides: "LocalDateTime[PatchObject]" (optional) - This maps the RDATE properties from iCalendar. The set is - represented as an object, with the keys being the recurrence - dates. The patch object MUST be the empty JSON object ({}). - - names: "String[Boolean]" optional) - This maps the TZNAME properties from iCalendar to a JSON set. The - set is represented as an object, with the keys being the names, - excluding any "tznparam" component from iCalendar. The value for - each key in the map MUST be true. - - comments: "String[]" (optional) - This maps the COMMENT properties from iCalendar. The order MUST - be preserved during conversion. - -5. Type-Specific JSCalendar Properties - -5.1. Event Properties - - In addition to the common JSCalendar object properties (Section 4), - an Event has the following properties: - -5.1.1. start - - Type: "LocalDateTime" (mandatory) - - This is the date/time the event starts in the event's time zone (as - specified in the "timeZone" property, see Section 4.7.1). - -5.1.2. duration - - Type: "Duration" (optional, default: "PT0S") - - This is the zero or positive duration of the event in the event's - start time zone. The end time of an event can be found by adding the - duration to the event's start time. - - An Event MAY involve start and end locations that are in different - time zones (e.g., a transcontinental flight). This can be expressed - using the "relativeTo" and "timeZone" properties of the Event's - Location objects (see Section 4.2.5). - -5.1.3. status - - Type: "String" (optional, default: "confirmed") - - This is the scheduling status (Section 4.4) of an Event. If set, it - MUST be one of the following values, another value registered in the - IANA "JSCalendar Enum Values" registry, or a vendor-specific value - (see Section 3.3): - - "confirmed": indicates the event is definitely happening - - "cancelled": indicates the event has been cancelled - - "tentative": indicates the event may happen - -5.2. Task Properties - - In addition to the common JSCalendar object properties (Section 4), a - Task has the following properties: - -5.2.1. due - - Type: "LocalDateTime" (optional) - - This is the date/time the task is due in the task's time zone. - -5.2.2. start - - Type: "LocalDateTime" (optional) - - This the date/time the task should start in the task's time zone. - -5.2.3. estimatedDuration - - Type: "Duration" (optional) - - This specifies the estimated positive duration of time the task takes - to complete. - -5.2.4. percentComplete - - Type: "UnsignedInt" (optional) - - This represents the percent completion of the task overall. The - property value MUST be a positive integer between 0 and 100. - -5.2.5. progress - - Type: "String" (optional) - - This defines the progress of this task. If omitted, the default - progress (Section 4.4) of a Task is defined as follows (in order of - evaluation): - - "completed": if the "progress" property value of all participants is - "completed" - - "failed": if at least one "progress" property value of a participant - is "failed" - - "in-process": if at least one "progress" property value of a - participant is "in-process" - - "needs-action": if none of the other criteria match - - If set, it MUST be one of the following values, another value - registered in the IANA "JSCalendar Enum Values" registry, or a - vendor-specific value (see Section 3.3): - - "needs-action": indicates the task needs action - - "in-process": indicates the task is in process - - "completed": indicates the task is completed - - "failed": indicates the task failed - - "cancelled": indicates the task was cancelled - -5.2.6. progressUpdated - - Type: "UTCDateTime" (optional) - - This specifies the date/time the "progress" property of either the - task overall (Section 5.2.5) or a specific participant - (Section 4.4.6) was last updated. - - If the task is recurring and has future instances, a client may want - to keep track of the last progress update timestamp of a specific - task recurrence but leave other instances unchanged. One way to - achieve this is by overriding the "progressUpdated" property in the - task "recurrenceOverrides" property. However, this could produce a - long list of timestamps for regularly recurring tasks. An - alternative approach is to split the Task into a current, single - instance of Task with this instance progress update time and a future - recurring instance. See also Section 4.1.3 on splitting. - -5.3. Group Properties - - Group supports the following common JSCalendar properties - (Section 4): - - * @type - - * uid - - * prodId - - * created - - * updated - - * title - - * description - - * descriptionContentType - - * links - - * locale - - * keywords - - * categories - - * color - - * timeZones - - In addition, the following Group-specific properties are supported: - -5.3.1. entries - - Type: "(Task|Event)[]" (mandatory) - - This is a collection of group members. Implementations MUST ignore - entries of unknown type. - -5.3.2. source - - Type: "String" (optional) - - This is the source from which updated versions of this group may be - retrieved. The value MUST be a URI. - -6. Examples - - The following examples illustrate several aspects of the JSCalendar - data model and format. The examples may omit mandatory or additional - properties, which is indicated by a placeholder property with key - "...". While most of the examples use calendar event objects, they - are also illustrative for tasks. - -6.1. Simple Event - - This example illustrates a simple one-time event. It specifies a - one-time event that begins on January 15, 2020 at 1 pm New York local - time and ends after 1 hour. - - { - "@type": "Event", - "uid": "a8df6573-0474-496d-8496-033ad45d7fea", - "updated": "2020-01-02T18:23:04Z", - "title": "Some event", - "start": "2020-01-15T13:00:00", - "timeZone": "America/New_York", - "duration": "PT1H" - } - -6.2. Simple Task - - This example illustrates a simple task for a plain to-do item. - - { - "@type": "Task", - "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", - "updated": "2020-01-09T14:32:01Z", - "title": "Do something" - } - -6.3. Simple Group - - This example illustrates a simple calendar object group that contains - an event and a task. - - { - "@type": "Group", - "uid": "bf0ac22b-4989-4caf-9ebd-54301b4ee51a", - "updated": "2020-01-15T18:00:00Z", - "name": "A simple group", - "entries": [{ - "@type": "Event", - "uid": "a8df6573-0474-496d-8496-033ad45d7fea", - "updated": "2020-01-02T18:23:04Z", - "title": "Some event", - "start": "2020-01-15T13:00:00", - "timeZone": "America/New_York", - "duration": "PT1H" - }, - { - "@type": "Task", - "uid": "2a358cee-6489-4f14-a57f-c104db4dc2f2", - "updated": "2020-01-09T14:32:01Z", - "title": "Do something" - }] - } - -6.4. All-Day Event - - This example illustrates an event for an international holiday. It - specifies an all-day event on April 1 that occurs every year since - the year 1900. - - { - "...": "", - "title": "April Fool's Day", - "showWithoutTime": true, - "start": "1900-04-01T00:00:00", - "duration": "P1D", - "recurrenceRules": [{ - "@type": "RecurrenceRule", - "frequency": "yearly" - }] - } - -6.5. Task with a Due Date - - This example illustrates a task with a due date. It is a reminder to - buy groceries before 6 pm Vienna local time on January 19, 2020. The - calendar user expects to need 1 hour for shopping. - - { - "...": "", - "title": "Buy groceries", - "due": "2020-01-19T18:00:00", - "timeZone": "Europe/Vienna", - "estimatedDuration": "PT1H" - } - -6.6. Event with End Time Zone - - This example illustrates the use of end time zones by use of an - international flight. The flight starts on April 1, 2020 at 9 am in - Berlin local time. The duration of the flight is scheduled at 10 - hours 30 minutes. The time at the flight's destination is in the - same time zone as Tokyo. Calendar clients could use the end time - zone to display the arrival time in Tokyo local time and highlight - the time zone difference of the flight. The location names can serve - as input for navigation systems. - - { - "...": "", - "title": "Flight XY51 to Tokyo", - "start": "2020-04-01T09:00:00", - "timeZone": "Europe/Berlin", - "duration": "PT10H30M", - "locations": { - "1": { - "@type": "Location", - "rel": "start", - "name": "Frankfurt Airport (FRA)" - }, - "2": { - "@type": "Location", - "rel": "end", - "name": "Narita International Airport (NRT)", - "timeZone": "Asia/Tokyo" - } - } - } - -6.7. Floating-Time Event (with Recurrence) - - This example illustrates the use of floating time. Since January 1, - 2020, a calendar user blocks 30 minutes every day to practice yoga at - 7 am local time in whatever time zone the user is located on that - date. - - { - "...": "", - "title": "Yoga", - "start": "2020-01-01T07:00:00", - "duration": "PT30M", - "recurrenceRules": [{ - "@type": "RecurrenceRule", - "frequency": "daily" - }] - } - -6.8. Event with Multiple Locations and Localization - - This example illustrates an event that happens at both a physical and - a virtual location. Fans can see a live concert on premises or - online. The event title and descriptions are localized. - - { - "...": "", - "title": "Live from Music Bowl: The Band", - "description": "Go see the biggest music event ever!", - "locale": "en", - "start": "2020-07-04T17:00:00", - "timeZone": "America/New_York", - "duration": "PT3H", - "locations": { - "c0503d30-8c50-4372-87b5-7657e8e0fedd": { - "@type": "Location", - "name": "The Music Bowl", - "description": "Music Bowl, Central Park, New York", - "coordinates": "geo:40.7829,-73.9654" - } - }, - "virtualLocations": { - "vloc1": { - "@type": "VirtualLocation", - "name": "Free live Stream from Music Bowl", - "uri": "https://stream.example.com/the_band_2020" - } - }, - "localizations": { - "de": { - "title": "Live von der Music Bowl: The Band!", - "description": "Schau dir das größte Musikereignis an!", - "virtualLocations/vloc1/name": - "Gratis Live-Stream aus der Music Bowl" - } - } - } - -6.9. Recurring Event with Overrides - - This example illustrates the use of recurrence overrides. A math - course at a university is held for the first time on January 8, 2020 - at 9 am London time and occurs every week until June 24, 2020. Each - lecture lasts for one hour and 30 minutes and is located at the - Mathematics department. This event has exceptional occurrences: at - the last occurrence of the course is an exam, which lasts for 2 hours - and starts at 10 am. Also, the location of the exam differs from the - usual location. On April 1, no course is held. On January 7 at 2 - pm, there is an optional introduction course, which occurs before the - first regular lecture. - - { - "...": "", - "title": "Calculus I", - "start": "2020-01-08T09:00:00", - "timeZone": "Europe/London", - "duration": "PT1H30M", - "locations": { - "mlab": { - "@type": "Location", - "title": "Math lab room 1", - "description": "Math Lab I, Department of Mathematics" - } - }, - "recurrenceRules": [{ - "@type": "RecurrenceRule", - "frequency": "weekly", - "until": "2020-06-24T09:00:00" - }], - "recurrenceOverrides": { - "2020-01-07T14:00:00": { - "title": "Introduction to Calculus I (optional)" - }, - "2020-04-01T09:00:00": { - "excluded": true - }, - "2020-06-25T09:00:00": { - "title": "Calculus I Exam", - "start": "2020-06-25T10:00:00", - "duration": "PT2H", - "locations": { - "auditorium": { - "@type": "Location", - "title": "Big Auditorium", - "description": "Big Auditorium, Other Road" - } - } - } - } - } - -6.10. Recurring Event with Participants - - This example illustrates scheduled events. A team meeting occurs - every week since January 8, 2020 at 9 am Johannesburg time. The - event owner also chairs the event. Participants meet in a virtual - meeting room. An attendee has accepted the invitation, but, on March - 4, 2020, he is unavailable and declined participation for this - occurrence. - - { - "...": "", - "title": "FooBar team meeting", - "start": "2020-01-08T09:00:00", - "timeZone": "Africa/Johannesburg", - "duration": "PT1H", - "virtualLocations": { - "0": { - "@type": "VirtualLocation", - "name": "ChatMe meeting room", - "uri": "https://chatme.example.com?id=1234567&pw=a8a24627b63d" - } - }, - "recurrenceRules": [{ - "@type": "RecurrenceRule", - "frequency": "weekly" - }], - "replyTo": { - "imip": "mailto:f245f875-7f63-4a5e-a2c8@schedule.example.com" - }, - "participants": { - "dG9tQGZvb2Jhci5xlLmNvbQ": { - "@type": "Participant", - "name": "Tom Tool", - "email": "tom@foobar.example.com", - "sendTo": { - "imip": "mailto:tom@calendar.example.com" - }, - "participationStatus": "accepted", - "roles": { - "attendee": true - } - }, - "em9lQGZvb2GFtcGxlLmNvbQ": { - "@type": "Participant", - "name": "Zoe Zelda", - "email": "zoe@foobar.example.com", - "sendTo": { - "imip": "mailto:zoe@foobar.example.com" - }, - "participationStatus": "accepted", - "roles": { - "owner": true, - "attendee": true, - "chair": true - } - } - }, - "recurrenceOverrides": { - "2020-03-04T09:00:00": { - "participants/dG9tQGZvb2Jhci5xlLmNvbQ/participationStatus": - "declined" - } - } - } - -7. Security Considerations - - Calendaring and scheduling information is very privacy sensitive. It - can reveal the social network of a user, location information of this - user and those in their social network, identity and credentials - information, and patterns of behavior of the user in both the - physical and cyber realm. Additionally, calendar events and tasks - can influence the physical location of a user or their cyber behavior - within a known time window. Its transmission and storage must be - done carefully to protect it from possible threats, such as - eavesdropping, replay, message insertion, deletion, modification, and - on-path attacks. - - The data being stored and transmitted may be used in systems with - real-world consequences. For example, a home automation system may - turn an alarm on and off or a coworking space may charge money to the - organizer of an event that books one of their meeting rooms. Such - systems must be careful to authenticate all data they receive to - prevent them from being subverted and ensure the change comes from an - authorized entity. - - This document only defines the data format; such considerations are - primarily the concern of the API or method of storage and - transmission of such files. - -7.1. Expanding Recurrences - - A recurrence rule may produce infinite occurrences of an event. - Implementations MUST handle expansions carefully to prevent - accidental or deliberate resource exhaustion. - - Conversely, a recurrence rule may be specified that does not expand - to anything. It is not always possible to tell this through static - analysis of the rule, so implementations MUST be careful to avoid - getting stuck in infinite loops or otherwise exhausting resources - while searching for the next occurrence. - - Events recur in the event's time zone. If the user is in a different - time zone, daylight saving transitions may cause an event that - normally occurs at, for example, 9 am to suddenly shift an hour - earlier. This may be used in an attempt to cause a participant to - miss an important meeting. User agents must be careful to translate - date-times correctly between time zones and may wish to call out - unexpected changes in the time of a recurring event. - -7.2. JSON Parsing - - The security considerations of [RFC8259] apply to the use of JSON as - the data interchange format. - - As for any serialization format, parsers need to thoroughly check the - syntax of the supplied data. JSON uses opening and closing tags for - several types and structures, and it is possible that the end of the - supplied data will be reached when scanning for a matching closing - tag; this is an error condition, and implementations need to stop - scanning at the end of the supplied data. - - JSON also uses a string encoding with some escape sequences to encode - special characters within a string. Care is needed when processing - these escape sequences to ensure that they are fully formed before - the special processing is triggered, with special care taken when the - escape sequences appear adjacent to other (non-escaped) special - characters or adjacent to the end of data (as in the previous - paragraph). - - If parsing JSON into a non-textual structured data format, - implementations may need to allocate storage to hold JSON string - elements. Since JSON does not use explicit string lengths, the risk - of denial of service due to resource exhaustion is small, but - implementations may still wish to place limits on the size of - allocations they are willing to make in any given context, to avoid - untrusted data causing excessive memory allocation. - -7.3. URI Values - - Several JSCalendar properties contain URIs as values, and processing - these properties requires extra care. Section 7 of [RFC3986] - discusses security risks related to URIs. - - Fetching remote resources carries inherent risks. Connections must - only be allowed on well-known ports, using allowed protocols - (generally, just HTTP/HTTPS on their default ports). The URL must be - resolved externally and not allowed to access internal resources. - Connecting to an external source reveals IP (and therefore often - location) information. - - A maliciously constructed JSCalendar object may contain a very large - number of URIs. In the case of published calendars with a large - number of subscribers, such objects could be widely distributed. - Implementations should be careful to limit the automatic fetching of - linked resources to reduce the risk of this being an amplification - vector for a denial-of-service attack. - -7.4. Spam - - Calendar systems may receive JSCalendar files from untrusted sources, - in particular, as attachments to emails. This can be a vector for an - attacker to inject spam into a user's calendar. This may confuse, - annoy, and mislead users or overwhelm their calendar with bogus - events, preventing them from seeing legitimate ones. - - Heuristic, statistical, or machine-learning-based filters can be - effective in filtering out spam. Authentication mechanisms, such as - DomainKeys Identified Mail (DKIM) [RFC6376], can help establish the - source of messages and associate the data with existing relationships - (such as an address book contact). However, misclassifications are - always possible and providing a mechanism for users to quickly - correct this is advised. - - Confusable unicode characters may be used to trick a user into - trusting a JSCalendar file that appears to come from a known contact - but is actually from a similar-looking source controlled by an - attacker. - -7.5. Duplication - - It is important for calendar systems to maintain the UID of an event - when updating it to avoid an unexpected duplication of events. - Consumers of the data may not remove the previous version of the - event if it has a different UID. This can lead to a confusing - situation for the user, with many variations of the event and no - indication of which one is correct. Care must be taken by consumers - of the data to remove old events where possible to avoid an - accidental denial-of-service attack due to the volume of data. - -7.6. Time Zones - - Events recur in a particular time zone. When this differs from the - user's current time zone, it may unexpectedly cause an occurrence to - shift in time for that user due to a daylight savings change in the - event's time zone. A maliciously crafted event could attempt to - confuse users with such an event to ensure a meeting is missed. - -8. IANA Considerations - -8.1. Media Type Registration - - This document defines a media type for use with JSCalendar data - formatted in JSON. - - Type name: application - - Subtype name: jscalendar+json - - Required parameters: type - - The "type" parameter conveys the type of the JSCalendar data in - the body part. The allowed parameter values correspond to the - "@type" property of the JSON-formatted JSCalendar object in the - body: - - "event": The "@type" property value MUST be "Event". - - "task": The "@type" property value MUST be "Task". - - "group": The "@type" property value MUST be "Group". - - No other parameter values are allowed. The parameter MUST NOT - occur more than once. - - Optional parameters: none - - Encoding considerations: This is the same as the encoding - considerations of application/json, as specified in Section 11 of - [RFC8259]. - - Security considerations: See Section 7 of this document. - - Interoperability considerations: While JSCalendar is designed to - avoid ambiguities as much as possible, when converting objects - from other calendar formats to/from JSCalendar, it is possible - that differing representations for the same logical data or - ambiguities in interpretation might arise. The semantic - equivalence of two JSCalendar objects may be determined - differently by different applications, for example, where URL - values differ in case between the two objects. - - Published specification: RFC 8984 - - Applications that use this media type: Applications that currently - make use of the text/calendar and application/calendar+json media - types can use this as an alternative. Similarly, applications - that use the application/json media type to transfer calendaring - data can use this to further specify the content. - - Fragment identifier considerations: A JSON Pointer fragment - identifier may be used, as defined in [RFC6901], Section 6. - - Additional information: Magic number(s): N/A - - File extensions(s): N/A - - Macintosh file type code(s): N/A - - Person & email address to contact for further information: - calsify@ietf.org - - Intended usage: COMMON - - Restrictions on usage: N/A - - Author: See the "Author's Address" section of this document. - - Change controller: IETF - -8.2. Creation of the "JSCalendar Properties" Registry - - IANA has created the "JSCalendar Properties" registry to allow - interoperability of extensions to JSCalendar objects. - - This registry follows the Expert Review process ([RFC8126], - Section 4.5). If the "Intended Usage" field is "common", sufficient - documentation is required to enable interoperability. Preliminary - community review for this registry is optional but strongly - encouraged. - - A registration can have an intended usage of "common", "reserved", or - "obsolete". IANA will list registrations with a common usage - designation prominently and separately from those with other intended - usage values. - - A "reserved" registration reserves a property name without assigning - semantics to avoid name collisions with future extensions or protocol - use. - - An "obsolete" registration denotes a property that is no longer - expected to be added by up-to-date systems. A new property has - probably been defined covering the obsolete property's semantics. - - The JSCalendar property registration procedure is not a formal - standards process but rather an administrative procedure intended to - allow community comment and check it is coherent without excessive - time delay. It is designed to encourage vendors to document and - register new properties they add for use cases not covered by the - original specification, leading to increased interoperability. - -8.2.1. Preliminary Community Review - - Notice of a potential new registration SHOULD be sent to the Calext - mailing list for review. This mailing list is - appropriate to solicit community feedback on a proposed new property. - - Property registrations must be marked with their intended use: - "common", "reserved", or "obsolete". - - The intent of the public posting to this list is to solicit comments - and feedback on the choice of the property name, the unambiguity of - the specification document, and a review of any interoperability or - security considerations. The submitter may submit a revised - registration proposal or abandon the registration completely at any - time. - -8.2.2. Submit Request to IANA - - Registration requests can be sent to . - -8.2.3. Designated Expert Review - - The primary concern of the designated expert (DE) is preventing name - collisions and encouraging the submitter to document security and - privacy considerations. For a common-use registration, the DE is - expected to confirm that suitable documentation, as described in - Section 4.6 of [RFC8126], is available to ensure interoperability. - That documentation will usually be in an RFC, but simple definitions - are likely to use a web/wiki page, and if a sentence or two is deemed - sufficient, it could be described in the registry itself. The DE - should also verify that the property name does not conflict with work - that is active or already published within the IETF. A published - specification is not required for reserved or obsolete registrations. - - The DE will either approve or deny the registration request and - publish a notice of the decision to the Calext WG mailing list or its - successor, as well as inform IANA. A denial notice must be justified - by an explanation, and, in the cases where it is possible, concrete - suggestions on how the request can be modified so as to become - acceptable should be provided. - -8.2.4. Change Procedures - - Once a JSCalendar property has been published by IANA, the change - controller may request a change to its definition. The same - procedure that would be appropriate for the original registration - request is used to process a change request. - - JSCalendar property registrations may not be deleted; properties that - are no longer believed appropriate for use can be declared obsolete - by a change to their "intended usage" field; such properties will be - clearly marked in the IANA registry. - - Significant changes to a JSCalendar property's definition should be - requested only when there are serious omissions or errors in the - published specification, as such changes may cause interoperability - issues. When review is required, a change request may be denied if - it renders entities that were valid under the previous definition - invalid under the new definition. - - The owner of a JSCalendar property may pass responsibility to another - person or agency by informing IANA; this can be done without - discussion or review. - -8.2.5. "JSCalendar Properties" Registry Template - - Property Name: This is the name of the property. The property name - MUST NOT already be registered for any of the object types listed - in the "Property Context" field of this registration. Other - object types MAY already have registered a different property with - the same name; however, the same name SHOULD only be used when the - semantics are analogous. - - Property Type: This is the type of this property, using type - signatures, as specified in Section 1.3. The property type MUST - be registered in the "JSCalendar Types" registry. - - Property Context: This is a comma-separated list of JSCalendar - object types this property is allowed on. - - Reference or Description: This is a brief description or RFC number - and section reference where the property is specified (omitted for - "reserved" property names). - - Intended Usage: This may be "common", "reserved", or "obsolete". - - Change Controller: This is who may request a change to this entry's - definition ("IETF" for RFCs from the IETF stream). - -8.2.6. Initial Contents for the "JSCalendar Properties" Registry - - The following table lists the initial entries of the "JSCalendar - Properties" registry. All properties are for common use. All RFC - section references are for this document. The change controller for - all these properties is "IETF". - - +====================+=================+================+===========+ - |Property Name |Property Type |Property Context|Reference | - | | | |or | - | | | |Description| - +====================+=================+================+===========+ - |@type |String |Event, Task, |Section | - | | |Group, |4.1.1, | - | | |AbsoluteTrigger,|Section | - | | |Alert, Link, |4.5.2, | - | | |Location, NDay, |Section | - | | |OffsetTrigger, |1.4.11, | - | | |Participant, |Section | - | | |RecurrenceRule, |4.2.5, | - | | |Relation, |Section | - | | |TimeZone, |4.4.6, | - | | |TimeZoneRule, |Section | - | | |VirtualLocation |4.3.3, | - | | | |Section | - | | | |1.4.10, | - | | | |Section | - | | | |4.7.2, | - | | | |Section | - | | | |4.2.6 | - +--------------------+-----------------+----------------+-----------+ - |acknowledged |UTCDateTime |Alert |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - |action |String |Alert |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - |alerts |Id[Alert] |Event, Task |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - |aliases |String[Boolean] |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |byDay |NDay[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byHour |UnsignedInt[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byMinute |UnsignedInt[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byMonth |String[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byMonthDay |Int[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |bySecond |UnsignedInt[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |bySetPosition |Int[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byWeekNo |Int[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |byYearDay |Int[] |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |categories |String[Boolean] |Event, Task, |Section | - | | |Group |4.2.10 | - +--------------------+-----------------+----------------+-----------+ - |cid |String |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |color |String |Event, Task, |Section | - | | |Group |4.2.11 | - +--------------------+-----------------+----------------+-----------+ - |comments |String[] |TimeZoneRule |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |contentType |String |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |coordinates |String |Location |Section | - | | | |4.2.5 | - +--------------------+-----------------+----------------+-----------+ - |count |UnsignedInt |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |created |UTCDateTime |Event, Task, |Section | - | | |Group |4.1.5 | - +--------------------+-----------------+----------------+-----------+ - |day |String |NDay |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |daylight |TimeZoneRule[] |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |delegatedFrom |Id[Boolean] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |delegatedTo |Id[Boolean] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |description |String |Event, Task, |Section | - | | |Location, |4.2.2, | - | | |Participant, |Section | - | | |VirtualLocation |4.2.5, | - | | | |Section | - | | | |4.4.6, | - | | | |Section | - | | | |4.2.6 | - +--------------------+-----------------+----------------+-----------+ - |description |String |Event, Task |Section | - |ContentType | | |4.2.3 | - +--------------------+-----------------+----------------+-----------+ - |display |String |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |due |LocalDateTime |Task |Section | - | | | |5.2.1 | - +--------------------+-----------------+----------------+-----------+ - |duration |Duration |Event |Section | - | | | |5.1.2 | - +--------------------+-----------------+----------------+-----------+ - |email |String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |entries |(Task|Event)[] |Group |Section | - | | | |5.3.1 | - +--------------------+-----------------+----------------+-----------+ - |estimatedDuration |Duration |Task |Section | - | | | |5.2.3 | - +--------------------+-----------------+----------------+-----------+ - |excluded |Boolean |Event, Task |Section | - | | | |4.3.6 | - +--------------------+-----------------+----------------+-----------+ - |excluded |RecurrenceRule[] |Event, Task |Section | - |RecurrenceRules | | |4.3.4 | - +--------------------+-----------------+----------------+-----------+ - |expectReply |Boolean |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |features |String[Boolean] |VirtualLocation |Section | - | | | |4.2.6 | - +--------------------+-----------------+----------------+-----------+ - |firstDayOfWeek |String |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |freeBusyStatus |String |Event, Task |Section | - | | | |4.4.2 | - +--------------------+-----------------+----------------+-----------+ - |frequency |String |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |href |String |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |interval |UnsignedInt |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |invitedBy |Id |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |keywords |String[Boolean] |Event, Task, |Section | - | | |Group |4.2.9 | - +--------------------+-----------------+----------------+-----------+ - |kind |String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |language |String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |links |Id[Link] |Group, Event, |Section | - | | |Task, Location, |4.2.7, | - | | |Participant |Section | - | | | |4.2.5, | - | | | |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |locale |String |Group, Event, |Section | - | | |Task |4.2.8 | - +--------------------+-----------------+----------------+-----------+ - |localizations |String |Event, Task |Section | - | |[PatchObject] | |4.6.1 | - +--------------------+-----------------+----------------+-----------+ - |locationId |Id |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |locations |Id[Location] |Event, Task |Section | - | | | |4.2.5 | - +--------------------+-----------------+----------------+-----------+ - |locationTypes |String[Boolean] |Location |Section | - | | | |4.2.5 | - +--------------------+-----------------+----------------+-----------+ - |memberOf |Id[Boolean] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |method |String |Event, Task |Section | - | | | |4.1.8 | - +--------------------+-----------------+----------------+-----------+ - |name |String |Location, |Section | - | | |VirtualLocation,|4.2.5, | - | | |Participant |Section | - | | | |4.2.6, | - | | | |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |names |String[Boolean] |TimeZoneRule |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |nthOfPeriod |Int |NDay |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |offset |SignedDuration |OffsetTrigger |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - |offsetFrom |UTCDateTime |TimeZoneRule |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |offsetTo |UTCDateTime |TimeZoneRule |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |participants |Id[Participant] |Event, Task |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |participationComment|String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |participationStatus |String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |percentComplete |UnsignedInt |Task, |Section | - | | |Participant |5.2.4 | - +--------------------+-----------------+----------------+-----------+ - |priority |Int |Event, Task |Section | - | | | |4.4.1 | - +--------------------+-----------------+----------------+-----------+ - |privacy |String |Event, Task |Section | - | | | |4.4.3 | - +--------------------+-----------------+----------------+-----------+ - |prodId |String |Event, Task, |Section | - | | |Group |4.1.4 | - +--------------------+-----------------+----------------+-----------+ - |progress |String |Task, |Section | - | | |Participant |5.2.5 | - +--------------------+-----------------+----------------+-----------+ - |progressUpdated |UTCDateTime |Task, |Section | - | | |Participant |5.2.6 | - +--------------------+-----------------+----------------+-----------+ - |recurrenceId |LocalDateTime |Event, Task |Section | - | | | |4.3.1 | - +--------------------+-----------------+----------------+-----------+ - |recurrenceIdTimeZone|TimeZoneId|null |Event, Task |Section | - | | | |4.3.2 | - +--------------------+-----------------+----------------+-----------+ - |recurrenceOverrides |LocalDateTime |Event, Task, |Section | - | |[PatchObject] |TimeZoneRule |4.3.5, | - | | | |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |recurrenceRules |RecurrenceRule[] |Event, Task, |Section | - | | |TimeZoneRule |4.3.3, | - | | | |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |rel |String |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |relatedTo |String[Relation] |Event, Task, |Section | - | | |Alert |4.1.3, | - | | | |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - |relation |String[Boolean] |Relation |Section | - | | | |1.4.10 | - +--------------------+-----------------+----------------+-----------+ - |relativeTo |String |OffsetTrigger, |Section | - | | |Location |4.5.2, | - | | | |Section | - | | | |4.2.5 | - +--------------------+-----------------+----------------+-----------+ - |replyTo |String[String] |Event, Task |Section | - | | | |4.4.4 | - +--------------------+-----------------+----------------+-----------+ - |requestStatus |String |Event, Task |Section | - | | | |4.4.7 | - +--------------------+-----------------+----------------+-----------+ - |roles |String[Boolean] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |rscale |String |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |sentBy |String |Event, Task, |Section | - | | |Participant |4.4.5, | - | | | |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |standard |TimeZoneRule[] |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |start |LocalDateTime |TimeZoneRule |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |scheduleAgent |String |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |scheduleForceSend |Boolean |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |scheduleSequence |UnsignedInt |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |scheduleStatus |String[] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |scheduleUpdated |UTCDateTime |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |sendTo |String[String] |Participant |Section | - | | | |4.4.6 | - +--------------------+-----------------+----------------+-----------+ - |sequence |UnsignedInt |Event, Task |Section | - | | | |4.1.7 | - +--------------------+-----------------+----------------+-----------+ - |showWithoutTime |Boolean |Event, Task |Section | - | | | |4.2.4 | - +--------------------+-----------------+----------------+-----------+ - |size |UnsignedInt |Link |Section | - | | | |1.4.11 | - +--------------------+-----------------+----------------+-----------+ - |skip |String |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |source |String |Group |Section | - | | | |5.3.2 | - +--------------------+-----------------+----------------+-----------+ - |start |LocalDateTime |Event, Task |Section | - | | | |5.1.1, | - | | | |Section | - | | | |5.2.2 | - +--------------------+-----------------+----------------+-----------+ - |status |String |Event |Section | - | | | |5.1.3 | - +--------------------+-----------------+----------------+-----------+ - |timeZone |TimeZoneId|null |Event, Task, |Section | - | | |Location |4.7.1, | - | | | |Section | - | | | |4.2.5 | - +--------------------+-----------------+----------------+-----------+ - |timeZones |TimeZoneId |Event, Task |Section | - | |[TimeZone] | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |title |String |Event, Task, |Section | - | | |Group, Link |4.2.1 | - +--------------------+-----------------+----------------+-----------+ - |trigger |OffsetTrigger| |Alert |Section | - | |AbsoluteTrigger| | |4.5.2 | - | |UnknownTrigger | | | - +--------------------+-----------------+----------------+-----------+ - |tzId |String |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |uid |String |Event, Task, |Section | - | | |Group |4.1.2 | - +--------------------+-----------------+----------------+-----------+ - |until |LocalDateTime |RecurrenceRule |Section | - | | | |4.3.3 | - +--------------------+-----------------+----------------+-----------+ - |updated |UTCDateTime |Event, Task, |Section | - | | |Group |4.1.6 | - +--------------------+-----------------+----------------+-----------+ - |uri |String |VirtualLocation |Section | - | | | |4.2.6 | - +--------------------+-----------------+----------------+-----------+ - |url |String |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |useDefaultAlerts |Boolean |Event, Task |Section | - | | | |4.5.1 | - +--------------------+-----------------+----------------+-----------+ - |validUntil |UTCDateTime |TimeZone |Section | - | | | |4.7.2 | - +--------------------+-----------------+----------------+-----------+ - |virtualLocations |Id |Event, Task |Section | - | |[VirtualLocation]| |4.2.6 | - +--------------------+-----------------+----------------+-----------+ - |when |UTCDateTime |AbsoluteTrigger |Section | - | | | |4.5.2 | - +--------------------+-----------------+----------------+-----------+ - - Table 1: Initial Contents of the "JSCalendar Properties" Registry - -8.3. Creation of the "JSCalendar Types" Registry - - IANA has created the "JSCalendar Types" registry to avoid name - collisions and provide a complete reference for all data types used - for JSCalendar property values. The registration process is the same - as for the "JSCalendar Properties" registry, as defined in - Section 8.2. - -8.3.1. "JSCalendar Types" Registry Template - - Type Name: the name of the type - - Reference or Description: a brief description or RFC number and - section reference where the Type is specified (may be omitted for - "reserved" type names) - - Intended Use: common, reserved, or obsolete - - Change Controller: who may request a change to this entry's - definition ("IETF" for RFCs from the IETF stream) - -8.3.2. Initial Contents for the "JSCalendar Types" Registry - - The following table lists the initial entries of the JSCalendar Types - registry. All properties are for common use. All RFC section - references are for this document. The change controller for all - these properties is "IETF". - - +=================+==========================+ - | Type Name | Reference or Description | - +=================+==========================+ - | Alert | Section 4.5.2 | - +-----------------+--------------------------+ - | Boolean | Section 1.3 | - +-----------------+--------------------------+ - | Duration | Section 1.4.6 | - +-----------------+--------------------------+ - | Id | Section 1.4.1 | - +-----------------+--------------------------+ - | Int | Section 1.4.2 | - +-----------------+--------------------------+ - | LocalDateTime | Section 1.4.5 | - +-----------------+--------------------------+ - | Link | Section 1.4.11 | - +-----------------+--------------------------+ - | Location | Section 4.2.5 | - +-----------------+--------------------------+ - | NDay | Section 4.3.3 | - +-----------------+--------------------------+ - | Number | Section 1.3 | - +-----------------+--------------------------+ - | Participant | Section 4.4.6 | - +-----------------+--------------------------+ - | PatchObject | Section 1.4.9 | - +-----------------+--------------------------+ - | RecurrenceRule | Section 4.3.3 | - +-----------------+--------------------------+ - | Relation | Section 1.4.10 | - +-----------------+--------------------------+ - | SignedDuration | Section 1.4.7 | - +-----------------+--------------------------+ - | String | Section 1.3 | - +-----------------+--------------------------+ - | TimeZone | Section 4.7.2 | - +-----------------+--------------------------+ - | TimeZoneId | Section 1.4.8 | - +-----------------+--------------------------+ - | TimeZoneRule | Section 4.7.2 | - +-----------------+--------------------------+ - | UnsignedInt | Section 1.4.3 | - +-----------------+--------------------------+ - | UTCDateTime | Section 1.4.4 | - +-----------------+--------------------------+ - | VirtualLocation | Section 4.2.6 | - +-----------------+--------------------------+ - - Table 2: Initial Contents of the - "JSCalendar Types" Registry - -8.4. Creation of the "JSCalendar Enum Values" Registry - - IANA has created the "JSCalendar Enum Values" registry to allow - interoperable extension of semantics for properties with enumerable - values. Each such property will have a subregistry of allowed - values. The registration process for a new enum value or adding a - new enumerable property is the same as for the "JSCalendar - Properties" registry, as defined in Section 8.2. - -8.4.1. "JSCalendar Enum Values" Registry Property Template - - This template is for adding a subregistry for a new enumerable - property to the "JSCalendar Enum" registry. - - Property Name: These are the name(s) of the property or properties - where these values may be used. This MUST be registered in the - "JSCalendar Properties" registry. - - Context: This is the list of allowed object types where the property - or properties may appear, as registered in the "JSCalendar - Properties" registry. This disambiguates where there may be two - distinct properties with the same name in different contexts. - - Change Controller: ("IETF" for properties defined in RFCs from the - IETF stream). - - Initial Contents: This is the initial list of defined values for - this enum, using the template defined in Section 8.4.2. A - subregistry will be created with these values for this property - name/context tuple. - -8.4.2. "JSCalendar Enum Values" Registry Value Template - - This template is for adding a new enum value to a subregistry in the - JSCalendar Enum registry. - - Enum Value: the verbatim value of the enum - - Reference or Description: a brief description or RFC number and - section reference for the semantics of this value - -8.4.3. Initial Contents for the "JSCalendar Enum Values" Registry - - For each subregistry created in this section, all RFC section - references are for this document. - - Property Name: action - Context: Alert - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | display | Section 4.5.2 | - +------------+--------------------------+ - | email | Section 4.5.2 | - +------------+--------------------------+ - - Table 3: JSCalendar Enum Values for - action (Context: Alert) - - Property Name: display - Context: Link - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | badge | Section 1.4.11 | - +------------+--------------------------+ - | graphic | Section 1.4.11 | - +------------+--------------------------+ - | fullsize | Section 1.4.11 | - +------------+--------------------------+ - | thumbnail | Section 1.4.11 | - +------------+--------------------------+ - - Table 4: JSCalendar Enum Values for - display (Context: Link) - - Property Name: features - Context: VirtualLocation - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | audio | Section 4.2.6 | - +------------+--------------------------+ - | chat | Section 4.2.6 | - +------------+--------------------------+ - | feed | Section 4.2.6 | - +------------+--------------------------+ - | moderator | Section 4.2.6 | - +------------+--------------------------+ - | phone | Section 4.2.6 | - +------------+--------------------------+ - | screen | Section 4.2.6 | - +------------+--------------------------+ - | video | Section 4.2.6 | - +------------+--------------------------+ - - Table 5: JSCalendar Enum Values for - features (Context: VirtualLocation) - - Property Name: freeBusyStatus - Context: Event, Task - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | free | Section 4.4.2 | - +------------+--------------------------+ - | busy | Section 4.4.2 | - +------------+--------------------------+ - - Table 6: JSCalendar Enum Values for - freeBusyStatus (Context: Event, Task) - - Property Name: kind - Context: Participant - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | individual | Section 4.4.6 | - +------------+--------------------------+ - | group | Section 4.4.6 | - +------------+--------------------------+ - | resource | Section 4.4.6 | - +------------+--------------------------+ - | location | Section 4.4.6 | - +------------+--------------------------+ - - Table 7: JSCalendar Enum Values for - kind (Context: Participant) - - Property Name: participationStatus - Context: Participant - Change Controller: IETF - Initial Contents: - +==============+==========================+ - | Enum Value | Reference or Description | - +==============+==========================+ - | needs-action | Section 4.4.6 | - +--------------+--------------------------+ - | accepted | Section 4.4.6 | - +--------------+--------------------------+ - | declined | Section 4.4.6 | - +--------------+--------------------------+ - | tentative | Section 4.4.6 | - +--------------+--------------------------+ - | delegated | Section 4.4.6 | - +--------------+--------------------------+ - - Table 8: JSCalendar Enum Values for - participationStatus (Context: - Participant) - - Property Name: privacy - Context: Event, Task - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | public | Section 4.4.3 | - +------------+--------------------------+ - | private | Section 4.4.3 | - +------------+--------------------------+ - | secret | Section 4.4.3 | - +------------+--------------------------+ - - Table 9: JSCalendar Enum Values for - privacy (Context: Event, Task) - - Property Name: progress - Context: Task, Participant - Change Controller: IETF - Initial Contents: - +==============+==========================+ - | Enum Value | Reference or Description | - +==============+==========================+ - | needs-action | Section 5.2.5 | - +--------------+--------------------------+ - | in-process | Section 5.2.5 | - +--------------+--------------------------+ - | completed | Section 5.2.5 | - +--------------+--------------------------+ - | failed | Section 5.2.5 | - +--------------+--------------------------+ - | cancelled | Section 5.2.5 | - +--------------+--------------------------+ - - Table 10: JSCalendar Enum Values for - progress (Context: Task, Participant) - - Property Name: relation - Context: Relation - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | first | Section 1.4.10 | - +------------+--------------------------+ - | next | Section 1.4.10 | - +------------+--------------------------+ - | child | Section 1.4.10 | - +------------+--------------------------+ - | parent | Section 1.4.10 | - +------------+--------------------------+ - - Table 11: JSCalendar Enum Values for - relation (Context: Relation) - - Property Name: relativeTo - Context: OffsetTrigger, Location - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | start | Section 4.5.2 | - +------------+--------------------------+ - | end | Section 4.5.2 | - +------------+--------------------------+ - - Table 12: JSCalendar Enum Values for - relativeTo (Context: OffsetTrigger, - Location) - - Property Name: roles - Context: Participant - Change Controller: IETF - Initial Contents: - +===============+==========================+ - | Enum Value | Reference or Description | - +===============+==========================+ - | owner | Section 4.4.6 | - +---------------+--------------------------+ - | attendee | Section 4.4.6 | - +---------------+--------------------------+ - | optional | Section 4.4.6 | - +---------------+--------------------------+ - | informational | Section 4.4.6 | - +---------------+--------------------------+ - | chair | Section 4.4.6 | - +---------------+--------------------------+ - | contact | Section 4.4.6 | - +---------------+--------------------------+ - - Table 13: JSCalendar Enum Values for - roles (Context: Participant) - - Property Name: scheduleAgent - Context: Participant - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | server | Section 4.4.6 | - +------------+--------------------------+ - | client | Section 4.4.6 | - +------------+--------------------------+ - | none | Section 4.4.6 | - +------------+--------------------------+ - - Table 14: JSCalendar Enum Values for - scheduleAgent (Context: Participant) - - Property Name: status - Context: Event - Change Controller: IETF - Initial Contents: - +============+==========================+ - | Enum Value | Reference or Description | - +============+==========================+ - | confirmed | Section 5.1.3 | - +------------+--------------------------+ - | cancelled | Section 5.1.3 | - +------------+--------------------------+ - | tentative | Section 5.1.3 | - +------------+--------------------------+ - - Table 15: JSCalendar Enum Values for - status (Context: Event) - -9. References - -9.1. Normative References - - [CLDR] "Unicode Common Locale Data Repository", - . - - [COLORS] Çelik, T., Lilley, C., and L. Baron, "CSS Color Module - Level 3", W3C Recommendation, June 2018, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource - Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, - . - - [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, - DOI 10.17487/RFC2397, August 1998, - . - - [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: - Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, - . - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, DOI 10.17487/RFC3986, January 2005, - . - - [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally - Unique IDentifier (UUID) URN Namespace", RFC 4122, - DOI 10.17487/RFC4122, July 2005, - . - - [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types - Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, - . - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . - - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - DOI 10.17487/RFC5322, October 2008, - . - - [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and - Scheduling Core Object Specification (iCalendar)", - RFC 5545, DOI 10.17487/RFC5545, September 2009, - . - - [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", RFC 5546, - DOI 10.17487/RFC5546, December 2009, - . - - [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying - Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, - September 2009, . - - [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource - Identifier for Geographic Locations ('geo' URI)", - RFC 5870, DOI 10.17487/RFC5870, June 2010, - . - - [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based - Interoperability Protocol (iMIP)", RFC 6047, - DOI 10.17487/RFC6047, December 2010, - . - - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type - Specifications and Registration Procedures", BCP 13, - RFC 6838, DOI 10.17487/RFC6838, January 2013, - . - - [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., - "JavaScript Object Notation (JSON) Pointer", RFC 6901, - DOI 10.17487/RFC6901, April 2013, - . - - [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, - DOI 10.17487/RFC7493, March 2015, - . - - [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules - in the Internet Calendaring and Scheduling Core Object - Specification (iCalendar)", RFC 7529, - DOI 10.17487/RFC7529, May 2015, - . - - [RFC7808] Douglass, M. and C. Daboo, "Time Zone Data Distribution - Service", RFC 7808, DOI 10.17487/RFC7808, March 2016, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", STD 90, RFC 8259, - DOI 10.17487/RFC8259, December 2017, - . - - [RFC8288] Nottingham, M., "Web Linking", RFC 8288, - DOI 10.17487/RFC8288, October 2017, - . - - [TZDB] IANA, "Time Zone Database", - . - -9.2. Informative References - - [ISO.9070.1991] - ISO/IEC, "Information technology -- SGML support - facilities -- Registration procedures for public text - owner identifiers", Edition 2, ISO/IEC 9070:1991, April - 1991, . - - [LINKRELS] IANA, "Link Relations: Link Relation Types", - . - - [LOCATIONTYPES] - IANA, "Location Types Registry", - . - - [MEDIATYPES] - IANA, "Media Types", - . - - [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., - "DomainKeys Identified Mail (DKIM) Signatures", STD 76, - RFC 6376, DOI 10.17487/RFC6376, September 2011, - . - - [RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON - Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May - 2014, . - - [RFC7986] Daboo, C., "New Properties for iCalendar", RFC 7986, - DOI 10.17487/RFC7986, October 2016, - . - -Acknowledgments - - The authors would like to thank the members of CalConnect for their - valuable contributions. This specification originated from the work - of the API technical committee of CalConnect: The Calendaring and - Scheduling Consortium. - -Authors' Addresses - - Neil Jenkins - Fastmail - Collins St. West - P.O. Box 234 - Melbourne VIC 8007 - Australia - - Email: neilj@fastmailteam.com - URI: https://www.fastmail.com - - - Robert Stepanek - Fastmail - Collins St. West - P.O. Box 234 - Melbourne VIC 8007 - Australia - - Email: rsto@fastmailteam.com - URI: https://www.fastmail.com diff --git a/specifications/calendar/rfc9670.pdf b/specifications/calendar/rfc9670.pdf deleted file mode 100644 index d63d9fd5..00000000 Binary files a/specifications/calendar/rfc9670.pdf and /dev/null differ diff --git a/specifications/calendar/rfc9670.txt b/specifications/calendar/rfc9670.txt deleted file mode 100644 index 13dd6891..00000000 --- a/specifications/calendar/rfc9670.txt +++ /dev/null @@ -1,857 +0,0 @@ - - - - -Internet Engineering Task Force (IETF) N. Jenkins, Ed. -Request for Comments: 9670 Fastmail -Updates: 8620 November 2024 -Category: Standards Track -ISSN: 2070-1721 - - - JSON Meta Application Protocol (JMAP) Sharing - -Abstract - - This document specifies a data model for sharing data between users - using the JSON Meta Application Protocol (JMAP). Future documents - can reference this document when defining data types to support a - consistent model of sharing. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc9670. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Revised BSD License text as described in Section 4.e of the - Trust Legal Provisions and are provided without warranty as described - in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Notational Conventions - 1.2. Terminology - 1.3. Data Model Overview - 1.4. Subscribing to Shared Data - 1.5. Addition to the Capabilities Object - 1.5.1. urn:ietf:params:jmap:principals - 1.5.2. urn:ietf:params:jmap:principals:owner - 2. Principals - 2.1. Principal/get - 2.2. Principal/changes - 2.3. Principal/set - 2.4. Principal/query - 2.4.1. Filtering - 2.5. Principal/queryChanges - 3. ShareNotifications - 3.1. ShareNotification/get - 3.2. ShareNotification/changes - 3.3. ShareNotification/set - 3.4. ShareNotification/query - 3.4.1. Filtering - 3.4.2. Sorting - 3.5. ShareNotification/queryChanges - 4. Framework for Shared Data - 4.1. Example - 5. Internationalization Considerations - 6. Security Considerations - 6.1. Spoofing - 6.2. Unnoticed Sharing - 6.3. Denial of Service - 6.4. Unauthorized Principals - 7. IANA Considerations - 7.1. JMAP Capability Registration for "principals" - 7.2. JMAP Capability Registration for "principals:owner" - 7.3. JMAP Data Type Registration for "Principal" - 7.4. JMAP Data Type Registration for "ShareNotification" - 8. References - 8.1. Normative References - 8.2. Informative References - Author's Address - -1. Introduction - - The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic - protocol for synchronizing data, such as mail, calendars, or - contacts, between a client and a server. It is optimized for mobile - and web environments and provides a consistent interface to query, - read, and modify different data types, including comprehensive error - handling. - - This specification defines a data model to represent entities in a - collaborative environment and a framework for sharing data between - them that can be used to provide a consistent sharing model for - different data types. It does not define _what_ may be shared or the - granularity of permissions, as this will depend on the data in - question. - -1.1. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - Type signatures, examples, and property descriptions in this document - follow the conventions established in Section 1.1 of [RFC8620]. Data - types defined in the core specification are also used in this - document. - - Examples of API exchanges only show the methodCalls array of the - Request object or the methodResponses array of the Response object. - For compactness, the rest of the Request/Response object is omitted. - -1.2. Terminology - - The same terminology is used in this document as in the core JMAP - specification. See [RFC8620], Section 1.6. - - The terms "Principal" and "ShareNotification" (with this specific - capitalization) are used to refer to the data types defined in this - document and instances of those data types. - -1.3. Data Model Overview - - A Principal (see Section 2) represents an individual, team, or - resource (e.g., a room or projector). The object contains - information about the entity being represented, such as a name, - description, and time zone. It may also hold domain-specific - information. A Principal may be associated with zero or more - Accounts (see [RFC8620], Section 1.6.2) containing data belonging to - the Principal. Managing the set of Principals within a system is out - of scope for this specification, as it is highly domain specific. It - is likely to map directly from a directory service or other user - management system. - - Data types may allow users to share data with others by assigning - permissions to Principals. When a user's permissions are changed, a - ShareNotification object is created for them so a client can inform - the user of the changes. - -1.4. Subscribing to Shared Data - - Permissions determine whether a user _may_ access data but not - whether they _want_ to. Some shared data is of equal importance as - the user's own, while other data is just there should the user wish - to explicitly go find it. Clients will often want to differentiate - the two. For example, a company may share mailing list archives for - all departments with all employees, but a user may only generally be - interested in the few they belong to. They would have _permission_ - to access many mailboxes but can _subscribe_ to just the ones they - care about. The client would provide separate interfaces for reading - mail in subscribed mailboxes and browsing all mailboxes they have - permission to access in order to manage those that they are - subscribed to. - - The JMAP Session object (see [RFC8620], Section 2) is defined to - include an object in the "accounts" property for every Account that - the user has access to. Collaborative systems may share data between - a very large number of Principals, most of which the user does not - care about day to day. For servers implementing this specification, - the Session object MUST only include Accounts where either the user - is subscribed to at least one record (see [RFC8620], Section 1.6.3) - in the Account or the Account belongs to the user. StateChange - events ([RFC8620], Section 7.1) for changes to data SHOULD only be - sent for data the user has subscribed to and MUST NOT be sent for any - Account where the user is not subscribed to any records in the - Account, except where that Account belongs to the user. - - The server MAY reject the user's attempt to subscribe to some - resources even if they have permission to access them (e.g., a - calendar representing a location). - - A user can query the set of Principals they have access to with - "Principal/query" (see Section 2.4). The Principal object will - contain an Account object for all Accounts where the user has - permission to access data for that Principal, even if they are not - yet subscribed. - -1.5. Addition to the Capabilities Object - - The capabilities object is returned as part of the JMAP Session - object; see [RFC8620], Section 2. This document defines two - additional capability URIs. - -1.5.1. urn:ietf:params:jmap:principals - - The urn:ietf:params:jmap:principals capability represents support for - the Principal and ShareNotification data types and associated API - methods. - - The value of this property in the JMAP Session "capabilities" - property is an empty object. - - The value of this property in an Account's "accountCapabilities" - property is an object that MUST contain the following information on - server capabilities and permissions for that Account: - - *currentUserPrincipalId*: Id|null - The id of the Principal in this Account that corresponds to the - user fetching this object, if any. - -1.5.2. urn:ietf:params:jmap:principals:owner - - The URI urn:ietf:params:jmap:principals:owner is solely used as a key - in an Account's "accountCapabilities" property. It does not appear - in the JMAP Session capabilities -- support is indicated by the - urn:ietf:params:jmap:principals URI being present in the session - capabilities. - - If urn:ietf:params:jmap:principals:owner is a key in an Account's - "accountCapabilities" property, that Account (and the data therein) - is owned by a Principal. Some Accounts may not be owned by a - Principal (e.g., the Account that contains the data for the - Principals themselves), in which case this property is omitted. - - The value of this property is an object with the following - properties: - - *accountIdForPrincipal*: Id - The id of an Account with the urn:ietf:params:jmap:principals - capability that contains the corresponding Principal object. - - *principalId*:Id - The id of the Principal that owns this Account. - -2. Principals - - A Principal represents an individual, a group, a location (e.g., a - room), a resource (e.g., a projector), or another entity in a - collaborative environment. Sharing in JMAP is generally configured - by assigning rights to certain data within an Account to other - Principals. For example, a user may assign permission to read their - calendar to a Principal representing another user or their team. - - In a shared environment, such as a workplace, a user may have access - to a large number of Principals. - - In most systems, the user will have access to a single Account - containing Principal objects. In some situations, for example, when - aggregating data from different places, there may be multiple - Accounts containing Principal objects. - - A *Principal* object has the following properties: - - *id*: Id (immutable; server-set) - The id of the Principal. - - *type*: String - This MUST be one of the following values: - - * "individual": This represents a single person. - * "group": This represents a group of other Principals. - * "resource": This represents some resource, e.g., a projector. - * "location": This represents a location. - * "other": This represents some other undefined Principal. - - *name*: String - The name of the Principal, e.g., "Jane Doe" or "Room 4B". - - *description*: String|null - A longer description of the Principal, for example, details about - the facilities of a resource, or null if no description is - available. - - *email*: String|null - An email address for the Principal, or null if no email is - available. If given, the value MUST conform to the "addr-spec" - syntax, as defined in [RFC5322], Section 3.4.1. - - *timeZone*: String|null - The time zone for this Principal, if known. If not null, the - value MUST be a time zone name from the IANA Time Zone Database - [IANA-TZDB]. - - *capabilities*: String[Object] (server-set) - A map of JMAP capability URIs to domain-specific information about - the Principal in relation to that capability, as defined in the - document that registered the capability. - - *accounts*: Id[Account]|null (server-set) - A map of Account id to Account object for each JMAP Account - containing data for this Principal that the user has access to, or - null if none. - -2.1. Principal/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. - -2.2. Principal/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. - - | Note: Implementations backed by an external directory may be - | unable to calculate changes. In this case, they will always - | return a "cannotCalculateChanges" error as described in the - | core JMAP specification. - -2.3. Principal/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3. - - Managing Principals is likely tied to a directory service or some - other vendor-specific solution. This management may occur out of - band or via an additional capability defined elsewhere. Allowing - direct user modification of properties has security considerations, - as noted in Section 6. A server MUST reject any change it doesn't - allow with a "forbidden" SetError. - - Where a server does support changes via this API, it SHOULD allow an - update to the "name", "description", and "timeZone" properties of the - Principal with the same id as the "currentUserPrincipalId" in the - Account capabilities. This allows the user to update their own - details. - -2.4. Principal/query - - This is a standard "/query" method as described in [RFC8620], - Section 5.5. - -2.4.1. Filtering - - A *FilterCondition* object has the following properties, all of which - are optional: - - *accountIds*: String[] - A list of Account ids. The Principal matches if any of the ids in - this list are keys in the Principal's "accounts" property (i.e., - if any of the Account ids belong to the Principal). - - *email*: String - The email property of the Principal contains the given string. - - *name*: String - The name property of the Principal contains the given string. - - *text*: String - The name, email, or description property of the Principal contains - the given string. - - *type*: String - The type must be exactly as given to match the condition. - - *timeZone*: String - The timeZone must be exactly as given to match the condition. - - All given conditions in the FilterCondition object must match for the - Principal to match. - - Text matches for "contains" SHOULD be simple substring matches. - -2.5. Principal/queryChanges - - This is a standard "/queryChanges" method as described in [RFC8620], - Section 5.6. - - | Note: Implementations backed by an external directory may be - | unable to calculate changes. In this case, they will always - | return a "cannotCalculateChanges" error as described in the - | core JMAP specification. - -3. ShareNotifications - - The ShareNotification data type records when the user's permissions - to access a shared object changes. ShareNotifications are only - created by the server; users cannot create them explicitly. They are - stored in the same Account as the Principals. - - Clients may present the list of notifications to the user and allow - the user to dismiss them. To dismiss a notification, use a standard - "/set" call to destroy it. - - The server SHOULD create a ShareNotification whenever the user's - permissions change on an object. It MAY choose not to create a - notification for permission changes to a group Principal, even if the - user is in the group, if this is more likely to be overwhelming than - helpful, or if it would create excessive notifications within the - system. - - The server MAY limit the maximum number of notifications it will - store for a user. When the limit is reached, any new notification - will cause the previously oldest notification to be automatically - deleted. - - The server MAY coalesce notifications if appropriate or remove - notifications after a certain period of time or that it deems are no - longer relevant. - - A *ShareNotification* object has the following properties: - - *id*: String (immutable; server-set) - The id of the ShareNotification. - - *created*: UTCDate (immutable; server-set) - The time this notification was created. - - *changedBy*: Entity (immutable; server-set) - Who made the change. An *Entity* object has the following - properties: - - *name*: String - The name of the entity who made the change. - *email*: String|null - The email of the entity who made the change, or null if no - email is available. - *principalId*: Id|null - The id of the Principal corresponding to the entity who made - the change, or null if no associated Principal. - - *objectType*: String (immutable; server-set) - The name of the data type for the object whose permissions have - changed, as registered in the IANA "JMAP Data Types" registry - [IANA-JMAP], e.g., "Calendar" or "Mailbox". - - *objectAccountId*: Id (immutable; server-set) - The id of the Account where this object exists. - - *objectId*: Id (immutable; server-set) - The id of the object that this notification is about. - - *oldRights*: String[Boolean]|null (immutable; server-set) - The "myRights" property of the object for the user before the - change. - - *newRights*: String[Boolean]|null (immutable; server-set) - The "myRights" property of the object for the user after the - change. - - *name*: String (immutable; server-set) - The name of the object at the time the notification was made. - Determining the name will depend on the data type in question. - For example, it might be the "title" property of a CalendarEvent - or the "name" of a Mailbox. The name is to show users who have - had their access rights to the object removed what it is that they - can no longer access. - -3.1. ShareNotification/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. - -3.2. ShareNotification/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. - -3.3. ShareNotification/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3. - - Only destroy is supported; any attempt to create/update MUST be - rejected with a "forbidden" SetError. - -3.4. ShareNotification/query - - This is a standard "/query" method as described in [RFC8620], - Section 5.5. - -3.4.1. Filtering - - A *FilterCondition* object has the following properties, all of which - are optional: - - *after*: UTCDate|null - The creation date must be on or after this date to match the - condition. - - *before*: UTCDate|null - The creation date must be before this date to match the condition. - - *objectType*: String - The objectType value must be identical to the given value to match - the condition. - - *objectAccountId*: Id - The objectAccountId value must be identical to the given value to - match the condition. - - All given conditions in the FilterCondition object must match for the - ShareNotification to match. - -3.4.2. Sorting - - The "created" property MUST be supported for sorting. - -3.5. ShareNotification/queryChanges - - This is a standard "/queryChanges" method as described in [RFC8620], - Section 5.6. - -4. Framework for Shared Data - - Shareable data types MUST define the following three properties: - - *isSubscribed*: Boolean - The value true indicates that the user wishes to subscribe to see - this data. The value false indicates that the user does not wish - to subscribe to see this data. The initial value for this - property when data is shared by another user is implementation - dependent, although data types may give advice on appropriate - defaults. - - *myRights*: String[Boolean] - The set of permissions the user currently has. Appropriate - permissions are domain specific and must be defined per data type. - Each key is the name of a permission defined for that data type. - The value for the key is true if the user has the permission or - false if they do not. - - *shareWith*: Id[String[Boolean]]|null - The value of this property is null if the data is not shared with - anyone. Otherwise, it is a map where each key is the id of a - Principal with which this data is shared, and the value associated - with that key is the rights to give that Principal, in the same - format as the "myRights" property. The Account id for the - Principal id can be found in the capabilities of the Account this - object is in (see Section 1.5.2). - - Users with appropriate permission may set this property to modify - who the data is shared with. The Principal that owns the Account - that this data is in MUST NOT be in the map, since the owner's - rights are implicit. - -4.1. Example - - Suppose we are designing a data model for a very simple to-do list. - There is a Todo data type representing a single item to do, each of - which belongs to a single TodoList. The specification makes the - TodoLists shareable by referencing this document and defining the - common properties. - - First, it would define a set of domain-specific rights. For example, - a TodoListRights object may have the following properties: - - *mayRead*: Boolean - The user may fetch this TodoList and any Todos that belong to this - TodoList. - - *mayWrite*: Boolean - The user may create, update, or destroy Todos that belong to this - TodoList and may change the "name" property of this TodoList. - - *mayAdmin*: Boolean - The user may see and modify the "myRights" property of this - TodoList and may destroy this TodoList. - - Then in the TodoList data type, we would include the three common - properties described in Section 4, in addition to any type-specific - properties (like "name" in this case): - - *id*: Id (immutable; server-set) - The id of the object. - - *name*: String - A name for this list of Todos. - - *isSubscribed*: Boolean - True if the user has indicated they wish to see this list. If - false, clients should not display this TodoList with the user's - other TodoLists but should provide a means for users to see and - subscribe to all TodoLists that have been shared with them. - - *myRights*: TodoListRights - The set of permissions the user currently has for this TodoList. - - *shareWith*: Id[TodoListRights]|null - If not shared with anyone, the value is null. Otherwise, it's a - map where the keys are Principal ids and the values are the rights - given to those Principals. Users with the "mayAdmin" right may - set this property to modify who the data is shared with. The - Principal that owns the Account that this data is in MUST NOT be - in the map; their rights are implicit. - - We would also define a new Principal capability with two properties: - - *accountId*: Id|null - The accountId containing the Todo data for this Principal, if it - has been shared with the requesting user. - - *mayShareWith*: Boolean - The user may give this Principal permission to access a TodoList. - - A client wishing to let the user configure sharing would look at the - "capabilities" for the Account containing the user's Todo data and - find the "urn:ietf:params:jmap:principals:owner" property, as per - Section 1.5.2. For example, the JMAP Session object might contain: - - { - "accounts": { - "u12345678": { - "name": "jane.doe@example.com", - "isPersonal": true, - "isReadOnly": false, - "accountCapabilities": { - "urn:com.example:jmap:todo": {}, - "urn:ietf:params:jmap:principals:owner": { - "accountIdForPrincipal": "u33084183", - "principalId": "P105aga511jaa" - } - } - }, - ... - }, - ... - } - - Figure 1: Part of a JMAP Session Object - - From this, the client now knows which Account has the Principal data, - and it can fetch the list of Principals and offer to share it with - the user by making an API request like this: - - [[ "Principal/get", { - "accountId": "u33084183", - "ids": null - }, "0" ]] - - Figure 2: "methodCalls" Property of a JMAP Request - - Here's an example response (where "Joe Bloggs" is another user that - this user could share their TodoList with; Joe has not shared any of - their own data with this user, so the "accounts" property is null): - - [[ "Principal/get", { - "accountId": "u33084183", - "state": "7b8eff5zz", - "list": [{ - "id": "P2342fnddd20", - "type": "individual", - "name": "Joe Bloggs", - "description": null, - "email": "joe.bloggs@example.com", - "timeZone": "Australia/Melbourne", - "capabilities": { - "urn:com.example:jmap:todo": { - "accountId": null, - "mayShareWith": true - } - }, - "accounts": null - }, { - "id": "P674pp24095qo49pr", - "name": "Board room", - "type": "location", - ... - }, ... ], - "notFound": [] - }, "0" ]] - - Figure 3: "methodResponses" Property of a JMAP Response - - A TodoList can be shared with "Joe Bloggs" by updating its shareWith - property, as in this example request: - - [[ "TodoList/set", { - "accountId": "u12345678", - "update": { - "tl01n231": { - "shareWith": { - "P2342fnddd20": { - "mayRead": true, - "mayWrite": true, - "mayAdmin": false - } - } - } - } - }, "0" ]] - - Figure 4: "methodCalls" Property of a JMAP Request - -5. Internationalization Considerations - - Experience has shown that unrestricted use of Unicode can lead to - problems such as inconsistent rendering, users reading text and - interpreting it differently than intended, and unexpected results - when copying text from one location to another. Servers MAY choose - to mitigate this by restricting the set of characters allowed in - otherwise unconstrained String fields. The FreeformClass, as - documented in [RFC8264], Section 4.3, might be a good starting point - for this. - - Attempts to set a value containing code points outside of the - permissible set can be handled in a few ways by the server. The - first option is to simply strip the forbidden characters and store - the resulting string. This is likely to be appropriate for control - characters, for example, where they can end up in data accidentally - due to copy-and-paste issues and are probably invisible to the end - user. JMAP allows the server to transform data on create/update, as - long as any changed properties are returned to the client in the - "/set" response so it knows what has changed, as per [RFC8620], - Section 5.3. Alternatively, the server MAY just reject the create/ - update with an "invalidProperties" SetError. - -6. Security Considerations - - All security considerations of JMAP [RFC8620] apply to this - specification. Additional considerations are detailed below. - -6.1. Spoofing - - Allowing users to edit their own Principal's name (and, to a lesser - extent, email, description, or type) could allow a user to change - their Principal to look like another user in the system, potentially - tricking others into sharing private data with them. Servers may - choose to forbid this and SHOULD keep logs of such changes to provide - an audit trail. - - Note that simply forbidding the use of a name already in the system - is insufficient protection, as a malicious user could still change - their name to something easily confused with the existing name by - using trivial misspellings or visually similar Unicode characters. - -6.2. Unnoticed Sharing - - Sharing data with another user allows someone to turn a transitory - account compromise (e.g., brief access to an unlocked or logged-in - client) into a persistent compromise (by setting up sharing with a - user that is controlled by the attacker). This can be mitigated by - requiring further authorization for configuring sharing or sending - notifications to the sharer via another channel whenever a new - permission is added. - -6.3. Denial of Service - - By creating many changes to the sharing status of objects, a user can - cause many ShareNotifications to be generated, which could lead to - resource exhaustion. Servers can mitigate this by coalescing - multiple changes to the same object into a single notification, - limiting the maximum number of notifications it stores per user and/ - or rate-limiting the changes to sharing permissions in the first - place. Automatically deleting older notifications after reaching a - limit can mean the user is not made aware of a sharing change, which - can itself be a security issue. For this reason, it is better to - coalesce changes and use other mitigation strategies. - -6.4. Unauthorized Principals - - The set of Principals within a shared environment MUST be strictly - controlled. If adding a new Principal is open to the public, risks - include: - - * An increased risk of a user accidentally sharing data with an - unintended person. - * An attacker sharing unwanted or offensive information with the - user. - * An attacker sharing items with spam content in the names in order - to generate ShareNotification objects, which are likely to be - prominently displayed to the user receiving them. - -7. IANA Considerations - -7.1. JMAP Capability Registration for "principals" - - IANA has registered "principals" in the "JMAP Capabilities" registry - as follows: - - Capability Name: urn:ietf:params:jmap:principals - Intended Use: common - Change Controller: IETF - Security and Privacy Considerations: RFC 9670, Section 6 - Reference: RFC 9670 - -7.2. JMAP Capability Registration for "principals:owner" - - IANA has registered "principals:owner" in the "JMAP Capabilities" - registry as follows: - - Capability Name: urn:ietf:params:jmap:principals:owner - Intended Use: common - Change Controller: IETF - Security and Privacy Considerations: RFC 9670, Section 6 - Reference: RFC 9670 - -7.3. JMAP Data Type Registration for "Principal" - - IANA has registered "Principal" in the "JMAP Data Types" registry as - follows: - - Type Name: Principal - Can Reference Blobs: No - Can Use for State Change: Yes - Capability: urn:ietf:params:jmap:principals - Reference: RFC 9670 - -7.4. JMAP Data Type Registration for "ShareNotification" - - IANA has registered "ShareNotification" in the "JMAP Data Types" - registry as follows: - - Type Name: ShareNotification - Can Reference Blobs: No - Can Use for State Change: Yes - Capability: urn:ietf:params:jmap:principals - Reference: RFC 9670 - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - DOI 10.17487/RFC5322, October 2008, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application - Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July - 2019, . - -8.2. Informative References - - [IANA-JMAP] - IANA, "JMAP Data Types", - . - - [IANA-TZDB] - IANA, "Time Zone Database", - . - - [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: - Preparation, Enforcement, and Comparison of - Internationalized Strings in Application Protocols", - RFC 8264, DOI 10.17487/RFC8264, October 2017, - . - -Author's Address - - Neil Jenkins (editor) - Fastmail - PO Box 234, Collins St West - Melbourne VIC 8007 - Australia - Email: neilj@fastmailteam.com - URI: https://www.fastmail.com diff --git a/specifications/contacts/rfc6350.pdf b/specifications/contacts/rfc6350.pdf deleted file mode 100644 index a40987ca..00000000 Binary files a/specifications/contacts/rfc6350.pdf and /dev/null differ diff --git a/specifications/contacts/rfc6350.txt b/specifications/contacts/rfc6350.txt deleted file mode 100644 index d853cbc6..00000000 --- a/specifications/contacts/rfc6350.txt +++ /dev/null @@ -1,4147 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) S. Perreault -Request for Comments: 6350 Viagenie -Obsoletes: 2425, 2426, 4770 August 2011 -Updates: 2739 -Category: Standards Track -ISSN: 2070-1721 - - - vCard Format Specification - -Abstract - - This document defines the vCard data format for representing and - exchanging a variety of information about individuals and other - entities (e.g., formatted and structured name and delivery addresses, - email address, multiple telephone numbers, photograph, logo, audio - clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and - updates RFC 2739. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 5741. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - http://www.rfc-editor.org/info/rfc6350. - -Copyright Notice - - Copyright (c) 2011 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - -Perreault Standards Track [Page 1] - -RFC 6350 vCard August 2011 - - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. vCard Format Specification . . . . . . . . . . . . . . . . . . 5 - 3.1. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Line Delimiting and Folding . . . . . . . . . . . . . . . 5 - 3.3. ABNF Format Definition . . . . . . . . . . . . . . . . . . 6 - 3.4. Property Value Escaping . . . . . . . . . . . . . . . . . 9 - 4. Property Value Data Types . . . . . . . . . . . . . . . . . . 9 - 4.1. TEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP . . 12 - 4.3.1. DATE . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.3.2. TIME . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.3.3. DATE-TIME . . . . . . . . . . . . . . . . . . . . . . 13 - 4.3.4. DATE-AND-OR-TIME . . . . . . . . . . . . . . . . . . . 14 - 4.3.5. TIMESTAMP . . . . . . . . . . . . . . . . . . . . . . 14 - 4.4. BOOLEAN . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.5. INTEGER . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.6. FLOAT . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.7. UTC-OFFSET . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.8. LANGUAGE-TAG . . . . . . . . . . . . . . . . . . . . . . . 16 - 5. Property Parameters . . . . . . . . . . . . . . . . . . . . . 16 - 5.1. LANGUAGE . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.2. VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 5.3. PREF . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.4. ALTID . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.5. PID . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 5.6. TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 5.7. MEDIATYPE . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.8. CALSCALE . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 5.9. SORT-AS . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 5.10. GEO . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 5.11. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - -Perreault Standards Track [Page 2] - -RFC 6350 vCard August 2011 - - - 6. vCard Properties . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.1. General Properties . . . . . . . . . . . . . . . . . . . . 23 - 6.1.1. BEGIN . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.1.2. END . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.1.3. SOURCE . . . . . . . . . . . . . . . . . . . . . . . . 24 - 6.1.4. KIND . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 6.1.5. XML . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 6.2. Identification Properties . . . . . . . . . . . . . . . . 28 - 6.2.1. FN . . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 6.2.2. N . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.2.3. NICKNAME . . . . . . . . . . . . . . . . . . . . . . . 29 - 6.2.4. PHOTO . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.2.5. BDAY . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6.2.6. ANNIVERSARY . . . . . . . . . . . . . . . . . . . . . 31 - 6.2.7. GENDER . . . . . . . . . . . . . . . . . . . . . . . . 32 - 6.3. Delivery Addressing Properties . . . . . . . . . . . . . . 32 - 6.3.1. ADR . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 6.4. Communications Properties . . . . . . . . . . . . . . . . 34 - 6.4.1. TEL . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 6.4.2. EMAIL . . . . . . . . . . . . . . . . . . . . . . . . 36 - 6.4.3. IMPP . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 6.4.4. LANG . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 6.5. Geographical Properties . . . . . . . . . . . . . . . . . 37 - 6.5.1. TZ . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 6.5.2. GEO . . . . . . . . . . . . . . . . . . . . . . . . . 38 - 6.6. Organizational Properties . . . . . . . . . . . . . . . . 39 - 6.6.1. TITLE . . . . . . . . . . . . . . . . . . . . . . . . 39 - 6.6.2. ROLE . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 6.6.3. LOGO . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 6.6.4. ORG . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 6.6.5. MEMBER . . . . . . . . . . . . . . . . . . . . . . . . 41 - 6.6.6. RELATED . . . . . . . . . . . . . . . . . . . . . . . 42 - 6.7. Explanatory Properties . . . . . . . . . . . . . . . . . . 43 - 6.7.1. CATEGORIES . . . . . . . . . . . . . . . . . . . . . . 43 - 6.7.2. NOTE . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 6.7.3. PRODID . . . . . . . . . . . . . . . . . . . . . . . . 44 - 6.7.4. REV . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 6.7.5. SOUND . . . . . . . . . . . . . . . . . . . . . . . . 45 - 6.7.6. UID . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 6.7.7. CLIENTPIDMAP . . . . . . . . . . . . . . . . . . . . . 47 - 6.7.8. URL . . . . . . . . . . . . . . . . . . . . . . . . . 47 - 6.7.9. VERSION . . . . . . . . . . . . . . . . . . . . . . . 48 - 6.8. Security Properties . . . . . . . . . . . . . . . . . . . 48 - 6.8.1. KEY . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 6.9. Calendar Properties . . . . . . . . . . . . . . . . . . . 49 - 6.9.1. FBURL . . . . . . . . . . . . . . . . . . . . . . . . 49 - 6.9.2. CALADRURI . . . . . . . . . . . . . . . . . . . . . . 50 - 6.9.3. CALURI . . . . . . . . . . . . . . . . . . . . . . . . 50 - - - -Perreault Standards Track [Page 3] - -RFC 6350 vCard August 2011 - - - 6.10. Extended Properties and Parameters . . . . . . . . . . . . 51 - 7. Synchronization . . . . . . . . . . . . . . . . . . . . . . . 51 - 7.1. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . 51 - 7.1.1. Matching vCard Instances . . . . . . . . . . . . . . . 51 - 7.1.2. Matching Property Instances . . . . . . . . . . . . . 52 - 7.1.3. PID Matching . . . . . . . . . . . . . . . . . . . . . 52 - 7.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 7.2.1. Creation . . . . . . . . . . . . . . . . . . . . . . . 53 - 7.2.2. Initial Sharing . . . . . . . . . . . . . . . . . . . 53 - 7.2.3. Adding and Sharing a Property . . . . . . . . . . . . 54 - 7.2.4. Simultaneous Editing . . . . . . . . . . . . . . . . . 54 - 7.2.5. Global Context Simplification . . . . . . . . . . . . 56 - 8. Example: Author's vCard . . . . . . . . . . . . . . . . . . . 56 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 57 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 - 10.1. Media Type Registration . . . . . . . . . . . . . . . . . 58 - 10.2. Registering New vCard Elements . . . . . . . . . . . . . . 59 - 10.2.1. Registration Procedure . . . . . . . . . . . . . . . . 59 - 10.2.2. Vendor Namespace . . . . . . . . . . . . . . . . . . . 60 - 10.2.3. Registration Template for Properties . . . . . . . . . 61 - 10.2.4. Registration Template for Parameters . . . . . . . . . 61 - 10.2.5. Registration Template for Value Data Types . . . . . . 62 - 10.2.6. Registration Template for Values . . . . . . . . . . . 62 - 10.3. Initial vCard Elements Registries . . . . . . . . . . . . 63 - 10.3.1. Properties Registry . . . . . . . . . . . . . . . . . 64 - 10.3.2. Parameters Registry . . . . . . . . . . . . . . . . . 65 - 10.3.3. Value Data Types Registry . . . . . . . . . . . . . . 65 - 10.3.4. Values Registries . . . . . . . . . . . . . . . . . . 66 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 69 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 71 - Appendix A. Differences from RFCs 2425 and 2426 . . . . . . . . . 73 - A.1. New Structure . . . . . . . . . . . . . . . . . . . . . . 73 - A.2. Removed Features . . . . . . . . . . . . . . . . . . . . . 73 - A.3. New Properties and Parameters . . . . . . . . . . . . . . 73 - - - - - - - - - - - - - - - -Perreault Standards Track [Page 4] - -RFC 6350 vCard August 2011 - - -1. Introduction - - Electronic address books have become ubiquitous. Their increased - presence on portable, connected devices as well as the diversity of - platforms that exchange contact data call for a standard. This memo - defines the vCard format, which allows the capture and exchange of - information normally stored within an address book or directory - application. - - A high-level overview of the differences from RFCs 2425 and 2426 can - be found in Appendix A. - -2. Conventions - - 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 - [RFC2119]. - -3. vCard Format Specification - - The text/vcard MIME content type (hereafter known as "vCard"; see - Section 10.1) contains contact information, typically pertaining to a - single contact or group of contacts. The content consists of one or - more lines in the format given below. - -3.1. Charset - - The charset (see [RFC3536] for internationalization terminology) for - vCard is UTF-8 as defined in [RFC3629]. There is no way to override - this. It is invalid to specify a value other than "UTF-8" in the - "charset" MIME parameter (see Section 10.1). - -3.2. Line Delimiting and Folding - - Individual lines within vCard are delimited by the [RFC5322] line - break, which is a CRLF sequence (U+000D followed by U+000A). Long - logical lines of text can be split into a multiple-physical-line - representation using the following folding technique. Content lines - SHOULD be folded to a maximum width of 75 octets, excluding the line - break. Multi-octet characters MUST remain contiguous. The rationale - for this folding process can be found in [RFC5322], Section 2.1.1. - - A logical line MAY be continued on the next physical line anywhere - between two characters by inserting a CRLF immediately followed by a - single white space character (space (U+0020) or horizontal tab - (U+0009)). The folded line MUST contain at least one character. Any - sequence of CRLF followed immediately by a single white space - - - -Perreault Standards Track [Page 5] - -RFC 6350 vCard August 2011 - - - character is ignored (removed) when processing the content type. For - example, the line: - - NOTE:This is a long description that exists on a long line. - - can be represented as: - - NOTE:This is a long description - that exists on a long line. - - It could also be represented as: - - NOTE:This is a long descrip - tion that exists o - n a long line. - - The process of moving from this folded multiple-line representation - of a property definition to its single-line representation is called - unfolding. Unfolding is accomplished by regarding CRLF immediately - followed by a white space character (namely, HTAB (U+0009) or SPACE - (U+0020)) as equivalent to no characters at all (i.e., the CRLF and - single white space character are removed). - - Note: It is possible for very simple implementations to generate - improperly folded lines in the middle of a UTF-8 multi-octet - sequence. For this reason, implementations SHOULD unfold lines in - such a way as to properly restore the original sequence. - - Note: Unfolding is done differently than in [RFC5322]. Unfolding - in [RFC5322] only removes the CRLF, not the space following it. - - Folding is done after any content encoding of a type value. - Unfolding is done before any decoding of a type value in a content - line. - -3.3. ABNF Format Definition - - The following ABNF uses the notation of [RFC5234], which also defines - CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT. - - vcard-entity = 1*vcard - - vcard = "BEGIN:VCARD" CRLF - "VERSION:4.0" CRLF - 1*contentline - "END:VCARD" CRLF - ; A vCard object MUST include the VERSION and FN properties. - ; VERSION MUST come immediately after BEGIN:VCARD. - - - -Perreault Standards Track [Page 6] - -RFC 6350 vCard August 2011 - - - contentline = [group "."] name *(";" param) ":" value CRLF - ; When parsing a content line, folded lines must first - ; be unfolded according to the unfolding procedure - ; described in Section 3.2. - ; When generating a content line, lines longer than 75 - ; characters SHOULD be folded according to the folding - ; procedure described in Section 3.2. - - group = 1*(ALPHA / DIGIT / "-") - name = "SOURCE" / "KIND" / "FN" / "N" / "NICKNAME" - / "PHOTO" / "BDAY" / "ANNIVERSARY" / "GENDER" / "ADR" / "TEL" - / "EMAIL" / "IMPP" / "LANG" / "TZ" / "GEO" / "TITLE" / "ROLE" - / "LOGO" / "ORG" / "MEMBER" / "RELATED" / "CATEGORIES" - / "NOTE" / "PRODID" / "REV" / "SOUND" / "UID" / "CLIENTPIDMAP" - / "URL" / "KEY" / "FBURL" / "CALADRURI" / "CALURI" / "XML" - / iana-token / x-name - ; Parsing of the param and value is based on the "name" as - ; defined in ABNF sections below. - ; Group and name are case-insensitive. - - iana-token = 1*(ALPHA / DIGIT / "-") - ; identifier registered with IANA - - x-name = "x-" 1*(ALPHA / DIGIT / "-") - ; Names that begin with "x-" or "X-" are - ; reserved for experimental use, not intended for released - ; products, or for use in bilateral agreements. - - param = language-param / value-param / pref-param / pid-param - / type-param / geo-parameter / tz-parameter / sort-as-param - / calscale-param / any-param - ; Allowed parameters depend on property name. - - param-value = *SAFE-CHAR / DQUOTE *QSAFE-CHAR DQUOTE - - any-param = (iana-token / x-name) "=" param-value *("," param-value) - - NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4 - ; UTF8-{2,3,4} are defined in [RFC3629] - - QSAFE-CHAR = WSP / "!" / %x23-7E / NON-ASCII - ; Any character except CTLs, DQUOTE - - SAFE-CHAR = WSP / "!" / %x23-39 / %x3C-7E / NON-ASCII - ; Any character except CTLs, DQUOTE, ";", ":" - - VALUE-CHAR = WSP / VCHAR / NON-ASCII - ; Any textual character - - - -Perreault Standards Track [Page 7] - -RFC 6350 vCard August 2011 - - - A line that begins with a white space character is a continuation of - the previous line, as described in Section 3.2. The white space - character and immediately preceeding CRLF should be discarded when - reconstructing the original line. Note that this line-folding - convention differs from that found in [RFC5322], in that the sequence - found anywhere in the content indicates a continued line - and should be removed. - - Property names and parameter names are case-insensitive (e.g., the - property name "fn" is the same as "FN" and "Fn"). Parameter values - MAY be case-sensitive or case-insensitive, depending on their - definition. Parameter values that are not explicitly defined as - being case-sensitive are case-insensitive. Based on experience with - vCard 3 interoperability, it is RECOMMENDED that property and - parameter names be upper-case on output. - - The group construct is used to group related properties together. - The group name is a syntactic convention used to indicate that all - property names prefaced with the same group name SHOULD be grouped - together when displayed by an application. It has no other - significance. Implementations that do not understand or support - grouping MAY simply strip off any text before a "." to the left of - the type name and present the types and values as normal. - - Property cardinalities are indicated using the following notation, - which is based on ABNF (see [RFC5234], Section 3.6): - - +-------------+--------------------------------------------------+ - | Cardinality | Meaning | - +-------------+--------------------------------------------------+ - | 1 | Exactly one instance per vCard MUST be present. | - | *1 | Exactly one instance per vCard MAY be present. | - | 1* | One or more instances per vCard MUST be present. | - | * | One or more instances per vCard MAY be present. | - +-------------+--------------------------------------------------+ - - Properties defined in a vCard instance may have multiple values - depending on the property cardinality. The general rule for encoding - multi-valued properties is to simply create a new content line for - each value (including the property name). However, it should be - noted that some value types support encoding multiple values in a - single content line by separating the values with a comma ",". This - approach has been taken for several of the content types defined - below (date, time, integer, float). - - - - - - - -Perreault Standards Track [Page 8] - -RFC 6350 vCard August 2011 - - -3.4. Property Value Escaping - - Some properties may contain one or more values delimited by a COMMA - character (U+002C). Therefore, a COMMA character in a value MUST be - escaped with a BACKSLASH character (U+005C), even for properties that - don't allow multiple instances (for consistency). - - Some properties (e.g., N and ADR) comprise multiple fields delimited - by a SEMICOLON character (U+003B). Therefore, a SEMICOLON in a field - of such a "compound" property MUST be escaped with a BACKSLASH - character. SEMICOLON characters in non-compound properties MAY be - escaped. On input, an escaped SEMICOLON character is never a field - separator. An unescaped SEMICOLON character may be a field - separator, depending on the property in which it appears. - - Furthermore, some fields of compound properties may contain a list of - values delimited by a COMMA character. Therefore, a COMMA character - in one of a field's values MUST be escaped with a BACKSLASH - character, even for fields that don't allow multiple values (for - consistency). Compound properties allowing multiple instances MUST - NOT be encoded in a single content line. - - Finally, BACKSLASH characters in values MUST be escaped with a - BACKSLASH character. NEWLINE (U+000A) characters in values MUST be - encoded by two characters: a BACKSLASH followed by either an 'n' - (U+006E) or an 'N' (U+004E). - - In all other cases, escaping MUST NOT be used. - -4. Property Value Data Types - - Standard value types are defined below. - - value = text - / text-list - / date-list - / time-list - / date-time-list - / date-and-or-time-list - / timestamp-list - / boolean - / integer-list - / float-list - / URI ; from Section 3 of [RFC3986] - / utc-offset - / Language-Tag - / iana-valuespec - ; Actual value type depends on property name and VALUE parameter. - - - -Perreault Standards Track [Page 9] - -RFC 6350 vCard August 2011 - - - text = *TEXT-CHAR - - TEXT-CHAR = "\\" / "\," / "\n" / WSP / NON-ASCII - / %x21-2B / %x2D-5B / %x5D-7E - ; Backslashes, commas, and newlines must be encoded. - - component = "\\" / "\," / "\;" / "\n" / WSP / NON-ASCII - / %x21-2B / %x2D-3A / %x3C-5B / %x5D-7E - list-component = component *("," component) - - text-list = text *("," text) - date-list = date *("," date) - time-list = time *("," time) - date-time-list = date-time *("," date-time) - date-and-or-time-list = date-and-or-time *("," date-and-or-time) - timestamp-list = timestamp *("," timestamp) - integer-list = integer *("," integer) - float-list = float *("," float) - - boolean = "TRUE" / "FALSE" - integer = [sign] 1*DIGIT - float = [sign] 1*DIGIT ["." 1*DIGIT] - - sign = "+" / "-" - - year = 4DIGIT ; 0000-9999 - month = 2DIGIT ; 01-12 - day = 2DIGIT ; 01-28/29/30/31 depending on month and leap year - hour = 2DIGIT ; 00-23 - minute = 2DIGIT ; 00-59 - second = 2DIGIT ; 00-58/59/60 depending on leap second - zone = utc-designator / utc-offset - utc-designator = %x5A ; uppercase "Z" - - date = year [month day] - / year "-" month - / "--" month [day] - / "--" "-" day - date-noreduc = year month day - / "--" month day - / "--" "-" day - date-complete = year month day - - time = hour [minute [second]] [zone] - / "-" minute [second] [zone] - / "-" "-" second [zone] - time-notrunc = hour [minute [second]] [zone] - time-complete = hour minute second [zone] - - - -Perreault Standards Track [Page 10] - -RFC 6350 vCard August 2011 - - - time-designator = %x54 ; uppercase "T" - date-time = date-noreduc time-designator time-notrunc - timestamp = date-complete time-designator time-complete - - date-and-or-time = date-time / date / time-designator time - - utc-offset = sign hour [minute] - - Language-Tag = - - iana-valuespec = - ; a publicly defined valuetype format, registered - ; with IANA, as defined in Section 12 of this - ; document. - -4.1. TEXT - - "text": The "text" value type should be used to identify values that - contain human-readable text. As for the language, it is controlled - by the LANGUAGE property parameter defined in Section 5.1. - - Examples for "text": - - this is a text value - this is one value,this is another - this is a single value\, with a comma encoded - - A formatted text line break in a text value type MUST be represented - as the character sequence backslash (U+005C) followed by a Latin - small letter n (U+006E) or a Latin capital letter N (U+004E), that - is, "\n" or "\N". - - For example, a multiple line NOTE value of: - - Mythical Manager - Hyjinx Software Division - BabsCo, Inc. - - could be represented as: - - NOTE:Mythical Manager\nHyjinx Software Division\n - BabsCo\, Inc.\n - - demonstrating the \n literal formatted line break technique, the - CRLF-followed-by-space line folding technique, and the backslash - escape technique. - - - - - -Perreault Standards Track [Page 11] - -RFC 6350 vCard August 2011 - - -4.2. URI - - "uri": The "uri" value type should be used to identify values that - are referenced by a Uniform Resource Identifier (URI) instead of - encoded in-line. These value references might be used if the value - is too large, or otherwise undesirable to include directly. The - format for the URI is as defined in Section 3 of [RFC3986]. Note - that the value of a property of type "uri" is what the URI points to, - not the URI itself. - - Examples for "uri": - - http://www.example.com/my/picture.jpg - ldap://ldap.example.com/cn=babs%20jensen - -4.3. DATE, TIME, DATE-TIME, DATE-AND-OR-TIME, and TIMESTAMP - - "date", "time", "date-time", "date-and-or-time", and "timestamp": - Each of these value types is based on the definitions in - [ISO.8601.2004]. Multiple such values can be specified using the - comma-separated notation. - - Only the basic format is supported. - -4.3.1. DATE - - A calendar date as specified in [ISO.8601.2004], Section 4.1.2. - - Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3 - a) and b), but not c), is permitted. - - Expanded representation, as specified in [ISO.8601.2004], Section - 4.1.4, is forbidden. - - Truncated representation, as specified in [ISO.8601.2000], Sections - 5.2.1.3 d), e), and f), is permitted. - - Examples for "date": - - 19850412 - 1985-04 - 1985 - --0412 - ---12 - - - - - - - -Perreault Standards Track [Page 12] - -RFC 6350 vCard August 2011 - - - Note the use of YYYY-MM in the second example above. YYYYMM is - disallowed to prevent confusion with YYMMDD. Note also that - YYYY-MM-DD is disallowed since we are using the basic format instead - of the extended format. - -4.3.2. TIME - - A time of day as specified in [ISO.8601.2004], Section 4.2. - - Reduced accuracy, as specified in [ISO.8601.2004], Section 4.2.2.3, - is permitted. - - Representation with decimal fraction, as specified in - [ISO.8601.2004], Section 4.2.2.4, is forbidden. - - The midnight hour is always represented by 00, never 24 (see - [ISO.8601.2004], Section 4.2.3). - - Truncated representation, as specified in [ISO.8601.2000], Sections - 5.3.1.4 a), b), and c), is permitted. - - Examples for "time": - - 102200 - 1022 - 10 - -2200 - --00 - 102200Z - 102200-0800 - -4.3.3. DATE-TIME - - A date and time of day combination as specified in [ISO.8601.2004], - Section 4.3. - - Truncation of the date part, as specified in [ISO.8601.2000], Section - 5.4.2 c), is permitted. - - Examples for "date-time": - - 19961022T140000 - --1022T1400 - ---22T14 - - - - - - - -Perreault Standards Track [Page 13] - -RFC 6350 vCard August 2011 - - -4.3.4. DATE-AND-OR-TIME - - Either a DATE-TIME, a DATE, or a TIME value. To allow unambiguous - interpretation, a stand-alone TIME value is always preceded by a "T". - - Examples for "date-and-or-time": - - 19961022T140000 - --1022T1400 - ---22T14 - 19850412 - 1985-04 - 1985 - --0412 - ---12 - T102200 - T1022 - T10 - T-2200 - T--00 - T102200Z - T102200-0800 - -4.3.5. TIMESTAMP - - A complete date and time of day combination as specified in - [ISO.8601.2004], Section 4.3.2. - - Examples for "timestamp": - - 19961022T140000 - 19961022T140000Z - 19961022T140000-05 - 19961022T140000-0500 - -4.4. BOOLEAN - - "boolean": The "boolean" value type is used to express boolean - values. These values are case-insensitive. - - Examples: - - TRUE - false - True - - - - - - -Perreault Standards Track [Page 14] - -RFC 6350 vCard August 2011 - - -4.5. INTEGER - - "integer": The "integer" value type is used to express signed - integers in decimal format. If sign is not specified, the value is - assumed positive "+". Multiple "integer" values can be specified - using the comma-separated notation. The maximum value is - 9223372036854775807, and the minimum value is -9223372036854775808. - These limits correspond to a signed 64-bit integer using two's- - complement arithmetic. - - Examples: - - 1234567890 - -1234556790 - +1234556790,432109876 - -4.6. FLOAT - - "float": The "float" value type is used to express real numbers. If - sign is not specified, the value is assumed positive "+". Multiple - "float" values can be specified using the comma-separated notation. - Implementations MUST support a precision equal or better than that of - the IEEE "binary64" format [IEEE.754.2008]. - - Note: Scientific notation is disallowed. Implementers wishing to - use their favorite language's %f formatting should be careful. - - Examples: - - 20.30 - 1000000.0000001 - 1.333,3.14 - -4.7. UTC-OFFSET - - "utc-offset": The "utc-offset" value type specifies that the property - value is a signed offset from UTC. This value type can be specified - in the TZ property. - - The value type is an offset from Coordinated Universal Time (UTC). - It is specified as a positive or negative difference in units of - hours and minutes (e.g., +hhmm). The time is specified as a 24-hour - clock. Hour values are from 00 to 23, and minute values are from 00 - to 59. Hour and minutes are 2 digits with high-order zeroes required - to maintain digit count. The basic format for ISO 8601 UTC offsets - MUST be used. - - - - - -Perreault Standards Track [Page 15] - -RFC 6350 vCard August 2011 - - -4.8. LANGUAGE-TAG - - "language-tag": A single language tag, as defined in [RFC5646]. - -5. Property Parameters - - A property can have attributes associated with it. These "property - parameters" contain meta-information about the property or the - property value. In some cases, the property parameter can be multi- - valued in which case the property parameter value elements are - separated by a COMMA (U+002C). - - Property parameter value elements that contain the COLON (U+003A), - SEMICOLON (U+003B), or COMMA (U+002C) character separators MUST be - specified as quoted-string text values. Property parameter values - MUST NOT contain the DQUOTE (U+0022) character. The DQUOTE character - is used as a delimiter for parameter values that contain restricted - characters or URI text. - - Applications MUST ignore x-param and iana-param values they don't - recognize. - -5.1. LANGUAGE - - The LANGUAGE property parameter is used to identify data in multiple - languages. There is no concept of "default" language, except as - specified by any "Content-Language" MIME header parameter that is - present [RFC3282]. The value of the LANGUAGE property parameter is a - language tag as defined in Section 2 of [RFC5646]. - - Examples: - - ROLE;LANGUAGE=tr:hoca - - ABNF: - - language-param = "LANGUAGE=" Language-Tag - ; Language-Tag is defined in section 2.1 of RFC 5646 - -5.2. VALUE - - The VALUE parameter is OPTIONAL, used to identify the value type - (data type) and format of the value. The use of these predefined - formats is encouraged even if the value parameter is not explicitly - used. By defining a standard set of value types and their formats, - existing parsing and processing code can be leveraged. The - - - - - -Perreault Standards Track [Page 16] - -RFC 6350 vCard August 2011 - - - predefined data type values MUST NOT be repeated in COMMA-separated - value lists except within the N, NICKNAME, ADR, and CATEGORIES - properties. - - ABNF: - - value-param = "VALUE=" value-type - - value-type = "text" - / "uri" - / "date" - / "time" - / "date-time" - / "date-and-or-time" - / "timestamp" - / "boolean" - / "integer" - / "float" - / "utc-offset" - / "language-tag" - / iana-token ; registered as described in section 12 - / x-name - -5.3. PREF - - The PREF parameter is OPTIONAL and is used to indicate that the - corresponding instance of a property is preferred by the vCard - author. Its value MUST be an integer between 1 and 100 that - quantifies the level of preference. Lower values correspond to a - higher level of preference, with 1 being most preferred. - - When the parameter is absent, the default MUST be to interpret the - property instance as being least preferred. - - Note that the value of this parameter is to be interpreted only in - relation to values assigned to other instances of the same property - in the same vCard. A given value, or the absence of a value, MUST - NOT be interpreted on its own. - - This parameter MAY be applied to any property that allows multiple - instances. - - ABNF: - - pref-param = "PREF=" (1*2DIGIT / "100") - ; An integer between 1 and 100. - - - - - -Perreault Standards Track [Page 17] - -RFC 6350 vCard August 2011 - - -5.4. ALTID - - The ALTID parameter is used to "tag" property instances as being - alternative representations of the same logical property. For - example, translations of a property in multiple languages generates - multiple property instances having different LANGUAGE (Section 5.1) - parameter that are tagged with the same ALTID value. - - This parameter's value is treated as an opaque string. Its sole - purpose is to be compared for equality against other ALTID parameter - values. - - Two property instances are considered alternative representations of - the same logical property if and only if their names as well as the - value of their ALTID parameters are identical. Property instances - without the ALTID parameter MUST NOT be considered an alternative - representation of any other property instance. Values for the ALTID - parameter are not globally unique: they MAY be reused for different - property names. - - Property instances having the same ALTID parameter value count as 1 - toward cardinality. Therefore, since N (Section 6.2.2) has - cardinality *1 and TITLE (Section 6.6.1) has cardinality *, these - three examples would be legal: - - N;ALTID=1;LANGUAGE=jp:;;;; - N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; - ( denotes a UTF8-encoded Unicode character.) - - TITLE;ALTID=1;LANGUAGE=fr:Patron - TITLE;ALTID=1;LANGUAGE=en:Boss - - TITLE;ALTID=1;LANGUAGE=fr:Patron - TITLE;ALTID=1;LANGUAGE=en:Boss - TITLE;ALTID=2;LANGUAGE=en:Chief vCard Evangelist - - while this one would not: - - N;ALTID=1;LANGUAGE=jp:;;;; - N:Yamada;Taro;;; - (Two instances of the N property.) - - and these three would be legal but questionable: - - TITLE;ALTID=1;LANGUAGE=fr:Patron - TITLE;ALTID=2;LANGUAGE=en:Boss - (Should probably have the same ALTID value.) - - - - -Perreault Standards Track [Page 18] - -RFC 6350 vCard August 2011 - - - TITLE;ALTID=1;LANGUAGE=fr:Patron - TITLE:LANGUAGE=en:Boss - (Second line should probably have ALTID=1.) - - N;ALTID=1;LANGUAGE=jp:;;;; - N;ALTID=1;LANGUAGE=en:Yamada;Taro;;; - N;ALTID=1;LANGUAGE=en:Smith;John;;; - (The last line should probably have ALTID=2. But that would be - illegal because N has cardinality *1.) - - The ALTID property MAY also be used in may contexts other than with - the LANGUAGE parameter. Here's an example with two representations - of the same photo in different file formats: - - PHOTO;ALTID=1:data:image/jpeg;base64,... - PHOTO;ALTID=1;data:image/jp2;base64,... - - ABNF: - - altid-param = "ALTID=" param-value - -5.5. PID - - The PID parameter is used to identify a specific property among - multiple instances. It plays a role analogous to the UID property - (Section 6.7.6) on a per-property instead of per-vCard basis. It MAY - appear more than once in a given property. It MUST NOT appear on - properties that may have only one instance per vCard. Its value is - either a single small positive integer or a pair of small positive - integers separated by a dot. Multiple values may be encoded in a - single PID parameter by separating the values with a comma ",". See - Section 7 for more details on its usage. - - ABNF: - - pid-param = "PID=" pid-value *("," pid-value) - pid-value = 1*DIGIT ["." 1*DIGIT] - -5.6. TYPE - - The TYPE parameter has multiple, different uses. In general, it is a - way of specifying class characteristics of the associated property. - Most of the time, its value is a comma-separated subset of a - predefined enumeration. In this document, the following properties - make use of this parameter: FN, NICKNAME, PHOTO, ADR, TEL, EMAIL, - IMPP, LANG, TZ, GEO, TITLE, ROLE, LOGO, ORG, RELATED, CATEGORIES, - - - - - -Perreault Standards Track [Page 19] - -RFC 6350 vCard August 2011 - - - NOTE, SOUND, URL, KEY, FBURL, CALADRURI, and CALURI. The TYPE - parameter MUST NOT be applied on other properties defined in this - document. - - The "work" and "home" values act like tags. The "work" value implies - that the property is related to an individual's work place, while the - "home" value implies that the property is related to an individual's - personal life. When neither "work" nor "home" is present, it is - implied that the property is related to both an individual's work - place and personal life in the case that the KIND property's value is - "individual", or to none in other cases. - - ABNF: - - type-param = "TYPE=" type-value *("," type-value) - - type-value = "work" / "home" / type-param-tel - / type-param-related / iana-token / x-name - ; This is further defined in individual property sections. - -5.7. MEDIATYPE - - The MEDIATYPE parameter is used with properties whose value is a URI. - Its use is OPTIONAL. It provides a hint to the vCard consumer - application about the media type [RFC2046] of the resource identified - by the URI. Some URI schemes do not need this parameter. For - example, the "data" scheme allows the media type to be explicitly - indicated as part of the URI [RFC2397]. Another scheme, "http", - provides the media type as part of the URI resolution process, with - the Content-Type HTTP header [RFC2616]. The MEDIATYPE parameter is - intended to be used with URI schemes that do not provide such - functionality (e.g., "ftp" [RFC1738]). - - ABNF: - - mediatype-param = "MEDIATYPE=" mediatype - mediatype = type-name "/" subtype-name *( ";" attribute "=" value ) - ; "attribute" and "value" are from [RFC2045] - ; "type-name" and "subtype-name" are from [RFC4288] - -5.8. CALSCALE - - The CALSCALE parameter is identical to the CALSCALE property in - iCalendar (see [RFC5545], Section 3.7.1). It is used to define the - calendar system in which a date or date-time value is expressed. The - only value specified by iCalendar is "gregorian", which stands for - the Gregorian system. It is the default when the parameter is - absent. Additional values may be defined in extension documents and - - - -Perreault Standards Track [Page 20] - -RFC 6350 vCard August 2011 - - - registered with IANA (see Section 10.3.4). A vCard implementation - MUST ignore properties with a CALSCALE parameter value that it does - not understand. - - ABNF: - - calscale-param = "CALSCALE=" calscale-value - - calscale-value = "gregorian" / iana-token / x-name - -5.9. SORT-AS - - The "sort-as" parameter is used to specify the string to be used for - national-language-specific sorting. Without this information, - sorting algorithms could incorrectly sort this vCard within a - sequence of sorted vCards. When this property is present in a vCard, - then the given strings are used for sorting the vCard. - - This parameter's value is a comma-separated list that MUST have as - many or fewer elements as the corresponding property value has - components. This parameter's value is case-sensitive. - - ABNF: - - sort-as-param = "SORT-AS=" sort-as-value - - sort-as-value = param-value *("," param-value) - - Examples: For the case of surname and given name sorting, the - following examples define common sort string usage with the N - property. - - FN:Rene van der Harten - N;SORT-AS="Harten,Rene":van der Harten;Rene,J.;Sir;R.D.O.N. - - FN:Robert Pau Shou Chang - N;SORT-AS="Pau Shou Chang,Robert":Shou Chang;Robert,Pau;; - - FN:Osamu Koura - N;SORT-AS="Koura,Osamu":Koura;Osamu;; - - FN:Oscar del Pozo - N;SORT-AS="Pozo,Oscar":del Pozo Triscon;Oscar;; - - FN:Chistine d'Aboville - N;SORT-AS="Aboville,Christine":d'Aboville;Christine;; - - - - - -Perreault Standards Track [Page 21] - -RFC 6350 vCard August 2011 - - - FN:H. James de Mann - N;SORT-AS="Mann,James":de Mann;Henry,James;; - - If sorted by surname, the results would be: - - Christine d'Aboville - Rene van der Harten - Osamu Koura - H. James de Mann - Robert Pau Shou Chang - Oscar del Pozo - - If sorted by given name, the results would be: - - Christine d'Aboville - H. James de Mann - Osamu Koura - Oscar del Pozo - Rene van der Harten - Robert Pau Shou Chang - -5.10. GEO - - The GEO parameter can be used to indicate global positioning - information that is specific to an address. Its value is the same as - that of the GEO property (see Section 6.5.2). - - ABNF: - - geo-parameter = "GEO=" DQUOTE URI DQUOTE - -5.11. TZ - - The TZ parameter can be used to indicate time zone information that - is specific to an address. Its value is the same as that of the TZ - property. - - ABNF: - - tz-parameter = "TZ=" (param-value / DQUOTE URI DQUOTE) - - - - - - - - - - - -Perreault Standards Track [Page 22] - -RFC 6350 vCard August 2011 - - -6. vCard Properties - - What follows is an enumeration of the standard vCard properties. - -6.1. General Properties - -6.1.1. BEGIN - - Purpose: To denote the beginning of a syntactic entity within a - text/vcard content-type. - - Value type: text - - Cardinality: 1 - - Special notes: The content entity MUST begin with the BEGIN property - with a value of "VCARD". The value is case-insensitive. - - The BEGIN property is used in conjunction with the END property to - delimit an entity containing a related set of properties within a - text/vcard content-type. This construct can be used instead of - including multiple vCards as body parts inside of a multipart/ - alternative MIME message. It is provided for applications that - wish to define content that can contain multiple entities within - the same text/vcard content-type or to define content that can be - identifiable outside of a MIME environment. - - ABNF: - - BEGIN-param = 0" " ; no parameter allowed - BEGIN-value = "VCARD" - - Example: - - BEGIN:VCARD - -6.1.2. END - - Purpose: To denote the end of a syntactic entity within a text/vcard - content-type. - - Value type: text - - Cardinality: 1 - - Special notes: The content entity MUST end with the END type with a - value of "VCARD". The value is case-insensitive. - - - - -Perreault Standards Track [Page 23] - -RFC 6350 vCard August 2011 - - - The END property is used in conjunction with the BEGIN property to - delimit an entity containing a related set of properties within a - text/vcard content-type. This construct can be used instead of or - in addition to wrapping separate sets of information inside - additional MIME headers. It is provided for applications that - wish to define content that can contain multiple entities within - the same text/vcard content-type or to define content that can be - identifiable outside of a MIME environment. - - ABNF: - - END-param = 0" " ; no parameter allowed - END-value = "VCARD" - - Example: - - END:VCARD - -6.1.3. SOURCE - - Purpose: To identify the source of directory information contained - in the content type. - - Value type: uri - - Cardinality: * - - Special notes: The SOURCE property is used to provide the means by - which applications knowledgable 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 [RFC3986] - 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. - - ABNF: - - SOURCE-param = "VALUE=uri" / pid-param / pref-param / altid-param - / mediatype-param / any-param - SOURCE-value = URI - - Examples: - - SOURCE:ldap://ldap.example.com/cn=Babs%20Jensen,%20o=Babsco,%20c=US - - - - - -Perreault Standards Track [Page 24] - -RFC 6350 vCard August 2011 - - - SOURCE:http://directory.example.com/addressbooks/jdoe/ - Jean%20Dupont.vcf - -6.1.4. KIND - - Purpose: To specify the kind of object the vCard represents. - - Value type: A single text value. - - Cardinality: *1 - - Special notes: The value may be one of the following: - - "individual" for a vCard representing a single person or entity. - This is the default kind of vCard. - - "group" for a vCard representing a group of persons or entities. - The group's member entities can be other vCards or other types - of entities, such as email addresses or web sites. A group - vCard will usually contain MEMBER properties to specify the - members of the group, but it is not required to. A group vCard - without MEMBER properties can be considered an abstract - grouping, or one whose members are known empirically (perhaps - "IETF Participants" or "Republican U.S. Senators"). - - All properties in a group vCard apply to the group as a whole, - and not to any particular MEMBER. For example, an EMAIL - property might specify the address of a mailing list associated - with the group, and an IMPP property might refer to a group - chat room. - - "org" for a vCard representing an organization. An organization - vCard will not (in fact, MUST NOT) contain MEMBER properties, - and so these are something of a cross between "individual" and - "group". An organization is a single entity, but not a person. - It might represent a business or government, a department or - division within a business or government, a club, an - association, or the like. - - All properties in an organization vCard apply to the - organization as a whole, as is the case with a group vCard. - For example, an EMAIL property might specify the address of a - contact point for the organization. - - - - - - - - -Perreault Standards Track [Page 25] - -RFC 6350 vCard August 2011 - - - "location" for a named geographical place. A location vCard will - usually contain a GEO property, but it is not required to. A - location vCard without a GEO property can be considered an - abstract location, or one whose definition is known empirically - (perhaps "New England" or "The Seashore"). - - All properties in a location vCard apply to the location - itself, and not with any entity that might exist at that - location. For example, in a vCard for an office building, an - ADR property might give the mailing address for the building, - and a TEL property might specify the telephone number of the - receptionist. - - An x-name. vCards MAY include private or experimental values for - KIND. Remember that x-name values are not intended for general - use and are unlikely to interoperate. - - An iana-token. Additional values may be registered with IANA (see - Section 10.3.4). A new value's specification document MUST - specify which properties make sense for that new kind of vCard - and which do not. - - Implementations MUST support the specific string values defined - above. If this property is absent, "individual" MUST be assumed - as the default. If this property is present but the - implementation does not understand its value (the value is an - x-name or iana-token that the implementation does not support), - the implementation SHOULD act in a neutral way, which usually - means treating the vCard as though its kind were "individual". - The presence of MEMBER properties MAY, however, be taken as an - indication that the unknown kind is an extension of "group". - - Clients often need to visually distinguish contacts based on what - they represent, and the KIND property provides a direct way for - them to do so. For example, when displaying contacts in a list, - an icon could be displayed next to each one, using distinctive - icons for the different kinds; a client might use an outline of a - single person to represent an "individual", an outline of multiple - people to represent a "group", and so on. Alternatively, or in - addition, a client might choose to segregate different kinds of - vCards to different panes, tabs, or selections in the user - interface. - - Some clients might also make functional distinctions among the - kinds, ignoring "location" vCards for some purposes and - considering only "location" vCards for others. - - - - - -Perreault Standards Track [Page 26] - -RFC 6350 vCard August 2011 - - - When designing those sorts of visual and functional distinctions, - client implementations have to decide how to fit unsupported kinds - into the scheme. What icon is used for them? The one for - "individual"? A unique one, such as an icon of a question mark? - Which tab do they go into? It is beyond the scope of this - specification to answer these questions, but these are things - implementers need to consider. - - ABNF: - - KIND-param = "VALUE=text" / any-param - KIND-value = "individual" / "group" / "org" / "location" - / iana-token / x-name - - Example: - - This represents someone named Jane Doe working in the marketing - department of the North American division of ABC Inc. - - 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. - - BEGIN:VCARD - VERSION:4.0 - KIND:org - FN:ABC Marketing - ORG:ABC\, Inc.;North American Division;Marketing - END:VCARD - -6.1.5. XML - - Purpose: To include extended XML-encoded vCard data in a plain - vCard. - - Value type: A single text value. - - Cardinality: * - - Special notes: The content of this property is a single XML 1.0 - [W3C.REC-xml-20081126] element whose namespace MUST be explicitly - specified using the xmlns attribute and MUST NOT be the vCard 4 - - - -Perreault Standards Track [Page 27] - -RFC 6350 vCard August 2011 - - - namespace ("urn:ietf:params:xml:ns:vcard-4.0"). (This implies - that it cannot duplicate a standard vCard property.) The element - is to be interpreted as if it was contained in a element, - as defined in [RFC6351]. - - The fragment is subject to normal line folding and escaping, i.e., - replace all backslashes with "\\", then replace all newlines with - "\n", then fold long lines. - - Support for this property is OPTIONAL, but implementations of this - specification MUST preserve instances of this property when - propagating vCards. - - See [RFC6351] for more information on the intended use of this - property. - - ABNF: - - XML-param = "VALUE=text" / altid-param - XML-value = text - -6.2. Identification Properties - - These types are used to capture information associated with the - identification and naming of the entity associated with the vCard. - -6.2.1. FN - - Purpose: To specify the formatted text corresponding to the name of - the object the vCard represents. - - Value type: A single text value. - - Cardinality: 1* - - Special notes: This property is based on the semantics of the X.520 - Common Name attribute [CCITT.X520.1988]. The property MUST be - present in the vCard object. - - ABNF: - - FN-param = "VALUE=text" / type-param / language-param / altid-param - / pid-param / pref-param / any-param - FN-value = text - - Example: - - FN:Mr. John Q. Public\, Esq. - - - -Perreault Standards Track [Page 28] - -RFC 6350 vCard August 2011 - - -6.2.2. N - - Purpose: To specify the components of the name of the object the - vCard represents. - - Value type: A single structured text value. Each component can have - multiple values. - - Cardinality: *1 - - Special note: The structured property value corresponds, in - sequence, to the Family Names (also known as surnames), Given - Names, Additional Names, Honorific Prefixes, and Honorific - Suffixes. The text components are separated by the SEMICOLON - character (U+003B). Individual text components can include - multiple text values separated by the COMMA character (U+002C). - This property is based on the semantics of the X.520 individual - name attributes [CCITT.X520.1988]. The property SHOULD be present - in the vCard object when the name of the object the vCard - represents follows the X.520 model. - - The SORT-AS parameter MAY be applied to this property. - - ABNF: - - N-param = "VALUE=text" / sort-as-param / language-param - / altid-param / any-param - N-value = list-component 4(";" list-component) - - Examples: - - N:Public;John;Quinlan;Mr.;Esq. - - N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P. - -6.2.3. NICKNAME - - Purpose: To specify the text corresponding to the nickname of the - object the vCard represents. - - Value type: One or more text values separated by a COMMA character - (U+002C). - - Cardinality: * - - - - - - - -Perreault Standards Track [Page 29] - -RFC 6350 vCard August 2011 - - - Special note: The nickname is the descriptive name given instead of - or in addition to the one belonging to the object the vCard - represents. It can also be used to specify a familiar form of a - proper name specified by the FN or N properties. - - ABNF: - - NICKNAME-param = "VALUE=text" / type-param / language-param - / altid-param / pid-param / pref-param / any-param - NICKNAME-value = text-list - - Examples: - - NICKNAME:Robbie - - NICKNAME:Jim,Jimmie - - NICKNAME;TYPE=work:Boss - -6.2.4. PHOTO - - Purpose: To specify an image or photograph information that - annotates some aspect of the object the vCard represents. - - Value type: A single URI. - - Cardinality: * - - ABNF: - - PHOTO-param = "VALUE=uri" / altid-param / type-param - / mediatype-param / pref-param / pid-param / any-param - PHOTO-value = URI - - Examples: - - PHOTO:http://www.example.com/pub/photos/jqpublic.gif - - PHOTO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhv - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...remainder of base64-encoded data...> - -6.2.5. BDAY - - Purpose: To specify the birth date of the object the vCard - represents. - - - - -Perreault Standards Track [Page 30] - -RFC 6350 vCard August 2011 - - - Value type: The default is a single date-and-or-time value. It can - also be reset to a single text value. - - Cardinality: *1 - - ABNF: - - BDAY-param = BDAY-param-date / BDAY-param-text - BDAY-value = date-and-or-time / text - ; Value and parameter MUST match. - - BDAY-param-date = "VALUE=date-and-or-time" - BDAY-param-text = "VALUE=text" / language-param - - BDAY-param =/ altid-param / calscale-param / any-param - ; calscale-param can only be present when BDAY-value is - ; date-and-or-time and actually contains a date or date-time. - - Examples: - - BDAY:19960415 - BDAY:--0415 - BDAY;19531015T231000Z - BDAY;VALUE=text:circa 1800 - -6.2.6. ANNIVERSARY - - Purpose: The date of marriage, or equivalent, of the object the - vCard represents. - - Value type: The default is a single date-and-or-time value. It can - also be reset to a single text value. - - Cardinality: *1 - - ABNF: - - ANNIVERSARY-param = "VALUE=" ("date-and-or-time" / "text") - ANNIVERSARY-value = date-and-or-time / text - ; Value and parameter MUST match. - - ANNIVERSARY-param =/ altid-param / calscale-param / any-param - ; calscale-param can only be present when ANNIVERSARY-value is - ; date-and-or-time and actually contains a date or date-time. - - Examples: - - ANNIVERSARY:19960415 - - - -Perreault Standards Track [Page 31] - -RFC 6350 vCard August 2011 - - -6.2.7. GENDER - - Purpose: To specify the components of the sex and gender identity of - the object the vCard represents. - - Value type: A single structured value with two components. Each - component has a single text value. - - Cardinality: *1 - - Special notes: The components correspond, in sequence, to the sex - (biological), and gender identity. Each component is optional. - - Sex component: A single letter. M stands for "male", F stands - for "female", O stands for "other", N stands for "none or not - applicable", U stands for "unknown". - - Gender identity component: Free-form text. - - ABNF: - - GENDER-param = "VALUE=text" / any-param - GENDER-value = sex [";" text] - - sex = "" / "M" / "F" / "O" / "N" / "U" - - Examples: - - GENDER:M - GENDER:F - GENDER:M;Fellow - GENDER:F;grrrl - GENDER:O;intersex - GENDER:;it's complicated - -6.3. Delivery Addressing Properties - - These types are concerned with information related to the delivery - addressing or label for the vCard object. - -6.3.1. ADR - - Purpose: To specify the components of the delivery address for the - vCard object. - - Value type: A single structured text value, separated by the - SEMICOLON character (U+003B). - - - - -Perreault Standards Track [Page 32] - -RFC 6350 vCard August 2011 - - - Cardinality: * - - Special notes: The structured type value consists of a sequence of - address components. The component values MUST be specified in - their corresponding position. The structured type value - corresponds, in sequence, to - the post office box; - the extended address (e.g., apartment or suite number); - the street address; - the locality (e.g., city); - the region (e.g., state or province); - the postal code; - the country name (full name in the language specified in - Section 5.1). - - When a component value is missing, the associated component - separator MUST still be specified. - - Experience with vCard 3 has shown that the first two components - (post office box and extended address) are plagued with many - interoperability issues. To ensure maximal interoperability, - their values SHOULD be empty. - - The text components are separated by the SEMICOLON character - (U+003B). Where it makes semantic sense, individual text - components can include multiple text values (e.g., a "street" - component with multiple lines) separated by the COMMA character - (U+002C). - - The property can include the "PREF" parameter to indicate the - preferred delivery address when more than one address is - specified. - - The GEO and TZ parameters MAY be used with this property. - - The property can also include a "LABEL" parameter to present a - delivery address label for the address. Its value is a plain-text - string representing the formatted address. Newlines are encoded - as \n, as they are for property values. - - ABNF: - - label-param = "LABEL=" param-value - - ADR-param = "VALUE=text" / label-param / language-param - / geo-parameter / tz-parameter / altid-param / pid-param - / pref-param / type-param / any-param - - - - -Perreault Standards Track [Page 33] - -RFC 6350 vCard August 2011 - - - ADR-value = ADR-component-pobox ";" ADR-component-ext ";" - ADR-component-street ";" ADR-component-locality ";" - ADR-component-region ";" ADR-component-code ";" - ADR-component-country - ADR-component-pobox = list-component - ADR-component-ext = list-component - ADR-component-street = list-component - ADR-component-locality = list-component - ADR-component-region = list-component - ADR-component-code = list-component - ADR-component-country = list-component - - Example: In this example, the post office box and the extended - address are absent. - - ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n - Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n - U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A. - -6.4. Communications Properties - - These properties describe information about how to communicate with - the object the vCard represents. - -6.4.1. TEL - - Purpose: To specify the telephone number for telephony communication - with the object the vCard represents. - - Value type: By default, it is a single free-form text value (for - backward compatibility with vCard 3), but it SHOULD be reset to a - URI value. It is expected that the URI scheme will be "tel", as - specified in [RFC3966], but other schemes MAY be used. - - Cardinality: * - - Special notes: This property is based on the X.520 Telephone Number - attribute [CCITT.X520.1988]. - - The property can include the "PREF" parameter to indicate a - preferred-use telephone number. - - The property can include the parameter "TYPE" to specify intended - use for the telephone number. The predefined values for the TYPE - parameter are: - - - - - - -Perreault Standards Track [Page 34] - -RFC 6350 vCard August 2011 - - - +-----------+-------------------------------------------------------+ - | Value | Description | - +-----------+-------------------------------------------------------+ - | text | Indicates that the telephone number supports text | - | | messages (SMS). | - | voice | Indicates a voice telephone number. | - | fax | Indicates a facsimile telephone number. | - | cell | Indicates a cellular or mobile telephone number. | - | video | Indicates a video conferencing telephone number. | - | pager | Indicates a paging device telephone number. | - | textphone | Indicates a telecommunication device for people with | - | | hearing or speech difficulties. | - +-----------+-------------------------------------------------------+ - - The default type is "voice". These type parameter values can be - specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a - value list (e.g., TYPE="text,voice"). The default can be - overridden to another set of values by specifying one or more - alternate values. For example, the default TYPE of "voice" can be - reset to a VOICE and FAX telephone number by the value list - TYPE="voice,fax". - - If this property's value is a URI that can also be used for - instant messaging, the IMPP (Section 6.4.3) property SHOULD be - used in addition to this property. - - ABNF: - - TEL-param = TEL-text-param / TEL-uri-param - TEL-value = TEL-text-value / TEL-uri-value - ; Value and parameter MUST match. - - TEL-text-param = "VALUE=text" - TEL-text-value = text - - TEL-uri-param = "VALUE=uri" / mediatype-param - TEL-uri-value = URI - - TEL-param =/ type-param / pid-param / pref-param / altid-param - / any-param - - type-param-tel = "text" / "voice" / "fax" / "cell" / "video" - / "pager" / "textphone" / iana-token / x-name - ; type-param-tel MUST NOT be used with a property other than TEL. - - - - - - - -Perreault Standards Track [Page 35] - -RFC 6350 vCard August 2011 - - - Example: - - TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555 - TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67 - -6.4.2. EMAIL - - Purpose: To specify the electronic mail address for communication - with the object the vCard represents. - - Value type: A single text value. - - Cardinality: * - - Special notes: The property can include tye "PREF" parameter to - indicate a preferred-use email address when more than one is - specified. - - Even though the value is free-form UTF-8 text, it is likely to be - interpreted by a Mail User Agent (MUA) as an "addr-spec", as - defined in [RFC5322], Section 3.4.1. Readers should also be aware - of the current work toward internationalized email addresses - [RFC5335bis]. - - ABNF: - - EMAIL-param = "VALUE=text" / pid-param / pref-param / type-param - / altid-param / any-param - EMAIL-value = text - - Example: - - EMAIL;TYPE=work:jqpublic@xyz.example.com - - EMAIL;PREF=1:jane_doe@example.com - -6.4.3. IMPP - - Purpose: To specify the URI for instant messaging and presence - protocol communications with the object the vCard represents. - - Value type: A single URI. - - Cardinality: * - - Special notes: The property may include the "PREF" parameter to - indicate that this is a preferred address and has the same - semantics as the "PREF" parameter in a TEL property. - - - -Perreault Standards Track [Page 36] - -RFC 6350 vCard August 2011 - - - If this property's value is a URI that can be used for voice - and/or video, the TEL property (Section 6.4.1) SHOULD be used in - addition to this property. - - This property is adapted from [RFC4770], which is made obsolete by - this document. - - ABNF: - - IMPP-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - IMPP-value = URI - - Example: - - IMPP;PREF=1:xmpp:alice@example.com - -6.4.4. LANG - - Purpose: To specify the language(s) that may be used for contacting - the entity associated with the vCard. - - Value type: A single language-tag value. - - Cardinality: * - - ABNF: - - LANG-param = "VALUE=language-tag" / pid-param / pref-param - / altid-param / type-param / any-param - LANG-value = Language-Tag - - Example: - - LANG;TYPE=work;PREF=1:en - LANG;TYPE=work;PREF=2:fr - LANG;TYPE=home:fr - -6.5. Geographical Properties - - These properties are concerned with information associated with - geographical positions or regions associated with the object the - vCard represents. - -6.5.1. TZ - - Purpose: To specify information related to the time zone of the - object the vCard represents. - - - -Perreault Standards Track [Page 37] - -RFC 6350 vCard August 2011 - - - Value type: The default is a single text value. It can also be - reset to a single URI or utc-offset value. - - Cardinality: * - - Special notes: It is expected that names from the public-domain - Olson database [TZ-DB] will be used, but this is not a - restriction. See also [IANA-TZ]. - - Efforts are currently being directed at creating a standard URI - scheme for expressing time zone information. Usage of such a - scheme would ensure a high level of interoperability between - implementations that support it. - - Note that utc-offset values SHOULD NOT be used because the UTC - offset varies with time -- not just because of the usual daylight - saving time shifts that occur in may regions, but often entire - regions will "re-base" their overall offset. The actual offset - may be +/- 1 hour (or perhaps a little more) than the one given. - - ABNF: - - TZ-param = "VALUE=" ("text" / "uri" / "utc-offset") - TZ-value = text / URI / utc-offset - ; Value and parameter MUST match. - - TZ-param =/ altid-param / pid-param / pref-param / type-param - / mediatype-param / any-param - - Examples: - - TZ:Raleigh/North America - - TZ;VALUE=utc-offset:-0500 - ; Note: utc-offset format is NOT RECOMMENDED. - -6.5.2. GEO - - Purpose: To specify information related to the global positioning of - the object the vCard represents. - - Value type: A single URI. - - Cardinality: * - - Special notes: The "geo" URI scheme [RFC5870] is particularly well - suited for this property, but other schemes MAY be used. - - - - -Perreault Standards Track [Page 38] - -RFC 6350 vCard August 2011 - - - ABNF: - - GEO-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - GEO-value = URI - - Example: - - GEO:geo:37.386013,-122.082932 - -6.6. Organizational Properties - - These properties are concerned with information associated with - characteristics of the organization or organizational units of the - object that the vCard represents. - -6.6.1. TITLE - - Purpose: To specify the position or job of the object the vCard - represents. - - Value type: A single text value. - - Cardinality: * - - Special notes: This property is based on the X.520 Title attribute - [CCITT.X520.1988]. - - ABNF: - - TITLE-param = "VALUE=text" / language-param / pid-param - / pref-param / altid-param / type-param / any-param - TITLE-value = text - - Example: - - TITLE:Research Scientist - -6.6.2. ROLE - - Purpose: To specify the function or part played in a particular - situation by the object the vCard represents. - - Value type: A single text value. - - Cardinality: * - - - - - -Perreault Standards Track [Page 39] - -RFC 6350 vCard August 2011 - - - Special notes: This property is based on the X.520 Business Category - explanatory attribute [CCITT.X520.1988]. This property is - included as an organizational type to avoid confusion with the - semantics of the TITLE property and incorrect usage of that - property when the semantics of this property is intended. - - ABNF: - - ROLE-param = "VALUE=text" / language-param / pid-param / pref-param - / type-param / altid-param / any-param - ROLE-value = text - - Example: - - ROLE:Project Leader - -6.6.3. LOGO - - Purpose: To specify a graphic image of a logo associated with the - object the vCard represents. - - Value type: A single URI. - - Cardinality: * - - ABNF: - - LOGO-param = "VALUE=uri" / language-param / pid-param / pref-param - / type-param / mediatype-param / altid-param / any-param - LOGO-value = URI - - Examples: - - LOGO:http://www.example.com/pub/logos/abccorp.jpg - - LOGO:data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvc - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...the remainder of base64-encoded data...> - -6.6.4. ORG - - Purpose: To specify the organizational name and units associated - with the vCard. - - Value type: A single structured text value consisting of components - separated by the SEMICOLON character (U+003B). - - - - -Perreault Standards Track [Page 40] - -RFC 6350 vCard August 2011 - - - Cardinality: * - - Special notes: The property is based on the X.520 Organization Name - and Organization Unit attributes [CCITT.X520.1988]. The property - value is a structured type consisting of the organization name, - followed by zero or more levels of organizational unit names. - - The SORT-AS parameter MAY be applied to this property. - - ABNF: - - ORG-param = "VALUE=text" / sort-as-param / language-param - / pid-param / pref-param / altid-param / type-param - / any-param - ORG-value = component *(";" component) - - Example: A property value consisting of an organizational name, - organizational unit #1 name, and organizational unit #2 name. - - ORG:ABC\, Inc.;North American Division;Marketing - -6.6.5. MEMBER - - Purpose: To include a member in the group this vCard represents. - - Value type: A single URI. It MAY refer to something other than a - vCard object. For example, an email distribution list could - employ the "mailto" URI scheme [RFC6068] for efficiency. - - Cardinality: * - - Special notes: This property MUST NOT be present unless the value of - the KIND property is "group". - - ABNF: - - MEMBER-param = "VALUE=uri" / pid-param / pref-param / altid-param - / mediatype-param / any-param - MEMBER-value = URI - - - - - - - - - - - - -Perreault Standards Track [Page 41] - -RFC 6350 vCard August 2011 - - - Examples: - - BEGIN:VCARD - VERSION:4.0 - KIND:group - FN:The Doe family - MEMBER:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af - MEMBER:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 - END:VCARD - BEGIN:VCARD - VERSION:4.0 - FN:John Doe - UID:urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af - END:VCARD - BEGIN:VCARD - VERSION:4.0 - FN:Jane Doe - UID:urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519 - END:VCARD - - BEGIN:VCARD - VERSION:4.0 - KIND:group - FN:Funky distribution list - MEMBER:mailto:subscriber1@example.com - MEMBER:xmpp:subscriber2@example.com - MEMBER:sip:subscriber3@example.com - MEMBER:tel:+1-418-555-5555 - END:VCARD - -6.6.6. RELATED - - Purpose: To specify a relationship between another entity and the - entity represented by this vCard. - - Value type: A single URI. It can also be reset to a single text - value. The text value can be used to specify textual information. - - Cardinality: * - - Special notes: The TYPE parameter MAY be used to characterize the - related entity. It contains a comma-separated list of values that - are registered with IANA as described in Section 10.2. The - registry is pre-populated with the values defined in [xfn]. This - document also specifies two additional values: - - agent: an entity who may sometimes act on behalf of the entity - associated with the vCard. - - - -Perreault Standards Track [Page 42] - -RFC 6350 vCard August 2011 - - - emergency: indicates an emergency contact - - ABNF: - - RELATED-param = RELATED-param-uri / RELATED-param-text - RELATED-value = URI / text - ; Parameter and value MUST match. - - RELATED-param-uri = "VALUE=uri" / mediatype-param - RELATED-param-text = "VALUE=text" / language-param - - RELATED-param =/ pid-param / pref-param / altid-param / type-param - / any-param - - type-param-related = related-type-value *("," related-type-value) - ; type-param-related MUST NOT be used with a property other than - ; RELATED. - - related-type-value = "contact" / "acquaintance" / "friend" / "met" - / "co-worker" / "colleague" / "co-resident" - / "neighbor" / "child" / "parent" - / "sibling" / "spouse" / "kin" / "muse" - / "crush" / "date" / "sweetheart" / "me" - / "agent" / "emergency" - - Examples: - - RELATED;TYPE=friend:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - RELATED;TYPE=contact:http://example.com/directory/jdoe.vcf - RELATED;TYPE=co-worker;VALUE=text:Please contact my assistant Jane - Doe for any inquiries. - -6.7. Explanatory Properties - - These properties are concerned with additional explanations, such as - that related to informational notes or revisions specific to the - vCard. - -6.7.1. CATEGORIES - - Purpose: To specify application category information about the - vCard, also known as "tags". - - Value type: One or more text values separated by a COMMA character - (U+002C). - - Cardinality: * - - - - -Perreault Standards Track [Page 43] - -RFC 6350 vCard August 2011 - - - ABNF: - - CATEGORIES-param = "VALUE=text" / pid-param / pref-param - / type-param / altid-param / any-param - CATEGORIES-value = text-list - - Example: - - CATEGORIES:TRAVEL AGENT - - CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY - -6.7.2. NOTE - - Purpose: To specify supplemental information or a comment that is - associated with the vCard. - - Value type: A single text value. - - Cardinality: * - - Special notes: The property is based on the X.520 Description - attribute [CCITT.X520.1988]. - - ABNF: - - NOTE-param = "VALUE=text" / language-param / pid-param / pref-param - / type-param / altid-param / any-param - NOTE-value = text - - Example: - - NOTE:This fax number is operational 0800 to 1715 - EST\, Mon-Fri. - -6.7.3. PRODID - - Purpose: To specify the identifier for the product that created the - vCard object. - - Type value: A single text value. - - Cardinality: *1 - - Special notes: Implementations SHOULD use a method such as that - specified for Formal Public Identifiers in [ISO9070] or for - Universal Resource Names in [RFC3406] to ensure that the text - value is unique. - - - -Perreault Standards Track [Page 44] - -RFC 6350 vCard August 2011 - - - ABNF: - - PRODID-param = "VALUE=text" / any-param - PRODID-value = text - - Example: - - PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN - -6.7.4. REV - - Purpose: To specify revision information about the current vCard. - - Value type: A single timestamp value. - - Cardinality: *1 - - Special notes: The value distinguishes the current revision of the - information in this vCard for other renditions of the information. - - ABNF: - - REV-param = "VALUE=timestamp" / any-param - REV-value = timestamp - - Example: - - REV:19951031T222710Z - -6.7.5. SOUND - - Purpose: To specify a digital sound content information that - annotates some aspect of the vCard. This property is often used - to specify the proper pronunciation of the name property value of - the vCard. - - Value type: A single URI. - - Cardinality: * - - ABNF: - - SOUND-param = "VALUE=uri" / language-param / pid-param / pref-param - / type-param / mediatype-param / altid-param - / any-param - SOUND-value = URI - - - - - -Perreault Standards Track [Page 45] - -RFC 6350 vCard August 2011 - - - Example: - - SOUND:CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@example.com - - SOUND:data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIh - AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm - ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0 - <...the remainder of base64-encoded data...> - -6.7.6. UID - - Purpose: To specify a value that represents a globally unique - identifier corresponding to the entity associated with the vCard. - - Value type: A single URI value. It MAY also be reset to free-form - text. - - Cardinality: *1 - - Special notes: This property is used to uniquely identify the object - that the vCard represents. The "uuid" URN namespace defined in - [RFC4122] is particularly well suited to this task, but other URI - schemes MAY be used. Free-form text MAY also be used. - - ABNF: - - UID-param = UID-uri-param / UID-text-param - UID-value = UID-uri-value / UID-text-value - ; Value and parameter MUST match. - - UID-uri-param = "VALUE=uri" - UID-uri-value = URI - - UID-text-param = "VALUE=text" - UID-text-value = text - - UID-param =/ any-param - - Example: - - UID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - - - - - - - - - - -Perreault Standards Track [Page 46] - -RFC 6350 vCard August 2011 - - -6.7.7. CLIENTPIDMAP - - Purpose: To give a global meaning to a local PID source identifier. - - Value type: A semicolon-separated pair of values. The first field - is a small integer corresponding to the second field of a PID - parameter instance. The second field is a URI. The "uuid" URN - namespace defined in [RFC4122] is particularly well suited to this - task, but other URI schemes MAY be used. - - Cardinality: * - - Special notes: PID source identifiers (the source identifier is the - second field in a PID parameter instance) are small integers that - only have significance within the scope of a single vCard - instance. Each distinct source identifier present in a vCard MUST - have an associated CLIENTPIDMAP. See Section 7 for more details - on the usage of CLIENTPIDMAP. - - PID source identifiers MUST be strictly positive. Zero is not - allowed. - - As a special exception, the PID parameter MUST NOT be applied to - this property. - - ABNF: - - CLIENTPIDMAP-param = any-param - CLIENTPIDMAP-value = 1*DIGIT ";" URI - - Example: - - TEL;PID=3.1,4.2;VALUE=uri:tel:+1-555-555-5555 - EMAIL;PID=4.1,5.2:jdoe@example.com - CLIENTPIDMAP:1;urn:uuid:3df403f4-5924-4bb7-b077-3c711d9eb34b - CLIENTPIDMAP:2;urn:uuid:d89c9c7a-2e1b-4832-82de-7e992d95faa5 - -6.7.8. URL - - Purpose: To specify a uniform resource locator associated with the - object to which the vCard refers. Examples for individuals - include personal web sites, blogs, and social networking site - identifiers. - - Cardinality: * - - Value type: A single uri value. - - - - -Perreault Standards Track [Page 47] - -RFC 6350 vCard August 2011 - - - ABNF: - - URL-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - URL-value = URI - - Example: - - URL:http://example.org/restaurant.french/~chezchic.html - -6.7.9. VERSION - - Purpose: To specify the version of the vCard specification used to - format this vCard. - - Value type: A single text value. - - Cardinality: 1 - - Special notes: This property MUST be present in the vCard object, - and it must appear immediately after BEGIN:VCARD. The value MUST - be "4.0" if the vCard corresponds to this specification. Note - that earlier versions of vCard allowed this property to be placed - anywhere in the vCard object, or even to be absent. - - ABNF: - - VERSION-param = "VALUE=text" / any-param - VERSION-value = "4.0" - - Example: - - VERSION:4.0 - -6.8. Security Properties - - These properties are concerned with the security of communication - pathways or access to the vCard. - -6.8.1. KEY - - Purpose: To specify a public key or authentication certificate - associated with the object that the vCard represents. - - Value type: A single URI. It can also be reset to a text value. - - Cardinality: * - - - - -Perreault Standards Track [Page 48] - -RFC 6350 vCard August 2011 - - - ABNF: - - KEY-param = KEY-uri-param / KEY-text-param - KEY-value = KEY-uri-value / KEY-text-value - ; Value and parameter MUST match. - - KEY-uri-param = "VALUE=uri" / mediatype-param - KEY-uri-value = URI - - KEY-text-param = "VALUE=text" - KEY-text-value = text - - KEY-param =/ altid-param / pid-param / pref-param / type-param - / any-param - - Examples: - - KEY:http://www.example.com/keys/jdoe.cer - - KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe - - KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE - UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l - <... remainder of base64-encoded data ...> - -6.9. Calendar Properties - - These properties are further specified in [RFC2739]. - -6.9.1. FBURL - - Purpose: To specify the URI for the busy time associated with the - object that the vCard represents. - - Value type: A single URI value. - - Cardinality: * - - Special notes: Where multiple FBURL properties are specified, the - default FBURL property is indicated with the PREF parameter. The - FTP [RFC1738] or HTTP [RFC2616] type of URI points to an iCalendar - [RFC5545] object associated with a snapshot of the next few weeks - or months of busy time data. If the iCalendar object is - represented as a file or document, its file extension should be - ".ifb". - - - - - - -Perreault Standards Track [Page 49] - -RFC 6350 vCard August 2011 - - - ABNF: - - FBURL-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - FBURL-value = URI - - Examples: - - FBURL;PREF=1:http://www.example.com/busy/janedoe - FBURL;MEDIATYPE=text/calendar:ftp://example.com/busy/project-a.ifb - -6.9.2. CALADRURI - - Purpose: To specify the calendar user address [RFC5545] to which a - scheduling request [RFC5546] should be sent for the object - represented by the vCard. - - Value type: A single URI value. - - Cardinality: * - - Special notes: Where multiple CALADRURI properties are specified, - the default CALADRURI property is indicated with the PREF - parameter. - - ABNF: - - CALADRURI-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - CALADRURI-value = URI - - Example: - - CALADRURI;PREF=1:mailto:janedoe@example.com - CALADRURI:http://example.com/calendar/jdoe - -6.9.3. CALURI - - Purpose: To specify the URI for a calendar associated with the - object represented by the vCard. - - Value type: A single URI value. - - Cardinality: * - - Special notes: Where multiple CALURI properties are specified, the - default CALURI property is indicated with the PREF parameter. The - property should contain a URI pointing to an iCalendar [RFC5545] - - - -Perreault Standards Track [Page 50] - -RFC 6350 vCard August 2011 - - - object associated with a snapshot of the user's calendar store. - If the iCalendar object is represented as a file or document, its - file extension should be ".ics". - - ABNF: - - CALURI-param = "VALUE=uri" / pid-param / pref-param / type-param - / mediatype-param / altid-param / any-param - CALURI-value = URI - - Examples: - - CALURI;PREF=1:http://cal.example.com/calA - CALURI;MEDIATYPE=text/calendar:ftp://ftp.example.com/calA.ics - -6.10. Extended Properties and Parameters - - The properties and parameters defined by this document can be - extended. Non-standard, private properties and parameters with a - name starting with "X-" may be defined bilaterally between two - cooperating agents without outside registration or standardization. - -7. Synchronization - - vCard data often needs to be synchronized between devices. In this - context, synchronization is defined as the intelligent merging of two - representations of the same object. vCard 4.0 includes mechanisms to - aid this process. - -7.1. Mechanisms - - Two mechanisms are available: the UID property is used to match - multiple instances of the same vCard, while the PID parameter is used - to match multiple instances of the same property. - - The term "matching" is used here to mean recognizing that two - instances are in fact representations of the same object. For - example, a single vCard that is shared with someone results in two - vCard instances. After they have evolved separately, they still - represent the same object, and therefore may be matched by a - synchronization engine. - -7.1.1. Matching vCard Instances - - vCard instances for which the UID properties (Section 6.7.6) are - equivalent MUST be matched. Equivalence is determined as specified - in [RFC3986], Section 6. - - - - -Perreault Standards Track [Page 51] - -RFC 6350 vCard August 2011 - - - In all other cases, vCard instances MAY be matched at the discretion - of the synchronization engine. - -7.1.2. Matching Property Instances - - Property instances belonging to unmatched vCards MUST NOT be matched. - - Property instances whose name (e.g., EMAIL, TEL, etc.) is not the - same MUST NOT be matched. - - Property instances whose name is CLIENTPIDMAP are handled separately - and MUST NOT be matched. The synchronization MUST ensure that there - is consistency of CLIENTPIDMAPs among matched vCard instances. - - Property instances belonging to matched vCards, whose name is the - same, and whose maximum cardinality is 1, MUST be matched. - - Property instances belonging to matched vCards, whose name is the - same, and whose PID parameters match, MUST be matched. See - Section 7.1.3 for details on PID matching. - - In all other cases, property instances MAY be matched at the - discretion of the synchronization engine. - -7.1.3. PID Matching - - Two PID values for which the first fields are equivalent represent - the same local value. - - Two PID values representing the same local value and for which the - second fields point to CLIENTPIDMAP properties whose second field - URIs are equivalent (as specified in [RFC3986], Section 6) also - represent the same global value. - - PID parameters for which at least one pair of their values represent - the same global value MUST be matched. - - In all other cases, PID parameters MAY be matched at the discretion - of the synchronization engine. - - For example, PID value "5.1", in the first vCard below, and PID value - "5.2", in the second vCard below, represent the same global value. - - - - - - - - - -Perreault Standards Track [Page 52] - -RFC 6350 vCard August 2011 - - - BEGIN:VCARD - VERSION:4.0 - EMAIL;PID=4.2,5.1:jdoe@example.com - CLIENTPIDMAP:1;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 - CLIENTPIDMAP:2;urn:uuid:42bcd5a7-1699-4514-87b4-056edf68e9cc - END:VCARD - - BEGIN:VCARD - VERSION:4.0 - EMAIL;PID=5.1,5.2:john@example.com - CLIENTPIDMAP:1;urn:uuid:0c75c629-6a8d-4d5e-a07f-1bb35846854d - CLIENTPIDMAP:2;urn:uuid:3eef374e-7179-4196-a914-27358c3e6527 - END:VCARD - -7.2. Example - -7.2.1. Creation - - The following simple vCard is first created on a given device. - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN;PID=1.1:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - END:VCARD - - This new vCard is assigned the UID - "urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1" by the creating - device. The FN and EMAIL properties are assigned the same local - value of 1, and this value is given global context by associating it - with "urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556", which - represents the creating device. We are at liberty to reuse the same - local value since instances of different properties will never be - matched. The N property has no PID because it is forbidden by its - maximum cardinality of 1. - -7.2.2. Initial Sharing - - This vCard is shared with a second device. Upon inspecting the UID - property, the second device understands that this is a new vCard - (i.e., unmatched) and thus the synchronization results in a simple - copy. - - - - - - -Perreault Standards Track [Page 53] - -RFC 6350 vCard August 2011 - - -7.2.3. Adding and Sharing a Property - - A new phone number is created on the first device, then the vCard is - shared with the second device. This is what the second device - receives: - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN;PID=1.1:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - END:VCARD - - Upon inspecting the UID property, the second device matches the vCard - it received to the vCard that it already has stored. It then starts - comparing the properties of the two vCards in same-named pairs. - - The FN properties are matched because the PID parameters have the - same global value. Since the property value is the same, no update - takes place. - - The N properties are matched automatically because their maximum - cardinality is 1. Since the property value is the same, no update - takes place. - - The EMAIL properties are matched because the PID parameters have the - same global value. Since the property value is the same, no update - takes place. - - The TEL property in the new vCard is not matched to any in the stored - vCard because no property in the stored vCard has the same name. - Therefore, this property is copied from the new vCard to the stored - vCard. - - The CLIENTPIDMAP property is handled separately by the - synchronization engine. It ensures that it is consistent with the - stored one. If it was not, the results would be up to the - synchronization engine, and thus undefined by this document. - -7.2.4. Simultaneous Editing - - A new email address and a new phone number are added to the vCard on - each of the two devices, and then a new synchronization event - happens. Here are the vCards that are communicated to each other: - - - - -Perreault Standards Track [Page 54] - -RFC 6350 vCard August 2011 - - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN;PID=1.1:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - EMAIL;PID=2.1:boss@example.com - TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 - TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - END:VCARD - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN;PID=1.1:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - EMAIL;PID=2.2:ceo@example.com - TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 - TEL;PID=2.2;VALUE=uri:tel:+1-666-666-6666 - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee - END:VCARD - - On the first device, the same PID source identifier (1) is reused for - the new EMAIL and TEL properties. On the second device, a new source - identifier (2) is generated, and a corresponding CLIENTPIDMAP - property is created. It contains the second device's identifier, - "urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee". - - The new EMAIL properties are unmatched on both sides since the PID - global value is new in both cases. The sync thus results in a copy - on both sides. - - Although the situation appears to be the same for the TEL properties, - in this case, the synchronization engine is particularly smart and - matches the two new TEL properties even though their PID global - values are different. Note that in this case, the rules of - Section 7.1.2 state that two properties MAY be matched at the - discretion of the synchronization engine. Therefore, the two - properties are merged. - - All this results in the following vCard, which is stored on both - devices: - - - - - - -Perreault Standards Track [Page 55] - -RFC 6350 vCard August 2011 - - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - EMAIL;PID=2.1:boss@example.com - EMAIL;PID=2.2:ceo@example.com - TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 - TEL;PID=2.1,2.2;VALUE=uri:tel:+1-666-666-6666 - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - CLIENTPIDMAP:2;urn:uuid:1f762d2b-03c4-4a83-9a03-75ff658a6eee - END:VCARD - -7.2.5. Global Context Simplification - - The two devices finish their synchronization procedure by simplifying - their global contexts. Since they haven't talked to any other - device, the following vCard is for all purposes equivalent to the - above. It is also shorter. - - BEGIN:VCARD - VERSION:4.0 - UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1 - FN:J. Doe - N:Doe;J.;;; - EMAIL;PID=1.1:jdoe@example.com - EMAIL;PID=2.1:boss@example.com - EMAIL;PID=3.1:ceo@example.com - TEL;PID=1.1;VALUE=uri:tel:+1-555-555-5555 - TEL;PID=2.1;VALUE=uri:tel:+1-666-666-6666 - CLIENTPIDMAP:1;urn:uuid:53e374d9-337e-4727-8803-a1e9c14e0556 - END:VCARD - - The details of global context simplification are unspecified by this - document. They are left up to the synchronization engine. This - example is merely intended to illustrate the possibility, which - investigating would be, in the author's opinion, worthwhile. - -8. Example: Author's vCard - - BEGIN:VCARD - VERSION:4.0 - FN:Simon Perreault - N:Perreault;Simon;;;ing. jr,M.Sc. - BDAY:--0203 - ANNIVERSARY:20090808T1430-0500 - GENDER:M - - - -Perreault Standards Track [Page 56] - -RFC 6350 vCard August 2011 - - - LANG;PREF=1:fr - LANG;PREF=2:en - ORG;TYPE=work:Viagenie - ADR;TYPE=work:;Suite D2-630;2875 Laurier; - Quebec;QC;G1V 2M2;Canada - TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102 - TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501 - EMAIL;TYPE=work:simon.perreault@viagenie.ca - GEO;TYPE=work:geo:46.772673,-71.282945 - KEY;TYPE=work;VALUE=uri: - http://www.viagenie.ca/simon.perreault/simon.asc - TZ:-0500 - URL;TYPE=home:http://nomis80.org - END:VCARD - -9. Security Considerations - - o Internet mail is often used to transport vCards and is subject to - many well-known security attacks, including monitoring, replay, - and forgery. Care should be taken by any directory service in - allowing information to leave the scope of the service itself, - where any access controls or confidentiality can no longer be - guaranteed. Applications should also take care to display - directory data in a "safe" environment. - - o vCards can carry cryptographic keys or certificates, as described - in Section 6.8.1. - - o vCards often carry information that can be sensitive (e.g., - birthday, address, and phone information). Although vCards have - no inherent authentication or confidentiality provisions, they can - easily be carried by any security mechanism that transfers MIME - objects to address authentication or confidentiality (e.g., S/MIME - [RFC5751], OpenPGP [RFC4880]). In cases where the confidentiality - or authenticity of information contained in vCard is a concern, - the vCard SHOULD be transported using one of these secure - mechanisms. The KEY property (Section 6.8.1) can be used to - transport the public key used by these mechanisms. - - o The information in a vCard may become out of date. In cases where - the vitality of data is important to an originator of a vCard, the - SOURCE property (Section 6.1.3) SHOULD be specified. In addition, - the "REV" type described in Section 6.7.4 can be specified to - indicate the last time that the vCard data was updated. - - o Many vCard properties may be used to transport URIs. Please refer - to [RFC3986], Section 7, for considerations related to URIs. - - - - -Perreault Standards Track [Page 57] - -RFC 6350 vCard August 2011 - - -10. IANA Considerations - -10.1. Media Type Registration - - IANA has registered the following Media Type (in - ) and marked the text/directory Media Type as - DEPRECATED. - - To: ietf-types@iana.org - - Subject: Registration of media type text/vcard - - Type name: text - - Subtype name: vcard - - Required parameters: none - - Optional parameters: version - - The "version" parameter is to be interpreted identically as the - VERSION vCard property. If this parameter is present, all vCards - in a text/vcard body part MUST have a VERSION property with value - identical to that of this MIME parameter. - - "charset": as defined for text/plain [RFC2046]; encodings other - than UTF-8 [RFC3629] MUST NOT be used. - - Encoding considerations: 8bit - - Security considerations: See Section 9. - - Interoperability considerations: The text/vcard media type is - intended to identify vCard data of any version. There are older - specifications of vCard [RFC2426][vCard21] still in common use. - While these formats are similar, they are not strictly compatible. - In general, it is necessary to inspect the value of the VERSION - property (see Section 6.7.9) for identifying the standard to which - a given vCard object conforms. - - In addition, the following media types are known to have been used - to refer to vCard data. They should be considered deprecated in - favor of text/vcard. - - * text/directory - * text/directory; profile=vcard - * text/x-vcard - - - - -Perreault Standards Track [Page 58] - -RFC 6350 vCard August 2011 - - - Published specification: RFC 6350 - - Applications that use this media type: They are numerous, diverse, - and include mail user agents, instant messaging clients, address - book applications, directory servers, and customer relationship - management software. - - Additional information: - - Magic number(s): - - File extension(s): .vcf .vcard - - Macintosh file type code(s): - - Person & email address to contact for further information: vCard - discussion mailing list - - Intended usage: COMMON - - Restrictions on usage: none - - Author: Simon Perreault - - Change controller: IETF - -10.2. Registering New vCard Elements - - This section defines the process for registering new or modified - vCard elements (i.e., properties, parameters, value data types, and - values) with IANA. - -10.2.1. Registration Procedure - - The IETF has created a mailing list, vcarddav@ietf.org, which can be - used for public discussion of vCard element proposals prior to - registration. Use of the mailing list is strongly encouraged. The - IESG has appointed a designated expert who will monitor the - vcarddav@ietf.org mailing list and review registrations. - - Registration of new vCard elements MUST be reviewed by the designated - expert and published in an RFC. A Standards Track RFC is REQUIRED - for the registration of new value data types that modify existing - properties. A Standards Track RFC is also REQUIRED for registration - of vCard elements that modify vCard elements previously documented in - a Standards Track RFC. - - - - - -Perreault Standards Track [Page 59] - -RFC 6350 vCard August 2011 - - - The registration procedure begins when a completed registration - template, defined in the sections below, is sent to vcarddav@ietf.org - and iana@iana.org. Within two weeks, the designated expert is - expected to tell IANA and the submitter of the registration whether - the registration is approved, approved with minor changes, or - rejected with cause. When a registration is rejected with cause, it - can be re-submitted if the concerns listed in the cause are - addressed. Decisions made by the designated expert can be appealed - to the IESG Applications Area Director, then to the IESG. They - follow the normal appeals procedure for IESG decisions. - - Once the registration procedure concludes successfully, IANA creates - or modifies the corresponding record in the vCard registry. The - completed registration template is discarded. - - An RFC specifying new vCard elements MUST include the completed - registration templates, which MAY be expanded with additional - information. These completed templates are intended to go in the - body of the document, not in the IANA Considerations section. - - Finally, note that there is an XML representation for vCard defined - in [RFC6351]. An XML representation SHOULD be defined for new vCard - elements. - -10.2.2. Vendor Namespace - - The vendor namespace is used for vCard elements associated with - commercially available products. "Vendor" or "producer" are - construed as equivalent and very broadly in this context. - - A registration may be placed in the vendor namespace by anyone who - needs to interchange files associated with the particular product. - However, the registration formally belongs to the vendor or - organization handling the vCard elements in the namespace being - registered. Changes to the specification will be made at their - request, as discussed in subsequent sections. - - vCard elements belonging to the vendor namespace will be - distinguished by the "VND-" prefix. This is followed by an IANA- - registered Private Enterprise Number (PEN), a dash, and a vCard - element designation of the vendor's choosing (e.g., "VND-123456- - MUDPIE"). - - While public exposure and review of vCard elements to be registered - in the vendor namespace are not required, using the vcarddav@ietf.org - mailing list for review is strongly encouraged to improve the quality - of those specifications. Registrations in the vendor namespace may - be submitted directly to the IANA. - - - -Perreault Standards Track [Page 60] - -RFC 6350 vCard August 2011 - - -10.2.3. Registration Template for Properties - - A property is defined by completing the following template. - - Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- - specific property (where NNNN is replaced by the vendor's PEN). - - Property name: The name of the property. - - Purpose: The purpose of the property. Give a short but clear - description. - - Value type: Any of the valid value types for the property value - needs to be specified. The default value type also needs to be - specified. - - Cardinality: See Section 6. - - Property parameters: Any of the valid property parameters for the - property MUST be specified. - - Description: Any special notes about the property, how it is to be - used, etc. - - Format definition: The ABNF for the property definition needs to be - specified. - - Example(s): One or more examples of instances of the property need - to be specified. - -10.2.4. Registration Template for Parameters - - A parameter is defined by completing the following template. - - Namespace: Empty for the global namespace, "VND-NNNN-" for a vendor- - specific property (where NNNN is replaced by the vendor's PEN). - - Parameter name: The name of the parameter. - - Purpose: The purpose of the parameter. Give a short but clear - description. - - Description: Any special notes about the parameter, how it is to be - used, etc. - - Format definition: The ABNF for the parameter definition needs to be - specified. - - - - -Perreault Standards Track [Page 61] - -RFC 6350 vCard August 2011 - - - Example(s): One or more examples of instances of the parameter need - to be specified. - -10.2.5. Registration Template for Value Data Types - - A value data type is defined by completing the following template. - - Value name: The name of the value type. - - Purpose: The purpose of the value type. Give a short but clear - description. - - Description: Any special notes about the value type, how it is to be - used, etc. - - Format definition: The ABNF for the value type definition needs to - be specified. - - Example(s): One or more examples of instances of the value type need - to be specified. - -10.2.6. Registration Template for Values - - A value is defined by completing the following template. - - Value: The value literal. - - Purpose: The purpose of the value. Give a short but clear - description. - - Conformance: The vCard properties and/or parameters that can take - this value needs to be specified. - - Example(s): One or more examples of instances of the value need to - be specified. - - The following is a fictitious example of a registration of a vCard - value: - - Value: supervisor - - Purpose: It means that the related entity is the direct hierarchical - superior (i.e., supervisor or manager) of the entity this vCard - represents. - - Conformance: This value can be used with the "TYPE" parameter - applied on the "RELATED" property. - - - - -Perreault Standards Track [Page 62] - -RFC 6350 vCard August 2011 - - - Example(s): - - RELATED;TYPE=supervisor:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - -10.3. Initial vCard Elements Registries - - The IANA has created and will maintain the following registries for - vCard elements with pointers to appropriate reference documents. The - registries are grouped together under the heading "vCard Elements". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Perreault Standards Track [Page 63] - -RFC 6350 vCard August 2011 - - -10.3.1. Properties Registry - - The following table has been used to initialize the properties - registry. - - +-----------+--------------+-------------------------+ - | Namespace | Property | Reference | - +-----------+--------------+-------------------------+ - | | SOURCE | RFC 6350, Section 6.1.3 | - | | KIND | RFC 6350, Section 6.1.4 | - | | XML | RFC 6350, Section 6.1.5 | - | | FN | RFC 6350, Section 6.2.1 | - | | N | RFC 6350, Section 6.2.2 | - | | NICKNAME | RFC 6350, Section 6.2.3 | - | | PHOTO | RFC 6350, Section 6.2.4 | - | | BDAY | RFC 6350, Section 6.2.5 | - | | ANNIVERSARY | RFC 6350, Section 6.2.6 | - | | GENDER | RFC 6350, Section 6.2.7 | - | | ADR | RFC 6350, Section 6.3.1 | - | | TEL | RFC 6350, Section 6.4.1 | - | | EMAIL | RFC 6350, Section 6.4.2 | - | | IMPP | RFC 6350, Section 6.4.3 | - | | LANG | RFC 6350, Section 6.4.4 | - | | TZ | RFC 6350, Section 6.5.1 | - | | GEO | RFC 6350, Section 6.5.2 | - | | TITLE | RFC 6350, Section 6.6.1 | - | | ROLE | RFC 6350, Section 6.6.2 | - | | LOGO | RFC 6350, Section 6.6.3 | - | | ORG | RFC 6350, Section 6.6.4 | - | | MEMBER | RFC 6350, Section 6.6.5 | - | | RELATED | RFC 6350, Section 6.6.6 | - | | CATEGORIES | RFC 6350, Section 6.7.1 | - | | NOTE | RFC 6350, Section 6.7.2 | - | | PRODID | RFC 6350, Section 6.7.3 | - | | REV | RFC 6350, Section 6.7.4 | - | | SOUND | RFC 6350, Section 6.7.5 | - | | UID | RFC 6350, Section 6.7.6 | - | | CLIENTPIDMAP | RFC 6350, Section 6.7.7 | - | | URL | RFC 6350, Section 6.7.8 | - | | VERSION | RFC 6350, Section 6.7.9 | - | | KEY | RFC 6350, Section 6.8.1 | - | | FBURL | RFC 6350, Section 6.9.1 | - | | CALADRURI | RFC 6350, Section 6.9.2 | - | | CALURI | RFC 6350, Section 6.9.3 | - +-----------+--------------+-------------------------+ - - - - - - -Perreault Standards Track [Page 64] - -RFC 6350 vCard August 2011 - - -10.3.2. Parameters Registry - - The following table has been used to initialize the parameters - registry. - - +-----------+-----------+------------------------+ - | Namespace | Parameter | Reference | - +-----------+-----------+------------------------+ - | | LANGUAGE | RFC 6350, Section 5.1 | - | | VALUE | RFC 6350, Section 5.2 | - | | PREF | RFC 6350, Section 5.3 | - | | ALTID | RFC 6350, Section 5.4 | - | | PID | RFC 6350, Section 5.5 | - | | TYPE | RFC 6350, Section 5.6 | - | | MEDIATYPE | RFC 6350, Section 5.7 | - | | CALSCALE | RFC 6350, Section 5.8 | - | | SORT-AS | RFC 6350, Section 5.9 | - | | GEO | RFC 6350, Section 5.10 | - | | TZ | RFC 6350, Section 5.11 | - +-----------+-----------+------------------------+ - -10.3.3. Value Data Types Registry - - The following table has been used to initialize the parameters - registry. - - +------------------+-------------------------+ - | Value Data Type | Reference | - +------------------+-------------------------+ - | BOOLEAN | RFC 6350, Section 4.4 | - | DATE | RFC 6350, Section 4.3.1 | - | DATE-AND-OR-TIME | RFC 6350, Section 4.3.4 | - | DATE-TIME | RFC 6350, Section 4.3.3 | - | FLOAT | RFC 6350, Section 4.6 | - | INTEGER | RFC 6350, Section 4.5 | - | LANGUAGE-TAG | RFC 6350, Section 4.8 | - | TEXT | RFC 6350, Section 4.1 | - | TIME | RFC 6350, Section 4.3.2 | - | TIMESTAMP | RFC 6350, Section 4.3.5 | - | URI | RFC 6350, Section 4.2 | - | UTC-OFFSET | RFC 6350, Section 4.7 | - +------------------+-------------------------+ - - - - - - - - - -Perreault Standards Track [Page 65] - -RFC 6350 vCard August 2011 - - -10.3.4. Values Registries - - Separate tables are used for property and parameter values. - - The following table is to be used to initialize the property values - registry. - - +----------+------------+-------------------------+ - | Property | Value | Reference | - +----------+------------+-------------------------+ - | BEGIN | VCARD | RFC 6350, Section 6.1.1 | - | END | VCARD | RFC 6350, Section 6.1.2 | - | KIND | individual | RFC 6350, Section 6.1.4 | - | KIND | group | RFC 6350, Section 6.1.4 | - | KIND | org | RFC 6350, Section 6.1.4 | - | KIND | location | RFC 6350, Section 6.1.4 | - +----------+------------+-------------------------+ - - The following table has been used to initialize the parameter values - registry. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Perreault Standards Track [Page 66] - -RFC 6350 vCard August 2011 - - - +------------------------+-----------+--------------+---------------+ - | Property | Parameter | Value | Reference | - +------------------------+-----------+--------------+---------------+ - | FN, NICKNAME, PHOTO, | TYPE | work | RFC 6350, | - | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | - | LANG, TZ, GEO, TITLE, | | | | - | ROLE, LOGO, ORG, | | | | - | RELATED, CATEGORIES, | | | | - | NOTE, SOUND, URL, KEY, | | | | - | FBURL, CALADRURI, and | | | | - | CALURI | | | | - | FN, NICKNAME, PHOTO, | TYPE | home | RFC 6350, | - | ADR, TEL, EMAIL, IMPP, | | | Section 5.6 | - | LANG, TZ, GEO, TITLE, | | | | - | ROLE, LOGO, ORG, | | | | - | RELATED, CATEGORIES, | | | | - | NOTE, SOUND, URL, KEY, | | | | - | FBURL, CALADRURI, and | | | | - | CALURI | | | | - | TEL | TYPE | text | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | voice | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | fax | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | cell | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | video | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | pager | RFC 6350, | - | | | | Section 6.4.1 | - | TEL | TYPE | textphone | RFC 6350, | - | | | | Section 6.4.1 | - | BDAY, ANNIVERSARY | CALSCALE | gregorian | RFC 6350, | - | | | | Section 5.8 | - | RELATED | TYPE | contact | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | acquaintance | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | friend | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | met | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - - - - -Perreault Standards Track [Page 67] - -RFC 6350 vCard August 2011 - - - | RELATED | TYPE | co-worker | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | colleague | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | co-resident | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | neighbor | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | child | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | parent | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | sibling | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | spouse | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | kin | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | muse | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | crush | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | date | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | sweetheart | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | me | RFC 6350, | - | | | | Section 6.6.6 | - | | | | and [xfn] | - | RELATED | TYPE | agent | RFC 6350, | - | | | | Section 6.6.6 | - | RELATED | TYPE | emergency | RFC 6350, | - | | | | Section 6.6.6 | - +------------------------+-----------+--------------+---------------+ - - - - -Perreault Standards Track [Page 68] - -RFC 6350 vCard August 2011 - - -11. Acknowledgments - - The authors would like to thank Tim Howes, Mark Smith, and Frank - Dawson, the original authors of [RFC2425] and [RFC2426], Pete - Resnick, who got this effort started and provided help along the way, - as well as the following individuals who have participated in the - drafting, review, and discussion of this memo: - - Aki Niemi, Andy Mabbett, Alexander Mayrhofer, Alexey Melnikov, Anil - Srivastava, Barry Leiba, Ben Fortuna, Bernard Desruisseaux, Bernie - Hoeneisen, Bjoern Hoehrmann, Caleb Richardson, Chris Bryant, Chris - Newman, Cyrus Daboo, Daisuke Miyakawa, Dan Brickley, Dan Mosedale, - Dany Cauchie, Darryl Champagne, Dave Thewlis, Filip Navara, Florian - Zeitz, Helge Hess, Jari Urpalainen, Javier Godoy, Jean-Luc Schellens, - Joe Hildebrand, Jose Luis Gayosso, Joseph Smarr, Julian Reschke, - Kepeng Li, Kevin Marks, Kevin Wu Won, Kurt Zeilenga, Lisa Dusseault, - Marc Blanchet, Mark Paterson, Markus Lorenz, Michael Haardt, Mike - Douglass, Nick Levinson, Peter K. Sheerin, Peter Mogensen, Peter - Saint-Andre, Renato Iannella, Rohit Khare, Sly Gryphon, Stephane - Bortzmeyer, Tantek Celik, and Zoltan Ordogh. - -12. References - -12.1. Normative References - - [CCITT.X520.1988] - International Telephone and Telegraph Consultative - Committee, "Information Technology - Open Systems - Interconnection - The Directory: Selected Attribute - Types", CCITT Recommendation X.520, November 1988. - - [IEEE.754.2008] - Institute of Electrical and Electronics Engineers, - "Standard for Binary Floating-Point Arithmetic", - IEEE Standard 754, August 2008. - - [ISO.8601.2000] - International Organization for Standardization, "Data - elements and interchange formats - Information interchange - - Representation of dates and times", ISO Standard 8601, - December 2000. - - [ISO.8601.2004] - International Organization for Standardization, "Data - elements and interchange formats - Information interchange - - Representation of dates and times", ISO Standard 8601, - December 2004. - - - - -Perreault Standards Track [Page 69] - -RFC 6350 vCard August 2011 - - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, - November 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar - Attributes for vCard and LDAP", RFC 2739, January 2000. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", - RFC 3966, December 2004. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally - Unique IDentifier (UUID) URN Namespace", RFC 4122, - July 2005. - - [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and - Registration Procedures", BCP 13, RFC 4288, December 2005. - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, January 2008. - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - October 2008. - - [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling - Core Object Specification (iCalendar)", RFC 5545, - September 2009. - - [RFC5546] Daboo, C., "iCalendar Transport-Independent - Interoperability Protocol (iTIP)", RFC 5546, - December 2009. - - [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying - Languages", BCP 47, RFC 5646, September 2009. - - - - -Perreault Standards Track [Page 70] - -RFC 6350 vCard August 2011 - - - [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource - Identifier for Geographic Locations ('geo' URI)", - RFC 5870, June 2010. - - [RFC6351] Perreault, S., "xCard: vCard XML Representation", - RFC 6351, August 2011. - - [W3C.REC-xml-20081126] - Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., - and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth - Edition)", World Wide Web Consortium Recommendation REC- - xml-20081126, November 2008, - . - - [xfn] Celik, T., Mullenweg, M., and E. Meyer, "XFN 1.1 profile", - . - -12.2. Informative References - - [IANA-TZ] Lear, E. and P. Eggert, "IANA Procedures for Maintaining - the Timezone Database", Work in Progress, May 2011. - - [ISO9070] International Organization for Standardization, - "Information Processing - SGML support facilities - - Registration Procedures for Public Text Owner - Identifiers", ISO 9070, April 1991. - - [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform - Resource Locators (URL)", RFC 1738, December 1994. - - [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, - August 1998. - - [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type - for Directory Information", RFC 2425, September 1998. - - [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", - RFC 2426, September 1998. - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, - May 2002. - - - - - - -Perreault Standards Track [Page 71] - -RFC 6350 vCard August 2011 - - - [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, - "Uniform Resource Names (URN) Namespace Definition - Mechanisms", BCP 66, RFC 3406, October 2002. - - [RFC3536] Hoffman, P., "Terminology Used in Internationalization in - the IETF", RFC 3536, May 2003. - - [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for - Instant Messaging (IM)", RFC 4770, January 2007. - - [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. - Thayer, "OpenPGP Message Format", RFC 4880, November 2007. - - [RFC5335bis] - Yang, A. and S. Steele, "Internationalized Email Headers", - Work in Progress, July 2011. - - [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Message - Specification", RFC 5751, January 2010. - - [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' - URI Scheme", RFC 6068, October 2010. - - [TZ-DB] Olson, A., "Time zone code and data", - . - - [vCard21] Internet Mail Consortium, "vCard - The Electronic Business - Card Version 2.1", September 1996. - - - - - - - - - - - - - - - - - - - - - - -Perreault Standards Track [Page 72] - -RFC 6350 vCard August 2011 - - -Appendix A. Differences from RFCs 2425 and 2426 - - This appendix contains a high-level overview of the major changes - that have been made in the vCard specification from RFCs 2425 and - 2426. It is incomplete, as it only lists the most important changes. - -A.1. New Structure - - o [RFC2425] and [RFC2426] have been merged. - - o vCard is now not only a MIME type but a stand-alone format. - - o A proper MIME type registration form has been included. - - o UTF-8 is now the only possible character set. - - o New vCard elements can be registered from IANA. - -A.2. Removed Features - - o The CONTEXT and CHARSET parameters are no more. - - o The NAME, MAILER, LABEL, and CLASS properties are no more. - - o The "intl", "dom", "postal", and "parcel" TYPE parameter values - for the ADR property have been removed. - - o In-line vCards (such as the value of the AGENT property) are no - longer supported. - -A.3. New Properties and Parameters - - o The KIND, GENDER, LANG, ANNIVERSARY, XML, and CLIENTPIDMAP - properties have been added. - - o [RFC2739], which defines the FBURL, CALADRURI, CAPURI, and CALURI - properties, has been merged in. - - o [RFC4770], which defines the IMPP property, has been merged in. - - o The "work" and "home" TYPE parameter values are now applicable to - many more properties. - - o The "pref" value of the TYPE parameter is now a parameter of its - own, with a positive integer value indicating the level of - preference. - - o The ALTID and PID parameters have been added. - - - -Perreault Standards Track [Page 73] - -RFC 6350 vCard August 2011 - - - o The MEDIATYPE parameter has been added and replaces the TYPE - parameter when it was used for indicating the media type of the - property's content. - -Author's Address - - Simon Perreault - Viagenie - 2875 Laurier, suite D2-630 - Quebec, QC G1V 2M2 - Canada - - Phone: +1 418 656 9254 - EMail: simon.perreault@viagenie.ca - URI: http://www.viagenie.ca - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Perreault Standards Track [Page 74] - diff --git a/specifications/contacts/rfc9553.pdf b/specifications/contacts/rfc9553.pdf deleted file mode 100644 index d58949d8..00000000 --- a/specifications/contacts/rfc9553.pdf +++ /dev/null @@ -1,17115 +0,0 @@ -%PDF-1.7 %âãÏÓ -3 0 obj -<>/EmbeddedFiles 1639 0 R>>/Outlines 1788 0 R/OutputIntents 1789 0 R/Pages 1 0 R/Type/Catalog>> -endobj -1637 0 obj -<>stream - - - - - application/pdf - - - Robert Stepanek, Mario Loffredo - - - - - This specification defines a data model and JavaScript Object Notation (JSON) representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable, and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. Two additional specifications define new vCard elements and how to convert between JSContact and vCard. - - - - - RFC 9553: JSContact: A JSON Representation of Contact Data - - - xml2rfc 3.21.0 - 2024-05-07T07:30:35-07:00 - 2024-05-07T07:30:31-07:00 - 2024-05-07T07:30:35-07:00 - WeasyPrint 56.1 - uuid:add3157a-b9ce-11b2-0a00-000000000000 - uuid:adda0949-b9ce-11b2-0a00-690800000000 - default - 1 - - - - converted - uuid:add3157e-b9ce-11b2-0a00-810700000000 - converted to PDF/A-3u - pdfaPilot - 2024-05-07T07:30:35-07:00 - - - - 3 - U - - - - http://ns.adobe.com/pdf/1.3/ - pdf - Adobe PDF Schema - - - - internal - A name object indicating whether the document has been modified to include trapping information - Trapped - Text - - - - - - http://ns.adobe.com/xap/1.0/mm/ - xmpMM - XMP Media Management Schema - - - - internal - UUID based identifier for specific incarnation of a document - InstanceID - URI - - - internal - The common identifier for all versions and renditions of a document. - OriginalDocumentID - URI - - - - - - http://www.aiim.org/pdfa/ns/id/ - pdfaid - PDF/A ID Schema - - - - internal - Part of PDF/A standard - part - Integer - - - internal - Amendment of PDF/A standard - amd - Text - - - internal - Conformance level of PDF/A standard - conformance - Text - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -endstream -endobj -1788 0 obj -<> -endobj -1789 0 obj -[1792 0 R] -endobj -1 0 obj -<> -endobj -6 0 obj -<> -endobj -14 0 obj -<> -endobj -95 0 obj -<> -endobj -187 0 obj -<> -endobj -276 0 obj -<> -endobj -338 0 obj -<> -endobj -358 0 obj -<> -endobj -376 0 obj -<> -endobj -385 0 obj -<> -endobj -397 0 obj -<> -endobj -408 0 obj -<> -endobj -428 0 obj -<> -endobj -453 0 obj -<> -endobj -470 0 obj -<> -endobj -491 0 obj -<> -endobj -513 0 obj -<> -endobj -529 0 obj -<> -endobj -551 0 obj -<> -endobj -570 0 obj -<> -endobj -585 0 obj -<> -endobj -601 0 obj -<> -endobj -616 0 obj -<> -endobj -629 0 obj -<> -endobj -642 0 obj -<> -endobj -651 0 obj -<> -endobj -659 0 obj -<> -endobj -670 0 obj -<> -endobj -677 0 obj -<> -endobj -687 0 obj -<> -endobj -699 0 obj -<> -endobj -710 0 obj -<> -endobj -726 0 obj -<> -endobj -740 0 obj -<> -endobj -752 0 obj -<> -endobj -769 0 obj -<> -endobj -780 0 obj -<> -endobj -792 0 obj -<> -endobj -799 0 obj -<> -endobj -804 0 obj -<> -endobj -814 0 obj -<> -endobj -826 0 obj -<> -endobj -840 0 obj -<> -endobj -855 0 obj -<> -endobj -861 0 obj -<> -endobj -871 0 obj -<> -endobj -880 0 obj -<> -endobj -890 0 obj -<> -endobj -899 0 obj -<> -endobj -912 0 obj -<> -endobj -926 0 obj -<> -endobj -936 0 obj -<> -endobj -952 0 obj -<> -endobj -960 0 obj -<> -endobj -1021 0 obj -<> -endobj -1055 0 obj -<> -endobj -1100 0 obj -<> -endobj -1141 0 obj -<> -endobj -1173 0 obj -<> -endobj -1189 0 obj -<> -endobj -1215 0 obj -<> -endobj -1235 0 obj -<> -endobj -1246 0 obj -<> -endobj -1267 0 obj -<> -endobj -1289 0 obj -<> -endobj -1313 0 obj -<> -endobj -1334 0 obj -<> -endobj -1357 0 obj -<> -endobj -1376 0 obj -<> -endobj -1400 0 obj -<> -endobj -1414 0 obj -<> -endobj -1432 0 obj -<> -endobj -1454 0 obj -<> -endobj -1476 0 obj -<> -endobj -1865 0 obj -<>stream -xœÍ[[sÛÆÞŽûÀ>Ô²åXuì);õMN¼ÞûÅN*K²ÌZ—J¢b3m§Ê‹™¤}ìCz¿³ i$…Lc˜¤@,p¾=—oÏÙ]ŽäHàxNÁHBôÎŒþñqøã{›.Î?Ó—?qæÝÈͽ>øQð–#¢±£Ÿþ9œ Ê?}?|ñ7ÉÅèû é~·H©·2ºî¹žâÀ£e˜·€”I”}˜‰üPºNç“gÆèø¿,¯dñàÒe¿tùúYN´j~=ÁZ:ÿPœË¥óåû–¾ÿ™á~:¸ÔôoTý\ùÍùpa{)ñdcŒ #)W:*üyþqøâÏ'§oOŽF¸žž …´£óëáû§ì̲é.{Ìî³»xÝgÚýîühøê|fËn(¬åÒKkb>Šw{E¡”€.œ³¦Š~QË!Ë·±Èû-»Ó --¹Ó1:7ÒVp¨"8Õˆ"°GlÌžàÕ@ðc7̲ePm)ç¹Õ:W”·‡ï^¿úfœÛc§ì€ ’àÅ£´W\¨®< -·ü¦ÚØ -ÁƒóAËœÆ6€"Ùª¹±S@¬L^c&ZïC9Ž./´TÛÃd -,âÚöš¹`ûì tt‡ÝÆënåþiHÂcòä9빶p”õò¶ªí•—m´ó†4[b:Ë9½UV¯Þ² -É pŒÑ1§±Røµ 0†‡]„Ñn³rÑBXaLÈj Mš¨0̬4†RŒL§›ì€±†¡#RƒfQÊDn‘²PjĨ=NòŒP&Ý,#¬Ü²Æ/—Ù†Éh¼d¥X/š‚rŒÓxa„•Æ­ŒÐ,ªle·B)7í•‘VpÖöCyuœ?|Mûõ634ªÁÿ‘Á4 qÞ/ÌÐØXÁÀ®0°gl-Q`LáZÎÕ“yK€ÍÂÚöös;çvyË&ÔJâÌë 7™P[Š#CÞU­×>Ü.“÷9"õèüƈДyZéfHÛƒì8D.䵇ó…àU\mü0iõŠáuÉ& å~Qóyx0ÖeÈSÞÐØà%¼%8¤8Š\r#=9Œa^‚ÀËÈÚž†°F 'µâÁ¹ýjãç)‚®Ò¹Ù¥`î}„3Äiy„ÝkM®åWøiåi¥$0Ž¹PMjRž¯ØÙôú¿ì$u‚è@ïJ2ãVׄPE”VÖYQMšjÀpêeÆWì/HJß‘N“SíuE£=ÐÄh|5+«As™±dˆü®ˆCø°NÙ;ÆëˆÌ}£+2+<¸£\ÌGö¥ƒNž¶Íîwàù!ª@ß®…vfÌ`^Uv…á´àRé¶0ž0žî\=-N5­‘½@ßÂû=hàK¼ßªÚ6‚ñBTw´€õ»¹Üy‘>À‘D.K2‚Æ ­$½ËOØ_ÁöÐù[X»žè±òõÂMDÍbf‚x¹À·ô~„–E¯qvkÖ®¢±M•|£QRhÓ -öïûô—òüÇf¡:8„®ˆgÙÛĵ¶;Íj¡x4xwùPD¢Ùó_$ uÆxxd^Õ⬖`¿E°Ð¸yh×ÀsÎËî¥üaú”½Oj;…‹q‰>Éq.ðùJ}œ¾à†}¼wfcŒ´­T‹nAߧO• -·ɳ©´ÎCµ–\ZÔ2_tâ]Ø †{Áf`%PµPËç 5ÜY¥ÏÓû5j§¸ÑoJ| ò9ç–,”ɹ([P\‰m¾¼> ·2Õûÿ$Ül(?3áf㸱†2YñÍ·)Ã$ïM$?,‘vwºµGi[Ùµwº-OÑ4ÒíNt›-:“n;c[¢ÛllÝè6[Ì/ŽnËSu™t»óùt›-¯Wº-¯iÕyè˜a óÑò&ÐÝÙªK6 Øc¯`ëç»QSœz }§¸‰ÆÓÍl*%qÿaâÛ74i‘¡®ÌþÖÒ~@Œg Ç8Ò\Uqáœ]áÒ ó$%Û¦ÿϬõ€ýÍBºxɦ×ÝYɽV¦WófÒªiw‹ÜƒOYTÜFiõ~êuקÎKë5z^=Jš%§ÍÒ”FgÂT^ æ0ÙP,ôQŒÇ…FDSÝ Ñ§XCÍR5Ø6ÂŽxs‹Ýî>/Font<>>> -endobj -1615 0 obj -<> -endobj -1619 0 obj -<> -endobj -1867 0 obj -<>stream -H‰tSÁŽ›0½óî!RöâBBUEÊ’]•C³«e{éØCŠ8äïëC‚ªææͼ±ß‹/ïÙê š3¬‚¯œ}@× FÂ*ù™·ÞbqläPƒîO -Ô”í¾±wÓÈ z¶LÒcªËþÉ’S-«AÁÄú?é.¥¾Sð¶<ýø¾<Ÿš¾Ye`Êbõ ãHÿ,ûÊÒ0˜Ì«*ï؃,Ç^´JšMtžçJ˜?i+J­Ì(‡Qœç­S¥ì'H‹¬mC¨>»v=Ô©.8žڑ˘ÿa?ºÞ\ÙÒ‰{b - -L¼eµéËC»1Ú¶TÌ8Å@+Zíñ–wÊk`þËH#Öçµ&\YàÔÉFA×æL®/à}çœ{f—Hì-…qŒh·ÍÉßãùÿÔ®C·å¹r3ÛJp,æ!'´9:$z%´)mB‘Ëø]‚à‚…Ás":ru"v¹˜êD²s(&tä3é<ŠØô-ÉY| ©Yˆ¡ãY5¹mÞL߸!.œy’ÆyìÐÚ-…ëO@=ÆþPcBטQÄz<Ìm]Ç¡»Ý¹Œ±CA#çO·]j¸oÛ´XE›üéGCôöêý`U0Z -endstream -endobj -1618 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1617 0 R/Subtype/CIDFontType2/Type/Font/W[3[260]5[408 559]9[742 220 346 346 500 559 250 310 250 288]19 28 559 29 30 286 31 33 559 35[921 705 654 614 727 623 590 714 793 367 357 700 623 938 763 742 604 742 656 544 613 717 675 1047 660 625 592 360]64[360]66[459]68[563 614 492 614 535 369 538 635 320 300 585 310 945 645 577 614 614 471 451 352 635 579 862 578 565 511]95[559]98[260]526[362]1079[330]1119[547]1170[139]1177[336]2170[1002]2172[663 662]3200[708]]>> -endobj -1617 0 obj -<> -endobj -1868 0 obj -<>stream -H‰ìU{L[×?ç^Û ˜€±c.6¾6ü¾¿óŠ'8,„ðˆDB€!@iF—v­DÕ¬mÓVK‘JóX)ê’¨Y÷J–LmÓmÝi­´¬Ûª$Ó’fí–Ç¢%xß½„0í¿=´ÍççsŽÏë{ßE!”¦‰ÖôÅzë¯_º;¿‚^¶m¸'©k›@ç ¤ô ÅFª.ä!U.œëß6¹¥Æjû#¬Ï#T8>Rl™„*}p^8046ñáVÉ!XoFÈ.ŠMŒ¤?ƒv#4Ú çtÏøø6ú7néZ¾ÙÑ7²|½=6Ô§móIküƒ‘ácñב¡!Ž^$j±oÍRµÃš£ß‹8Ý„¬=ãwgún#’ü=GçË<7ÿ®ûúWâ·â«’‚¥ˆ»ûw-Uó8ˆ¾…~Ž>ÇÙ˜ÁAÜŒ{ñ(þ>‡ÿLxˆ­Äâ*ñ€ “Ï‘o‘¿&¿rÀs‚w…B¡[Ø#|AøŽð®È#ê=)zOôUJuS3Ôw©»)å)S)ó)§f¥v¤žH½-Î[õ€õ€WÄ¥‰ÓêÓ&Ò§«Ó[Ó÷¤¿•~/Cž11—ñ#Iª$"Ù#ù¡ä³ÌüÌhæ\æ­Uìª6@_I$ñ/Âî$þ#8•Dÿ“ø蟌ßü[pã1,$‘DI$‘Dÿ}ÈêʺšDI$‘DIü"Û‹" “Ðs`Äü,@ûa¦~Ö¡ -´ u¢n4…v¡9bØG¼K|HkÿJÆãü -bP#¶âŠÇ㟮À9ücÀûø½ßÞ€×ÏÜ@‚ôé”])O¤L¤nü î&ÞI)xhpP:èXªÔü:þä:4N#% r¸·å#äpéØDwP|—éø®sé()D˜Ž~fh¢Ð¯ŸÑûô_ÒïØÍø˜Æ>£Ÿ¹è=ï½ ¦‹/bÑyÎV…ñ;Äeâ*EnTP˰β2ÃM»\.ˉ(EYË­ˆâVr¹‘ˆ„}'Û²¹Ô^æ‚-ø‡³'ÆõVÆ°±·ªY§]ã?-I=™ªõd¤*²:%cê\´p ä-79J¬´Á»^}Ù̶ˆÇºÊ²Òf[p!ÀWØUgK;ô“ÜL‡™žL±©­ÈÏ*«Xc™³˜ñ/4™uŸ© ÍœÕÁ–è Þ–H -VÜðЀÜI|{ˆ¿ ,ÐÍLðºÉ$H)W`OǨÓ9ÚQJ5Ó…cÇ&'ŽŽ–íÞ‰ìßm‚×4¼.H¼V°ðœa ¬†àŒB‡‚Ri0Ä“˜6›oŠJ ÇŽNLƒ·Ex -_H¼•º(ƒËàR€h.¥  Š”¯èÖ½ªÚ ~Mwäˆî55ž:ÐÝl·Gb¯èj¶Ùš:Ú‹o>”†‹¯ƒÀò²{o¿í;sfïïøqúkâ[Ð9ô$ZÅÉ >á5÷ šnyž\¯Î7‡_5å{3WIrêüRSÕ ÷N‰®ã<\ÆÙÍÅÈ”Xp=†ýŠø=ô |Zf‰Ö*½^¥dJÃòò Œ†øø3˜=†Lê ¯z®L’£÷÷Bä–Bl[™»\dñ¡µTû£ØÁ¹-6Û@´¹ßéhnp»ë¼qÇÁááùöö7‡‡ßì(;8;;??;{ã„á2ñ¤€|`@'K$Ò˜à[—#+‡‹ÎÍÕZ+ã×ÈÕš ½¶Êªµ™”"ÃâÖäRzçƒy‹ÒÄQòÃð9HXÀQrñ‰D²e:Spº”ÿ[±Úî4[² -í=±®¡¶È‘k¥4%0 ÎVlj1»kM!ÃjÆÓ¸©±öé ï˜ó²Oü¾ œK–ù쉼ѱ‹ÿVðQR–#!îö´kó‚~cµ)¶ž¦KêL6Ï"û1S½Y]å.47nW—h´lHSç«lt0µOð¡ ÑÆÒ0›FJ»/j“ƒG ‰È“¨smÇ°Ø‘ÅEo8½ƒÏ IýR­µ.|€Ùî]»¬ÚŒ…ÖX@åjU*˜²¥_^°—·€ïŸÉkX“/6ZŠ%œE] ïUàPÄë»Ba¨iBg`@yêQ,ÜZÓROûüE}´Æé”æÒ¸YhRúœ4ÓSR5às‰i3n±‡n¨Š4IR(Üó²F–sY˜féª õ»¹JéÞ÷ÁÖy÷D¼U¼Eu æe‹ö] ->J.Çúê?]ÕŒ¶4­áf¡²Æ¶i»cs€uû=†@®‡ßxªnO¿·ªÈg ½øB=´¹n«ßÝÔÑË^ú*h ß­Å`Ui–‚z\ #¿wcá+„Áß¿CL9ì§òD¹šk†¼À § -ãQf¸–„ ;Þ2‰û¨ÂÂâaÍ -÷9Œ¡w}IwSWÿÿšŽ=ëË r»©Ü²"‘˜¥<$v´²Ö UF·Uš[±p°A£ëtâ9uÈ©q†œeÁ…á°ÇÑhR­+¯hâlèˆßÆÙòQñ’]r΃®D’-¥°„ íœÌ á>uW*¥i—%ÊœÀ€ÕÕƒ>M _c«”uÖãISdR¥ ß:û²Ê´¥¯~¸²vv<²w$€7Úè§';ÛZêA‚uP{~JäAíü–.Ë -rÙÿ¯s•hYÇ/.–¤…Þ¥âD +ÔÅK<-õ -Z+ªä"½©¥jùˆâƒŸ­(œ\]Þu¹ ‰ÒëY½L(Ä7¢øø ¼vûUݵêÓ'{]Á7ñ•Ä^ -õU=·à&þ¦×{Áë}œ–‹jB¸²ß^}òtõ5ç•@|Ù ñUƒZ‹l>˜Á+?-n+ \Yù8y˜yà¤ÄGó£>Üv®V.mã[v…vÝ2òR£¯Ý\â“e•c­IíÕЖLc®C@ês5^cýt´áÙm•-Ï®m™.QØöujK”BFDg—V³MÏGæ&O}-ü¥}훟o²œúF1ÖVž.‹Ëó%º‚ŠñÖ ~ÿο1^í±MÜwÜwçÄŽ_‰íØ—‡óùí;ÇöÙNLž8‰MbBóBˆRòh"¬UŸj)HÀÈÄЊ¦Ah0µðÇ&Á†6i•¦N6VÊÖ²U+ØPËÖ×Díìû»‡1¤ý‘;ßåôý~?ßÇçûùÞ:w 5J9]­X™«ú­®¬~`Ðò -N†_¬502qTÌ1òšƒ†'4Zàà*‰P­VÃG=«)«6{‡l–˽ÙÿºKÚIòãÖ²*¥Â¬gjBø@æû”™aBJƒz~ºÂÈ1}Áßãt¶ÑTºÁo?ø­€mÀä6 OÓ´0’&”ošˆäáÐK?ÜZ{ˆ£µ˜æ¥ç;ëƒÙå-É¡¶Uë;6¯_Õ64t‰ÝöW0F:Rz¹f¸÷ -öÝxWjEæx{_O7¯^€0sö¶$xtäfŸ/œPnlzb2uxfËdØeŽøwŽ±éÕ©µ•Ju`L5rfnÇ™ÑxÈ榚<§Ž ï_±K+£|!„?„F4 ã+Z€(|üÔÒŽÙ ‹‹‹{†$ ¿øÉìɡȉ£G‘BA6“`“*°(’Îiû3gxm/pT_Ç£9Jy¢ª*ŸÛÙ3±’£é…ºtïªõ Àüæ¦mñs0X²l]?{{ò†b÷'ÃÜy·Gò@àÁº©Î⑽͆پbÏJoÙ§"œ[Þ'Uc'¶ -Æ°¹4Ñk b†0×1Àå’ -pÙx—¤ØߌçaˆB£k1ÌŸp¨ -Q„®5Éš_] oÇV¡]“ãJ]ʯùÀëe´÷ß~‡PÏôôô% +B Žïór'€É{p{³tH>_O¹í¸¥1رÆÚÑ4šn˜X¹qœuš8¦1nM4¿¢êYYãbºjÛZ\…{jmC?›ðÛhªÑÝõÆØ -ç¦'Æn*wlu.Hƒ#µ,q:üIsOúír s<‚8Ý^»9d'#΢݀Eæ†8µ¥Ð‰¿â3‹jù£Ýo‰°™=û$ÞØ”Ûþ9Õ¶§±—E¦xzCj(ŸvOîâOºý)ðä”ÉhÂ-¹D‘ÀN$°ƒQ–äJA`þë*›U‹‘ ™-5#2+/j'¿0Z©²«øvId/û×9¬UC*9†±r™óà¯D&“ëÀ_è±þ"vì ¬ü¢ä»ˆÑš•Êríb׳:³BiÐ J>ZwnøÔkyq¼U;äôŒ†@¢ö†GìξV§±¡ˆ,áÌy<”y¢RBBT-b c±û±¡®!ÉXîxˇ£(oŠbA¼)‹¾êŸ1ÌZ¬”p˜•eÃcjE.±2–¥KfQ›ýwQ³Æ41§4´ åù ÓX¡$zÚ\õ½#zJkP3 åû}ö:zM«+駵®2 -XpùĹâär'ÝÂ8…ÜÅÌ0{' ®·TA]ÕzMñj}¥²Ä®«”ÍÖ/4&WåY¡‰µ!ÏF­Î¢ÞG5“¦VjAOiüLmöú%¡_p7¯» Lêx&ê"'¶øÐìØìþokùŸ^|uº/³Ä‹!°2¹üÖ#ÓÂüêóÈäMí öb/béâ\¸à{¹ø}þл„Ïo¾_ãGáëo÷£­~oyöÞò› „a«ÃY»vÎ'¸, ó¥ÄíÀ`!‰9b1ñTZlÊÅ`‡Gü_Ç—ùÝŽ¡ k5^ŸÛ«eX®?<’¶Ø‰WË”&o½¡¥+¾¾MÕ3зFN4;c6K˜²Úí¬±g,›aj˜A [ÙÚï'ä-M£h7 ’ ²Éüü¬{ -G>2žH#=°„&SæbÃI%ÚÊKŽÉÍ]MÓÓ í =*ÎÓƒÒQÉåÔúWŽ,í‹ÏMÏÌLïØ6ùŒ¾ y ÚwŽ¨ A: -"½ºcKSÓdœé‹ÖúawÕÙLêõînÕŠïŒo&bØíÖ`Â;9<3í¡t•¤ß -Á¾R2V`3þ|JFÀ8Q¹,lYÀð !„¿sjÀȶ^À¨Bh8OeKÅÚé{à2¨#h¢Lð}øH8yÝ÷ Ú4ÿðADxõÔ3 Û7ÏeŠwwES…ÆÝûÖ-®9Ö¢:òÒÁÃ{OM°Õ„A[ ±dïxòœ]$ð¼½pD'RM&t^à!V%§Óc=­§ÅÍÚ -ÙÝh§/Ãǯóöã,LéB^¹I5ŽÌ_Í[àýeiÇÐï´Fûµ2ÒΈ'7µ/¿õË1Ȧße †vWCH½$Ã@rf_œ`ˆw&5 æâ[j~Ñß|ÿö¤W0ËYŒÒ¦†Šn/wÔŒnrÖßl6•…ÃqyôÍ`8l°6{Îf&•{$Ì“JSs‡4Œ›I d_Wco…æíG5[îDÿ~›Ý%;EÕÚiÕâw7,Ýuš¼+epÖ¤—†[b#Öri¬eíF¦Ñöp¬Nmȉzõh¤ Åkó…m¾Õõÿ¬5#C+5Qd¤»QÆÐÒ2.# ^qÔ£?oÒ7~)6º)äÕ£VFÒ"Žq_à\`§ÙJ#ò«dú©/ÒœEv±qÏ‘¯Ïì9òƒÃ]«†±O<óôììÓÏœH: à£eBÛEZ~ÅÇ-%½j'|õ…sX‹˜¨zbzÙ¨9f‡u”â ¦4÷2Ç^4¨]Õ»V[·±è<0ïa؉,hý½ÉbÌ¢Wcô2´õ¾_)öý¤ø¬!7F-’bÞåå~«9&ɸ%·anïöe¼a^Ž¼­xýÒ×\E‹L¨™j÷áá{V½IJÈ™ôÊ„Íå Ôãgá!·Kq)àk †šäþA×YUk"èuNSD -»5©í©BZ¶È?`Ø&Qìþix²NªŠv¥³uéx²Ï³sÃÀPÀ–“r¶/ÝÛ¸×ØšrHUé¡D¨ÁÝXW/·!ËL“Óh‹ø!G½Üeç´"ÿAú,óNŒ?ú$ôuxçÉ‚'ÂnÁ0·ö¾µ5+««ëËZŽùj$‹)e¼oœŒWTפ‡³¹—“1 ŒHSDÍœ¢6æé˜^ynåEKý8©gÖLîêíŒy… Øþ~ë[vÎ1ÃòÃÕ›ßà ·ï ?&·Õ¶yxñ}X\«„¯‹¢Úâ öŸç*Ý7L˜†ô›ìåúFó@EoÙU.WÍ÷É«…èÿõ¦öºuþ7lV ø¥XnãƒY°ù¤4>…<Šq’(û:X¢´J#iÌBÞ;^Ùèþm’$½5˜«Ag3íêžÂD*¤&Ce˜\+Ž­›=©J‚¶­òG¶ŽVKÃXiÉ]¶eS–ä—Ï™\j’ÛFÎ綢\z¼.”lÕ|Ò\"_i".‘‡°}…_v=ZM9ÌCª*{Sóyˆ´óY%Éé;Wˆ}÷WÔ¸Ð.Ú/ý´Á©ä!VËä°–‡Ø‚³oªiˆÝ=ù•*Ÿ¥ÚÌ4\‡_uådŽÊÕšY¸ÆºZåïx.³à ôoLW¿jvº„9¡³|Ðhµe¢±¯¢Wx_pIÕÏÛc½sÑÔ¦6rQyÀêÚ_ˆ™¤ÅÙ-Í?àæÁÍÉZ”€¹·P‚eò0ñ¾´W’°‘|;÷Ñ/½Ž2}X$¿ -u'C¹¡„[<Ï4ázÞBÒè½%ÿ¨¾Þ9'|rËÆfâp‰dÉ5æß2;¥D‹³ÃÃÙ¦¿¿ãR÷úõÝŽîLk !ˆ´>E‰š”¯NÙR«„™ê5dæe”¯Ýð÷µã>oÐÞ–V¾-þ᢯AOãòøåþ}=3sRDtú)oó†þŸ…þåô™ÏÆs·tò–‘{Sì{Tâ«‹m™§ÈŽŠ® ã%NµfaJ¿8¬so1œÏd¦Ìä”3Рخއ.ØA'^|­øNäF™†Z›“BFüñÄ+¯LLSOÞþäI–k1k#|$”±µw‹…‹G4¯éQåõh»–ê©‘óCjä|mæð–­É`m\N¶Õ‘ðx¹žøµ˜·&÷\Ëj`]µkX?Øo/ßûh$àjªùâ¦Ê•xÝÊ%ÞV–k‘·rzO_î4w“]•–‰˜¡ˆ©L‰ˆªdÒæG4i¢ÃaW‰4f1»ˆÞ)ƒ˜\Ä·”d3‡mÙª)•³7Öº -9s¦ˆÿrª„c¬+Ü)†]Ñb÷}þ÷\œí|Æ –¤A¹w—}¶;s£â·b²‚NÎ]Ácï×tf6RŒªc¨×[ =¢Óêç!K£ÐP§c¬t²dR)nrB8¿n€DZqÝ XEܸ. -,½Xº°´c©Æ’ÑúXZ°$‰cXbŒF¡0>Âlÿ霄Ý2|ˆõ~,#XެЂ}2¿F£Î ?Áú&–¡nÖêSX»‘þ4ÔÒ? -ú»¨ ÏA9=˜¿Iןì‚)嬻˜]ÂúÝüMå¬IH ïò)ʽ‹rÔ"=Œã= 9•b»LÂÏÁIŸÀ²ZYob{ȇà!o@„l+îièôb´ô4 :’åyðÜ×Kƒƒƒƒãä«,äà¸7@}ü¢eàààààø| C ~Ñ2Ü ÿW>å©åÏBÖÁØSŽ{ÂßÀÁjzô»j›ƒƒƒƒƒƒƒƒƒƒƒƒƒƒãÞý=8€Tƒq €m²hÚ/ƒIœ%º -loÅ¢¶ ÔbOmS0ÃÃZ[€6xLkëÀ¿ÖÚzØW´¶¼¤ú`?€oâÎÝ°ggÀ ˆAÒØZƒ³ûq|LcoöÁvhÁÖjÙƒõúù]‡”Þ4ÖÓHëkø?…+Gp÷ 7< Œï†ʪðîG¸*¦ü:Û(þÖ`«°oaW¤dßR”Ý%kÆ•™C8·%w/ÃkŸF)‚+÷ãÞ‡ñŒÓЮÝBÿ³Êm´cÙXg!‰¿6œÝŽcŸ-­ >eþ¤ºtt9…¯ôÀþ°Z“­ ½8JõÔ ×Sª{ ÙS´qÍèèÒNÎ]AB2ñÏk–¾ƒ•5ñ>|!N -endstream -endobj -1866 0 obj -<>stream -H‰|’ËnÂ0E÷ùŠé i úB*ÐJT*¥MûÁžÐH‰9É‚¿¯Ç“€TU,ò¸ž3¾×ÁÍ> Ÿ”9`ß -øÄÚ´Vb¸~K«`0ØÙ–¨›¢BÕWëGØ[#l`¸Þn¶:oFÞjY´ -{êh…Ç\_òqõýÇnÿº3 ´y®L¡Âo*RÏWÞŽ½†L‹"­á"h®g­Ö¦¤5ÕAuÁ ê£f¹V¶KÊã ¨\6½ôYºýñýÉ©n°ÜêÌ@Ìœj«Žˆ>ÝOÝØ 9áfTx·ÊÔÇë«ï餭ª)6?†Zù¯Ëà¸]Z"D×O¬G¿N„{ÇœS…u•J´©>b°BÄKXy/–dô§>ã®C&R{¡ÅÄѤRVw^M…W³ ©û;éÕ|îõ@Cäqš{¿næiïs‰•yv¬Øaí&ì³í”CÄl#»?p–)+nŸ;3žžÖI‡zÞNÙZëöÛiÔïa®ñ|=*SQ—øfõ÷šÔûKð+ÀŠt -endstream -endobj -1614 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1613 0 R/Subtype/CIDFontType2/Type/Font/W[3[260]10[290]15[294 310 294 288]19 28 559 29[304]35[921 753 672 668 767 653 621 769 819 401 397 734 654 952 788 787 638 787 707 586 653 747 698 1067]60[693 666 414]64[414]68[599 649 527 649 571 407 560 667 352 345 636 352 986 667 613 645 648 523 488 405 667 606 856 646 579 529]2172[719]3200[762]]>> -endobj -1613 0 obj -<> -endobj -1869 0 obj -<>stream -H‰ìUûs×¾wWZɲ$[–V–l½v×z[–µ«Õödù%aübÛ`\Û` ãð 3q›)Å0MBI'˜0}ÑNÛ„N;ÓtÚ2i§IIh:dèÀÐÒP&ÓÉR¤Þ•åGÓLþî~£Ý½÷®¾sÎwÏ9@€ -8Ø<µktüADÛˆf®£_hfvl4,Ô`”Œ¥G3ø;ŠPa@ë™É™ÃòøÌËÂ"·•Äˆ–¢õª©ôü¡ïò:4ÀJÒ£‡2ʧÀÓ´n;0oùkz@¸Od&ÓëÇ™¹]™õã½£é]Ö7£ºå1¼œ™Ý?Ÿ{°äÿfÛ´ÅÏÎ(Σ±À;„Ø0nœû©s¤¤á>Àñ;‡ï©ý…çÍ‘»Çrws¥/Ž¡o áÛ/¹Ô«ð‚0èƒ`||iØOÃwá,ˆíÇ^X®Á{ðSø›ø‡ƒ¤YrTòKÉM©LÚ-—þHz‹(!šˆÃÄÏe@æ‘È^”Ý‘Ý‘×È{å{ž,à×E’¢hÑ¡¢¥¢÷)Å‚âªâvqMñ¦âW‹¯+1e»rQù+P¹UCªgT7Ô~õAõ9"Dˆ!B„"Dˆ!B„ˆ/ÅM"Dˆ!BÄÿ+JZúáè§Cw˜JÀ0z–R4ƒp‚:ІÀvpäS˜Ë¡5a®$À647ú)Èår·Ö}!0­¿$(Ë¢ùø¸½-ØÔâžñ½äƒo@möZóå&À_Àó@@9 -ñÁŒ†8VOêŸ×§7ëÝVÛ{.XJ™Õ%«…fê¹ÄôO#¸Í°M` ói„’ë»w£ù¦Üp1#FÚ±Jö,ã÷3T g|54]ãcòç  { pZÿsòO‡ñ}ŸBйO0öGP*ÒH`¨'‹u04AêôÐ0<í÷Ï ÷O³ìL„¦Ã‘*F1|ivöâààÒììÒpÓ+‹‹.,.¾"Xô [û=(€ã9Ä£!¹ -…ÃœF§ç8r´×htÄ,Ú²‘MftÖ¾Òïû£.ZFÙƒ.Û(^`B`yH Lá8Vðˆ^ñ”Ô©1™Œc¯Œ9k©ðTqîh*ð•öÌãƺñŽñ¿'´òzéäs;‚Q¾¿ÏªŠ9¶u1ÍÝ“©‘6ë5dÄTl°y-ób"ÙP>|&ïÞjÁì²Ò2 &Øþ¸cÄÇ2­a[”ÞÜoN4z]UvU¼5“ž>:Ðäêøºv*èÍáJ$*ÑèÆxOs(îK9½5üÆǺ[†ô2gª.¶…Õ «B7Ê!°®(ÇS<ä4ÉyÙìò ¬Æe?1ѵٻÐô©©ZZ•M¼ƒK¤¤QOðF,ß˲Í1¿‘ÿìŠw¯tùE(NWîø±{Öǹ(MÈœZªœq:PвUqïw ºª«ÈZ7¡SMN_cƒG¤Q¹¤Ìðnii£uþ¤¿kXÁ„­ mŠT™ÛâíŲ28ø:]¦ûQ4=Ý4À„Ø|He%RÙ -¼+¹Ç -¹Æy -V×RO¦×CûÆLœIÎlHt3¡æbSe}’еpCéÇg¾€·2¦‚Šöçæ{OOǬœÉê·48Ÿ>¦2ì^hÞÔ×ÓaÕœ>¢¯FN¨Qô -¤,¤h™Œ S$\‚Šì¿ƒÑ …dÿmçØkG“Bç° 5È_#p™Q¨Ž°c-óïÐÏëW(mÞs'‘/Í–™`OsC¢z¢oÏt{|°ókÃvŠt[ÝÕkë¢}qE°ŸOôRÌ@]ÍÖàXgCÒæÝ™‚WȆ€9H'jƒÑì\2hbômÁºv¤#ƒüÂ_à^ÝÇ°°Úå[­`5†³‚¿yÇnÅR¶ò -u„}²¸¼í۞ذa_“­-m¡95ŒÔxý -Š3ë-R_Òfçž]Ò±äÙ½gÒq¸Ën9¾ÿ±­ßv1‰ú·…úªmíºzÀ×½?O×ÖÒ¨ Q…'<±ÒŽ²W¸Ü>‡v$ ú}…ž¸šB(N&ÿXI”rTây] ‹S£´ µP¸œ P´¨½¬Lëáµ¾oÍ5¥N\™šisl„­Žk2Á{RÕ–ÄD;(õ<˜ÔVZb6|µ'µ°§18|°µg±Æüös•ŽpÖRGˆ.eNÕî<3:þ½c©¾gÇOvT³Î°½³Î5:)S’•ÕJwEݾÞá#±ú½çÇžè¶óV‡+ -I&dþª„ïÙbayA;tV`ÿDñRBæ«;¬å´z¡¬©B—q:™BŒ‰s¨Q&É$ÊJ{éûOÿ¡Än(˾î,18ó±Y"7i<Æ·y…Q^T¡äM>¬óÑ=ž/#•åòñ>%¥ÔiyèºHoel= Êh²Ù7¬ó€×ä{µœÏ¤ =…:£Yy1¹õ+é†U§N'#mýÙ›)G’‹´T5·D‚m­¼Þ o¸ üÀŽæÖ2©f[ûoàÙ†ÖVþÑc]í)¡‹‡QÎΣœ¥þë”Y+ü¦†ó;ÏÌŸëì~anÿ¾DLpt Í’Æ3¦^šYÚÞp¨„çü™3‹fo¹ÚlŠy‘ºBto¡è´ÂÛÿÆF0ÎÕh.°þ ¹{µÖÅd?ªÿ-2PÐù6ÒÙý:¯Ê^>Ö(R˜!‘Þ¯}µgëkGŽ>ÑÜØHo= µkª¬SYMõWEgØX'ÒüE\ò¬ËÊó6ïÅÊÊå8ðr÷¹8–é©õÆ–O~ªp®­EgÕyà6/iR é…ÿa¼Ú‚Û8«°ÿ]ɲd[ÒJZ­îÒ®¬›Wwi-GñýߧI3‰˜Øñ=&ICÁ¹P“Ô¹áÔ! L;P¦ -mÃhf(m†ÀL&ô&3eè„  mú^¦T2çß•dÉ6 Öz/sÎùÎùþ_z’û1<ÉýžJ×wß pÍÙý|}ô—¢@_†(˜­¢ òžŒv¨Ø¯Øêü5N²²öxM‹ÅR¡D™)7£&ܴΕ®Ãì3ŽàÀ¡Ä“4—é$F¥ø²¯wh0å«ûð¿f%%µ\¸…§$+ϧ(«¹èäe—ÙìD·ûümG‚•5 îé.!Opüñk\˜¦j’ɘïzîa7¼rýÍýÚzvD›·ÌN‘Á…üÐŽÛœ_©mTsDû³ Õü9_ïïJSD™-½~s‘)ÒMRe€\¯ÞDVÉQî•Ëy¯ë ó 9;ú°PAïAŸe¿MÌä4ë(H üñʉ^üÒÂK™/-Œ Ëd¤‰xt´8ß¼)NÄ’:‚Ø-x¢ÝJÜÑß R‰+Óç8Ý|ÂÔßšêôâ?1Ñ4Ûþ=8h`hdxHŒ]+Ænª¨“b÷•…+vP‚ho:>Tyé¼㹯ȃ-¬v-åItv}ç[œÞ¶õgiäۈ鷀É[Ù“‚)!öf|'.LÇÕóþnѶËئáÃb‡ÓÀ5v'; -´øˆÐUÿŽ÷ j¯÷ƒ»óñþ¾Á6àžÒL xÑ’j‰*‡›©¸emê4FFª&ª™®w%íCMéŽÝ{v<ån;Úst¦¥™ûiKoç̾ÎÓ*¾ÝÅtOïk 'šÝöÖ¡XóH¤0jk GBöHÄZ?Þ×>Ñ‘À\I,C6¬Å\àùO™Eð¨ëpˆ“):åÄ1y§BÆ…†%5"/ÛrçN ëÍ~œg¼Ðý lzDt›4m“ÌU¢åå?ñ ïêêÌ`U‚Ž.ªæΠ%‰î¹¥=í=ƒèrþîôä³ÒVKÜkYÁ’Þu›#òÄ@oÖö!ñ…‚DõT ƒúÃjs%9]¥#ez匬ʨK""ªÖiïSv½ ¨õ0¡äî3ýVs·EUÎ*Šk8û³ -ɯŒ¿ñ2¿Ø-ã D·‰¼ÿÔÿn’DÕ?W²öZ”aš*eUÚR¡Užï[¡¬r]#•N–Ar½U¿|â'׈C.@­bkÿnnn¢]ÛìèVîùÈAKÝTôý®Êoí±ì[èAŽÏgäMˆ,VÜÄ6ä…)‰k=,‰æ?Œ˜¸·4Vˆm'åp(+ûµ†ªj •®®ì`P¥Þbe^g™˜ ã¯ Ãv“ ˜ µöÚoºbŒ¥…;itTÅÁɽùu^/ò´–8*î… *ðŠFâÐÒ]ïFœ2y¯œ0æ.¿R$ü'Fã†÷ÙWíasè=°3¹v"þ…÷L†*•ëIDóxXçÏ’'aƒÌ>»#|ïïÓùïKÏ7呾FôYøšX›æåüŽ—"< ?aq7Á«I*/7ÅÕ„–Räö¹ÕD -çUœxïuŒ{æ):àµwv5Ü67gád·i¥Ñ§øD¨)¬Þ½+##Sñ¶–°Ãã Òƒck‡ÐmuS}ÝÛHr[Ã^ˆ€‚F b¶"$ž˜§Ý¥—ûÙݒ쥬‡îÿ´Ž¯«®-¯~ãôbbj4Âi8¾ ÙÞ=A=¤ñCa-JäkX$û`¶ äâô-Ô5,³ÿÄ|[ŸãŒÊ¨3Ó++ «‰J› uyÎè9C»ÖkMu¤ºr?°Ù”ìCôKžh©HUtV ã bºŠ“~q2Ëh…X2¼™æw4ñUiGÕç»›XåO?ÙÑn Ç}Áôôw3c‰:êê“ÚPk°OÌV{•j£…>5yàê×ü6»ßÓʾaàYCÀö䊖Wón6Æh3ÍûÆuµ6Ç0œÁXÍtz¨Òª£4»zÌ¢ZRÝ;RɶܞxÜe®v±» ‡”èp£Ø™É¤·ÈÿX¢…(9ˆTR¢%#Þ.„L¬ºæ±L¦4D\CûXŽ|Xd½ZäeIÁ"j,Ö*áG–íõ^Ny`꣰Y@}í;øžÀ¯ê…Y}Ø·ðQ8î>w·°}.™ü‹"•ŽºÈÇíÏô¯ÿü•–Áiô}ž²F¦ùÜ}r'¬ó¯/$O|È$–áˆ&¤ÙßQE¹D©’Ÿs]¾Ö –©N $ýúý~ C"´"¤%]̳ª7*¬ñx Øû¿WSuλD¨RDh'DDoÑ—妳K¢ „;ùœÖö ³3#QÙš[ÞA‚>–ü}­³#•Ñ) ñ´³À——*ÒÅ'²ñõL¼ÇSWíÂÏ:]|í¾»˜#Æ ¼õlÜ.ÿ3ÀòˆJøšÀ¶{Ê|æu¬¼÷1e}‡)ö¬nAçÙ¢/qS‹Ëèµ+~­“ûÒ“s³ãÛzŒ -hDPU£2 Æšxþ‰X^&l2¾ØÅ×/ðu$¤éÆ•Fá©éÉùùó“bЗ žaäÒ Ú½À½Þ,R˜½•…9•bèبœTнãsóé~£ÒpOfô2QV—{%ß)žt ï?ì—{lSUÇçÜ{»¾k»¶Û½ím×m¥½[KKWö`°vaÀ€ S# fbP2‰DA >>â>B"Fâ+MˆãÿUCˆÆ(&ø‡ÿRiýÝö®Œ¹ñ‡è?çÓüzÎ={~çqÏù9ë 5?ù܉Hñ|¼õž$16¼{݃Ҽ’¿hX½™Ì›WuXf7X+Q.ÃÉ›q ®ö“¹v·X-Ûu¿Œrƒ„ìzcãƦԒh8ÝìxWñ¿¼ ‹ØFù4œs˜ÝÐË{ùœ›Àõ}ÛeÅѶtY|YïÆ-‡v®\WÏ( -ª±öæÜæÆ\2(›:Á¨O\—ÛÐ_ó„j“™@À-ûž¾•;°u7¶>M_À^±u<²ðlÆá-Sê™èÖénæ6ôÉ)[À6pôh ÖUk·¯6öl%«R>G0{¤+?ÓøΊJµ?Õ¸2Q¯¦$æœé¥™,?i<¡ëï•Ãôš¬$b1‰û¡^Ò_®ü;G¾SjÒù‹«Ömê¹ÛïvÅ™î]&iú›Ñâ1¥êÛÛò{žêN•äíïo낤9Ôq9“Kì]‚®Ê!]u¹DÇIò¾ªøe³Wÿ©Üåó®p}i­v êÛD~HáîBÛ°µ”ÖÚ<5*ëýÔa*ëýËGM‰#u¿_àêŒvž¬–ÑÎÍ&ŽL&…²?Z$¿}z|ß$yO•ûŸÞk:^ëó¥ëˆ”ÿ&œtú”úSI•ØÒÒü^²6ÇÁ„ãð8zÖ¦­ÏL¦aŽ{OæŽaжý –TWC…¦Ü&C8柚Š*ÒÊÕVy–Ç}¢‡»n"òîç«œ–ü%¡Ýâké1˜%Ü›jê^z#NšRWKÀWiÆ‘j˜úXô¥ÓA“èï4û,x[Rç ¿åú—P÷Uõãð5,rQ3ÐOÔ¹œ•«­éÞ’´Ÿ7ÉnžHœ(WpÝV3%•\–×…ƒü÷¼´®ŽwÜ¿æ×VeCš\¨¶‘¶´Ý­÷V|XŸp¹Sú/Œ~C•ƒ¤ÓDŽäGWïH»ÑuÞDœÿ¼‘¨’JÒpÊã5êÚÍä\þës~Q¯k–·ýï›±ü`}LþJJ~†J/½°ÒÓ•¥^P;炳¥î~Çžع¤»ß©O$É°'d5ç/™­!ÏÜ7k4¨ÄÝ ÖÅÍÑŽl¢$#JYš ,ùÃõ ?}w÷GÕže]¿€]ÄË]cžLJהּy,W”k¶w=fpÙ$ŠÕ5žm¾Ëú½ã¾=$¡põfWØ £íÑ€*c²5šŒ½³Å/šWòWñ?V¸Q8Ïk7ÙÛ˜§ilž}"<, - ¡.žŸV¤|vg/!´(Z-šˆfA‹ 5¢)h~5$ g¡6¸—!Ež¾ŽuÏ@†0<¶Dœ‡ —‘œD;Q¸A¯aú³˜~Í…æÄòSZø9æ­Á¶N€‘Þ;ýHR—}¢ä,ì*öá,žˆs ƒèëSà 6ˆcØDÛ NNƒ“&€ÒWÁA@ÛVø…)ŹoÁ…é.:‚åŸÀþ>‰uLà"?ƒŸ¼nÌ«¦CØ·­…[ô8˜(Ž"u¨_ ƒÁ`0 ƒÁ`0 ƒÁ`0 ƒÁ`0 Æ¿ƒ~ÎÿÛƒÁ`0 ƒÁ`0ÿ-ôp0Oà pÅ$²@± -¸s oÀøZ)NÀ…O¥8=Ðâ$áQ-΃ÞÑâŒÁŒ×H’ƒ xcÍ=°s‚Œu°ÒëÅÜ L‡|Z ûaš0Ö‰)ãn*ך,>`8‚ï:„ÿ»°äz¬}M†bú…,>cnóÅ_¶Ó¿^ŒÍÖ¸]¾±\c¡·ÉåÜ-Å´IL@?åEÞ¿_{G#–œ€‡±Æ0ÖkÕúœÁÿ–bß[1L`Î(†-ÂßrÌÆ´»yXš?(œÁ÷-OÓOp€>M·âs_)$C$YL¥zªJyu¬šS±·¿¿—È ÿIx%_¤pyyé 2¨µào—÷ -endstream -endobj -1785 0 obj -<> -endobj -1477 0 obj -<>/AP<>/BS<>/F 4/Rect[303.105951 757.790154 487.425775 744.190545]/Subtype/Link/Type/Annot>> -endobj -1478 0 obj -<>/AP<>/BS<>/F 4/Rect[340.991938 722.590936 489.634027 708.991326]/Subtype/Link/Type/Annot>> -endobj -1479 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 708.991326 181.583246 695.391717]/Subtype/Link/Type/Annot>> -endobj -1480 0 obj -<>/AP<>/BS<>/F 4/Rect[340.991938 673.792108 489.634027 660.192498]/Subtype/Link/Type/Annot>> -endobj -1481 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 660.192498 181.583246 646.592889]/Subtype/Link/Type/Annot>> -endobj -1482 0 obj -<>/AP<>/BS<>/F 4/Rect[362.189691 624.993279 510.831781 611.39367]/Subtype/Link/Type/Annot>> -endobj -1483 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 611.39367 181.583246 597.794061]/Subtype/Link/Type/Annot>> -endobj -1484 0 obj -<>/AP<>/BS<>/F 4/Rect[405.570307 576.194451 525.297113 562.594842]/Subtype/Link/Type/Annot>> -endobj -1485 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 562.594842 200.189691 548.995233]/Subtype/Link/Type/Annot>> -endobj -1486 0 obj -<>/AP<>/BS<>/F 4/Rect[398.273676 540.995233 430.929438 527.395623]/Subtype/Link/Type/Annot>> -endobj -1487 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 527.395623 241.854975 513.796014]/Subtype/Link/Type/Annot>> -endobj -1488 0 obj -<>/BS<>/Dest(name-authors-addresses)/F 4/Rect[65.905512 495.696014 207.103266 476.976014]/Subtype/Link/Type/Annot>> -endobj -1489 0 obj -<>/AP<>/BS<>/F 4/Rect[98.97143 385.378358 212.000238 371.778748]/Subtype/Link/Type/Annot>> -endobj -1490 0 obj -<>/AP<>/BS<>/F 4/Rect[98.97143 293.780701 215.068354 280.181092]/Subtype/Link/Type/Annot>> -endobj -1883 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1882 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1881 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1880 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1879 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1878 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1877 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1876 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1875 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1874 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1873 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1872 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1871 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1870 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1864 0 obj -<>stream -xœÅ\IoÇn€Ð…:زvÉF&€6ÊR©ö‚À!¥1EK").²éCD¾Øìä˜C~z¾zÝ3ÓÛôT³+ŠiŠäÌ›®¯ê½úÞRËLÌ8¾žÇ^ æ}pVÏþöËö¯ÛÌzsñ“^üu9;³Z1ǹónæaZó Íì·¿oŸmÿc[Ìâ×o?m¿ø‹`|öÓ?·ãç]X~D)™ÁzúÌÇíC|áÑÂ/$ÐÊ/Ô”™ý\5ùsãýø÷ÙS4Æü¬ü¿ÞÞåƒo»ÚÛŸ¶á#ï¬Úß?—‹ÚßõÏÕ^ÿÃ]}1¡â³öÏz“ß¼ß^ê^<À8“5r·¸‘¸•EŒK·1Åí¬(¬Õ ©0Å=èãNVN;&ƒð „µDgHÚ¬¡šI©GÌ‘{Åu`È;1ŽÆêtÄ‘¸ÞF1´–‚ m'öfþý·{ßô!ø¬Ø¢&—±Þ2+ŒwmOØ',•cÎâhQZ¦œäŽ+!×É+.™U>Y^#xPÊX®Såá.”ÖJöÊ?.æÅK|¿+öðïI±u3á^ó)ÆÀ÷Jg‚Mì•Ž¡Š òZ3õ÷ª¾ÖöŽy§¡Ï1Â^£Á¹&ÙJ9wðñ›ÝGSÒ‚…[ÀGž‡Å·Å:÷®Ø-Ίƒâºº;›ãõØé9$â œ¶:!“Ü ¸ÒtŸÛV< !áÚ‘ÊSÓÊ3ã‚Ã4i>¤WØ"^6ŽV‡I®œpzÝ KµyXšmÅ1½êóœicœ ÂÚÒ0¥ “—‚9èv8Õ;ñdXØz‚pð f¦ƒI–ÀlUPЄô`&´µ+aØÉañª3*.Z2X=ô~¨ÕQo˜—°™ l G/Ó„8½tÝ€·È¥Mv…… „®ðóâÝœWsþzq³Ý]ÇŒâ!ôÆvÀì,¬յŀ¤RŒEëV@Û;–J±˜ ÉI†ÄÀ4IXê·$É‚²0Á[Æ nÖʃt$D—Þ'ßϦ׋ۭ‘5 -OÁÙ´V­D‚Ct×÷‘î{ Çl³­P½×H,l•+åÚqýÐlÐÙ.Ž$ts 2`ÜŒÅaÖÁÀ­_ÏkÑy®— ÂZpæJ6&€1‰}„;(@œ]áç4&çø÷¤¸¸XêùNwZããd]›;Ó’œ†H I웣#Ú(gÛ9PôKkØË"0áÞÑýH×â@› ¢3Û,Œè’©R1Úð›ìåÔ¤æKt„ÓT á -\©‚ÍÍE6@Œ*àFU4pèßj7ÀcN`”^3ì5'†tÅ’„mì¸M®‘˜‘ -–ãx*‰õÉ?Ø‘ü vߧˆ—!á–nT´è=KR«–s¸\ -Dûä{Ì1kZ©íºÉ# G’ l$,Zš4aÌYæ¤TR% äZFs‹™`æ¾ «ðm]¤}£Í”ê”òQóíGôòYÞaêÁñvä»cŠØ”íö4õÚ@´«5ѸÚéI~, ÊH¡gV@}È‚L£ž&¬A¥Uì•"Œl€[Å]W8Q &²qÚ‰”ž¬²«(ÞZ…o]€Z­óÑÙ6˽O–Ö§#Ãô ¯Q|ð“ÐÂ4Âó <‡ªÐ‹Ái¬4b— “åÁÞÌŽy“*Ïæ=Rì^ùuäÔŠ]aä g—Ø«¥c¡ Õú|Uº8¨R+ -_›UžÞ‡cVTyZŸðšðÊ"ã*Ø”(æÅÔç!AØÂ% -„’IµdÃ!JÔR¯¢’¡d£#|±³£¡¹9¦ÝIÛkß(nµ:ÏËÇDXˆžgu»8íV]áÞ ˆÜÚµ±~s4µTe³<’U£¼’‘7Ë×|·†j‡â“•ãî÷†C7:™‡B\á¬-#œÍ-Z(Q ¶=ðz<¶b˜r±NÖ,÷ xdÞ’.:éêÂKÞ4ðÛŽOú¡:œi;!Ó„Ñ+L¶àáä7 ל<-¹IÙdx±KUS—]5ò`“zžÑ² *°ä+ûäªØ{OuÚF v…6¹ú°8¡.,:²xÉTŽ~»F¿_<:¯M-K¤ª4€dxW -W¼¦ºE4úø¶pé'ÅAqLA‚c¾#7ÿÅ~–…¿#ØàVqŸ³ÅÅGüù˜ÞÜÅo±RxFQÁK4 vŸš©¸kUB¼2¹2^ÓJ»ž:ÐsK -q€¼U|Y\Ÿ<ø±4 ®²nŠª@¿µXå -Cq¸|åÆÂx >Š˜c×bɺ¸MK{_´¡§Âñ c6 -ÞïívÚ ñ‡Œkh²Ñx¤¼ «ê)´4öFyó?-¾Bÿ¿(¾_;Ž&ëIñ-ìùóÃЀµÑjUýds°Ä°ÅÉsþݾƒª&ÿE…®¥ª5 G¹E,šŒç÷§nr¹aòŒEæÌ2‚öúÀ ]®xí°F„»Å[ÌÛ9¢2p|ý%^y€×‰ÿöèÕÉd—CF8§ÒA_böhà hÉÍ´æMÞ9Ò\”@QŸ­kuuÜÒÔnKOËÙ5ri -G¼,ƒídÐY'RsgÍë9‚®âz]™½ïS(òÂrŽIGoå3ZŠž £>›Kˆ0¾®’²·•Z”Ï3X/GŽTµ³T:€æ‚ò˜jVá+Â:™>Ä¢˜Œä -@ÀeÃ'D8s(ét™•#OŠW“çïj;u2¡Zö‚ùh4‰,}J<ýŒxú42õdN´N0d,Î'w¨œò9M«±Ëq åê$ÜdsRqÙž0¹éDœŒM;Όӑ’“±]fáÁy7ï{—ÞLÌ»XÑÜí:€¼Î»÷Fò®Ô’ ‰aÒÛËÉ»­“šÃµâ:´Ke‚’}mŽýÔD§ƒ¹‚€íQɹT’ü°ük«ø¸ùEEyÇø´"º%9ÒÞ…é…øÉl9“|mUç]'c€ÍXmFaø…Î~æÍc’iDâ~®`éÐÙ—) è¸ím\wóEz­Kd£r/bù 쬤Ó<˜=T•Ü­òÝÏ‹´0sRÔŽy* -檤£ºÒà†É$0©¾Â+Çøz[-Egåm‘Rhï½M‡Yã:Õ>™k¤e^ªQ6Æ5™°Qq]Éxôª¹ç?ó”ç–¹å.Üä–rNùÆp¥Ny¨ËhCGR1gïÍ+†ê\4»Y†‰mЖÇ’›HI]¬>{ÅîdW$ 3BƱN†Ðä–Î6KÚdú¥{‡Ë%ØSŠ˜g·JîŽ`,[èÎ>xóû¬õ~µó¸ÚèY}"£Â›DùaN^ç¡Iïþ‰uÌZ4y{zÐ3ËÃ( ‰49[ܸɃW’¶S&ûÌÆM'<’›ùä[6›G“&oÙl))‘œk[6“ñä$çÖÍ0éÎi™ø  -Âïä‰Áœ`H{%oéôI‡öçØx29„òS2V¹ŒƒÉíÃâ o¢É_ÞYt“ãr«–Jç41/tØÍkÖ½x£›šÇåaUÌÜ[&9«öHôfNûŽ8>µG[ýæÕÎÝ·´3é°r}W!Ëñ:txDM|¨6N–O/ÏÓ½ªrSðv_½É8$3x£r8A~JûªÎÑßéÞÒ„µ&Œ‚Ss˜tCÔôU+ŽHMŒ…‘à3³À3^-Šòcà]ÆgŽ\”ÇË]Æ´ôÉÝfói;÷ª ùð·å6["¹y®¿ -\pÇ}ûíPA¹ªàP¹§Ì3½d å BɘÖUvâRÙªëÌ3,ŠÅB­N¹t`5Î¥ûð&c°ñš; -Cî-¬ÍsÉ—Ùši0´@¼åµ•>ÓeŤ`á¥iÉþD•£ÆX%²¬“(8#F MV–m^Õ8‡W„ö=:~JIJÖ*±ƒg”4'#ºR|×X£ZÐ-OÚö싽­+š¾L¯S,7ß&c_ÒMuñåôºƒcÚ›Q>Å2UóÿæÉ4qC&²¡xãS2‚ËT«†£¡S†ÉÍä#œÖX¥–ªC`ÞÓåŸÉ˜sNëVÖ¡“BG”[.NÞ½,ÞäZucî}¼`(Ž¡@ª$ÃòðÒäƒà Kœ—Œâò‰g”㊒û«Ä9Uݸ×b W‹"C,šì“9[\Q;ð´º4¡¬ ¼,/P%èíÃP± aªòÙ¼›c¯•öñOºÎ4¹gµ{ î.oŠ›t£+Ä( —dÁ&­@º¤EðÝ C2ïÿDp­´‹¤i)õ¶F,•zA;U7vƒ}ÊáôÐuªˆ«´)»åA¹æóeÛ2ãµÛwº Äà (K—úÄ;š65ñ² xFËcgãZŠµÚ˜eêÍ-u®Á¹Ù]ÐÙ8nÁÅCÐNÑÛ†%Þ<¦zç dú/ªO]|ü4_G#ÇÒp&¬iKBãåÊbéN)ê]0åËnýtÃÐ:Äš½Vx|y/ͽêÚ³š9nÿ`fø2 -endstream -endobj -1782 0 obj -<>/Font<>>> -endobj -1455 0 obj -<>/AP<>/BS<>/F 4/Rect[427.784662 757.790154 504.515375 744.190545]/Subtype/Link/Type/Annot>> -endobj -1456 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 744.190545 253.494623 730.590936]/Subtype/Link/Type/Annot>> -endobj -1457 0 obj -<>/BS<>/Dest(section-5.2)/F 4/Rect[65.905512 716.090936 95.494623 700.490936]/Subtype/Link/Type/Annot>> -endobj -1458 0 obj -<>/BS<>/Dest(name-informative-references)/F 4/Rect[95.494623 716.090936 239.403803 700.490936]/Subtype/Link/Type/Annot>> -endobj -1459 0 obj -<>/AP<>/BS<>/F 4/Rect[339.623774 690.490936 372.279535 676.891326]/Subtype/Link/Type/Annot>> -endobj -1460 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 676.891326 341.323725 663.291717]/Subtype/Link/Type/Annot>> -endobj -1461 0 obj -<>/AP<>/BS<>/F 4/Rect[293.837152 628.092498 478.156977 614.492889]/Subtype/Link/Type/Annot>> -endobj -1462 0 obj -<>/AP<>/BS<>/F 4/Rect[276.146234 592.893279 460.466059 579.29367]/Subtype/Link/Type/Annot>> -endobj -1463 0 obj -<>/AP<>/BS<>/F 4/Rect[151.495356 544.094451 335.81518 530.494842]/Subtype/Link/Type/Annot>> -endobj -1464 0 obj -<>/AP<>/BS<>/F 4/Rect[358.52099 508.895233 507.16308 495.295623]/Subtype/Link/Type/Annot>> -endobj -1465 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 495.295623 181.583246 481.696014]/Subtype/Link/Type/Annot>> -endobj -1466 0 obj -<>/AP<>/BS<>/F 4/Rect[260.566156 460.096404 444.885981 446.496795]/Subtype/Link/Type/Annot>> -endobj -1467 0 obj -<>/AP<>/BS<>/F 4/Rect[230.08935 424.897186 414.409174 411.297576]/Subtype/Link/Type/Annot>> -endobj -1468 0 obj -<>/AP<>/BS<>/F 4/Rect[427.163568 389.697967 503.894281 376.098358]/Subtype/Link/Type/Annot>> -endobj -1469 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 376.098358 253.494623 362.498748]/Subtype/Link/Type/Annot>> -endobj -1470 0 obj -<>/AP<>/BS<>/F 4/Rect[443.220453 327.299529 519.951166 313.69992]/Subtype/Link/Type/Annot>> -endobj -1471 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 313.69992 253.494623 300.100311]/Subtype/Link/Type/Annot>> -endobj -1472 0 obj -<>/AP<>/BS<>/F 4/Rect[316.153315 278.500701 500.473139 264.901092]/Subtype/Link/Type/Annot>> -endobj -1473 0 obj -<>/AP<>/BS<>/F 4/Rect[265.59643 243.301483 449.916254 229.701873]/Subtype/Link/Type/Annot>> -endobj -1474 0 obj -<>/AP<>/BS<>/F 4/Rect[202.010492 194.502654 386.330316 180.903045]/Subtype/Link/Type/Annot>> -endobj -1903 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1902 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1901 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1900 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1899 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1898 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1897 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1896 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1895 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1894 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1893 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1892 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1891 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1890 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1889 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1888 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1887 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1886 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1885 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1884 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1863 0 obj -<>stream -xœÍ\[sÇž*•^ä‡æšÊ¦ -"ÐôýâJR)G€ -`å!I¿Ø®²“Ç<ä§ç;=3«™ÝÙ³šÆe¯%±ÒÙ鯻ÏùÎ¥/35“x= Ñ*c -ÞÎþùýÎ;"¸üÇögþå;xüÌ[#‚”!†Y NX+“u³Ÿþµs²óÃŽšÑë§owþ] 9ûöß;ôùæQJkáTò1æãÎ+¼ðh[ ´ò}nÊ;kšü®ówzr‰8«ÿ_lo ÈúÁ?‡…?¼×‡“œnÿža-¼ÿ®~¯Þ/~ná÷ŸîÙK(CÿÍú?›üúÍÎ|î•Â“­µ.ΔŒB›¤ñÏ7ßï<üËËWÏ_Ìð÷ü#•›½ù¸óÍÝêO•«Nw«ÛÕåê -¾®UÞýÛ›ƒGoš¹œ†Â9¡‚r6qQ|‘_7‹¢ÐZb,¼w–‹â -ÆáJu£, -„ò‘暉â*æã à(‰Â±°’?#Wá2^EQ„„±ðÆ*>ŠkyVJ¢ÀwŒ…²›ÌÈêzu±( -'“ÐÉo`#×0#WK£p^h#F®ÁJ/V—Š¢ðZa,Ì6rZqãQ…wj¯M࣠[-ËZÁŒ…ÚÀFn`6J3xHQç7°Bq¥°^Dë”3ðg„P\ïs禴W"1½êûÓçûž>úz‚­j¯zU=©¶rÃóG›DÔ)`»ÂG~ÕÎÆh]´»L˜lFiÉ6°©~²öÂ|P¥WÊ+ <Ì1¦¥ò¾Ú¯^W'øþ²z„ïÇèþ%ØÁÍêF÷9V‘óƒ ^þœa§¢K³TþB_^;)’ÖNõcŽ‘qÔ„¶! ?2Äc£P1(ÂZ[ØŒQQÏT€†HküꆄtÒÚȆ٤d„TïªÕé)ú{Ä|±ºÜ›…&­ i¨+¬^©` ä¢_ðfåø‰ô"Y£{ÑÖRõÆã\D<ä¶@¦À^Po÷ Ýëê1Ôúh®Ôõˆ^ë= %8ž4h}kP~aƒ6Ú …‡Ã™¤01«7lQç×@×aø‘áôî‹ÆytÐVs†Žv)òµÂ‰’4–'l1€Áh90œô™T -?Ècòß-àF_ïä\•Öc“•v.@« ÔŸe ŒRôD¾½{éÃ=Œ>¨sY/ìtPž°^À[«Ôõ— «d…³Òƒ¨ ¦ç”°ÜnôÍÇÌðÃ~À‰#¥†+ -/N’ih‘ w’†QZ¶¼³ðL¨àæ9ÂDã2%7&gü -ÓPOÂ¥êb_û ª)3XßÎÙKaM,Љ”Õ¤›[.g"¸ ©CÒ a‡PL†ÀöÁŠœìõ LDtg‘ιáÖ®–w1žøz oÇôÒ°ÛÁK+ÓðÞ ÒÜ5^2 ˆ@£¥à¦›&/WQH8$,~©ð -ê‚Ýx©´NŒ4Eccgcl¼‹ˆð8c"O“çíB -J%Ž¼R"‚It -ßW‡IÛùú¢÷á׃] §–ê¨.Ѩ¦m²cÑB-çSB\Ö-(,5‡ ®6ÅõÂN‘ê n½°˜TŸ(¾\/¼`" þ,6‘9®y\=›åÕ~‡á”Ï@õ^¢úˆ¤$Õ/É«ŒðÏÚt ##œR‰™h¦ÝÁ§–8c×úÄðži,ÂJ/yµ&5,€ImR#1Š±.($øã0¦!3Ñ<À̃E rôÆ3šòà+írö0^2‘²‘ÞõêBË„Õ!&o— -¯  ³Š‘âWF &sŒheDÛ‘ ÂRñ¦Žò× ;xFÿÆö•ˆ< aï ÷Ë17îz¥Iˆù,ò©§ÿúÊÈoð%¹lDÁJüPxI\…Œ.HGÓß)ÈØ Bsòë´ÆÖÿÈpl$Õ4RÈõÂÈõ¥³<á…Œ<*Øb­Neäá¡?é¾/D€‘–ÑÕsŒÌq÷@x8ú±Œé"WÕ+‚²p aÀÈÖ©rGèähY‰¼¤V ;x;Ewˆ¾(ÿfÃØ®ÞW·sDÎÀôÞÇ×)ÑÈX×1PÕySH1øÇÑé?þ »Û¯¶§âuT÷°u9™‹·)èoµ ÔS1xÊ!UÚÃJW÷'¯g,(p¿¦=Ò6’G(M½šA«Ÿ÷ì§Â"¦ ÜŒ¶slë·m»ƒöýÐ}£ÉNKnQŽÚlžAOÀþo«ß óŸÃrðÚ Ù–Ž«§Ð×_C7Ÿ@{k½½¿@òfÿï>oäz#62R… ä|#êF°WR_ºû(V7*ê%*=ßÝ+ÀtTÒ; Žâvf9ª—žLæ9O ÊÈþòË(ÏûŸä"L!U*ñ2ÿ†<Âþú,¿»w'¹jF#wE;“¥’ÃþE -8™ag"EG5#vGjs/©M埑–›Í8“Uv¯œ–ª¿ò´Žqójâ -ö+„jŽ¡µÍ%6¼ó°ŸÓB™ ‰ÛLê[;@ÀkU§³8‚¼F×›$&ájKUä\Xe·W’m{ûÅV7úüðßÏ‚L_€tár-‘*>˜m0VÍf_‚¯Ö¥êZÔ¾§}\ ùÿü÷´³j«aË=Š’ïBà1úó$«ÑA âs”)6+šÜÍ#¿f;ÞdòEô©‘Co‚¡tä×]û=OØWh0,Rþ(=¹T6¦ó°ž¢1¯7p›)ðõÆŠðQI¸ÎÙ˜‹òOw§èXœ…ä Ý|ž3t -_ȼïäwê„÷.Æi2­„—V¹ÄÇfšL 42ÎýœZ¾¨^LÆ£ÁƒJøX¶w£\\G¢°®øjTdY[YshÝÔ·W™¿Éœþ:gƇ” -?ÎLy˜ :Zræ;ÛFzt«E=™˜ÉÙ&“w6±[¯(€·``“©H'@py­Ÿ aîšMÒÓ+)ADc6°6F-„ÍÑ:}ã·¸ØÎAÕ°pd¢Õæ¢Vß=:3€a¨h¹ì¾Óp‘©ß*ªÔVåبdŽ)×|\o ¢±2ãrÊFƒœy×@uör’{Þ :D<Äï ÖyðVõ0'Ïy«éAfªé%A¤¢I¹æöKX»É‰ñõÉÍÕ.É°›/^‘ìîDi¹9V°"ÉnšA¿E°Y$8-8>¶ó$æÉ ÚöTïõb·ô‹«Hv7¥®­Hö&ióŠ$»½’¤ß;©8F¯óÕúcÌÕúÜ–n• |j1ÑÞ6¢z-ˆògbÎãšI'¡Œ1"fÚ`hš"ÀÄ ?mbÊ­&>>©Ó.»ý.ÿSÂ_o§nÃ=¼?‚Jç‘ÞCÏÈÑ>.9Ý=Á#}z˜Ë?‹Õˆ­ê³êô‡2dœ§?ä;ôéôãtoe(p1èÄG¹<çã³Óg?!Õ0a`°wl^! -I^¹þv󹺶íQv3Ÿ4WìLÿD¹zg’6ÏÕ7Y’À{‡¼Ç¢v"ª•îåó|'å–”"3*iù`º[…™øê²h,¨G!¥j6³QÏé¦9'?=W×"ïmHh› c-ã‚Gë\¢íÕÝ£ …sõè…TšžÍn¦\®Þ+v®®DZÑù.æ¢Vß½Ta,ŸËÛíöšäOQž‹F¨˜²³Qý‘0½Î DàÑKU»ó“ B6{‰Ž².Õyø³¼!§`é &a¥ÌG•¸¸¶ó¡Ó÷øòÐÏã\d9É‹]ª¿6»([Üg¼XP·:gfF€~ °Å´¡ó(b]u¾|”¨VÓÑAç+D¦ktÛ„00ع6­€ÆÛ øØÎÁÎt¤žŠïÉó›a°sÙ±{rk×'tfˆ š R*>ž’>¡wÅͨO¨Ì&¡Ï»Ç‰óÚ}äíGó1ÊÀ‡w¶Ýè>¼xK1?Ïú±N±Øhç”ÓÜ4=&”ˆ,ÔFÖRN!l Ø¥¥€°{À¯t@ˆÇÄ̺ìfÊ„½±â„: .F@ÈÆ\Ôø»7K\y„îe+¿]"þ› Ø îåÐë»>—¹žçã×dòï§;ìØwfƒÙαÔ+(ȽœdÕ8Ì1s]Â{œ xǹpW—ñ\N¡÷sYìplÃwÉ)îœI-Œîep´s¯-Œ.ìÎôùÄ/Yû¼†Wÿõvîöþ Ð\¹A‰ -‚‡ƒÆJ”‰øš",»Ó <œoL+8ðÝC´Óx¸6›/yP–Žár±k‡elðØÍ”äáÎX1y˜vâ¶w¹˜Kòpïn½1#­óÎvo·,ÀÄ_èp2|1‡°÷½f?÷ôdÜ!I¨on`ƒ8;¿¨2‡NÎh­JB×gkÙ@¶áÞa<žä¥‡™ÂWï¿ÊlzÒaT¢ü[~«¤uŽ‘¯Ñ"Zœ©!·ëF‹‹6¾!ò–³¯–ù¨À&+ÁÕ2/x³Q·› Jœ1tZÈúî.vósWÑ\k99dWCà6°ÖU¶°¡{@áÝPÜå”éß9𳸊ÞX1]…TÎh¯pbÃ.ê-ºw Žì‹†U×µµ_ƒl(Ö:nbšBçÎá7„I†.qd£z9[4ñ±Ðôó˜”Mè¼ Ÿ c›±î®raw¿YǦUk… V0DµÉtvèÊôZ ÝÍ›ûA¸JŸ?êÞvqžóG…ÃÄ ¼É—j±1ƒòè¦]žÆn¦,å]Ù¸Dé­D®ž¯¤bc.Éw½Û–Æ°T;ÄÆѻؿ<…±¯‡î=<Ì[3i^òå´ý‰6¿¼ÎÉñq΋ßf¢yŸ)æasÇâ_:‘?—òÆ ÐæU~òW¹(r”WÆKìE>äH&ñûó’³Þ¹»e”&ŸhÑj~Á5»Ù_/€!ÎïÍfc`Ń°Ùê»6˜–ó¬!÷öÚzøÍüâ6€vïZ»´7CLJ^ØÊn¯CÉm_e~âªn7sIØäe2¡è¾ܬ®Ò†þ`Ž7`òÙOJ¿®!ZÒ©WZÀ~<,’Ž·”ïÌ•:Øõ- ®˜º<´ µã–’ Æ©¥mø\®¨7¡îWÏiaê?µ8ýø¿¦?©Ž6K'éø)•.ïÍk¯O²ï ó:ßÝlh¹ˆäÝÚ^›ù2ÜõnÄV¿þ)WÈY -endstream -endobj -1780 0 obj -<>/Font<>>> -endobj -1433 0 obj -<>/AP<>/BS<>/F 4/Rect[323.563959 757.790154 507.883783 744.190545]/Subtype/Link/Type/Annot>> -endobj -1434 0 obj -<>/AP<>/BS<>/F 4/Rect[339.202631 722.590936 487.844721 708.991326]/Subtype/Link/Type/Annot>> -endobj -1435 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 708.991326 181.583246 695.391717]/Subtype/Link/Type/Annot>> -endobj -1436 0 obj -<>/AP<>/BS<>/F 4/Rect[309.944574 673.792108 494.264399 660.192498]/Subtype/Link/Type/Annot>> -endobj -1437 0 obj -<>/AP<>/BS<>/F 4/Rect[453.532221 638.592889 486.187983 624.993279]/Subtype/Link/Type/Annot>> -endobj -1438 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 624.993279 297.569574 611.39367]/Subtype/Link/Type/Annot>> -endobj -1439 0 obj -<>/AP<>/BS<>/F 4/Rect[219.379145 589.794061 403.698969 576.194451]/Subtype/Link/Type/Annot>> -endobj -1440 0 obj -<>/AP<>/BS<>/F 4/Rect[371.979975 554.594842 520.622065 540.995233]/Subtype/Link/Type/Annot>> -endobj -1441 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 540.995233 181.583246 527.395623]/Subtype/Link/Type/Annot>> -endobj -1442 0 obj -<>/AP<>/BS<>/F 4/Rect[468.636957 505.796014 501.292719 492.196404]/Subtype/Link/Type/Annot>> -endobj -1443 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 492.196404 297.569574 478.596795]/Subtype/Link/Type/Annot>> -endobj -1444 0 obj -<>/AP<>/BS<>/F 4/Rect[214.509272 456.997186 398.829096 443.397576]/Subtype/Link/Type/Annot>> -endobj -1445 0 obj -<>/AP<>/BS<>/F 4/Rect[443.720697 421.797967 520.45141 408.198358]/Subtype/Link/Type/Annot>> -endobj -1446 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 408.198358 253.494623 394.598748]/Subtype/Link/Type/Annot>> -endobj -1447 0 obj -<>/AP<>/BS<>/F 4/Rect[212.540522 372.999139 396.860346 359.399529]/Subtype/Link/Type/Annot>> -endobj -1448 0 obj -<>/AP<>/BS<>/F 4/Rect[313.533441 324.200311 497.853266 310.600701]/Subtype/Link/Type/Annot>> -endobj -1449 0 obj -<>/AP<>/BS<>/F 4/Rect[178.953852 275.401483 363.273676 261.801873]/Subtype/Link/Type/Annot>> -endobj -1450 0 obj -<>/AP<>/BS<>/F 4/Rect[296.315668 240.202264 480.635492 226.602654]/Subtype/Link/Type/Annot>> -endobj -1451 0 obj -<>/AP<>/BS<>/F 4/Rect[378.4685 205.003045 527.11059 191.403436]/Subtype/Link/Type/Annot>> -endobj -1452 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 191.403436 181.583246 177.803826]/Subtype/Link/Type/Annot>> -endobj -1923 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1922 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1921 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1920 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1919 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1918 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1917 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1916 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1915 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1914 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1913 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1912 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1911 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1910 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1909 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1908 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1907 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1906 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1905 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1904 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1862 0 obj -<>stream -xœÍ[IsÇž*/ôA´"[‹í -Rå=ê}9Ø•r@a‚E@¢èC’Š|±Se'ÇòÓóõëžÁÌ 8A €AO¿ý½ïu7ú¼Ïðø:¼8Åsç¼5ªÿ·Ÿ9Ì­¦/‹WºøË!>YÓ7Jæ–1ëlßY+żÒý_ÿ~8?üÇ!ï‡Ç¯?>ÿ ÏYÿdžû­/oá\ˆ\soÝóöðLÍ]1T~&RºÿS"ùSíûðyþˆå®ÿWém`2N\ûÚV¾~ûU“¯Eñ=±UùüSüÌ+Ÿ«÷U®ÿÆì.9—á_¿ùZ%ùÝËÃÒö0G®sÂôµ–¹ÓWú/>|þç«ëË«}.sšA2®û/ß¾ù2û6;É>Í8žG™Í¾ÉþtüÃˇ§/“)·gÂù\3Ï!”·}íDn´ÕžoÁÆëìólÝfg»3Ãìfø鎷Ú2/¼u37&Ç‚}™½Ÿ}˜=Êžâq„×Ý99«”Ò®o¬¹·j#;:»?†Ve¿7÷Ê…zQʘí¸x²_.œ ‰Dw³Nbä0ò†Ù'#£2Ýòò(û¸ÎÅÖQcsgfwÌõ•S^¸†«ñàs‘h?Wöˆ\E—;grR©Æ ¸Cg£ìÏ[<¯³!þÎê÷ arÅô~ù橯–3/µð5^M…ÓG+¸6—ÂpÔ¨ú¸…gS°y…0ÏÆH£¬·™}É\.¸tÚ/OØkJêrÅ”—&o&ÊËÑÝùéw«ìý 9´*·R{¯“¬l˜È¹ÐÈý˃—´Óà°–CWr¢LΤppZÉ;Œ70°áÒ ½OöPv î|‹+7AÃ1M ËQÑ}¢L3²Høûz!ùLBAi¶…Q ·¼ +£µô‚;¿Ä|ãëm -ÀàÀÎ%^Ž[ˆ½,L² <êDïà—' '„ùt–¸ -¯CÊ:!rÉ!‹¬W0=‰Y¿R -U½ß&„4’Ú”eàþøXQ¼Î©¼Š»MÑ0O·žg¥´·¥"ÃåJÁ¼Æq¨Ñü×$X=ý]c¸2‰ÂžÙ"ï’˜1{Ý‘ð“ì¨ELàÀ`§DáÙ—Tîh‚Šòyr j^hŒ.3'Ç -51ðûÕÊ뚃®=#¨“}_ -ôÇÌâ!³‡å;ÓÈÁc³g´ÈRÔ$EFÁàý[Ò ƒÛÄ•hîÐÓJ[ÉÏkÊ=­rBz–RáœÌv]ŠR «¢j75S¤êarDZLµÊoVyBµ‚„jÑ"'Ú"&à -M-«$ëÕú6å¢A2Þ lLXˆ7/]6"³¢ÎSjVØ#ÊYrÕâ°†o cb±d’Še¦d§¤ûaŠ”•h¬™D§0ì÷I“ (Ñ̤Êž£¢ÀM(~#î»E{Á@™MHmUØ0¤TÜ抡° &”¥xšÐõ+™$X…àïYr”ùé˜æî(û]$Þ71<£ÙC& ‰'~C|Fj¼h¨«¨6¯Ø=-Íe„t‹„a‹Ê„·œéoŒK Á_1ê¯Îs×)ªÉ9]/âcçö­iéìGk¶õŒ•[ÑÚà”’&wÞÁŒI¼UE`’ÏHÇ£l LO×ÇÉÆ£Jʾ4¾ÿë¿k]v{•¬h ¢CTáü9Z‚óa¦-—à›/Â[¿~ÃB£½ c¼QÊ7¢aE¢g-ð±JSp `ë…k‡š…Ò¿]K«&kœb944²;¹´#ó!­’=ÝV>Öó…âª;ÁÝwž@È×8Ñ}'"í”îJZÈ°ø„&Íu'} 0¦ìÑ˾!? -ï¾HÎiÌÈÙÁ®¬IÇT•ÍÝ’Ö~¿½‹IçrW®;“¹ H¾œŸP=D¢ÆãØÒFñ˜ÒÈï¦T"R´m¡ÁÚšmé•:¬’[¡ù<þaŸ^YßÁÿŸzeWÒ•#½ìþËƲÐîî¨Eî$Ë´yzw4,.z}W2Û¹ã u¥/p}¡Ÿ‡Pß0©ï¨¹¨¶¥»†n˜´”ÜYŒ}zìòA6§­ö -EmŒ^ÒTÛ¨a¢úÊz×´ÂsK¸«2nW‰Ô!‘ -ò66?KÀ¨àt†FÔMÆň:\¬cîɵÝß–¯ wÒÊày‰‡¯ˆ¥u—j¯;ÖˆµÏhñlLž]@Ù#sgãç)ë‰~Vž 8‹§(š=äO®xèÎÌA–§­>Zu¹#£œÕV¨Šóxm&^ìí ‡ ³ø“ʼn™„ö²çi¯}²—Eζoù6šÿœ¶÷íÞáU _;ÎÚ-QÑï’öˆ.;óÐ!Qí…7E?6¤tæí]:`ôO¨Êtà¼+™=$ªýâÌúùæ΋ôX³PWt©DÎ9 ¿‰êL¯– Y͸N,«ûÁ+½að©6¿h†ÁÇÙ<–½vÒ€ykÂoh6Z:³%@Ñ\0®e#%V=Vl—2ÌF½ùðË”/ÍWÒ0”]o¨Ñ©‰ûQRÞ¿ýO:a1ÝR—šåܸð[›Ä«û)3Â}Ef—[ªÈZ8¾‰°,ž?«¯ÇÇß¹U? -endstream -endobj -1778 0 obj -<>/Font<>>> -endobj -1415 0 obj -<>/BS<>/Dest(section-4.2)/F 4/Rect[65.905512 688.891717 95.494623 673.291717]/Subtype/Link/Type/Annot>> -endobj -1416 0 obj -<>/BS<>/Dest(name-uri-values)/F 4/Rect[95.494623 688.891717 160.650873 673.291717]/Subtype/Link/Type/Annot>> -endobj -1417 0 obj -<>/AP<>/BS<>/F 4/Rect[118.998774 653.692108 161.834467 640.092498]/Subtype/Link/Type/Annot>> -endobj -1418 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[180.091547 653.692108 221.049311 640.092498]/Subtype/Link/Type/Annot>> -endobj -1419 0 obj -<>/BS<>/Dest(section-5)/F 4/Rect[65.905512 493.195623 89.131635 474.475623]/Subtype/Link/Type/Annot>> -endobj -1420 0 obj -<>/BS<>/Dest(name-references)/F 4/Rect[89.131635 493.195623 169.812299 474.475623]/Subtype/Link/Type/Annot>> -endobj -1421 0 obj -<>/BS<>/Dest(section-5.1)/F 4/Rect[65.905512 462.775623 95.494623 447.175623]/Subtype/Link/Type/Annot>> -endobj -1422 0 obj -<>/BS<>/Dest(name-normative-references)/F 4/Rect[95.494623 462.775623 231.160395 447.175623]/Subtype/Link/Type/Annot>> -endobj -1423 0 obj -<>/AP<>/BS<>/F 4/Rect[291.740961 437.175623 446.004389 423.576014]/Subtype/Link/Type/Annot>> -endobj -1424 0 obj -<>/AP<>/BS<>/F 4/Rect[270.213617 415.576014 507.8706 401.976404]/Subtype/Link/Type/Annot>> -endobj -1425 0 obj -<>/AP<>/BS<>/F 4/Rect[322.304926 331.577967 506.62475 317.978358]/Subtype/Link/Type/Annot>> -endobj -1426 0 obj -<>/AP<>/BS<>/F 4/Rect[391.918695 296.378748 518.573481 282.779139]/Subtype/Link/Type/Annot>> -endobj -1427 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 282.779139 203.570551 269.179529]/Subtype/Link/Type/Annot>> -endobj -1428 0 obj -<>/AP<>/BS<>/F 4/Rect[151.495356 233.980311 335.81518 220.380701]/Subtype/Link/Type/Annot>> -endobj -1429 0 obj -<>/AP<>/BS<>/F 4/Rect[372.719721 198.781092 521.361811 185.181483]/Subtype/Link/Type/Annot>> -endobj -1430 0 obj -<>/AP<>/BS<>/F 4/Rect[145.905512 185.181483 181.583246 171.581873]/Subtype/Link/Type/Annot>> -endobj -1939 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1938 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1937 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1936 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1935 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1934 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1933 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1932 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1931 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1930 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1929 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1928 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1927 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1926 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1925 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1924 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1861 0 obj -<>stream -xœ½[KsÇÞ*Ü mÇŠ²ãÂÁ刮hµóž¹¤`!ñ ’¢I*ô…J•sÈOOOÏìÎÌbw±! &ˆÝéÇ×Ý_÷@òˆŒ -x½¶¿4'¹ÖFI>úûûáÏÃ\ ¼YþÆÅŸ‡p¥äHr–«¢PZ´9ç…ábôË?†Ûá?‡dd_¿ü4|óW’£Ÿþ5´û•©¶Bi.ˆ‘÷<—ðÑD—O€–÷¨JŒž¼Ê§ä¾½Þ~Êr=rÿÅúöé'·Utûñûº9FÐò>š]?¹k]Çû¢õlnü¢”À³Šq32<#RÈv*F ,—’p.$)vð†Ü¦¨(¸Òøñðà3ªr¥WÜ[ HÎ(§Ä´˜|à†`r¡27V¥<ëþÛrfrSP2jþø,Äc;À½ÿ¶`~ £ê2š3}ú½·}`ô#;A¿÷¶k¾á@ŠVZ]|mÉ/~>"Ciÿ€£æ±]©0áVX»R}ÑÝ×$âHnL. # sV§^ìZ?ÿÿYj°qÒ.Nhuª/º›XùF`wׄ9m»Žö=ûbÄXšd©f0¾þ€÷¤ÆMžDëO-ž?¥rŽåY¤¹#»"}íY¦Ë¬Iâ­c|ÒlL®ŸéUªi7^©æöx%EñjŽc{\ŽçY³æŽºŠãÕ£¾„É £ÔÐά¤{׃œãeegÝEÏõ«?¡›= ëO-Ȥq>ž§AsWý}}ê/ŽgR—²%;[ÖŸçe³æκìÏÄÂ(žÍqnÛñÃsýꦻFOÃúS 2iœçiÐÜUŸA_ŸúŒã™Ô­nÉΖõçyÙ¬¹»>ûÄ3±0ŠgsœÛãv…Ê+5YK÷®9ÇËÚÎúŒžëWŸB6{ÖŸZIã|£x6ÖgN˜ý3ªÿŽµþp=¬þ¦†²Ð³ˆÈM! å£ë÷Ã7^,/ç#Âr”À -"F×÷¯²‡WÙ2»ÍÙ 3§²x•³+¸ž¾»>’ ]?‘ D6Ë~„ŸøYfxÿ,û¼oàóM6ÏÖÙÞWÙ2ËuÎ\ŒP´÷rvÿãÙMö®Á@§i‹òήwa2ö5ÊX¤b€b7Ð)Aߤô€z™}š}?_µZ«çnŠ£R?hN¹fšéc±Ï €s°óüyø$¢?28}u·#CíÓg’VȬÁÀ[ø={.©à‹Koݸp‘+UˆBW¸Üƒ¡30ôÞmm=¯®RŸ¾ºëøD=ˆXH¦PÄÅŸ6—W"Ô)C²´Õ6Có_Ö„*–­•á5¡°ù·;@Æs©€[w~ P}‡ mAŸ…lÐÊÚÎñ -Â8ÈnN)Ü™Áq G~k“«‚*c¼Ö•ÎYöÞÁddúHXöð¸Û%ˆ„~¦˜d»"ed—þo¥íoZåZqˆ†[eRfDÒáLN}„¾€dªÁLˆÎ5tY¥ç5 UJÞb×Úfà²ÁÒêÔ¶8D4°©ù/O.a¨kG|͘Ô  ÆÅžÔ­g‚ezðEd˜]·©p‡}=Y£[w¸6ØE7è럼²ß£Ô L‘ŸfÉÚ>M³ùÃßþ³“™%®öú,·Þ¥­/°KPòi—{Â~Æ-)Nù -™¢±‹s° - –CP¿ü-ÆfŠÖ—PTv¹6õ X¡psƒ;›{”páá´©û‰OÚ+Ü6ñ”6Ë®±e¸™}£ªz’ŒïèÃé)»\£±bìkqæ¡EÛq ä·¾ä&ƒzzvn«Œ¼óÌ2hìySëÝ×›ˆ›–hÉ,*Ï%æúÒw‡‡Z[¶&¢¬É5¦×Æ×à¨*é¶L¼RéÝ™ì˜;ë¹å»ªôæS<ÆÀóoaíM¾G½wà÷Yv‘UáíÄ=¡‚OE!€ˆ‘å¡!eŠÒÒ1z|Qñö¤²uŒ|RÈÌ%é ²ÊÌw”˜q\'YFÀ-ÖI+å®ï<Ði½¸®e»t§—”óp¥Lűž/PÔ¹¿Zyr‰M{Þu¬°s¾ófì4¾®ºö‹S„ò%ך§Ø[n£žeóÁó4$e¬e-¹âqCü&!ä²¼[&ô륹‰`×óÐ!.*`3Ü PM]~*üÀS5´¿ÍtÄAUò3è´*Ц®ÖNq_,÷{Ï-`W“kД„çLhÉX2hÊhÌü¼aÔ¤*gTèñ©?ÑÓŒ€ñ ÁßDçõèÐÆrɉ0 º&IÉ 8‹íZnÇ$YöªÍîÔ»?‡ûÚôËá fLAdÍk0l_cˆÆÀy›ˆ°8ã–ܳ\ZËqMt%œPr*dQuío“c =×qýÜ·²wɈë;ÁzrÁtìîæÅ™ÏãÒßrÌ-6¾«ì ŒÀeä,’»ë&o+dÂÍ[æÜË/±éôÚ9ÓZW-<ºè -›Ó²âá²'8Úoªõ³*)ÀnÌÜ&(n<ߗϹÆ^­½ªxª½ÁÞ:R¯Íàsßw7YÛ`:ö_Y4û­ - ÔD¤à5jšUã_?pÝdåZŸÅÜ|åâ7Åû®]ð»Oë@@2d×À§Ì[»Ûßo¼Œyçä­¨„y†óªË»žfsóÆ›âª|ê€õ©x^ te‡J žÝŽÇ×Σ¦8ð]Y ÇÄœÐBº“ÕxÐDÓB~«„+Msó/žüJ˜Ÿ7~8d3ïÔºbÌtv.AÒÜsk¬ìòéè*Dv[QE©s^ÿŠ&uVI .Æ«i¢îŽ¿«úû<‰S=EÝÈ=ñ«ÒyÍÁNû,‹‡óh*,M -‡Ñ.7 ´;-i5L”Dë\8ÃQu©kºٽ¹7ûÏçÙÌŸÆNjq¯Çm\iWõ¸Là É]Öá¢&ø/§ ^¶ &t]Ët_ÊÚ«iöL›0D¯°Šüá>¿À“ƒ=ÍƱ›feãªSaCwyÊ -à!¢«/â¾ð~žX¡q™y^}ZÃóà׳g=ªaЦ¢ÿèô‡Ã¿"§€JíW˜þj³¡ž¿Ê^f_f_ø½8œÕsi %¤¿Â?Æ`–€(± >%FÂÀÜ' ÃTúå%MÝd_ƒ_f¿®G¬[“ÒI*Iö*ÚùÖà0MRòœTñýšŠø{™—Ù¯àç‹Ã”Ùÿ5L) sÅiÔ!±"×ØJg8>üÞÞd«‡ÇÿzÞZˆ¥(r"µ¬r7 Xö™bªd(9 Z%l‘I±×kVR~Y½þNaJd -endstream -endobj -1776 0 obj -<>/Font<>>> -endobj -1623 0 obj -<> -endobj -1940 0 obj -<>stream -H‰„“Mo£0†ïüŠÙC¤ôÀb¾²ÉªŠÔ¤­„ªMªÒÝ»cY$°‘1‡üûb4ÒªÊÀÌøyg^°øöZ†RŸ0L¿3xÃ^F`¸ÿÅ»`±xÔbhQÙ¢D9Ïö?áÕhQ¢…å¾x,TmïF¸P¢$ÎÔ×Ðϵº"®,_þŽ»ƒ¶:,ÑÔUXXÞÔ"üí¦ê½¶ÍHßAð¦á=܆˜«÷¤ä^·ne}D“=ˆfÃU­¤™<ÂÉ9‚8Y ;‡~í¸K^_^z‹m¡* )qrè& z?zk.°$w ±rG#G‹êü¿=˜ùrèºq`>‡Júqt1rÞ"D·7ÀÑ~¿t ©cò*´Ä¾ã Wg îcéîÙzo]«æSR*ñ—›+ͶõQNQâ"WÂE«Œ¯/7 7s™kדg™ k*Wù(f”ÜûdLc釔'!ÜYLI*–’ ÛødJ¦R"sï”e$ÏH°"y†„|µóÉœä9uÿ‘L«¢u¸ýräó`Ä`ÌxrþzDóYÔ -?¯Z§;§òÝÒùOqÑñ9ø`é^[ -endstream -endobj -1622 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1621 0 R/Subtype/CIDFontType2/Type/Font/W[3[260]5[408]11 12 346 15[250 310]19 28 559 29[286]36[705 654 627 725 623 590 714]44[367 357 700 623 938 763 742 620]53[664 544 613 730 675 1045]68[579 562 487 579 493 318 556 599 304]78[569 304 896 599 574 577]85[468 464 368 599 538 819 546 528 511]2181[594]]>> -endobj -1621 0 obj -<> -endobj -1941 0 obj -<>stream -H‰ìVipçþ¾]Y+­­E¶,ɲ$ëXYÇê²u­l#Ù`Ÿ_‹Ã²_ƒ1.˜#Ä ÐÊÈ@~$L'™4ÉdH:Í1ít˜öO;ÉLó#d¦IÛ!…ΔÖmÚ Cé õÝ• ž˜þèí3{|»Ú÷yßç=V#„h‘¨gb4½óüóçpç÷°GvïÝ‘&´ÞG—#TÊì˜NÏÜ·+3•Ùàù™ñ݇ÆÞ~»÷4¬ßAÈxy Pÿ¢?A¨¦ žÛ&¦çæϘÈ^XïFÈZ1žŸ‘FÃõ€çææÌHÜú^Žc3ãÓË×3³£3Ë×{ÒÓ£–ãõŸçÖøÙ½ûç²/ B[{úý]7¯ôÃú(¬w"!6¡ƒ‰ÀúÔªÕß ’¼#Øù”ñŽ ç[©Å§³ÃY¥dŒ$àwRá·+6Õ2Q¿ˆ½è¨ˆwÑ—XGðeü)¡#j‰cįˆ¿/é'÷‘¯‘¿•¬’$$'ïJ¾, - ½Qôg©IºðºôoT5Nýº»²fÙÙu¹Yž’_¡õônú-À?Š«Š/ß*Q—ì¼Tò…B®RœV|Á0L3W@P@P@P@ðâc$lì$ìåpÄâY‚æá\‰”p‡FfdE.äEõ¨õ MhÍ ÃÿÁÙ,üFxæDTƒÖ vÔ‡Òh -Í -ϲ·ŸÅ ‘ám:ŽoâŸ/…ŠRAØ—ïê9;¾¹XಠøEâ>*CHk·‡Cq‚§‰º\£ýÝp¿wË©mtã––q†œoNlùàê\…׺÷»ÏÍ»šæ«ÂÙO²ó8F|-¼OñqI8dwðºœ!jsoºB´hè¹Çïùò¦„÷ÿ”݃^B  ¼ ‡|D8 À‚Ô +וWëLþ¡‹œ6Æ(•Úrc•Û‘˜¿´ˆ­8"¨ÍóŠQb‰r±³âvf¿!ʈÏÀ#Ädb"Á àéÄIp‘µ2$„ø—Á)­¿55¾ué×ä5(®Ñg`¢ÅGÆO=3¯í‰>¹g ß8ñÔ±p_GãøSÇBýà;²ÃáMâ7ȈhˆðªH„g¥RHኒR` )»,lÐÝ2- ´˜Õ*¶­®·é‰Ë‘s:?žqlpÔò&­ÜTzxUYRÉp ÌW`ý!q±±<'D¿¥RJˆ(’—HJQ/$¶T½ØÜn¨ñ¸ë­”ÉÜÞ2œªÙÖüÇ;>§‚✽7bÃ}no”kqVYÙ¸³;áÛ¼#ö‘Ϩ| ˜fïEÀõÌË508Y~éj%{.Ó×[«½&ïõtz:šÝ´9:ty¼u&¹ÉÝ°3Ö?êM6·ôúFèª=ë0E«íÑx"è¨s¹„C_íŠY:þx‰¬{ÍÚ-‘ -¨ßì?áÀ@ýj 3òúòÉ ÅRyaI2ÈƒÒ ± ó€Â¥™åøÊÈö#%GÊ@]­üÒíÛy%Sl±‚Î}.ü‡L :( -LH3÷~æžð—z]I( .W¾b"Á*sAS•…bóbP‚ÿ Ýmsà2¿»+ÕÎÛjëîÖs˜P鹶Ôk™Mì 0e=y/`þå†ei8‰ÙgIÑ%öÑY-S@³NHÜF…“ûº;|8’¸xκ~xàôêãéñ¡3Â\ü«Ø©]|§–Ðí{àóÚ÷=¼’Ú<+ÌßdùTnBYW4Ž8â¯D_pÛ³ë§_Ü6”æÝŒÛÍoi­Ñ%“­C• -÷VúÌBòõݱ€Ó7yÃÉ™ƒÑäö:+­Õ×9„I$Äú>Ī…zzéòP‚u<—ù談ð*¾w)4v)=½iûÙŽñMÄ°¨UR½‚ûþÉäÕ#ë‚ã„Ëa`±­P“bCyÛÂì#óx,ÀCºï›C$avü¨î.}·éþH‰2äá4^¼ÈÐf%w­¨²‚482÷j3ŸÕZÜ×–±±O`[F¶4h²pñ¤ÄiΑ¤…{5d^Òi´È8­%fëZiµÄhÏܬ½Á›”\>K?…,yWf)ßqb@éaºÁxÃ=gÏÇg_Ù5Ùè^½¶iºÏ›œ0ĵ¨¹Ór‰ÁOÛù)úù£é7Úš<gCçºù+§eÒWDW@ëŸhµ¹Xñk«þ ±ù8F±,ÅY¹ÂÎ/×"\e4¹4ØÍ*ñU±|…ÿ=b+~Ûº´]_]Æ(ªWY#ÿ¥¼jc۸˸ïÎgûîbÇŽ_Ï/±ÏgûÎç³}~=Çv⤎óâ8mI·ÆišÒ7B»QZ¦n똄Є|Et_‚¡2Q -hc_(_à  -CTBÓP[©&»üïξÄi2Ø;wŽþÿßó<¿ç÷üvð˜Kêñ7ȧèи¥ŽNç{7´_¾òt·BÁéâ¨ÃJ™¤„)Ý” t¾^pD£ÌÒVÒpß@O ·¯šãA3•kãæjŸ`ßÿ[˜5±h4ûNç,ËY¢ôÙo÷<Êû£ø1™íRÕ†öì®ü2‘&ÜÙì®ëœñö½b`îwʹÈ;à\aï¹+”é+¥ü ÑHï ¸,êþyš~»[I)ï1$ÀOw¾™ß¼¤„ šDanû.\Ü©/çˆÂŽöóð³í¨õ–P•*öITê_ -8Ú…F ýö?OÈßɈžè<>½'åíßC?Sið -\ï„”ËaÐEÀ¿®Ö*¹NTñ ØZT¬¡˜ØxöhíÊŒ¿rò¹zq­ÊÛW'‹­*ïàf‰Ê3Nj׿¸Y,^ݯ_Ý*‰Å“Ÿ¿œ:½.M.I3Fªìg@¬~uÆô«;¼¦j__¡5ç¾äš¸ºQG -Käæ×£sÓ‰`?}2Ò¬'_‘ÿ†jé•‘#UM÷æmÙ‹ež¼Y+Î]\ß„JH÷îÈ7c - ãH1Oñ2œÈ|®™¯NîÔÿ{“K ì^4ÂÙÒÉ»¿QPÍW¦G¤Y£**&ìõàʳÛòtm›Ëá”໳§Ò‚ªf§†òùÊ‘âvcù —JÆé1ÆSˆÎ;„3àÄ|rª4,þЉÆÈrª,ø#žRÔSˆ…Óœ+Ö*o} i€ü|Wžþ½­CVL¹ç”-…9¥VÛàã„)ËÁ™@‚aodóŠlŽAèpL?D½$⎴ïõ˜®Ùxü!âUúOÖì}DMÑí]=Ðûªn_Ñkë]“†1‡ê“‡£ø¢üö#ùeÓ~?~Ì\°@ªÜÜ$“öL.:ÍC_Sß]Þj¨YQw"°tfˆŠDZTôÙ»@z8tzèÁ"ê–&£Y19,Šš÷$Ÿó³Ú<ž¡ÎkðÕát~Î7C¡…4&9ɵ_·®j4Z© Rß*ù.}¾ëÔ<=‚îe¯Œ“¸´ˆ%êúí ¥…ÇrÝÄð‚ËðoÌê‹·ZñοvÃy3¾bÖè#éV0tT€Æ¬ ó¦Û¯Â\ûžä)c€“cpPÃhFÔÝAÒ'Ø<¥Á*‘à U© -íc°(ªæèû|ÑC¦gNŒ„Fm|`6 ”9l2 y2Ä¡¨Ž^wºÅT œ“(sŽe“g6$mf²ó&Áñ¦Ì á3z­7eÇà <±6%^;¨örØTŽ-&¦ný#îÖf -ÄÖLö×&/y^>Y™|i¬ƒqDõ°;—?I½L„‘Æ© j¿ÝW8#»Oá” ?€<ù5±½™ÒÑtO”’VÄX±¸½¥—‘Ÿ~²½¬s6/—£ÂÞ‘•ÒpÎfËI’ šL&wx -Ë%ƒEï|Žú§¾’ -~S8 &'ŽÒ|j3X>¨V¸bÈ€…\~Þ3XŽÑ‡'9³ÙǹmvÐ>hð'‚ó5‚ða§yÆ •òñ ÐýðÈc”ÏN“0Ši=©P$%ußå­ØU~QTöfWëíµ®ì×%‹N ÿ¿æ“V ‚,¾Àh.¬Ë¯ßТ2aÂ…ìj¡$Q·NOûè!W /ð‰ÕÃÆX|ÈÆ$fæ‡kàóJßÉ°ªUy²ä¾âÍ;§Ï–x9x„iÉ™Xå -)(nµÄ'»K§{‡ôSW ²ÆÆ ¸–A(¯{M•x}¸”)blÑ»•–¨gúáÓÿ×Å ¡ú¥Fn)ãHLm¦Sµ˜-›`Ê11Ÿ9+É-ךlÕã™Ê©ÏÆçƹZs1Ô“÷# zp «)µÝmWðMˆ¤nB7hÉYZ•Y­ký‹ -³o¹P[¦=äJNo”}i«V þ! -lP6R( á!}!¨bÜøšÂò÷]_‰ÞZH ~˨Ž!†ÍdåëË«a_>È×Ô)wøxKžIšÌ>8»# âA² ·ì¸•‹s,Û]î\2BDzùþzt*Æ ÓÑP,¿z.}œN‚®ú1`A\íª¯X|%÷=‹/‰½üüÆÜqûð€#Í¥‹ QØb-‚Ôâ¿söâR*>ÏwøÏüóÏüs9óŸ™o–ø[äÕF ÓîP?rJ?äÊG.Bîêq“Ô=fiÞçk­?[u¶Û({Ü΄Ãá´žÙÒVÔhïãË™üî–jo½ÍÒèl@ëDÓ0¯£Î2«•iG')ö£ýáëöv#š0p³§³¿¥«½Ê1˜´¿Öo²×zvvF-G‡ ²1àð`ƒÀ³I©nŒèA}ÅÓ¾yþfÃÞ­îplp2v¿¸³n–ÖæîPÿd÷¹W»×¸ -\;Uãã®Tv”X¢üÁcÈk5_l5Z°³†R¾ 'QçoLM<´°/À¡ó·‚CGhúÐ$–7iNv­,ϵ>±¯ù?;ð:°}Û²\ìËÇè*öIÎB—‘Ò¯6]2IÌè·'‚ò¼ÌÂ^«ý"ãLªËtg\S“Q2ÈÁþtÀUkð»ÝžÞS£ÖÖå•g}ö¾éÃÓ½¶*v¥µ>¾çÝwc‹/,§%ßS¹ÅCîØ‘£n\jlêºða¬ç6~Ç6¬P€(”Ö¯WéHax®ÒÅF?R GäÚM¶¯R·Ò·Åíµ™Ï[†Á§¸†ª`8ÿÄŸÕç}ûr³7¾º¯ò{_û$ቯ­¡ŸY°«ßé ]È–{ÝWç_Ý„=p{lsUÈ¿mjOfë«?VàÍq¹f334u‡žàȾmSûçïnIJ¸ŒözÙ5Ÿ+ž¿W¿·ß‘y>×â „›âññ¯^;9¢­·ªâu s­ÑæÊÊwX¦E&ËÌlÿËÑP GÙ¬9ÿñ§¡°ÝDÙÕXTºË&×{T`Š|L±ë‘L1PÍ¡[Ø€=ÚjÏMìèpÇÚÒ6 Tð„Fý@M~ùP>¹k÷îJÎP8f旅$%òkx;± -¤cš¥æóü Í–rL*¦—èÚl†âlFýºløKý‰u’½”åm…4ñ6õ7Èß{È›!» 3+$Ä|Ú·1øuõ¿ þÊOS¿‰4‡¬jç%Æ€<˪Yþ¹^vÛð‘z›?€üŒú‹ZL£KÈ+$ó,ñïéŸ&%'zXŸëú fž¤ö Rèì¤G]â õ~€¬zôz]1¬PB³óÔïSïëcüeß›¤!”ex=9 )jäAŒ«ZE8ªÿe,ÿ|R]"Fd>O‡É ›ØÕdšA)“,Ðg!Q-rS*êꤗŠºDAú¬¨éú®¨›Ha=4@9:Igá¹@ó(]"…’ÔNÛh;´a”æ`_¤,r#t‚æ¨Z,‹H'Ë^§õ\im=‡÷Ó¨9ï%ˆBSº}Ž¡•%: -ï´•DvýéB_x†¡•¼þõiYçµQ«ÊºÓºý4ôƬ<¤ŸÅvZP3Ggà1¿Åù§ñÎèßa'Òv”Cš¡ž(ƒíQ#Åzª@.£Í ñqöV…øëü z—ÓRe³”dý°r#7.iQ±»Âqxbb˜1R0)‘_CC .GT_E¢æEÿ0û¯÷~ -endstream -endobj -1401 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 741.290154 312.353998 727.690545]/Subtype/Link/Type/Annot>> -endobj -1402 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 716.940545 312.353998 703.340936]/Subtype/Link/Type/Annot>> -endobj -1403 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 692.590936 312.353998 678.991326]/Subtype/Link/Type/Annot>> -endobj -1404 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 668.241326 312.353998 654.641717]/Subtype/Link/Type/Annot>> -endobj -1405 0 obj -<>/BS<>/Dest(table-22)/F 4/Rect[165.905512 648.891717 204.891596 635.292108]/Subtype/Link/Type/Annot>> -endobj -1406 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-r)/F 4/Rect[210.350336 648.891717 373.763178 635.292108]/Subtype/Link/Type/Annot>> -endobj -1407 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-r)/F 4/Rect[165.905512 635.292108 252.875483 621.692498]/Subtype/Link/Type/Annot>> -endobj -1408 0 obj -<>/BS<>/Dest(section-4)/F 4/Rect[65.905512 603.592498 89.131635 584.872498]/Subtype/Link/Type/Annot>> -endobj -1409 0 obj -<>/BS<>/Dest(name-security-considerations)/F 4/Rect[89.131635 603.592498 263.434125 584.872498]/Subtype/Link/Type/Annot>> -endobj -1410 0 obj -<>/BS<>/Dest(section-4.1)/F 4/Rect[65.905512 393.576795 95.494623 377.976795]/Subtype/Link/Type/Annot>> -endobj -1411 0 obj -<>/BS<>/Dest(name-json-parsing)/F 4/Rect[95.494623 393.576795 175.231195 377.976795]/Subtype/Link/Type/Annot>> -endobj -1412 0 obj -<>/BS<>/Dest(RFC8259)/F 4/Rect[215.316645 371.976795 256.274408 358.377186]/Subtype/Link/Type/Annot>> -endobj -1953 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1952 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1951 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1950 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1949 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1948 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1947 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1946 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1945 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1944 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1943 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1942 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1860 0 obj -<>stream -xœ½]ÛŽÜÆ% ·ÉCœÄŽ$æ!p,#¦û~yŒ£ËÚRt_I°7Aù…`'OO“séªÙêbS쯵»SË®SuN‡ÜålåV¤/Ç/ÁÈ>„èÙþóÇÍO›ÞÛ采¯Sð§MzäÝÖÝ{!|ðÛàmoŒˆÆnþ×æÍæß¹?~þaóÕ?d/¶?üg3®÷ñ¸DJ¥z+£ Óšw›çé#¥–á°EBùq‚²Ûa9 Ÿß|‘Àú°ÝýñfŠÜ%F?öàÇï¾8-'ZuøùTx<ìKð®ñ3—‹?z©Çÿ¶§_!ìׯ6Gýƒïƒ7BÚ ÂV Õ íÒ’í«7_=¹úî›û_o¥î§:mµ}õnóýçî®»ÝËî*}}ÓÝÜtw:ÙÝ랥À§wÿþêÛÍýW{m×V¤D/];æ+ú,Õó<ÕrÕ}Ÿ>7.™>ͬQf¦ˆ?§'ølj‹§‰“\Ôøù5.kiIJÉ^ ¯M¬×é:A?MÅŒ%¥Ü™ - S"¢ÓRK.”þ´—ûÝòhz»•"¥‹é³Kézãœ4Æ:yØ=,^ÐG©½²B&ãß.ßÕè1hg÷xÙke”Œ…’.8CÉ€4©\Äéq]¿¬©L…’[úÛUŒÃ:ð^¿ì åCcz¢ŒÁè°ŒýêegfÔ±„ýêeç-?šô vXéñ€Oµp{ðÔëÆÿR[ú[XFó;ÁÄXÆ?ýR‚gd“öA)ô®jÜÅí*áöïW5Fu -;¦ª1ø)ªô&•ßÉëHÎUé1X·ž{±ÕFNÅŸn°ïädßAuâC¡óçiÕ@f¦ à•§L¦éâ“>xÑã•]a¤Ûzaä²^¨" ­cY—vÑÈŒ¯ ^þ²±iuTìTªÙxÎÓn*YßíêügÝiŽf°Îí:ÍÈœÿ2^ÿ žÈ—®0…øº.idÖ—Uz¢ -ž´ÎeÝÚuJ#sþzVø3ª^ïŽy¸©U³ñœ§ÝÔòþÌÛÕù3Ý‘æøP`ëܮӌÌù3ãÕøê‰| -ÓYˆ¯ë’FæýY£'ªèIë\Ö­]§42çO ç¼?•J…:3ÊM­š‹ƒ<í¦–÷gޮʟJi²S -Ì 8O«N2ãO€WáO¤'ò­,L'_Ù%Ìû³FOT!Гֹ¬[»NidÆŸPOÒŸ‹Ïfêì iû(lÜŸ^ýë³çOž}Kͼù¼{Þ½ížuwºx׉ϧ³¬o»+|RSë¼WA™÷'5¿™ÎZ§d¤Ï¿îþ”>¿Nß_w»—‡Ó'çIA±&ôÚ§BK5söuÌwïpÚôAqü¢¢#GØÀ4—úxO×vv¿ê>Iÿ>.V%‚ðFÊÞBXzjPDtPi°SáoヷݛuÔ ¬æ¥»LŠ·F;µ'åe*ðù]•¦úæf18óe‰©Æ._ˆP:öRè`ä”âÑ_^?yJ¦ðwõ´ ¸ŸvW©üºO’zÝË|4'IÓâOoU$5Χ=Æí¿LT.åÜ›(»SÜ¥]É´‹yÑ]—;´¾WÚ9kŽÒ?š²_Mb<èÜ~ R®ñÚшñ‹Ó \)öÇi³‡éãzúnÄ~Ýý\‹»y‡‹0>ôVJa¼vúvü%mS*JçÓSºë…RÙùÓßõËÎr¹Ç÷>Xã ªcþô÷{,;ï¥tï¢÷Ëد^v–³÷™FPÇö«—÷ÒIO„Ny'Ì"öë——}XÇöë——}›öþÖÆÝ"öë——}XÇöë—™ýô¤a¢’aÙ~¿~Ù™Ùu,a¿zÙyÙûÇ(cÒ!ßöë——}XÇöë——}/Ò ë¼—‹Ø¯_v^öa د_vföÓ¼ -Q8½ŒýêegfÔ±„ýêeçe?½ÀMG¾RÛeÇ<õËÎË>¬cûõËÎ|ÀlEïw¯;Љ_p\æøÉë—c|Õ‰_€< -kwžžøx`«“¿±w"º¨q—t÷ånPžU]ÒÈ·O‡RuT\®ÐÁôr÷*†ÓRÍÆsžvZ²—+ÀvÜå -ôzì4LJ3Xçvfdnj3^yjÃqÚ ž0u£§Ç×uI#S—+¨J¸Ë B '­sY·vÒÈœ?žóþ4Òõ#6°S«æâ O»©åý™·«ò§‘–ìć3ÎÓªS€ÌøàUøé‰|« ÓIÇWvI#óþ¬ÑUô¤u.ëÖ®S™ñ'ԳŸ&örwŠ›Z5ÏyÚM-ëO°]?M ;Íñ¡À Ö¹]§™ógÆ«ñ'ÔùÖ¦³_×%Ìú³JOT!Гֹ¬[»NidΟ@Ï -ÙÛ¨§¿Ý+­šÓ´›YÞy»:wAöy 4+Xâf]a9cÑj| tDv …¡,ÄWuHó®¬Ñ˜u$å- -Ö¬K–3dÖqÞVš^ì®0ƒªf K³IåíxܬÊãõªK -¬ 8O«>2cI€WáI¤%òª §’ ¯ì‘Äå-Y¡%ªhIk\Ö¬]Ÿ42cK¨e…/M’[¥Ý”b'VÍÆsžvËZlWçMcéNs|(0ƒun×iFæ¼™ñj¼ õDžÕ…é,Ä×uI#³ö¬ÒUô¤u.ëÖ®S™ó'гŸ>ôqwÍ—›Z5ÏyÚM-ïϼ]?½§;Íñ¡À Ö¹]§™ógÆ«ñ'ÔùÖ¦³_×%Ìû³FOT!Гֹ¬[»NidΟ@Ïy:)ûñWеf§VÍÅAžvSËû3oWåO'Ù)ˆfœ§U§™ñ'À«ð'ÒùÖ¦“Ž¯ì’FæýY£'ªèIë\Ö­]§42ãO¨g…?îãî·v¸©U³ñœ§ÝÔ²þÛÕùÓ(ºÓ -Ì`Ûuš‘9f¼B=‘oEa: ñu]ÒȬ?«ôD=i˺µë”Fæü ô¬ð§w½ŽÂ)ËN­šç<í¦–÷gޮΟÞÒæøP`ëܮӌÌù3ãÕøê‰|« -ÓYˆ¯ë’FæýY£'ªèIë\Ö­]§42çO ç¼?Çß» »ß»ä¦VÍÅAžvSËû3oWåO/<Ù)ˆfœ§U§™ñ'À«ð'ÒùÖ¦“Ž¯ì’FæýY£'ªèIë\Ö­]§42ãO¨g…?Íø ¡*JÏN­šç<í¦–õ'خΟFÐæøP`ëܮӌÌù3ãÕøê‰|ë ÓYˆ¯ë’FfýY¥'ªèIë\Ö­]§42çO g…?½N §ßœç¦VÍÆsžvSËû3oWçO¯èNs|(0ƒun×iFæü™ñjü õD¾…é,Ä×uI#óþ¬ÑUô¤u.ëÖ®S™ó'ÐsÞŸ!I®¬U"°S«æâ O»©åý™·«òg–ìć3ÎÓªS€ÌøàUøé‰|« -ÓIÇWvI#óþ¬ÑUô¤u.ëÖ®S™ñ'ԳŸ:ô~÷·OÜÔªÙxÎÓnjY‚íêü©=ÝiŽf°Îí:ÍÈœ?3^?¡žÈ·¶0…øº.idÖŸUz¢ -ž´ÎeÝÚuJ#sþzVø3m"Ã鯟žÌ¬š²´›XÞ›y»:ozAuyˆ$#XÝV09G°jü˜õC.õ…Y,Ä×tGãò^¬ÑÕwÔRµ¤T«)LÎGýæý…îÕîôfâh69ZM'ï¾ÃVUÞ‹B‘‚øP`dÀyZu ¼ -"‘?9Tte‡*ïÂyQu@GZß²^íº¤‘7B[ßfR§c~§­ˆ²Ñm&ó_›¢ÌMn3iÒRi?s#½ñ~t¯Ru÷ÆÛN÷§›ßç‚ù jÁOï øQ÷«é.‚¿_|A×/c õØå[+šÔ‰u^½—ã^÷íî-˜Ö±‚Ò^˜•Zl†•´Z[÷¬<襟v×±‚Ò^˜•Zì2+6í–ÒþÎysdåEâd¼£ä85oW: §¿,;ÕØ ;z|ã3Ôáþ¯{‚Ž7Â\GÎiö 󳞡ÈùÞhü|0íù_§j6Øñ`ˆ “T‹Í0”'B MÐÝwã=R»'û;—^¯cA\˜¡Zì2C.}›Žy” G†®Ó®çu÷h+8íeY©ÆfXq¦ZqØ5?œÞpÝ'½0'µØ 'Ñ÷*í´ÌáIüjºÏïõþçÁ{Þ;:Óƒò_˜žZì2=^ÅÞ;åâáM,¿™·GjÖåàė奛áÅ¥oUÈw´~2Ýl|#(å…©Åf‰¦w1½ -÷{Fž­Ü±à„棻ÌGH¯Á¥“ûw”Ýñ±ò°§¼,#ÕØ #6Ž7?V>Ÿ’×M NzaNj±N¢êEÔæø~ã=ë§'ŸGÝýã-ïß›”üÂÜÔb£[än“/¦Œ¥SPÞ¦cÄôJ̉éïáa~µÏj»›»Ýg©•?tŸ¤ßžÞ‡ŸÐ.z眺õNËÆ#%”7óH¢»wxƒQ¡ß¤/ß^ݧC뵕$†›ÞáåtÎë*=§Ýénþ›>}Õ½¸y÷¿é%ØÃîÅB.íô6ØÞêðx<*½NŸÇ÷}ðûwb©}²ZoÇ»¾:;۵ޟϺÓý.üóãÇÿmU—¿ -endstream -endobj -1774 0 obj -<>/Font<>>> -endobj -1377 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[249.748774 741.290154 308.763666 727.690545]/Subtype/Link/Type/Annot>> -endobj -1378 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[249.748774 716.940545 308.763666 703.340936]/Subtype/Link/Type/Annot>> -endobj -1379 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[249.748774 692.590936 308.763666 678.991326]/Subtype/Link/Type/Annot>> -endobj -1380 0 obj -<>/BS<>/Dest(table-21)/F 4/Rect[165.905512 673.241326 204.891596 659.641717]/Subtype/Link/Type/Annot>> -endobj -1381 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-p)/F 4/Rect[210.350336 673.241326 334.478266 659.641717]/Subtype/Link/Type/Annot>> -endobj -1382 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-p)/F 4/Rect[165.905512 659.641717 358.883295 646.042108]/Subtype/Link/Type/Annot>> -endobj -1383 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 548.743279 312.353998 535.14367]/Subtype/Link/Type/Annot>> -endobj -1384 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 524.39367 312.353998 510.794061]/Subtype/Link/Type/Annot>> -endobj -1385 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 500.044061 312.353998 486.444451]/Subtype/Link/Type/Annot>> -endobj -1386 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 475.694451 312.353998 462.094842]/Subtype/Link/Type/Annot>> -endobj -1387 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 451.344842 312.353998 437.745233]/Subtype/Link/Type/Annot>> -endobj -1388 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 426.995233 312.353998 413.395623]/Subtype/Link/Type/Annot>> -endobj -1389 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 402.645623 312.353998 389.046014]/Subtype/Link/Type/Annot>> -endobj -1390 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 378.296014 312.353998 364.696404]/Subtype/Link/Type/Annot>> -endobj -1391 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 353.946404 312.353998 340.346795]/Subtype/Link/Type/Annot>> -endobj -1392 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 329.596795 312.353998 315.997186]/Subtype/Link/Type/Annot>> -endobj -1393 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 305.247186 312.353998 291.647576]/Subtype/Link/Type/Annot>> -endobj -1394 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 280.897576 312.353998 267.297967]/Subtype/Link/Type/Annot>> -endobj -1395 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 256.547967 312.353998 242.948358]/Subtype/Link/Type/Annot>> -endobj -1396 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 232.198358 312.353998 218.598748]/Subtype/Link/Type/Annot>> -endobj -1397 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 207.848748 312.353998 194.249139]/Subtype/Link/Type/Annot>> -endobj -1398 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[253.339106 183.499139 312.353998 169.899529]/Subtype/Link/Type/Annot>> -endobj -1975 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1974 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1973 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1972 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1971 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1970 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1969 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1968 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1967 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1966 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1965 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1964 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1963 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1962 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1961 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1960 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1959 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1958 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1957 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1956 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1955 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1954 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1859 0 obj -<>stream -xœÍ\Ks·ž*Þ6‡TŽØ®šC*]„÷ã‡)‰EŠI96}H¥"_V©’“ŸžÆì]ƒÑ`ikÅÇöýu÷×ßì 0ÜžõOý+±Ö-û¾_|X£†7?ã‡<3º×RC©±¦·F)©“ªÿñ_‹·‹/Xï?þ°xöFhÿÃ~¾qÛ)ŒqNsÚsÞ-®á®™ÝŒ”÷”ê—kÈeôºþö+#¶_ýÇx#A®G/ôò»¯vÃqŠo^ÂBÏ—«ç =ÇóýÀáÆ„ÿ×ïþÄ°_ß.¶ü[C¬‘”)KmϨ%\8®lû~ñìòüÛ§_÷LÁ‡€Qýí»ÅwOº?u7Ýu÷¶;ﾃï_ûrqz»¦snJ*¬f$ˆ¿@ÑtWÝ -Ê¿o–šX¡4ã#a‰îyaÜAƒ_ƒ¡qDZ’äò'd º‘m âqÙRF8«aüÏ„-eh‹IÐîOÇ–´EÝhË<.[–Ã3nŒs?¶¬T -:®öC²emQêXK¶¦†Ä9#œ!]ýûƒºÂð!ù_À³£!”ëøð -..!›ëî¬4%:þÁ3á -°ó“âLòÃÿ_W¥I‘v?*¿¸ÅÁÅ›îÕ0ý|àíy§9}â[ú~ îuÉWÔœàëÃÜ3xÜÁÔ{xü)ãh·)?,¼3³æT@nÎIãéßu/à›ÈϬ,ÓÈž»âÈ2e‰kb8á+E—¸ä£öৗ´"nît$ÜîÀu¦;Ç®d¦Á¾ÌT&æ¹]¦¹Ôµ/ßµbÛm˜OlǼ¥»<¶ÏË2¼Ïg:’<ŸQ„ˆÏ4ÏyÞÚešF.éñ9®ON%1‚Ê]ËÇìÈO»®-ë3Œ«Ò'§"™)²/3•YÆ~ZeŠ úDxúŒøŒtË2Ý™¶ÏÌ2\Ög ŸQ„ˆÏ4ÏyÞÚešF.èóY¡Oa[“•º–ÚƒŸv][Ô'W§O8ûLfìËLebžÛeKú x5úÄ|Fº™îÌØçe™F.곊Ï(BÄgšç#ÝêLwfìó²L#—õYÃg!â3Ísž·v™¦‘KúD|&õ9y[„sJM‰¡J®7­þöúúòõËÔ:öÓîºûÆ/ÆvîXÓ'Ãbï7Ýy¼4+D8+<ƒÕw/†Õb¿ÿ¾ÿºûó°HûlÝ›aù÷¦»ÞYíEÁB@”Ûñ[›­‘ 8߬ûîUÊùšÈ ×gR «òù& (Ô'ݯºÏáëÓ,| -cKƈ¶ÒZ[½»FªMK´0Úm–ìýjûiwº^eŸUšØ÷ã–¦»Pe £ÂJ¶.ÍÅz³hµyðv^m"ç\›ZìüÖ -·‚8 -ùP±Þú{õ×ûË«¤s,†#ÂéjË©ûm÷ùŽ_ml­qrß/Ìÿr/Káhn ¤Æ?…šmvöN†ÚePÀãÑ°#u?×[iù4Ê šm÷Ä~±»­ Nr[^ïv†Þ2˜6\îû-ïD § åVK=i5¾~Úaw¢pVãë§v'JrK¤_6㓪_?í°› 8Ž Õ¯ŸvØð…SD­º :ëFöel×Á¾ÓM[û¬³n„\8ëFx{!Q–éìóÙD~fe™F.œ‹â,ǯ}O¹UO•¸äcv䧗ÅkE4®êZQr“ÌÙ—™Ê,wUØ&S„\èZ„Wq­ñ‰ìoé.ì3³L#¯«øŒ"D|¦yÎóÖ.Ó4rAŸ˜Ï -}j… N˜b×òQ{ðÓ®k‹úDãêô©i:Ó`_f*óÜ.Ó€\ÒgÀ«Ñ'æ3Ò­ÉtgÆ>/Ë4rQŸU|F">Ó<çyk—i¹¤OÄg…>¡Ž -–º–ÚƒŸv][ÖgW§OÇÓ™û2S™˜çv™ä’>^>1Ÿ‘ni¦;3öyY¦‘Ëú¬á3Šñ™æ9Ï[»LÓÈ%}">[¯µJfˆR™íŠJÃåÖ=çMV\¥tÄÁ•ôtyÉߌ~5sµ,µ`æ¿>ûø³jìüb¢´œ­­Þ”ÿíæ&ìyU‰Ü>rUj± 7ŒSK˜Öb½9e ñ‹ìbìtdqoðÁV×þVj¦daõ0Üš¿·^UaÜq.÷=•× 5§~½IëiwïÖO;ìz!ŽcŠUý´Ã®jʼnQƲië…õÓ»à†ã˜Rýêi‡½sÝÀŸv”Q9©úõÓ[}Ç„ê×O;pó0oô Áè¼Ù£óv¯Ù­}GË[û¬óv„\8oGx«µQ–éìóÙ`?ó²L#Îfq–ãW›Z ÂWŠ.qÉGíÁO;.‹W›h\ÕÕ¦?v%3 öe¦21Ïí2 È¥® xW›ŸØŽyKwylŸ—e¹xµYÅg!â3Ísž·v™¦‘KúD|VèÓ*b¸pÊ»–ÚƒŸv][ÖgW§O+Ó™û2S™˜çv™ä’>^>1Ÿ‘ny¦;3öyY¦‘Ëú¬á3Šñ™æ9Ï[»LÓÈ%}">Çõé?õ„­ÎÉJ]ËÇìÈO»®-ë3Œ«Ò§?ûLeŠìËLe–±ŸV™"ä‚>^…>#>#ÝÊLw¦í3³L#—õYÃg!â3Ísž·v™¦‘ úÄ|VèSQ’øsŦå£ö­›v=[T'W§Né’ynÍËtUbŠ›e¹…- s‹V£KÄc$W“iÊŒ}V†ià¢*«xÄãIz³„5Ë2 [dà±õÌÿ­¾ZLí“Øs“}m$aZŒr×+pô²{5k‡ ì7Wcç÷M ÕDsgmøš›îÛY‰]>nEª± ŽP§)ß|BŽÿìš3ºz^]"Ç\—Zìü^’ñ7T;¥¨¸—ôI÷›ì^Rìtd/ioðGï%m?l)Ÿ­þvèèÆ÷F·£§\G;L›]&:LÎê•#Ò ÷Ä…Á×L¨îáb>ê¾è>ƒÇïv·±ÊB;b6ð9´GÄ4$ Åá”9ŽD»“ÍT _ŸNó—iŒ¿‚Š%1ôÀðÈÄ,Ö¥oªÿ·gÝÍûÿ ïKgÝÍÄZÂ[3ÓÖ(Q~2|âØ @ mkº»!i_Úˉ¥5Špë´ÍZ€û—ƒ`ßýa·¯ÿÅb[ -endstream -endobj -1772 0 obj -<>/Font<>>> -endobj -1358 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 707.690545 308.763666 694.090936]/Subtype/Link/Type/Annot>> -endobj -1359 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 683.340936 308.763666 669.741326]/Subtype/Link/Type/Annot>> -endobj -1360 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 658.991326 308.763666 645.391717]/Subtype/Link/Type/Annot>> -endobj -1361 0 obj -<>/BS<>/Dest(table-18)/F 4/Rect[165.905512 639.641717 204.891596 626.042108]/Subtype/Link/Type/Annot>> -endobj -1362 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-cont)/F 4/Rect[210.350336 639.641717 357.586176 626.042108]/Subtype/Link/Type/Annot>> -endobj -1363 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-cont)/F 4/Rect[165.905512 626.042108 273.612543 612.442498]/Subtype/Link/Type/Annot>> -endobj -1364 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[249.748774 515.14367 308.763666 501.544061]/Subtype/Link/Type/Annot>> -endobj -1365 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[249.748774 490.794061 308.763666 477.194451]/Subtype/Link/Type/Annot>> -endobj -1366 0 obj -<>/BS<>/Dest(table-19)/F 4/Rect[165.905512 471.444451 204.891596 457.844842]/Subtype/Link/Type/Annot>> -endobj -1367 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-cont-2)/F 4/Rect[210.350336 471.444451 357.586176 457.844842]/Subtype/Link/Type/Annot>> -endobj -1368 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-cont-2)/F 4/Rect[165.905512 457.844842 234.846918 444.245233]/Subtype/Link/Type/Annot>> -endobj -1369 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 346.946404 308.763666 333.346795]/Subtype/Link/Type/Annot>> -endobj -1370 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 322.596795 308.763666 308.997186]/Subtype/Link/Type/Annot>> -endobj -1371 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[249.748774 298.247186 308.763666 284.647576]/Subtype/Link/Type/Annot>> -endobj -1372 0 obj -<>/BS<>/Dest(table-20)/F 4/Rect[165.905512 278.897576 204.891596 265.297967]/Subtype/Link/Type/Annot>> -endobj -1373 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-l)/F 4/Rect[210.350336 278.897576 358.39477 265.297967]/Subtype/Link/Type/Annot>> -endobj -1374 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-l)/F 4/Rect[165.905512 265.297967 273.612543 251.698358]/Subtype/Link/Type/Annot>> -endobj -1992 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1991 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1990 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1989 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1988 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1987 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1986 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1985 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1984 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1983 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1982 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1981 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1980 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1979 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1978 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1977 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1976 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1858 0 obj -<>stream -xœÍ]KsÇÞ*ÞS¿”Š«prDW4š÷㇒iÚE‰ÔƒJLR©Ð—Uªää䧧wpº™ÙYí@²(’@c¦¿îþúÃîì\‹5‡¯GÃ/¯ó>8«×ÿ|»z·bÎŒ/î~Æw+xæìÚjÅçλµw†i̓6ë_þµºYý{%ÖÃ×/?¯ÿC0¾þù?«a¾ ÷S„’¬çÜ­®à \ ¿(oG(³î·=y}x~ó5€1¿ÞüÇxAn“—zùîëýp‚‘»×Ç°Ðó~ó\ çx²9\úÅ„þ­÷cØo^®îù÷Žy§¹0žûµTŽ ® #Ö/ß®_žÿý»'߬…b££Ö/ïV?>ìT÷ª»î^tçðû¦»½íN:ÑuÏÁðåéO//VO^n¹]‘1L*kžˆè+ˆç -b9ï~„ŸmƒPœ3®,L™âÏÂÿÔâÔ$5ü|Ý8, Âò%l!X°ÆK®„üˆ„c™³F†ð«",É|O5s-as£‘R0ÉÒ¡^ê—Pœ«îÛîdNº"…)âüv¬i~mÞ*œƒî‚Y»² Ä=‡Š ômÈËû¡4@#¶ß­†in;M3³Üøi× -6Ö -­»-àì ,å¤á¶ É‡ó·¦ -¬!xeÍ6'˜’ZŠ yæ„#„ŒŠ&¤’ÒΪuý4 L¸ëôÃEÇq̨{ý´ã†4ìç`©hØÁχý<íßØáıN?ÄqQ„0·!ŒqQ<ôê#v{4ôª—Òxµ‰šfq%ÿ~QS„'¿áiŒšâ¡WIÔ(7!݆^›¬¹Ì=Gó–מ¯•¢MF‘!øýÛLöº7• ²÷™Ì{ê§Uf¹Ð]/ßej×5„/dù¡ÝHž/ÌŠ"òE‘ó|‘ˆ_ió¼´Ë,\Ðæ«B_&°³ƒ,v¥œ´G?íº²¨;4®NƧ3ö>SÊs»L#rI¯F˜O¢K›éÎŒ}Y–iä¢.«ø$">Ó<çyk—i¹¤OÄgRŸ³×+*jB¸ r³vúëó«Ëç©õÊíCØ—‹“.œZþp\Ù½éÎér@©5ñ  ¬ ¾×^ÃJâ)üü]÷'øù¿‚¥Â‹qÁ+½ -V{{ÃÜU¬ƒŸn—œgðèf·9(T~ÉàÂP+\"œÈ T ù<Ýå¥ú´ûm÷¾?ËF©ÂðÖdÖkïý,øüâL8Í y`gvtñý_^_>Kºp§j$÷ Ð{|Ò}±çÔ)&¼wã¾v -“¿<ˆÀsP¥ƒ^8üªõf Ðr]MrÍs r²[Wæs ’)®•Ý­f³Tœ<\v·w{<Ô„+nä¡ŸòBVz $ëݼålý´ã.jq3–XõÓŽ»ÀUÃQb«†¥Úœê×O;î -Ç1£úõÓŽ>.£WÌ3¼Cͪ~õ´#WÅ1§úÕÓŽ¾ôöòF ’Udï©ÝFûž–ïí‹vTraGáUŽ Y¦³ÏgCü,Ê2\Ø}ÃYN/¯”Ln]âRNÙ‘Ÿv\—Wh\ÕòjxïJeŠì}¦2=õÓ*S„\èZ„W±¼"|";á-Ýåľ0Ë4rqyUÅ'‰ñ™æ9Ï[»LÓÈ}b>+ôi€rØPYWìZ9i~ÚumQŸh\> Ogí}¦2”çv™Fä’>#^>1ŸD·>Óû²,ÓÈE}VñI"D|¦yÎóÖ.Ó4rIŸˆÏ -}zXfnöÉJ]+'íÑO»®-ë3Ž«Ó'ì}&3ö>SÊs»L#rIŸ¯FŸ˜O¢[žéÎŒ}Y–iä²>kø$">Ó<çyk—i¹¤OÄç´>µ°l¨ƒñÅ®•Svä§]×–õÇUéS “ÌÙûLezê§U¦¹ O„W¡OÂ'Ñ­ÊtgÚ¾0Ë4rYŸ5|’Ÿižó¼µË4\Ð'æ³õéÅs\ºía OPÏMN(Í™°~¸Ì³|ý¸¹è®5¨Ë2øüýOTcï­Gµr’YØ‚±-ÿ‹î{ðfiUˆÛ\•Zì|U47 Þ ¥rÛª¼†ðÞÜŸŒxߪP·¶*ÕØ…kgs[‰¹ç–dÏ-Q§ç–íÜ’Öq¥Œ …sKñB̓³KR± ¥…‡Úï;+Ÿ`2Z1.-×ó²×O;î &ÇŒƒìõÓŽ{‚É ÷)¼ŸWýêiÇ=G€ã˜SýêiÇ=Áda“¦¥Öð>:§úõÓŽ[}ÇŒê×O;nõl$”±ÎÍ;¹Z?í¸ÕÇq̨~ý´#Wßq&}àVÍ«~õ´#WÅ1§úÕÓŽüÆ©aÀfûC–ñÈÞS»Šö½íؽ}Ñ2!–ñ¯âä*É2}>âgQ–iäÂâg9}ðiØš…Í֬ĥœ´G?í¸,|Bãª>§Ó™F{Ÿ©L¿¿ýo”iD.umÄ«8øDøÄvÌ[ºË©}Y–iäâÁ§*>I„ˆÏ4ÏyÞÚešF.éñ9­OË=Ó&¬XK]+§ìÈO»®-ë3Ž«Ò§å.™)²÷™ÊôÔO«LrAŸ¯BŸ„O¢[éδ}a–iä²>kø$">Ó<çyk—i¹ OÌg…>a=6ë‘R×ÊI{ôÓ®k‹úDãêô©B:Óhï3•é÷Wp2È%}F¼}b>‰n]¦;3öeY¦‘‹ú¬âÇ|¦yÎóÖ.Ó4rIŸˆÏ -}:Å,™¤)v­œ´G?íº¶¬Ï8®NŸN¦3ö>SÊs»L#rIŸ¯FŸ˜OlǼ¥»œÚ—e™F.볆O!â3Ísž·v™¦‘KúD|Nës8¢ä7G”J]+§ìÈO»®-ë3Ž«Ò§ã:™)²÷™ÊôÔO«LrAŸ¯BŸ„O¢[™éδ}a–iä²>kø$">Ó<çyk—i¹ OÌg…>•gÖ»VNÚ£Ÿv][Ô'W§OåÒ™F{Ÿ© å¹]¦¹¤ÏˆW£OÌ'Ñ­Îtgƾ,Ë4rQŸU|’Ÿižó¼µË4\Ò'â³BŸŽ3·9'PêZ9i~ÚumYŸq\>mHgí}¦2”çv™Fä’>#^>1ŸD·.Óû²,ÓÈe}Öð‰Çc>Ó<çyk—i¹¤OÄç´>=WL#¹/v­œ²#?íº¶¬Ï8®JŸžËd¦ÈÞg*ÓS?­2EÈ}"¼ -}>±J0oé.'ö…Y¦‘Ëú¬á“DˆøLóœç­]¦iä‚>1ŸúT†9)”ÑÅ®•“öè§]×õ‰ÆÕéSét¦ÑÞg*Cyn—iD.é3âÕèóIt+3Ý™±/Ë2\ÔgŸ$BÄgšçxQñÁ=¯ÆËg77:~‚좋««SWߟ ¿ç^`  .>ªÆÏ_vne`Êjhà-cu€ŽS9²‰‹ÿ¾u¢ ¾NÕø…:YP˜âúþh/ È¿ µZVâö#T¦¿Px”ÁÆ_º¯L!°ªÚÇ¡6µøùÚ89|ªµ´ÁÜßÔqohgH]×ðxI•(ć¯R5~¡J&0)ýöƒ­Ç*½wê«ÍE/«qýªS‹_¨N Z1x—ªÎBQç¡>µøùúÀ~Vl?ê†ÞŒŸÿlaçP·¾2Õøù›§¼,Xn·»snžúCöæ)êtâ橃ÁG»yÊ[ÏxPúþ#!S7Oå?zþàfª ™QNKwè™ÜIµ»›Š3s{ÖnØWdJ”£o”rËénO!°“îÝðõÙþíZeeóÎ:+&(˜‡daÿ]réô4ïÎÆÍÜø×>í~ߟÏþ^‹s°šsʈ$† 6©•—C;ýwüÆëÛ»ÿmw÷¯gÖÒŒ·¸:£jÀÏÆ¿C[tø94¬»ß¶?í.g–Ö™á¶k&³Vàþb”êƒí}Ž¨¯Vÿ8r´¶ -endstream -endobj -1770 0 obj -<>/Font<>>> -endobj -1335 0 obj -<>/BS<>/Dest(links)/F 4/Rect[249.748774 741.290154 308.763666 727.690545]/Subtype/Link/Type/Annot>> -endobj -1336 0 obj -<>/BS<>/Dest(table-15)/F 4/Rect[165.905512 721.940545 204.891596 708.340936]/Subtype/Link/Type/Annot>> -endobj -1337 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-c)/F 4/Rect[210.350336 721.940545 357.586176 708.340936]/Subtype/Link/Type/Annot>> -endobj -1338 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-c)/F 4/Rect[165.905512 708.340936 234.977289 694.741326]/Subtype/Link/Type/Annot>> -endobj -1339 0 obj -<>/BS<>/Dest(media)/F 4/Rect[249.748774 597.442498 308.763666 583.842889]/Subtype/Link/Type/Annot>> -endobj -1340 0 obj -<>/BS<>/Dest(media)/F 4/Rect[249.748774 573.092889 308.763666 559.493279]/Subtype/Link/Type/Annot>> -endobj -1341 0 obj -<>/BS<>/Dest(media)/F 4/Rect[249.748774 548.743279 308.763666 535.14367]/Subtype/Link/Type/Annot>> -endobj -1342 0 obj -<>/BS<>/Dest(table-16)/F 4/Rect[165.905512 529.39367 204.891596 515.794061]/Subtype/Link/Type/Annot>> -endobj -1343 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-co)/F 4/Rect[210.350336 529.39367 357.586176 515.794061]/Subtype/Link/Type/Annot>> -endobj -1344 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-co)/F 4/Rect[165.905512 515.794061 242.957025 502.194451]/Subtype/Link/Type/Annot>> -endobj -1345 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 404.895623 316.853266 391.296014]/Subtype/Link/Type/Annot>> -endobj -1346 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 380.546014 316.853266 366.946404]/Subtype/Link/Type/Annot>> -endobj -1347 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 356.196404 316.853266 342.596795]/Subtype/Link/Type/Annot>> -endobj -1348 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 331.846795 316.853266 318.247186]/Subtype/Link/Type/Annot>> -endobj -1349 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 307.497186 316.853266 293.897576]/Subtype/Link/Type/Annot>> -endobj -1350 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 283.147576 316.853266 269.547967]/Subtype/Link/Type/Annot>> -endobj -1351 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 258.797967 316.853266 245.198358]/Subtype/Link/Type/Annot>> -endobj -1352 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[249.748774 234.448358 316.853266 220.848748]/Subtype/Link/Type/Annot>> -endobj -1353 0 obj -<>/BS<>/Dest(table-17)/F 4/Rect[165.905512 215.098748 204.891596 201.499139]/Subtype/Link/Type/Annot>> -endobj -1354 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-con)/F 4/Rect[210.350336 215.098748 357.586176 201.499139]/Subtype/Link/Type/Annot>> -endobj -1355 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-con)/F 4/Rect[165.905512 201.499139 294.40307 187.899529]/Subtype/Link/Type/Annot>> -endobj -2013 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2012 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2011 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2010 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2009 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2008 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2007 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2006 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2005 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2004 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2003 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2002 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2001 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2000 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1999 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1998 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1997 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1996 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1995 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1994 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1993 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1857 0 obj -<>stream -xœÍ\M“É툹É'Û°ìFx#t±6LQßG¯fÀÄÀØ;>8f/#Xûø§;»%MeJUÕÕti†I©ªz™ùòµºS%­ÅšÃÏÃáÆkÁ¼Îêõ??®>­˜3ã“»ÛÑøiœ][­˜ãÜy·öÎ0­yÐfýó¿VïVÿ^‰õðóóO«GÿŒ¯úÏj˜ïÂÍ!¤dFëÇ9V—ðK ¿(G(³î·=y~xüî{c~½ùñ&œÜ,LžvèéßﻌÜ=?º…÷›Ç=ÆóýÈîÒ&Ôðo½‹ax³ºáß;ææÂxîׂ{&UƯß|\=º8ÿÛÓÇ?¬…bã -F­ß|Xýx¿ûcwÙ=ïÞÁïi÷¢;éþнË»î|üû¶ûöÁßß<[=~³%x¡[Òfl²[ª»G^ƒWàÆõ5x&À×`hìÈ0Y2³Øšë’”‚Iî”õÇÀ på²;ëNFàäRäà5&òH-M¡š®B¡¢ƒ)ßÁ”+ÈËÈË+¸7”Pv6-Ë*@Z70åÑ8åb;UƧÕ0Ím¦Í ¼ðÁ2À¹°k8¨jk…ÖƊ݉Íì ,å¤á^ò“wçŸ$)°ýÊš­N0%µ!ãòÌ Gp%MH |¤•ëúi,€›:p)Ö黋2Žý˜‘÷úiÇu?h8}ERÇ=y<œ¦âñè´ÕÿÀuú.ö‹" „¹ a|ð‹â¡g -t6«¡V½„3PµñšFqè%ÿy^S„'¿áiôšâ¡g‰×(6!݆^›Ì¹Ì=Fó–çžÃÉ!-2Š ÎïØF²W½©H½ÏDÞÓuZE† Õ…ðòU¦vUCøBö‘Zäñ¨(Ò!_9Ïññ•æ1ÏK»ÈÒÈ]a¾*ôe 0;ÈbUÊI{\§]Uu‡ÆÕéÏøt¤ÑÞg2CyniD.é/âÕèóIti3Õ™±/‹2\ÔeŸÄCÄgšçƒHGí}&3”çv‘Fä’>#^>1ŸD·>Sû²(ÓÈe}ÖðIg·TÔ„0,p¶Í˜?¿¼¼xù,Õv¸¾×Úï»—ÝIX~l‡¼ïÎéåúвÜyMV†LwÞ=ÛKCïä üýM÷ü} ÷¯àRþõØeyÕ]îu³Ú3¸Z厫ÉvÖ“ÑÁó±§pÚ]íZ© -à . ÙÂI¡ÌÀµÛÈ $ën÷ëîüÞÉzÉÂðZf½öÞÏ‚ßoŸ äyμò>žŽLœw¿ßv××ËRDV¿åüÔbZfÜ2«œ…KÀa‰¿üéíÅ‹äîkÿñX\'ÝîîÞ¢N1ὃ“zº(LþöÀð\[R9üRµk6žŽ);ÉŠø;>‡®ÛÉ®“–Ujæ7Üo‘~µßiÛœD>Ýõ‡=¡kxaÑÂÈÄzå~œÞE³jèyÌéÕO;noû1£ST?í¸}:e w<ëæe¿zÚq]Ø9Ù¯žv÷Qµ°L¢ñ³²_?í¸ÙÇ~ÌÈ~ý´#gß‹á 7ïí€êYGÎ}tcNêkgY¶pô“›£¹’BöžÚC´“u}Ñ•B.\I!¼Š~6‰2}>²Î¢(ÓÈ…ë åôõÿp,u›ci‰K9ië´ã²xýÆU]ÿ+ÃÓ‘F{ŸÉL¿ÿêÓ(Òˆ\ªÚˆWqýOøÄvÌ[ºÊ©}Y”iäâõŸÄCÄgšç“Ês»H#rIŸ¯FŸ˜O¢[ž©ÎŒ}Y”iä²>kø$">Ó<çyki¹¤OÄç´>‡³a»9.U­œ²£uÚUmYŸq\•>µ0ÉH‘½Ïd¦ß¿~h)B.èáUè“ðIt«2Õ™¶/Œ2\Ög ŸÄCÄgšçµOGí}&3”çv‘Fä’>#^>1ŸD·&Sû²(ÓÈE}VñI‰fU¦:3öeQ¦‘‹ò¬â“xˆøLóœç­]¤iä’>Ÿ­÷i)Í™°~ødpã}Ztå&û´”“Ì*Ã'?!z -‹½ÿžÛµð²Ÿ»©:µéΰéó÷!Ucç7iin¤r[2ÎÀÍ¿Žù9_”ºðí楻嘱Nm>\ CŸŸV}ß½^–²ì-g¥»ÇWjØ„µÉÊæ#”ÏÇŠ9ƒì€ö—å‡Ür~j±óù1\2‚u»-¨/À½VGºøí榻¥Y°ÆËݦR=ì|¶,)û«Þr^fÀç7ƒË™³PxaöfЯ²›A颛Am3¨qžùàÅM ä6ƒ^=|x9:Ø*àà®åprw°Vy#¨…—K¸•óöcÕO;îFPìÇŒYõÓŽ»ÔÁ‹²‚×7oný´ãî(Ã~ÌÈ~ý´ãº?TÚT¹dEöžÚU´“u}Ñ%+B.\²"¼Š q$ÊtôùhÈ:‹¢L#.äp”Ó–¡¦ü¦¦J\Ê);Z§—ÅF WÕhq\'#Eö>“™~_…m"EÈ…ªExÂ'²ÞÒUNì £L#-U|Ÿižó¼µ‹4\Ð'æ³BŸÊ³áS‚«VNÚã:íª¶¨O4®NŸpI™Œ4ÚûLf(Ïí"È%}F¼}b>‰nu¦:3öeQ¦‘‹ú¬â“xˆøLóœç­]¤iä’>Ÿú„ }7œ«bÕÊI{\§]Õ–õÇÕéÓ†t¤ÑÞg2CyniD.é3âÕèóItë2Õ™±/‹2\Ög Ÿx<æ3Ísž·v‘¦‘KúD|¶~£ÂBX2X¸HjýF]¹ÉNZæ¬Ü}ì7ß,:;øn»Em²jÜTìø½ûù=²jì|ïЙÀ¤ô^ï¾-póeˆËÓBÖ½å´Ôbçû†ÎÆ¥W±û8§ux/Û:>/Font<>>> -endobj -1314 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[249.748774 741.290154 308.763666 727.690545]/Subtype/Link/Type/Annot>> -endobj -1315 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[249.748774 716.940545 308.763666 703.340936]/Subtype/Link/Type/Annot>> -endobj -1316 0 obj -<>/BS<>/Dest(table-12)/F 4/Rect[165.905512 697.590936 204.891596 683.991326]/Subtype/Link/Type/Annot>> -endobj -1317 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kin)/F 4/Rect[210.350336 697.590936 357.586176 683.991326]/Subtype/Link/Type/Annot>> -endobj -1318 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kin)/F 4/Rect[165.905512 683.991326 256.306147 670.391717]/Subtype/Link/Type/Annot>> -endobj -1319 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 573.092889 308.763666 559.493279]/Subtype/Link/Type/Annot>> -endobj -1320 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 548.743279 308.763666 535.14367]/Subtype/Link/Type/Annot>> -endobj -1321 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 524.39367 308.763666 510.794061]/Subtype/Link/Type/Annot>> -endobj -1322 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 500.044061 308.763666 486.444451]/Subtype/Link/Type/Annot>> -endobj -1323 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 475.694451 308.763666 462.094842]/Subtype/Link/Type/Annot>> -endobj -1324 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[249.748774 451.344842 308.763666 437.745233]/Subtype/Link/Type/Annot>> -endobj -1325 0 obj -<>/BS<>/Dest(table-13)/F 4/Rect[165.905512 431.995233 204.891596 418.395623]/Subtype/Link/Type/Annot>> -endobj -1326 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind)/F 4/Rect[210.350336 431.995233 357.586176 418.395623]/Subtype/Link/Type/Annot>> -endobj -1327 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind)/F 4/Rect[165.905512 418.395623 236.357172 404.796014]/Subtype/Link/Type/Annot>> -endobj -1328 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[249.748774 307.497186 308.763666 293.897576]/Subtype/Link/Type/Annot>> -endobj -1329 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[249.748774 283.147576 308.763666 269.547967]/Subtype/Link/Type/Annot>> -endobj -1330 0 obj -<>/BS<>/Dest(table-14)/F 4/Rect[165.905512 263.797967 204.891596 250.198358]/Subtype/Link/Type/Annot>> -endobj -1331 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-)/F 4/Rect[210.350336 263.797967 357.586176 250.198358]/Subtype/Link/Type/Annot>> -endobj -1332 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-kind-)/F 4/Rect[165.905512 250.198358 257.973871 236.598748]/Subtype/Link/Type/Annot>> -endobj -2032 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2031 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2030 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2029 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2028 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2027 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2026 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2025 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2024 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2023 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2022 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2021 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2020 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2019 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2018 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2017 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2016 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2015 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2014 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1856 0 obj -<>stream -xœÍ]Ïo·@·í©MÒ¦hì!mã ¦‡¿ÉcSËRÑd[NcåÐu.ãI{*P zgµË÷vIÇÕêµ%íÓß{ß÷¾™YqM­ùº‡ÇÃðÉ)ÎœóÖ¨õßÞ­~\1«Çon?ÁWðÌšµQ’Ù¾·Î®ÕL©Þ+½þéï«×«¬ø:<~úaõ诜õëþ¹ -ã­ß á\¦¹7nóvu ˜š»í€òn„Òëár ßÏ_`Ì­71ÞD’›‰É·-úöÛÏ÷ÓñZl¿?¦…ž›ç=ÇãPüÈéÒã2üYïÆ°_¼\íôw–9«z®]ïÖFf¼Õž¯_¾[=z~þí—§_¬¹dãŽZ¿|»zóY'»WÝU÷¢;‡Ï¯»››î¤ãÝãîŸ<øîåÓÕéË[m—f¤s²W½šÈè÷Ï%ärÞ½“pžá“IüRxðÏ€‹¯“˜TøxÝ8-ȇ)a¬vÿ/jùž3­½¶½äâý››ƒœ‰ÞJåë;ø9ˆtÙu'#pr*Òz0äSôýËHä50øj$3;¨ -ô€Á‘©ÐMçãÈ€y²¯Ù«0ƒ½A1½æ½c\i šH8cÕ҆oOÔ³0Ï¥ºçp -K~9ÿ¤/…gN §ím–3)”à>“òÌGH‘Æ¡Ï|€4³¸®Æ<¤©|/ø:ýå"Æq3x¯v„ô1nY¼SÒÍc¿zØ‘ÙGyÌa¿zØqÙÚ„£~ûõÃŽË>ÎcûõÎ˾ _æ™Ã~ý°ã²ó˜Á~ý°#³ïÂý…çYìW;2û(9ìW;.û -^Va Ü’Ía¿~ØqÙÇyÌ`¿~ØqÙ×Ü„{SççÝóÔ;.û8ì×;nú^­ß­ð+µÈóð£|<úу  uúKœE‚™`}È‹â¡ï>äè'p{ÍŒùÍ&kZÅa–øø÷Ëš"ÜF§1kŠ‡¾K²Fµqa7òš$ç"÷[Î}¿–’6E†ä÷¸­dïŽ=U Š™Ê:O«Êr¡»^¾Ëúm×½P|Ô‡v#y¾°*Št¨EÎëE2Bz¥uÌëÒ®²4rÁWX¯ -iϼ‹bWŠÉxœ§]W}‡Ž«óŸvéJc|È0CunWiD.ù/âÕøëI|i2Ý™‰/«2\ôe•ž$C¤gZç¼ní*M#—ü‰ô¬ð§Ln~ÒPêZ1ó´ëÚ²?ãquþô<]iŒf¨Îí*È%F¼b=‰o]¦;3ñeU¦‘Ëþ¬Ñ“dˆôLëœ×­]¥iä’?‘žÓþB°ÒN»VLÅÑ<íº¶ìÏx\•?…ÉJQ|È03ÐyZUŠ þDxþ$zßòLw¦ã «L#—ýY£'Éé™Ö9¯[»JÓÈb=+ü©-“›Ÿ—ºVLÆã<íº¶èOt\?µIWãC†ªs»J#rÉŸ¯ÆŸXOâ[™éÎL|Y•iä¢?«ô$"=Ó:çukWi¹äO¤g…?gÖ7¾Û(ßµb2çi×µeÆãêüé\ºÒ2ÌPÛU‘KþŒx5þÄzßšLwfâ˪L#—ýY£'Éé™Ö9¯[»JÓÈ%"=§ý)CÃoVûJ]+¦âhžv][ög<®ÊŸa]3U)Šf:O«JrÁŸ¯ÂŸDOâ[—éÎt|a•iä²?kô$"=Ó:çukWi¹àO¬g…?µbpÊâÆ»VLÆã<íº¶èOt\?µLWãC†ªs»J#rÉŸ¯ÆŸXOâ[žéÎL|Y•iä¢?«ô$"=Ó:çukWi¹äO¤g…?e|ó~R׊Éxœ§]×–ý«ó§3éJc|È0CunWiD.ù3âÕøëI|+3Ý™‰/«2\ögž$C¤gZç¼ní*M#—ü‰ôœö§âž´+v­˜Š£yÚumÙŸñ¸**î’•¢øaf ó´ª!ü‰ð*üIô$¾5™îLÇV™F.û³FO’!Ò3­s^·v•¦‘ þÄzVøS Æ7ï¸+u­˜ŒÇyÚumÑŸè¸:jž®4Ƈ 3Tçv•Fä’?#^?±žÄ·.Ó™ø²*ÓÈEVéI2Dz¦uÎëÖ®Ò4rÉŸHÏ -:Å´—û?ÔÜkZ1ßMÓ®gËîŒÇÕ¹ÓÉd»ðf…JܬÊlɘ;´_"‰]y¦)3ñE¦Ë®¬Ñ‘$uLÊ›¬Y•IØ’!£ŽÓ~Ôܲ~óéB£Š‰0š¥Y§–í¸;¬Êáà©*Q|È°2ÐyZÕ‰ –Dxž$Z¯ÊtW&à kLâ–-Y¡%Éi™Ö8¯Y»:ÓÈ[b-+|©<ÓNS¢Ø±b2çi×±Ek¢ã꼩\ºÒ2ÌPÛU‘KÞŒx5ÞÄzÏšLwfâ˪L#íY¥'Éé™Ö9¯[»JÓÈ%"=“þœ½·Œïãšy QlöÂøóÅå󋧩½ n>ë.»oº‹î¤óLÿÙ¸À7Ý9Ýu@ÊøîC23Ì »óîËq›ƒ°íÀøø‹îðñ¾~Õ=ë^Œ›\\u—{ d.iáIÅVg0W@zBf=}yH–Ÿ„·>ð…iÂÅÌ@6èú¨ûy÷1üûþ}”Í"J†SPÐRhÍå¬ö÷‚@ºž9é7·ªž®!Û d½Œ%2ù=PT‹ŸçG„£{%ÍíF7ßÿr¼ê^-"†Îz÷ÄTãˆQšÁé/\I6ó5œÂî!ãþ!Ï—ñC&¿~jñ üXÇ„4F«?Wj8K>7ÈYF™ýªÅÏ$yÏl/¬÷·]n¶ ZÄ ôîy©Æ/ð¢$ãÆ…ý·¶¼„Ëìi¸R.ã†L|ÜÔ⸱š©ûÍÎKpè H1\­žÀç³¥½C&¿~jñóü¨ðß{.¤ÝãGÜ|ÿïñëwx³ˆ&Šq÷4UãhR=ÓÆÊÍ^kph¸1|Úà¶N|ÜÔ⸱’õRjáwÜ„û‹e¼Iï—Zü]iŒf¨Îí*È%F¼b=‰om¦;3ñeU¦‘‹þ¬Ò“dˆôLëœ×­]¥iä’?‘žþ„{2»¹'+u­˜ŒÇyÚumÙŸñ¸:Z‘®4Ƈ 3Ãþ]l£J#rÉŸ¯ÆŸXOâÛ>Ó™ø²*ÓÈeÖèI2Dz¦uÎëÖ®Ò4rÉŸHÏiºÞ0¡µè]±kÅTÍÓ®kËþŒÇUùÓõ:Y)Šf:O«JrÁŸ¯ÂŸDOâ[‘éÎt|a•iä²?kô$"=Ó:çukWi¹àO¬gë7yAvLx£•oô&¯øª™ÌÜäM^Vxf0~jÙøt|‡×ëî«÷Y[ˆçÅZ¸ÔÂÂoÂÂÂÜEΙqÊ9W_€áLçÔv…ü Ò|¼œ2í³R‹]`|l¼òn».þ-¤y6®I]vO—1C¦¾cfj± ¿>Jô Îrp½õavŠN:±upðÑV œtáwëK+Pé_Àµ¿à$ ë܈ÃiÉ‚ÓvÑ©GæNÎV¯µL?þ÷¬¦¸@w7 ß“î·ÝÇðøåþªV@Ïœ5.“S@üÏC2Fá^ÿM"õÝãq•oümquÀ¿_Í ¿ÑÂ%G[©yÃŒê¾ßœx-½ô/ø𨻺yûßñ²tÖ]ÍäR÷áLVËðǻߩv6v«Ý½càI|—d%µV‡• £'«–0ýÓѧ¿¦”nÿ¸¤ -endstream -endobj -1766 0 obj -<>/Font<>>> -endobj -1290 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 741.290154 321.994135 727.690545]/Subtype/Link/Type/Annot>> -endobj -1291 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 716.940545 321.994135 703.340936]/Subtype/Link/Type/Annot>> -endobj -1292 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 692.590936 321.994135 678.991326]/Subtype/Link/Type/Annot>> -endobj -1293 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 668.241326 321.994135 654.641717]/Subtype/Link/Type/Annot>> -endobj -1294 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 643.891717 321.994135 630.292108]/Subtype/Link/Type/Annot>> -endobj -1295 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 619.542108 321.994135 605.942498]/Subtype/Link/Type/Annot>> -endobj -1296 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 595.192498 321.994135 581.592889]/Subtype/Link/Type/Annot>> -endobj -1297 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 570.842889 321.994135 557.243279]/Subtype/Link/Type/Annot>> -endobj -1298 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 546.493279 321.994135 532.89367]/Subtype/Link/Type/Annot>> -endobj -1299 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 522.14367 321.994135 508.544061]/Subtype/Link/Type/Annot>> -endobj -1300 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 497.794061 321.994135 484.194451]/Subtype/Link/Type/Annot>> -endobj -1301 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 473.444451 321.994135 459.844842]/Subtype/Link/Type/Annot>> -endobj -1302 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 449.094842 321.994135 435.495233]/Subtype/Link/Type/Annot>> -endobj -1303 0 obj -<>/BS<>/Dest(table-10)/F 4/Rect[165.905512 429.745233 204.891596 416.145623]/Subtype/Link/Type/Annot>> -endobj -1304 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-k)/F 4/Rect[210.350336 429.745233 357.586176 416.145623]/Subtype/Link/Type/Annot>> -endobj -1305 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-k)/F 4/Rect[165.905512 416.145623 304.209467 402.546014]/Subtype/Link/Type/Annot>> -endobj -1306 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[249.748774 305.247186 308.763666 291.647576]/Subtype/Link/Type/Annot>> -endobj -1307 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[249.748774 280.897576 308.763666 267.297967]/Subtype/Link/Type/Annot>> -endobj -1308 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[249.748774 256.547967 308.763666 242.948358]/Subtype/Link/Type/Annot>> -endobj -1309 0 obj -<>/BS<>/Dest(table-11)/F 4/Rect[165.905512 237.198358 204.891596 223.598748]/Subtype/Link/Type/Annot>> -endobj -1310 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-ki)/F 4/Rect[210.350336 237.198358 357.586176 223.598748]/Subtype/Link/Type/Annot>> -endobj -1311 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-ki)/F 4/Rect[165.905512 223.598748 271.473871 209.999139]/Subtype/Link/Type/Annot>> -endobj -2054 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2053 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2052 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2051 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2050 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2049 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2048 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2047 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2046 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2045 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2044 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2043 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2042 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2041 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2040 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2039 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2038 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2037 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2036 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2035 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2034 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2033 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1855 0 obj -<>stream -xœÍ]K·n@·É)Çs0ˈ©æ›<ÆÑc- «Õêa%^‚ ò¥@N~@~zŠ={Èjö6gwWSCÖWU_}Ý=Cnï–o{x|~8Å™sÞµýÇû͇ ³z|ñðs4~ØÀ3k¶FIfûÞ:»uV3¥z¯ôö§n¾Ûük÷áñÓ›ç¬ßþøïM˜oýq -çB0ͽqãœw›ð×ÜFÊûJo‡=伞÷%€1·Ýýñf‚Ü9N^¶èåw_NÃñZ^ÃBχÝsŽžãyÈ~æpÓã2ü·þÄ°_¿Úùw–9«z®]ï¶R*¦{!¬ß¾z¿ypyñ·o}½å’>$ŒÚ¾z·ùþ‹Nv¯»ëîew?¿ënnº{ïvW`øôþ¯žn½Ús»6"(¸‘º÷|&¢Ï!žËE÷=|o„‡²K¥m/¹˜‰ãOÅ3ˆà”ã9”%ƾ¿i™qŽá“ÿ/„ÙÞ0k„ñúg$Ì‚ü´ܪ–l- IÎDo¥òõÂzÚ½¾/ú/Fj®à{íñÜ—cPOFïae½€C3’þ°»ìì} Ž¯»Ï ¯²ƒ´£ÀÁ%DpËSRÊaÊgc -Oàñ°ßÀ#Ôõ -" ÕÝÕöÞ”ð›àÒî\z(×–÷Ž94ò­„î1\)møál³xó\Z¡{Çáì?—Ÿ¹€:¦­ÔÊJ#÷AXΤP‚ûBÔËçœ!pT:. óÒ,ªxý4æ!Lå{Á·ù®­;eYõëgž! \L×`Þ)é–qP=íü PrP=óìIx—yèÈχäy¸œ›LAWx&üÑlóÿÄÑ¥ ¼÷LîÈëCt)$zõ+Ž.üà„ÂàÒÄZ¿ ü$—l¬xÖíb?Á ´¹mcø'¨h@’Ê“ »#Üd)¥çhÞzz8Q§m—"CðÓûLN+¹d}($?å¬]~œè7„Wî;~è „5dYJû3y¾2«锵¹ÌZ¢¬È&ÉN»üŠø´Ò0wŠÓžy)„d“ŠY{ôÓ®CI%¢qÕŠÔ.Ÿl´…âœpÞ.ßN)2âÕ(³š(Õ:µ`_—e™Tj«I„ˆÒ"Û${íò-âÏ(q[¡X¯”¨&³öè§]ÓŠãªëy>Ùh -Å9á¼]¾œRlÄ«Q,f5Q²+tjÁ¾.Ë<2­ØV“¥E¶IöÚå[ÄŸQ,âv^±B(€WÚI²‰Åœùi×Á´bã¸ZÅ -!³É"ûP(Δóvù"pB±¯B± «‰’y¡Sóö•Yæ‘iÅÖ°šDˆ(-²M²×.ß">­XÌm…bµe0ß -O6±˜µG?í:˜T,W­XmòÉFûP(Î çíòà”b#^b1«‰’e¡S öuYæ‘IÅV±šDˆ(-²M²×.ß"þŒb·YÅ.^‰‘ñ¼Æ5ó½öb·4ô—«—WOs+17_t/º·ÝUw¯ó÷͸$óž_¤Ë R%‰sp¢»‹î›qÉ&¬z<†ï¿êþ8®‰<Û³îå¸Àsݽ˜,® x•cÒ“ŠµÇýbÚaeå¤J>üx…BáúL²Xiòñ! (ÕGÝ/»ß†¯b‘*âž Ó÷nütQ -ÕÍõÌI'¸ÙSqXi|Ù}»[†Z]¦áŽkT‹].£{%Øè¯`X^¼^[˜Ôóݦ›(ŒÒÌÚ^÷îX˜ëqvuǤžï¸0µØåu^aêº÷ÎŽ.¾ýó›ËçYö¾—àˆyáÿ~âÒ@(RÃébâ¦~z‚o%ëy8õútøWPªÃšýñd÷Šî°ì ãë°~>”ÃêúÛýz;¼ZÎÛyf{a½ß£þbºyÊÃa¥»y79E„3¸ÔaíÿĽ -.dÆëpäpå <|7ó«‚õÓα"V HÄ1»$x›iç]WÜ0ˆÚ-ª~ý´s,gÆ2â8T¿~ÚyWÄ•ƒ™^Z½¬øµ³Î\ûÆ’Ò×Î:oåµ2¬‡³†ZvÔ©ŸvÞÚã8¿~ÚyÃG?¾;ú%oÉ‘}Hí*Ú?Ⱦêý8BÄÚ±Ó÷ãJÞ+¯à½œoe“,óÙ—³Iü¬Ê2|òæ4GÅgIáXjvÇRŠK1gG~ÚqI~–„ÆŸ%᳆ÎfŠìC¡2ÃôìÓ&S„Lt-Â+w­’2ŸI„ˆÏ<ÏeÞÚešG&ô‰ù¬Ð§òŒ }²kŬ=úi×µ¤>Ѹ:}*—Ï4Ú‡BeRžÛe‘)}F¼}b>ÝêBwìë²Ì#“ú¬â3‰ñ™ç¹Ì[»LóÈ”>Ÿú„ b=^SM+fíG7íz–VgW§N×gó<š‡|U†é»‡6Ya)aÑjt‰xLäê -MY°¯Ê0L«²†Ç$ÀÈc–Þ"aͲÌÂR‚Œ<ÎëQsÅzí7T£Š3òÒ¬Si9‡U©Qs™ÍÙ‡BU†ÔO«<2!I„W¡É„ËD«}¾+³æ•9fqiIVp™Ä‡¸Ìs\æ¬]žydB–˜Ë -]*Ãôî³ ªcŬ=úi×±¤4Ѹ:m*Ï4Ú‡Be†é§=2È”6#^61Ÿ‰fe¡; öuYæ‘IyVñ™DˆøÌó\æ­]¦ydJŸˆÏ -}Zw–ìZ1k~Úu-­Ï8®NŸÖæ3ö¡P™”çv™FdJŸ¯FŸ˜ÏD·ºÐûº,óÈ´>køL"D|æy.óÖ.Ó<2¥OÄç¼> ç,ì°’’ìZ1gG~Úu-­Ï8®JŸ†÷ÙL‘}(TfHý´Ê!úDxúLøLtk Ý™·¯Ì2L볆Ï$BÄgžç2oí2Í#úÄ|¶Þá§zÍ =„´mvøÉøf9ñÜd{Ÿ’–icåì <ŽwªØÝâ6‘Pµ¹]HáëãÅ»83N9çê±ËÛ³”íY/¥‡=4Ç{K\Ë|ëº$Žï¸.µØ庄]»Ê{c{OCc^7ïxvË펱6©ó»­M56Q©˜7ډÖRŠÒNT'w\£ðD™L¸Ï÷æ°g6T&ËÞ±A%îï¸@µØDu¼÷©àÇ -›ýÞŽ›_¯«KâøŽëR‹MÜ1HhWz‹®úm¡(n M]În =~»m¡å UØÁÙ«þph­¼KSv£(¾!“<Þiºi4|.@‡œ¢Ó›F-œbáªÎs;Þ†+öüÎnߪŸv–M£Ð…Z8m“8æ·oÝbÚy7B?2á|~?`Iõ«§e÷Y,#ŠcIõ«§w뢓:¨Fjµ¨úõÓÎ[}Ç‚ê×O;só€åNƒÉ‡ È>¤ví‰d_õáBÄš±Óuò«„ºÜš4Ë|öål?«²Ì#Ÿ¾åÎÅQñ‘XP´Ý)šâRÌÚ£Ÿv\’‰¡qÔGb±.Æç3ö¡P™az l”iD¦º6â•»¶?væÛ1où.Oíë²Ì#ç~6 õ °q<æ3Ïs™·v™æ‘)}">çõézÉ„Ö¢wd׊9;òÓ®ki}ÆqUútðö?—)²…Ê ©ŸV™"dBŸ¯BŸ ŸX%˜·|—'ö•Yæ‘i}Öð™DˆøÌó\æ­]¦ydBŸ˜Ï -}Â5™Ý]“Q]+fíÑO»®%õ‰ÆÕéSª|¦Ñ>*3L¯be‘)}F¼}b>ÝŠBwìë²Ì#“ú¬â3‰ñ™ç¹Ì[»LóÈ”>Ÿú4ð>ÏMwÜNzVÌÚ^Úu,­Í8®N›Ææ²Ãh -Ixm˜eD&Tˆð*t˜ð˜èÓf»1g]™a•VáQm˜vÿ÷\Æʼ…0ŸwOÆuò§ëê“8ÿêS‹OÔÇùp+ u¼Zؤóv\ }ÝÝܬ+Oâûg(O-~²N{X«íG¥c¬ »˜òfwì_ì½êîæ~÷yX>‡d>‰·„ªêh…³ÝÐÉ"ú2$ctƒ°j©ïŽËé㟥ú¨û5|}¼ ,ü)6ká}®•šg1̸ÿrÜòsÑ]† ÿoºë›wÿÏ.OâÏ*k©{8ŽÀ…„¬8î ç—'ã–{ÜC€Ž§•¥µ:,·=›µ÷OÇÍ¿K;e÷ø=Q¤ -endstream -endobj -1764 0 obj -<>/Font<>>> -endobj -1268 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 741.290154 314.445063 727.690545]/Subtype/Link/Type/Annot>> -endobj -1269 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 716.940545 314.445063 703.340936]/Subtype/Link/Type/Annot>> -endobj -1270 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 692.590936 314.445063 678.991326]/Subtype/Link/Type/Annot>> -endobj -1271 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 668.241326 314.445063 654.641717]/Subtype/Link/Type/Annot>> -endobj -1272 0 obj -<>/BS<>/Dest(table-8)/F 4/Rect[165.905512 648.891717 199.301752 635.292108]/Subtype/Link/Type/Annot>> -endobj -1273 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-f)/F 4/Rect[204.760492 648.891717 369.102777 635.292108]/Subtype/Link/Type/Annot>> -endobj -1274 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-f)/F 4/Rect[165.905512 635.292108 242.876459 621.692498]/Subtype/Link/Type/Annot>> -endobj -1275 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 524.39367 308.763666 510.794061]/Subtype/Link/Type/Annot>> -endobj -1276 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 500.044061 308.763666 486.444451]/Subtype/Link/Type/Annot>> -endobj -1277 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 475.694451 308.763666 462.094842]/Subtype/Link/Type/Annot>> -endobj -1278 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 451.344842 308.763666 437.745233]/Subtype/Link/Type/Annot>> -endobj -1279 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 426.995233 308.763666 413.395623]/Subtype/Link/Type/Annot>> -endobj -1280 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[249.748774 402.645623 308.763666 389.046014]/Subtype/Link/Type/Annot>> -endobj -1281 0 obj -<>/BS<>/Dest(table-9)/F 4/Rect[165.905512 383.296014 199.301752 369.696404]/Subtype/Link/Type/Annot>> -endobj -1282 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-g)/F 4/Rect[204.760492 383.296014 328.888422 369.696404]/Subtype/Link/Type/Annot>> -endobj -1283 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-g)/F 4/Rect[165.905512 369.696404 360.916498 356.096795]/Subtype/Link/Type/Annot>> -endobj -1284 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 258.797967 321.994135 245.198358]/Subtype/Link/Type/Annot>> -endobj -1285 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 234.448358 321.994135 220.848748]/Subtype/Link/Type/Annot>> -endobj -1286 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 210.098748 321.994135 196.499139]/Subtype/Link/Type/Annot>> -endobj -1287 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[254.889643 185.749139 321.994135 172.149529]/Subtype/Link/Type/Annot>> -endobj -2074 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2073 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2072 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2071 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2070 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2069 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2068 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2067 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2066 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2065 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2064 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2063 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2062 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2061 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2060 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2059 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2058 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2057 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2056 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2055 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1854 0 obj -<>stream -xœÍ\[s·Þ½±é%N“N3ÇNbejxq›Ê–|Ù²-Û‰•‡N§Î ݧýýé=—ÂÁÀbµ ËɳÀ¹}ç[8»\Óu?÷܃”cµë~X}\-ýÁÝ£~\Á+­ÖJp¢û^½6Z!z+äú—­Þ¬þ½¢k÷óËÏ«ûÿ ¤_ÿüŸ•›¯íõJ#’Zeüœ÷« øÕÔìF€•Þ”\o“›è¸{ýæ;0FÌzûÛ›pr«8:¬Ñá÷ßݱ’íŽ{·ÐëÍö5E¯ñ<$?°»ñ¡Üý[±Ùï_­®ñ7š-z*MoÖ´7„qˤY¿ú°º~öã£߯)'^‡QëWïWïîv¼»ì^t/»3x|Ó]]uGíNºç øúø§WW^ Ø.õˆ)Â5ëuÏ)›pêpéÜ9ëÞÁßÆ~hJàW -;áÄ_Á…§`þ)¤ã¤%8åþ¾nì·P\ÈšôÜf‚J"•æ†BÀ„UDq&€5¿&À4e„+ª¤øµ ¥yO„B©Oˆ–†ó³ÜØ¢5×%Æ(S ’WŸ FYyÝy’*ǧ2˜ý—cÖßíNáç4¼.Îßãú,ë1)=œ.ƒ.o§ðì²ûÌgóÒ•ÚKÐõ¢#Þ·3[x⎠ywŽ>ô.ñ¡«»P›'püY"(7à>½èwoáñ1ȹ?úh8öŽûç=HO=¾Ÿåƒáþ-‘Z9CaÂCPp1PÄ)bðê™W|Ö)Ï£ü¨ÝÑKpãÄ—ÓOðèJÊåÒãÝÿülxué_½×/\0y·à]ß@qôfpK¹'>ž·ƒ+gAŸ-@á#˜â|};L.LhíO(» ŽÆÔý¸rõP¦Ò•c– @…¿jÍásRT©èîãÞ §K²§ðq(ùtþH°K¬5\ÉÈxφwFmÆýM;€û8Æcàf^ö«§ n -Û3ºN?]–}äÇœìWO;€û( Ükfge¿~Úa³ý˜‘ýúi.©ˆÝrðà -¿qù&–ë qùZ>,¾”û~®ÓO±ßiËX½¶wþ§ý@£îQ´Fƒ311 >Mð8Êtôùh"=‹¢L[vø›-þ>Ê´hT%Ήí ß2º„%›”=í°ì×ðù!*î´'ÜxàéèÜ•Œ4È7™ÌÄ8·‹4X.Um°—¯Z~]mO,Ǹ¥«<–/‹2myÏ´'y<ñxŒgç3¼w×]1mí™}sú|QNb¥·›“jÛ…‹¸ ²g Ã«xò·×çÏ’*ô1÷§Éþb€£î«‘J%‰æÞF*aê×{ö5'=åÖUúþð{ªÝå'>eGÙóµkmÃiØÁx4¾È!³dDqÙ[:XüÍøšP†ÚïÃõ ®õ~üï£Òh×Æk-·Ï…aÄøýæY-Äúi‡mŸc?f´ë§¶}.),â¥åâ¯6ûõÓÛÅ~ÌÈ~ý´Ãºïª€o« ZŠ ù&–ó ô ù¢¥²\XŠ { Ü(Êtôùh"=‹¢L[.|@ÇQN/ ]M™mM•°dSr¤§–Å4Wµ€–T$#EòM&3›1 ÛDŠ,ªÙ«X@Gx"y„[ºÊ#ùÂ(Ó–‹ è*<#žiœó¸µ‹4m¹ÀOŒg?…½”ãmŸQÕ²IyÐÓ®j‹üDãêø)t:Ò ßd2ãÜ.Ò`¹ÄÏ`¯†Ÿψ·"Sù²(Ó–‹ü¬Â3òá™Æ9[»HÓ–KüDxVðÓôr¥t±jÙ¤<èiWµe~†quüÔ6io2™‰qni°\âg°WÃOŒgÄ[©ÎŒ|Y”iËe~Öà‰Çc<Ó8çqkiÚr‰ŸÏÖв°*´tØ¥j¸kn²-¹"ZI6¹}Ôn±Úäv˪mçw¥²„qGŠ†;ˆ±Ò[ÎI­íü¢´’ô¼·LÌÜAüSv1V9¹ƒ¸7üà;ˆ -£Šk® ;ˆ£§ŽõpTÕÍSƒx|UÞ#Ôpßéö“¸Ï -mefîµFÜì~+%,Ìý›Þoå]HÞs•7¬4‘ŠQ½+½[³¼Òèö,OÜwUØøR€A£´Þ·]ÞøÕŠ)…2ÛÛ¨áMQ:½õX?í¿¼'È)4WªiOò¨F"H³hÑkoÖþc¶ÓŒ5Lk”[/–Š˜MÉ‘žv\flWËXÃd2X$ßd’3Ƽ]¼Èx±È^c#T#&óL¥¦å £L[.3¶ÕÈCií"zíâÍÚ/3c[ÁX +Þí'¹R³IyÐÓ®‚‹ŒE㪠[“Áù&“œ=ÌÛÅŒ—ìÕ0£1Yf*5#_eÚr‘±U¨F"H³hÑkoÖþc¶Œµ”Xj™¦Å"f“ò §]—ÆU3Ööé`ƒ|“IÎæíâ ÆKŒ öj‹Q˜l2•š‘/‹2m¹ÌØT#¤Y´‹èµ‹7k‚±ÛiÆZ&7RP],b6%GzÚUp™±a\-c-ãÉ`‘|“IÎóvñ"ãÆ"{ŒP˜Üg*5-_eÚr™±5¨F"H³hÑkoÖ~™±ÛÖMsm±ªWÃ7“.nš‹h)oÒ77TÁ”žüÎÇGàà»ô†£ª­¥nIúÂýÎn»ÛøzXõÕÛηÌÐÄXfû]wlÛ•¼è~;`ùÀa±8I‘•[NR­íB’Lï.Ìﯻ·ÏÁ½ím7¹Þ"NM¤û–SSk;ŸKœmdø -Ï—C¯zqÍÄšo71Õ¶£^ò®ŸÜ{¹3«vWD'=­%ÖÏ­²»:î¾PþÜ} ?_ŒÖe\Yb´Òð~7ehïJŒy–”PL‹iK}wâÛõþït€ß?Î3澦]kÂ\…Ф å¯ïxé¯L8ëÎÝU%ÿõWI¼¸zÿ?ÿ†rÚ½˜™KÙênúæ5ÆO®¿…÷Ô_·¢‡k\jÏg¦Ö}“²±JNFÍÂu_uwÆåx±ú?ùÌý -endstream -endobj -1762 0 obj -<>/Font<>>> -endobj -1247 0 obj -<>/BS<>/Dest(address)/F 4/Rect[249.748774 694.090936 316.853266 680.491326]/Subtype/Link/Type/Annot>> -endobj -1248 0 obj -<>/BS<>/Dest(address)/F 4/Rect[249.748774 669.741326 316.853266 656.141717]/Subtype/Link/Type/Annot>> -endobj -1249 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[249.748774 645.391717 308.763666 631.792108]/Subtype/Link/Type/Annot>> -endobj -1250 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[249.748774 621.042108 308.763666 607.442498]/Subtype/Link/Type/Annot>> -endobj -1251 0 obj -<>/BS<>/Dest(table-6)/F 4/Rect[165.905512 601.692498 199.301752 588.092889]/Subtype/Link/Type/Annot>> -endobj -1252 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-c)/F 4/Rect[204.760492 601.692498 370.473871 588.092889]/Subtype/Link/Type/Annot>> -endobj -1253 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-c)/F 4/Rect[165.905512 588.092889 251.144037 574.493279]/Subtype/Link/Type/Annot>> -endobj -1254 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[249.748774 449.995233 308.763666 436.395623]/Subtype/Link/Type/Annot>> -endobj -1255 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[249.748774 425.645623 308.763666 412.046014]/Subtype/Link/Type/Annot>> -endobj -1256 0 obj -<>/BS<>/Dest(table-7)/F 4/Rect[165.905512 406.296014 199.301752 392.696404]/Subtype/Link/Type/Annot>> -endobj -1257 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-co)/F 4/Rect[204.760492 406.296014 370.473871 392.696404]/Subtype/Link/Type/Annot>> -endobj -1258 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-co)/F 4/Rect[165.905512 392.696404 355.41308 379.096795]/Subtype/Link/Type/Annot>> -endobj -1259 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-co)/F 4/Rect[165.905512 379.096795 362.37475 365.497186]/Subtype/Link/Type/Annot>> -endobj -1260 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-co)/F 4/Rect[165.905512 365.497186 350.798822 351.897576]/Subtype/Link/Type/Annot>> -endobj -1261 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-for-co)/F 4/Rect[165.905512 351.897576 340.926508 338.297967]/Subtype/Link/Type/Annot>> -endobj -1262 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 240.999139 314.445063 227.399529]/Subtype/Link/Type/Annot>> -endobj -1263 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 216.649529 314.445063 203.04992]/Subtype/Link/Type/Annot>> -endobj -1264 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 192.29992 314.445063 178.700311]/Subtype/Link/Type/Annot>> -endobj -1265 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[255.43017 167.950311 314.445063 154.350701]/Subtype/Link/Type/Annot>> -endobj -2093 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2092 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2091 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2090 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2089 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2088 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2087 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2086 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2085 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2084 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2083 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2082 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2081 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2080 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2079 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2078 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2077 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2076 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2075 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1853 0 obj -<>stream -xœÝZIsÇž*/ÈA•ÄR—“šƒË]v«÷åê$H!â -€¦áƒí -}‘\e'ÇüÓýúMÏ`ºg ±¢1KO÷[ú½ï-@Îr -Ççþd%#Ö:£eþÝ»ñcb–g|øãîŒÎµÄPj¬É­QDJê¤Êú×x5þaÌrüôýøÕ7ŒÐüûý|ãª)ŒqNsÚ✇ñ°4³å@å’RùÛ@òm4îïWŸ1bóâÞ“ÅÂÑ°© ?|š²ã/Ç‘­ÚýÛâžÕîëójÏŸ˜Ýø Løyz®“ýâv\í¿5ÄI™²ÔæŒZÂ…ãÊæ·ïƯÞÌîϦ_äL\CÀ[ùíÃø«—Ù'Ùuv•­²Yö|þõøëÛóñô6lç¾L G¥Ð|€ ͉`b”¹cM_ÂÕ"[ÂSÏÜã2Å…%B;©õSõ2Ï.À”àŒ(m„ƒÛõ:›ùsÔU¹y 8_Àá|dÆ´%Ò9mäc -ˆŸ!³j+¯án”ý®—ðdš»A6ô·+‹L#qF9ÛÞÐ hÎ3u , ÏÞ|NPs×Ù=ŒžâÓiöO¸>ÁwVÙz \{ FðÊë ¡(–»Aåßàs|¹;˜‡%.³É1SÂ'0ì_˜À+Ïð~‰ZÙÈIÃ^èœqM„áÔPÁÐ@$ÏÉy§àË à]iÃßQö9¸Wi(“ –haîž×W\“Çxý= xíÍQ‚S°xºÞVˆß=ýPpÑ­ljÑÆQÅþ¨ö€ ~Æ™1:åð á2IàΩ؞f\pNaߢ*ÉQá}tW†³Ep´Z!jmÛ|¬^‰s^÷ã·ÁŠà~Ž&3B4Ù$º+x?öæ°1ëBR’zr§‘á|ÆœªÁQöY¶öð·>Æí/¹SþÁ'Hà -ñ²ÆÄfÊ(ØÉ ó‹V-j桬VIB ä?FÿY`sVˆÒ’.b–FϦg¼¦NƒŸÔ&-Z²òR:¤[MVƒ—sYÅK¿ô%Z!Ø·yoéÙ D5…„êš: 1(,Í`¡U•4NBâýºJÕŠM Rn2´+ÌЊ”ïǦÕm3ÓÄ¿²™6\Š”T Ïà—¦Ú¢ÄXVL U$y5ÞTQ¢ÁǼŠB; gŠp«W ÍÞ²;¶–°qÂßóÁraâ ×ÒmOÛGÂÑbïÐü€›nëIð°UÐSšé/Lw±È”ÓˆÒ·uJôÉPYËeýð‡¤Lðëßá–‚åï[}׋ (/õË«7—繯þPƒ2e•Ù—¨€b@YFešæô¹YƇŸ•0a“ôâP o¢åÌ. ¤D÷î¶( m4×nÈ{Ö/«„¶ÈbJ«Üî¦B>gƒÝŸC6ð4DPÍMi¡¿žQPžqÅwîÐ <ã,1`WƒÅâAx1ÐÂÔ·"ê×d±ŠO-e­à„j1™,ÓÚrÿNZb’ÕˆFñK£ŸG¡<©•"” VÚ`¨/9R IP9\!T1­™RÌ£è7xy%×>׸ï,‹‹d{Òœ·iÚô¨ø¨OÜ™'+»í=É´«Zs0]‚¡µ®FQ\NQIó†Ðq*[*f ÿããûÚÿˆvrÓûìÿi(û,7ƹªì{Œþ_¼ìaú[ÓèÿÅô ý¿žV_5·µ‡×½¯P§M7ݨVÂi/Œf­Ô®9ýI»z‰6zÚuPÌ -gE‹„Èb§B …™Žoš`=]=oTšƒã«æ´÷ºÁ¡\™Î@’íÕÕcÖª…7¢˜Ò‚ÛÄ Tº_ßÕ‹×÷¶«g4d ?P[Áû!»zq–ýÛíêY¦ÁË)¯¢à¯éê=Nw#Î:ž²»Á@•¦J¤p¨æ‚f”ðÂmÿ7 0©‰føíMŒóO©ö(«·Òû§6ToYã½è­ñâå`ÚgI³w󳦲M[õÞ5aRí9Ör_í5Xë«öàŠ¥‡Û¥ëcŒveAW4FKÄ,üPDÑ -ôº¯|K{©›ð[Ô1àÔ¿Híoô”õÈQölßá\Ÿ[¥F} -qœHë6M×n"Wø­Aù­eÐpeÃh=F<«anÉÃà»Äi‹†«ée†ãEÜ.]Š¢º²2åˆtš:abáUÓ&&“úl?AÓm Ž"Ôð—Ý(A™I8åFS¢õß -=#zžýi7bþלÆHŽ„b­44Zþ nö,{ã}ÿ?ðñ*»ö?*~Hu½£.%LC&-¶!^X™7šS4“-Ph¯Ú7;ªÖø/~œVƒR X¾p‰¿l2Ï«êø¬ó‹¶ -endstream -endobj -1760 0 obj -<>/Font<>>> -endobj -1236 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[102.172846 695.391717 136.409174 681.792108]/Subtype/Link/Type/Annot>> -endobj -1237 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[253.663324 632.993279 287.899652 619.39367]/Subtype/Link/Type/Annot>> -endobj -1238 0 obj -<>/BS<>/Dest(iana-enum-registry-value-template)/F 4/Rect[161.464594 525.395623 220.479486 511.796014]/Subtype/Link/Type/Annot>> -endobj -1239 0 obj -<>/BS<>/Dest(section-3.7.2)/F 4/Rect[65.905512 486.696404 99.092035 473.696404]/Subtype/Link/Type/Annot>> -endobj -1240 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regist)/F 4/Rect[99.092035 486.696404 341.255609 473.696404]/Subtype/Link/Type/Annot>> -endobj -1241 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[102.172846 372.698358 136.409174 359.098748]/Subtype/Link/Type/Annot>> -endobj -1242 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[141.797602 310.29992 176.03393 296.700311]/Subtype/Link/Type/Annot>> -endobj -1243 0 obj -<>/BS<>/Dest(section-3.7.3)/F 4/Rect[65.905512 214.801873 99.092035 201.801873]/Subtype/Link/Type/Annot>> -endobj -1244 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscont)/F 4/Rect[99.092035 214.801873 373.411859 201.801873]/Subtype/Link/Type/Annot>> -endobj -2102 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2101 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2100 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2099 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2098 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2097 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2096 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2095 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2094 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1852 0 obj -<>stream -xœµ\Is·î*–.“CJñ¦8qÕTŠè’ ìË1IÑ’JI‰#ÙÌ!IE¾ŒSe'ÇòÓó€î™~èÐhvS#r¦±¼ïmè±fk -¯§þÍJF¬uFËõ?~^ý²"F…ÊÝ{(üeWF¯µÄPj¬Y[£ˆ”ÔIµþõŸ«Íê_+¶ö¯_Z=û#týÓ¿W¾¿qû.ŒqNsÚ†>ŸVðÑÌîZÊÏJ­·ä6ª÷×›oŒØuûã(Ù -Žª ªþôíP§ø®>¨…®·í5C׸*¿cuûaÂÿ[ß1äwïVûØ[C¬‘”)KíZRJ¤ÊPÁøúÝÏ«g¯Ïøþô»5$ˆÐpýîÓêÇÇi^6çÍQó}sÙ¼×eóCóª¹h^@Ù¦9iN¡Ì׿Òk(¹åmßî\½‚voàú^óʯáç}ó~?‡’£æ”œ€<ßãzl öæ..´v¯yÚèæ”^à3ø}êAÓ« ÕËòò_tšx)ÇŽ>nîCÅÍñ±„—Íû㿾{‘ó DUi#¬ðNã=ö«Î¤ç·H¥Á’khâ•:êšÞk>ÈÏà·}ï'ÁoíÕegiëU/§ïÿ¤¹ñŽ¿9îdø~Ï‘,å«ÁïʳààVoþ÷A˜wäY„ë.|EÓ…ö™ÇœêLßcü±y¯/›û¡÷黎Èþe-{ NµfRËCZ  ÖP 4Û·èB†+Ê€QÉÓÇ .aN -¾ÓÀ0"¸äÌe”žØáTŽÜÆ”úrîøD×w$T•Žr¶Nœåu¬Çß×w»õ#Gr.‰ÐRÁ@1-õï6X ¨ïvç°Žpha¦Ž9õï8H)¨îv·ê; ³¤è%ÛA‰Ÿá>h†¤ý?Ðeþˆu¢0©Àî6êµb¢ú§ Mž$UF_%M«}lÍ¡¦¸ýí4|¼l¯ wŒ‡j#­#ë7m uÚû¶X‚z/º¢´âƒ!Ã&UxTç:cªÙfý°e-g!B/fÂÌgžÜeRAT¢ght=Ó²é0r1r>n‘F(néxæc³œeiä×p¼ª8³×Î:ŠùiëjziKfèQË:N*›³¹¯r[6˜µ-fq^ædYÃIራ:“±™òy–¦‘‹\­Šk¤!Šk:ÞùØ-gi¹ÄYÏ*Î:N„³RØrþÚºš^Ú’<ÆÙ¾egËÙÜ× 9‹-‹d-hq^ælYÃYáˆË6“±™òy–¦‘Ëœ­‰k¤!Šk:ÞùØ-gi¹ÄYÏÎúµ¥m×–ÅüµU5HÚ’<ÆÙ¾eg9›QÍ6ë§ípm¾”ŽÈY„YÁÙ(—Y&cÓå3-M#—9[×HC×t¼ó±[ÎÒ4r³8žUœU†A wåüµu5½´%3x„³¨eg•ÎÙÜ× 9‹-‹d-hq^ælYÃYáˆË"“±™òy–¦‘‹œ­Šk¤!Šk:ÞùØ-gi¹ÄYÏ*ÎZGLû±˜¿¶®¦—¶dq¶oYÇYè±¹¯r[6x»˜Å=z™³=f gq„#.ëLÆfÊçYšF.s¶&®‘†(®éxçc·œ¥iägQÏÒ4r‘³Uq4DqMÇ;»å,M#—8‹â™äìÔmt.zÚÃqT9.ú¿¼½xýöEz]·yì¨aÍIó¶9wbqÙ?5‹d†}XÃ-]¿kþö»AÙ+ÛmÿŠEÆŠJ¿‚Óšý~ä¾ {ó>„=}~ÇÚÃcNCÉónÿÞõn+ØûœãÎ8ïAì8lâ$mâ n_4÷›¯à独}1¼Ox ®P|üQÉ©–+,gº‹”!>i^7æX…½†çz*‚˜è¦àªnªÅ.ùˆûöT -Í÷>Ú„¬…¬šå™XðÏø­™_ÎK jì¢gàöb Uð±õŒßvmÂq5Ï?‘ø‰™óøù|†j±‹þ1–p¡µ’È?¿Svž_"±·`Ôƒ~©Å.ùE0J åƹÎ/Ôó;_À»µŸø}ų|CLäÖÌÁ¹»è#o‹¶~ëüÎG&ÜÁÁó>ß±mžŸ"˜[øiF.Ucö| m ,Üd7yùçë×oÒp,À{ý^ÿ¯b¡Ìo?¤0íÒ‘Ðõ›¡L8¢-Õ*ÑxdƒÿQøÓ¿ Þo’?ƒ†oáå§>~k¿ßþowJc -`žQÔiwˆy4²­]ÂRrC­X;E¬Š)ÍUÍVÓ)]ï`Ï8³’pn”`X“Ñͦ·êv×[Þ¥ÕĆoͧGaB×;Ø3‹ÝÙk2) -ÕÝîX}Xr¹6‹{T³ÖȾfYûò™‹{„î4û.ïjÔ2Zà ¥ UÌ(ca}vFÞ°¡¨Y6§Á‡‹ß´*U¬$\‰6ÏŠñµu5½´%#<òÀ -µÌ?Øp+cs_3ÌilY$kA‹{ô±œîQK9­p"â@ªp<³L8¨šgyV…Ã`gUÊG{¨* -x:òA]Ôê4x‰Ï=^Ÿa0‡Û‡_zƹm«j´%³{ŒÏ}Ë*>+f36£šmÖOÛXÖr#ô>#ÔZ>GR]çÓ7[5Óò¬ -£|®‰öPUðt"䃺¨ÕiðŸÞ<œ–&»°ˆëžÂÜþá4¬v÷#P$s¡‡ÓŠZÂc£ET|Ù|Ñg·Y»#KªAsk÷©OV¹á°’T©zìÒÚ] I¨³Zˆ‰k÷Ùµ{,rdí~ÐxÒÚý}x38 - d­â„ ?ìŸè$úŒ+"¡Zv9XèÏ:BA9N¨ÖB²ˆ^ºóºÄüµ?x`¨ܹfZüèN½_ô¹ŸrðÍc¸üœ=jܱq~×­ÃÕð,„HÅ(ÄR(«U)%ž†± \¬ÉÞ'ÍCP‚"þà¯ÐÙÞÂóè8ƒôÉÛŠ'=쬸 -ÅH½×±7ýÃÒbö&lšË’„&ZPIw‘Nö‡c´Ç^lBf_†ìo³½§àyóc¨¿@GG´ÚyM߆ã|œõ'7dâÕc„C¦w.<Ôá#rçý’¡þT-úo¹nô—AÛݧXàE¯Ä›pê‡ÿÇzÒu:M¹½õ@ïÇ6Gªõ„©Ìúošvi@Ú2²ó×uðð¦C¿ - -ŸB]ƒV£.3.B£ëp«ógrìNBñžw§xœW‡›Âá)g¡ÌGÇçÁ7bàÇ‚Á†ú?ÅçÌì2°»y{rÜüý¿á\’M8=äP,:€¤ÍÅ{û³D.ƒYøБ{w¯ö§‰´TDǞ쟽¶g¥x7`žïIü1œ:Ÿ— äpgrÒYƒ(638÷Ûqå¨ÑžH“O…¸‹>šHNIo¿(ÕŒíLlysÖ~©Ž¸~‚F¨”öíž#;S½™Ÿàj;âù™Õ¦ûο%_ðÁôyVì˜øP'¦Kâo¡_Nœe1å¿z”’êzÜĹ63çÖùÌåÝ1Bè/w,þk5OªÓT(>²ØÍY>OÌ[`–È`êÌä@\fâ7i^E G´óV;¼‚¾aÒë$!¬´ìP§ÒÆrG”¦ttcÐáO‘ñ¡JIfïr%†Wqæ%ÕS§’¤!Úq·ŸÀÔϱ{—(#F -iù ïÑÈwÑ%õo@Òͧƒ¹XÂÊÖI¹éÍËnɹq}0¥9òÓ¨~ä> >„†Ï‡0Ú9F¯ŸsÕŸ‚µÏA#ˆgƒ1‡]vhØy­ºû!u$|"aviÊ;waÃ,H•¶þ ’Èšý`Á;JPXxéàVƒAwÀ4HÌÁXú:HMÃ3L>¾_âLJŽ -+í Úh6 -tàöiHZKÂ)Œ>ãHçáÍgðóÕ40ÿ$ÐuÊÅ’:¤ØU˜²7¯ýðøõ¬¹¼ùô¿.õ.'úRQ¿Á&35àí\ñ$Ì®Ãìo7’5¯'ºÖ(­ÓjÔj±?5ð÷ÍgÃt¼Xý@öæ -endstream -endobj -1758 0 obj -<>/Font<>>> -endobj -1216 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[182.395746 741.290154 241.410639 727.690545]/Subtype/Link/Type/Annot>> -endobj -1217 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[182.395746 716.940545 241.410639 703.340936]/Subtype/Link/Type/Annot>> -endobj -1218 0 obj -<>/BS<>/Dest(type-signatures)/F 4/Rect[182.395746 692.590936 241.410639 678.991326]/Subtype/Link/Type/Annot>> -endobj -1219 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[182.395746 668.241326 241.410639 654.641717]/Subtype/Link/Type/Annot>> -endobj -1220 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[182.395746 643.891717 241.410639 630.292108]/Subtype/Link/Type/Annot>> -endobj -1221 0 obj -<>/BS<>/Dest(int-unsignedint)/F 4/Rect[182.395746 619.542108 241.410639 605.942498]/Subtype/Link/Type/Annot>> -endobj -1222 0 obj -<>/BS<>/Dest(utcdatetime)/F 4/Rect[182.395746 595.192498 241.410639 581.592889]/Subtype/Link/Type/Annot>> -endobj -1223 0 obj -<>/BS<>/Dest(table-4)/F 4/Rect[65.905512 575.842889 99.301752 562.243279]/Subtype/Link/Type/Annot>> -endobj -1224 0 obj -<>/BS<>/Dest(name-jscontact-types-with-common)/F 4/Rect[104.760492 575.842889 284.063227 562.243279]/Subtype/Link/Type/Annot>> -endobj -1225 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[145.670649 471.344842 204.685541 457.745233]/Subtype/Link/Type/Annot>> -endobj -1226 0 obj -<>/BS<>/Dest(table-5)/F 4/Rect[65.905512 451.995233 99.301752 438.395623]/Subtype/Link/Type/Annot>> -endobj -1227 0 obj -<>/BS<>/Dest(name-jscontact-types-with-reserv)/F 4/Rect[104.760492 451.995233 253.144037 438.395623]/Subtype/Link/Type/Annot>> -endobj -1228 0 obj -<>/BS<>/Dest(name-jscontact-types-with-reserv)/F 4/Rect[65.905512 438.395623 94.122797 424.796014]/Subtype/Link/Type/Annot>> -endobj -1229 0 obj -<>/BS<>/Dest(section-3.7)/F 4/Rect[65.905512 410.296014 95.494623 394.696014]/Subtype/Link/Type/Annot>> -endobj -1230 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-e)/F 4/Rect[95.494623 410.296014 383.01269 394.696014]/Subtype/Link/Type/Annot>> -endobj -1231 0 obj -<>/BS<>/Dest(iana-registry-policy)/F 4/Rect[65.905512 273.498748 116.830805 259.899139]/Subtype/Link/Type/Annot>> -endobj -1232 0 obj -<>/BS<>/Dest(section-3.7.1)/F 4/Rect[65.905512 248.399139 99.092035 235.399139]/Subtype/Link/Type/Annot>> -endobj -1233 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regis)/F 4/Rect[99.092035 248.399139 357.955561 235.399139]/Subtype/Link/Type/Annot>> -endobj -2120 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2119 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2118 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2117 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2116 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2115 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2114 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2113 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2112 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2111 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2110 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2109 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2108 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2107 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2106 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2105 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2104 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2103 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1851 0 obj -<>stream -xœ½]É’·­Þæf[¦ì}ph *ìÀU&ÅE4¥¡8¢l‡©KÓ’ýþt£ª§™5@VVmgÃ’/_¾|ÕU5==;¹ÓÛçÓ§`¤!zgvÿxwõó•ðvž<~ž¾Jßy·sF ?Ž>ø]ðV3Fcw¿üóêÍÕ¿®änzû姫/þ.ŸûéßWÓ~O[¤TJX]˜÷¼½ºNo)´ Ç åÝ ewû;È=šŸ¾óYawøñV’<FÓL¿ýl™N´ê8?§¾ß¾—à{¸Œ_8]ø‚Ðތ҆1ì¢v'AZªN¹;—¬“GÉÎØ"¢Ô^ÙQ&:Å/·7€ÒZÈh´:fà¥ÐÊ(+IoÜp”QÙ¤"%£¢ÚXoþFSª&ŽJîÊ_6U污öümHR)#´36è -ð7^V˜ÇøÛ.®@ˆB¥~ë1‡¿ñ -€<¶(ÀÞvi´5"yQ:¿QþÆË*óØ Û¥02 -™0mبãe€ylP€¿íâ -#ƨ7„Øû.\ÿœÆ–òsw]ºú)Š•ÍÖó þÆËÖæ±Aþ¶K+à¤1 è­çAü—Uæ±Aþ¶‹+àƒqtjë!ˆ¿ñ -€<¶(ÀÞvi|º`Ó ÁÖó þÆË*óØ Û¥HïÂ[«Æ­çAü—Uæ±Aþ¶‹+àµ8ãZŒ»íÂÕ?e±¥öÌM—M=šÝ»«àE·ÔvûÅÈtSî7 Ýô/å²+ s[¢¤ÓïÄ{–lœ²[b‚ùÏ%¸hF+F¬ñ‡ì1›û™ÂõçeŽ&½ÂA¯9oŒfQÖˆTþ ´+W?#`wÆ]"€Ún‰Ÿˆ,—ܱ‚÷Ö”«p3ûjö8V?†ì8€YïM,ý -h-~o©Û4mÖ"Ç«@YdaYiÔÊxË20íTŽž(Á¬gQæªhÝXa)“f9µÒ‹ÑÆï=—µlàL€X»vÍ¢§…,‡Zé*|Á̾Z£=ŽÕ/@'m -0>Eê"ÿêr§‡yqi›24EùMËZ×uëdzŒLXjÉòª‰Â~—’ìÝÀ›ÉÑzvïŠ]ÁJž_M¨qÎ3K¿Bf‹ßEíÆ8£Ó~͘¿B…‘]¥c+ãmLËȤeYº¢ ®e½ëÚõcZF¦< ôdy6H£’áÞÏ7pÿÞLŽÖ³ƒ×<›Wò<Æç<³ô,d†budœÑiÏfLŽg¡ÂÈË¡Ò±•ñ6¦edÚ³]Q†@ײÞuíú1-#Sžzr<›Š Ìá7æÉþ ¬­g¯y6¯dyvz•€2g0³¯Öicõc ÐIÏL†g‘ÂÈËc¥cËãLËÈ´g9º¢ ®e½ëÚõcZF&< õdyÖ8•1þÞslqÿÞLŽÖ³ƒW< Vò<›½Â9Ï,= ™¡XgtÚ³“ãY¨0ò²®tle¼i™ô,KW”!е¬w]»~LËÈ”gž,Ïú(ôáuQÈþ ¼™­g¯y6¯äyÖ‡ç<³ô,d†budœÑiÏfLŽg¡ÂÈ˶ұ•ñ6¦edÚ³]Q†@ײÞuíú1-#Sžzr<ëeZd÷÷žc‹û7°f@´ž¼æÙ¼’åY/Ç -g0³¯Öicõc ÐIÏL†g‘ÂÈË¡Ò±åñF¦edÚ³]Q†@ײÞuíú1-#ž…z²üp{;|7< rx4|;<ýôÇ×ÏsTeNã˜i¯MÛž¥÷›ô~=|•>þzø8}ü>}}3¼Haߤ¯†k'j¦×éW£ŸÛxÊõåÓ¿>{üe)×R‚ßÌXOÒW7sÔǯï*NŸTôqª,$³×%̯Ž\R¡~;üjx?½¿WÍ K᧗a‰´U›àPå £:(éî4™jt3N)ÞÜ%ûj®X[Pü3 -´¹@¸Ød|ºtÓÎÙãîö“t`|”òüføÃÜDOÒÛÍ|¤û¾­Tic©6ö›*•–é,zT>Æ»Rý±ñ؃n¨È{íe66Y‘‰‹ Óß2>VäzxÓVòŒš4ŠMÖħ3"mÇ(ïjòErÓõð|ø!}~ž’Ö³›žµU œá¥÷ªÄŦªdÆ ä(•ö§*½H ¾lª -zÆÁøáùUac“UI×éÖyô]UƔ蓔棶º °gÔ¥¡[ØØd]ÒUÒ¨µUÇ#/<}?»*(èƪLïïsÖJLWTÁðñ©ÊØtýebtÞàʤ³ÁWéówsÊO›ÊæÌZm>2çZ±ñÉZi/¢³wíX®)ß—)×ö†ºÿŒ:5h;4³±©ª¸Q‰ƒóCê˜ÇÓ-¦ÊàÀOx¶µ ›¬Œ¶ÓŸ¯Wöx‰¥RzßÌçOç¤o†¿Ì.kë sÆ)OK¸ØdœOWý£Í©N7é„p:9|1ü˜>ÃHgW œqj𛪒G¡ÒaÌDT¥0W©íA ‡þÿÖ†MÖ&= z§\<^néùØ”èt³ð㹇Ú\†!Î8N7\’²±É9+” -ÁHP£7)Õ¯S'=þ|H»­FâŒKÔ–>âb“5Š^¸hbð§MGéïç4§Nš.㟠¯Úª„@Î褆‹66U¥t(ÒÉvªÒׇÓ馺à°g<Ž5t›¬‹K§åÊ+Ou¹™S|•Îˆ®oâàg£º†MV'Z1FmÐŽ¾éô莃o¬Îtôù ¡:\ìGŒë»·ŸÓÛ8G¬ý8ÏÛéÏók)Áøê.ªn?Mµ†‡ß¥·‡d@»˜4rÞÉU ÏSñ>šËö&©+xHΡFåÍ:Ò8<šo°ßÞÎ -ý&½¿¿ ,ŽÞ e½¶²ˆá¦3‚á»ù,óiºÎ}0Üþ'}øbxuûö¿óÈ'ù8Ϭ¥"Á[Ítü fúø}Böéri"=•öåÆÒúôØÒIÔ*k}w«õAê”—íx}õ?ZC¢ -endstream -endobj -1756 0 obj -<>/Font<>>> -endobj -1190 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[182.395746 741.290154 241.410639 727.690545]/Subtype/Link/Type/Annot>> -endobj -1191 0 obj -<>/BS<>/Dest(card)/F 4/Rect[182.395746 716.940545 225.23144 703.340936]/Subtype/Link/Type/Annot>> -endobj -1192 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[182.395746 692.590936 241.410639 678.991326]/Subtype/Link/Type/Annot>> -endobj -1193 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[182.395746 668.241326 241.410639 654.641717]/Subtype/Link/Type/Annot>> -endobj -1194 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[182.395746 643.891717 241.410639 630.292108]/Subtype/Link/Type/Annot>> -endobj -1195 0 obj -<>/BS<>/Dest(id)/F 4/Rect[182.395746 619.542108 241.410639 605.942498]/Subtype/Link/Type/Annot>> -endobj -1196 0 obj -<>/BS<>/Dest(int-unsignedint)/F 4/Rect[182.395746 595.192498 241.410639 581.592889]/Subtype/Link/Type/Annot>> -endobj -1197 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[182.395746 570.842889 241.410639 557.243279]/Subtype/Link/Type/Annot>> -endobj -1198 0 obj -<>/BS<>/Dest(links)/F 4/Rect[182.395746 546.493279 241.410639 532.89367]/Subtype/Link/Type/Annot>> -endobj -1199 0 obj -<>/BS<>/Dest(media)/F 4/Rect[182.395746 522.14367 241.410639 508.544061]/Subtype/Link/Type/Annot>> -endobj -1200 0 obj -<>/BS<>/Dest(name)/F 4/Rect[182.395746 497.794061 249.500238 484.194451]/Subtype/Link/Type/Annot>> -endobj -1201 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[182.395746 473.444451 249.500238 459.844842]/Subtype/Link/Type/Annot>> -endobj -1202 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[182.395746 449.094842 241.410639 435.495233]/Subtype/Link/Type/Annot>> -endobj -1203 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[182.395746 424.745233 241.410639 411.145623]/Subtype/Link/Type/Annot>> -endobj -1204 0 obj -<>/BS<>/Dest(type-signatures)/F 4/Rect[182.395746 400.395623 241.410639 386.796014]/Subtype/Link/Type/Annot>> -endobj -1205 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[182.395746 376.046014 241.410639 362.446404]/Subtype/Link/Type/Annot>> -endobj -1206 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[182.395746 351.696404 241.410639 338.096795]/Subtype/Link/Type/Annot>> -endobj -1207 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[182.395746 327.346795 241.410639 313.747186]/Subtype/Link/Type/Annot>> -endobj -1208 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[182.395746 302.997186 241.410639 289.397576]/Subtype/Link/Type/Annot>> -endobj -1209 0 obj -<>/BS<>/Dest(patchobject)/F 4/Rect[182.395746 278.647576 241.410639 265.047967]/Subtype/Link/Type/Annot>> -endobj -1210 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[182.395746 254.297967 241.410639 240.698358]/Subtype/Link/Type/Annot>> -endobj -1211 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[182.395746 229.948358 241.410639 216.348748]/Subtype/Link/Type/Annot>> -endobj -1212 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[182.395746 205.598748 241.410639 191.999139]/Subtype/Link/Type/Annot>> -endobj -1213 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[182.395746 181.249139 241.410639 167.649529]/Subtype/Link/Type/Annot>> -endobj -2144 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2143 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2142 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2141 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2140 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2139 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2138 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2137 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2136 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2135 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2134 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2133 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2132 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2131 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2130 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2129 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2128 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2127 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2126 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2125 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2124 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2123 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2122 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2121 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1850 0 obj -<>stream -xœí\IÇn€˜ }[Š'Š¢1¬Rí “ÃÙdBÎ IIž’ òedÀNŽ9ä§çUU/UÍêîêaON=$»¶·|o«fµdáõÊ~hNÖFI¾øûçùÏs¤„ë¬>]ãÏs¸Rr!9C -c¥ÕB+8dž‹Å/ÿ˜ïæ?Íɾ~ùqþú¯áÅÿœÛùÊÔS¡ b¤vs>Í×ð‚¥‰®F•ÏŽ”XÜ•$ï¢~{½ûˆ!½ðÿ…ô˜ô GÝ*èþôM›#hÕïØ -®ïü5 ®ÃyAû³Û¼aöߢý’üîf^c¯ÒŠc"4Ö Â8’XcøzóyþúÏ—ë·—oD.n>ÍxY<-¿¿Ùñ_nÞ4Kª£’€ñÄ À”Ŧ8/–Å®XWź˜Áû¼ïŠï¡}V¼*$Œ±=;u -ï³B··Å5toáBÀ瘼…® tĤ9`¡ \í“nq *AÌPá}{þñâä;X9e1UŠümñ¼ ð7~—Ž¡ÓZ¢óâ,ähH–#¸Ü´¥1ø¥U(Œó«\ï¡ãVÙºëF[+G} ­ A“°ƒ)3 ÿ>WÅYŸ”ADQ¬ä¼ÎÖ0óÒ>…ùïàeWõÐÙÕ/àÛ¦¶]%ê¬^fëXY;=]ÃÄ+` ˜rc–%‘Kèy-;×j庀?û¹†þó€èÒ14ƒùKG6 ¹í“Ó€yb®5+…|ït{6 Žç÷Úñ²óþàXxï{ÜC‘RŠ`jJŠº ÔÎÑ 4zumK»RÜkgv'N=+`Ì« „{ím–¬ŽmËg3§c+ÙÉ1 sCU R¤Dꨆü=\¯MÞ¾,nàhöÉÊ%2˜A)eí¨âxÝðÔ°Ú«O¥“Æ@ôÔ§‡íÔßFÆÓ8O`©Þi®@Ì3öuiŽWÇÒÉÍ~L5öƒelX £)pŒ0Å"5¡-¾{¢Œª§AŒ´öi'õ&¢G¤¥F†bmH>ÝÇuEÊ ŒCP‘†K9@:aƒ¿kss''¡È°yr(į]ðY;K´àk0Š%ÖÔ,q,‘’šS>h«:ú™c‰_:©ñÄL)(ý>Xõ0¥žV.?4SBÈÏ„‚÷ÂȵkVÇðM™¼,ƒÓ2&ÁÁdŠ ¹–H$2‰þèbÓ© ‘×µÓGlføêN&™aQ·ÏbUÎ}•(éEP§+Â[ËÁ´Ñ%›í?fÎ^|²wÅSLIlÄ’tŸ`›7%m £œ2lÆœï£Ú¤]‰ÖIaO3D!Ç Õ -*°*.–M6;ñùÕ5øÒæÒêé˜ÃõQñÈåÞS’µ‹.Úøvo~欳uì‹¢£<#‘DSÃx+¬¢¦úyí¬|ÿè -ÌSx‹Í OBh¼ýÛ¿aì*HS~Ô‰+B¬,a!Û¢Óâ—+À5Ô„²*·Ÿ”جùòç -Øõ:,ÈÚcÛ‚&ê9_ôð{‘®D3Y||áq~ŸÊ!T lö0ã˜EdïU¶>|ç$øjdÉ@C‚R.X>ÍÛO s„øcˆ´âl2Ò—à®,\ÛyžaË-ZۃΊß׫ø Æ•û|äl`·`(˜X'çÚ€¿KVW·•“7{oDePs¬Çbm#·èO¢¡EÛ­ÁªfºÅ¢0zŒ°n·Nú2¶túŸÀacˆàÿ÷¿J%T"ʈN)Óù_6Í”ÿQŠ¡ÞW‹VáãY©»*Úoê=窂Á§¤ëÒZWµ8ÕÖÉöß”(ïê]¦ß¿‡Õ—¿õPÁYíÄíOÎ>ö}¶Û*ƒ¬ÎËû3 Æù·vG -•Æ±ƒ¿âN؆å^oã²nÃD3eVÚɹKÿI-J -æ!´­*È?w^å7µ^”D 7‹Y²µ†ÝMŸ”q¡º²míöR÷<>ÖÁª¦SUÀÇF -ÞDÜÖîvë®N‹•Õ~•§o#5‡EIÇÍœGfSLûÅ:tÓ`a- N0«cÐ¥3•]Åô¡•<Ð@L¢T{+VÉ´ô2 ZºjLJ4LìQ¨î#êvÅt#eÓí\ñ¿b@ -…lD]ç3p°Ô’W26°ÑçÇ -HþiÚ¢°Œ!3waOzwañrå] G—®˜¨ò¦»ûéøÐí°ÍRʳÏJßv &!©4Cùª@º(·î¶È¨RÍ.ȱïJ·l«–.ºv`¾l[–éª}£2§ɽßD×>Ý»ç¢þÅ¢ºÁ"·+ß8÷ß'ªâÿ‘ÛáYn5w™•hõ{ÕÜ“áüá;/nù˜¦šaMpU®ÄYþQ5ë¤:œ>ýÏ›¨ˆ©§ÿ¶x¯§©{ŸZ#ÖpgæÔþ‚À90 -e]€Gr)m4“¤úÉóÞaÓÄ…­†^¤¿Žÿ•2pNÃù€]£œÓ!À½¦=û±"!„cJlMF"=`•¼H= €1dO{ö#E‚w"#˜är$ùäO{p`¸Ö°±Q(â#ð1ìiì ±†ŸçqöjzîÚ=´é‰Ö -ÚË!Òþ^é¯!ï]Ô  /¶RtñŒ{E‚³# ÑÚž¡ˆ¤Mk¡[¢hƒ$MS¶v ½89Ó|£")c­@„>Âö¢ªózšÕ¦Ä/@ÀÈÜ»ø±¿Ÿ´†–RGY…uÉÜô´-9”¬•¡&“¸¡ÞoÉ ÍnK浆‡í!ŠiËÛ“4MyÙ4'ݸF¸¦ñîÆn:IÓ”û|6À3ËgD.µR†ö›°Î뉜Ҏ‡<·™ç¹°Oì–<êlûoKÄhÑi¥ØèwäˆrŽ/·ÜœusGûÁR§‰÷{tÞ“1ަРè¤Rw²Ðçà1Î9>®©AÜ×ÝCf®s;ƒ5'¶ò!7gyºÝw¤åzî:uv¯5Üõ^×hføu„väï¢Û’;»”·“~¿kgbñ`œÆ¾ÇéäMSîqçÛ,_–b)+¶e×Ó¬6¥5¸p02Ï%î’¹éiûo(Y´Ö„7Ôûý·¡™ã¿!‘_ë‹íh?LÒ4å^·ÍÂ5â0À5w7vÓIš¦Ü糞Y>kì¤î®K¯ý꼞fµ)-xÈg›‘y>kX—ÌMOÛgCÉ¢µ&”¸¡Þï³ ÍŸ Ž|wXlGûa’¦)÷ûl®‡®i¼»±›NÒ4å>Ÿ ðÌñYC%Òövë·_Õ¬6¥ùl32Ëg 2=wzº‹×šNâ€z¯Ï43|6B8òeÖa±éö%MSî÷Ù\#\Óxwc7¤iÊ=>â™ôÙ±GIL´‘I`ÊÀQ’ýgjZ'Üx³9ÖL>¯ð«ô“ -ñ’1£Z NUC‡ˆŸ»gðò'϶ãÏk†²ä’m?feÜ<+€{v¸BÖt4ϧ?ëÑ&Ê>ÉÚâßÓ‘;cqYžÓt‡WÒZLðžZ{r­eÓïÕšÀˆ #Dp„ä9piÏU—Íq¦{ëªMf¤º¾¾QûH>†°2Š|¯¶4…Ø$‘‘½wgzª³J÷ÖQ´ø=4öÇPA¹´û´cˆ@Ôû’×΀AÿÁ² {÷ÕM¼ôÝX{z?kt“M;:^[ŠÂnÅ®4¥ÄBÄĆ©Ø2iý\|îª}ꪟ“’J’AB{ÇõÆQ’’#Š©âÔ¢g¾ž_Â߯dzÿ×¥X,$ICº£œ×îôÛyñÖ)ü¼½.®n?ýÇe„³âj¤.!Š©•`9Äý±»¥{>{ëN>nœÐVµoGªVj#Å Ô¬>œù¬øºmŽëùè»Ó= -endstream -endobj -1754 0 obj -<>/Font<>>> -endobj -1174 0 obj -<>/BS<>/Dest(section-3.6)/F 4/Rect[65.905512 753.389764 95.494623 737.789764]/Subtype/Link/Type/Annot>> -endobj -1175 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-t)/F 4/Rect[95.494623 753.389764 339.67016 737.789764]/Subtype/Link/Type/Annot>> -endobj -1176 0 obj -<>/BS<>/Dest(iana-registry-policy)/F 4/Rect[300.765375 643.791717 351.690668 630.192108]/Subtype/Link/Type/Annot>> -endobj -1177 0 obj -<>/BS<>/Dest(section-3.6.1)/F 4/Rect[65.905512 618.692108 99.092035 605.692108]/Subtype/Link/Type/Annot>> -endobj -1178 0 obj -<>/BS<>/Dest(name-jscontact-types-registry-te)/F 4/Rect[99.092035 618.692108 274.274897 605.692108]/Subtype/Link/Type/Annot>> -endobj -1179 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[80.905512 520.29367 115.14184 506.694061]/Subtype/Link/Type/Annot>> -endobj -1180 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[80.905512 457.895233 115.14184 444.295623]/Subtype/Link/Type/Annot>> -endobj -1181 0 obj -<>/BS<>/Dest(section-3.6.2)/F 4/Rect[65.905512 362.397186 99.092035 349.397186]/Subtype/Link/Type/Annot>> -endobj -1182 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscon)/F 4/Rect[99.092035 362.397186 337.296869 349.397186]/Subtype/Link/Type/Annot>> -endobj -1183 0 obj -<>/BS<>/Dest(address)/F 4/Rect[182.395746 263.498748 249.500238 249.899139]/Subtype/Link/Type/Annot>> -endobj -1184 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[182.395746 239.149139 249.500238 225.549529]/Subtype/Link/Type/Annot>> -endobj -1185 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[182.395746 214.799529 241.410639 201.19992]/Subtype/Link/Type/Annot>> -endobj -1186 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[182.395746 190.44992 241.410639 176.850311]/Subtype/Link/Type/Annot>> -endobj -1187 0 obj -<>/BS<>/Dest(type-signatures)/F 4/Rect[182.395746 166.100311 241.410639 152.500701]/Subtype/Link/Type/Annot>> -endobj -2158 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2157 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2156 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2155 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2154 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2153 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2152 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2151 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2150 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2149 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2148 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2147 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2146 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2145 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1849 0 obj -<>stream -xœ½]KGr.` Ëø`È+Qô® ôA – ±”ïÇÁ†½‘C.AŠ¯jwö`æ^ZvíàŸîȬîÉȪÈì¬GK­áLWVÆ_FÄ—õ®ß1ø< ¿œâ½sÞµûÏŸ/ÿzÙ[¿ã¿^Â7kvFÉÞ2fÝ9«{¥˜Wz÷·ÿº¼½üïK¾ Ÿ¿ýåòûÿà=Ûýå.Cëï»p.D¯¹7.öùtù>`š»ã€òs„Ò»ýrŸµ‡ï·¿°Þí†ÿ1Þ 'ÃY³EÍŸ~7vÇkqln¡ïûá;Gßq?´üÌî¦OÏeøo7þ!ÿþò>öÎöÎ*ƵcnôÂË`ûýÏ—ß¿ºþãó~¿ã²6$¬µ{ÿéòO¿íl÷‡îº»èžwo»×ðyÛý±{Ù½é^À²Ûîªû–…ö×°ô–ÜÄåCŸ°ÞKøöÖ{ ß?ë>ÀòøùÐýÿ>ƒ%ÝGXröBkèq ­/ãz€öÙû¬{Ò™î,}±ŸÂ¿„õßvï¢ÕÛCÏ`7`½8xõ¡»»{ìÙo»Ïÿùý‹Ò˜h×+aàWà~÷ø±‚>o¡ûàÄËèÔ» ð`øï‘Ÿà÷U£áÛÛ«a¯£¹ÁÔgÝwÝ]ä»Çðw°ú=C¶thz„a{ s½çÑX´§‡¿9„êîúu÷>äx(Äðq®—÷àU¯w\Ë^[Ï™ØIHc¸RÚðcÕ/èÒ{.­ÐŒCEÎ×*æµäÜ<0ªgÆ(¨/Úé™Îà²b¦gÜk/„÷½d–[Wpyf‡3¸œEš Óûjp¼5ëµw^[VL‘öŽ½W•g‚ïè?W% -ö#EŸ&°¨ÛÜG9€ü@™@»¿¨ÛÜÏò@pÖ3ÉÅ\‰iîwÞôAnÌ›æ^çMžäÆÙiîuöÔ± -’Xj%ææNsÇ3'òcNö4w;sú$?fåOs·s'”¾¹s°yDZÛ]•¤„Ø H˜'I¿Hft*d9G¶"Fˆßi-™›I”-"½|C¸ºmÔ”¯ØAG2¼Å€mÆ’„­ˆPBkÓ %zïm8VP+I×ÔlmX•'$(­Ø¦@áOšojkæ•ÙÚoB¯ËPÂlÑ!Ì–…2£ÌÎ*¦4rMŒË5Â9Œ—£D%‹:_¼Ž#‰[£–ÌÍüC±¤c\ŽÙvàuh~‰pŽbC¬™í¥ãÎÏãlFO£ý²û<þ<(zR-ƒw@Õ8%ø,ø»Oña¹ÃH¸á1Ãå14¦×L9'¸`˜”`½‘Ã0eæ~1Rá¹1|£Vì»Oµä†oÞÂŒær‹äª{ÕÙÇ:>ñ¸šËãîætwŽq÷GÐõC|èñ’ÀÀô,4Hû˜Ö‚À|57y¥è½bÊ‹vìj`„ä½’ ÚG >‚nvÿ=-ëç¤c‹¶L:}óX@ôžÁgxN÷ÍÂXÝ3Ð5&43$áç‹ð37,°-£9sáÖïVüzXŒ„‰È"¾O6Oó. -Õï;ݹìØû_Ëá!zoU*Û ªåáòj™_Œ7½„ÍcôÜ|VÈxõ¦2wÚ,™á™…ñõŠ´bW‡_¿“°-î‡xâ¹&&]²9J£\…®Ûoå@¿ìVP3v=0°Çë¦W|„)úY¢ëJ}Lº9˜ÑÃœð¨ûöÐÙ3R9Hc[UKnxAµ|ÑýjnXâõÕ<™Åa Oì3Ö3uPŸr8Æ«·ÈÕ¤Ó0«Œo”^ ±$x-ôØ«™øÍ’êPæsØ•åí؇„GñÍ#×ñWK¹ÛÂI'r/ÆJqˆ5ƒÝôãÔ·Blò(›\Jy§F6[†èðc} ®ö1W®‡}å%"*¨—`n3ÓäŒ ·ðsªuî| àn¼^S ™ ÏÄ—ú~ïeÝÎdnnÁ(}¹|g²û0JßGåyµ03 ˆ­E´šó\1ñ™WÊ33›3‹¯)zÙ]•B¹vË¥âÛ$DfnÁàÌ݉Šъ}øåM|ïì™FwÂ[^^E´DgYH *¦¥^7T†q!K㘞ˆrfÓ ï¹NÓ÷ÓøV§g0¿>¼Ek£}n €°eF°3î«%'`o¶oŒsʶÃÃØ}¨ßÀP„#¨Ã® u”s§`‡ŸûÙûT_ÈÏ/Õ‡§ç…Y§ûóIz#QPŽvªâ+ÓŠ›‰“-›‰“N³ÞÌHØvAý•¬=ï­f̈vìêv»V ‘F ´;uÛ=-d¼úüݨ‰‰C‡ø6»p.åÝÂíx:a”e^…ˇ2”›ò³ÍÙ \HÕŽ]Œã°ÁÉÔýÞÎOq‹ÿcåXé¤KS¹Œ;Mu;œZ -q‰GjãI¦…JîzÅ“|ºðèél5—*Ä|ªCìÇŒòmïvŽ—¥:̲ ½|Û»Á}T‡ØåÛÞí¼¹o-ì° 22ºšµìÇ-&µŒæ³ûå+¯&GèAü  Ó«É&Z/»Î:›²[zÊŒFSß -¦42‘ájrÒ´V~Í<žÙKš}™Íh†\Á’FFZYÒ~ µ2–ÙˆXÒìËlFé -–42’¤áJrÒ´Ö“ÂõòKš}™MfgK9(—”+²¤ý@k•ïäØ]zXÕ!×Ô‚¬m©D'Þ^…Ö|R~{U¾AsF-ûâ8ís[Û1FèUíE˜ Ú›±¥G¡Ì(³³Š)\Ñ^Ìò´öf,iöe6™U,iäŠöb–§µ7cI³/³Éì¬bI#W´7ËØ’öÞß•iZžé­ÕÙò•,iäê›Èš”(óÅ“Žs9nÛ1¥‘+³ ŽgÓ,cá›æÚLžÂ•+®kkIÖ¶Ôܳ Z³m–™¸À9µŒgÌ,³µ!ã„^ŸefË,ƒÙÒ£Pf”ÙYÅ”F®Í2ˆeÃ,ƒYÒìËl2;«XÒȵY±l˜e0Kš}™MfgK¹6ËàŒ==Ë`MÊfSÐØÂòu,iäê,Ó¤D™‡(žtœËqÛŽ)\›eP<ÉYfÕ½¿ÖÛ^ë0nÇOí·ÿVN:›^Èû;3éû„y:Æ0öã$êºpÞ蓬å¶÷°ûõ8ß\þ?¾œÿÆ -endstream -endobj -1752 0 obj -<>/Font<>>> -endobj -1142 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[380.536423 741.290154 439.551316 727.690545]/Subtype/Link/Type/Annot>> -endobj -1143 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[315.473923 727.690545 374.488816 714.090936]/Subtype/Link/Type/Annot>> -endobj -1144 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[340.690476 703.340936 399.705369 689.741326]/Subtype/Link/Type/Annot>> -endobj -1145 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 678.991326 423.383103 665.391717]/Subtype/Link/Type/Annot>> -endobj -1146 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[340.690476 654.641717 399.705369 641.042108]/Subtype/Link/Type/Annot>> -endobj -1147 0 obj -<>/BS<>/Dest(uid)/F 4/Rect[340.690476 630.292108 399.705369 616.692498]/Subtype/Link/Type/Annot>> -endobj -1148 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[380.536423 605.942498 439.551316 592.342889]/Subtype/Link/Type/Annot>> -endobj -1149 0 obj -<>/BS<>/Dest(updated)/F 4/Rect[340.690476 581.592889 405.295213 567.993279]/Subtype/Link/Type/Annot>> -endobj -1150 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[351.618943 557.243279 410.633836 543.64367]/Subtype/Link/Type/Annot>> -endobj -1151 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[468.396287 557.243279 503.042771 543.64367]/Subtype/Link/Type/Annot>> -endobj -1152 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[312.014695 543.64367 333.783738 530.044061]/Subtype/Link/Type/Annot>> -endobj -1153 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[398.12407 543.64367 457.138963 530.044061]/Subtype/Link/Type/Annot>> -endobj -1154 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[315.473923 530.044061 374.488816 516.444451]/Subtype/Link/Type/Annot>> -endobj -1155 0 obj -<>/BS<>/Dest(links)/F 4/Rect[410.833787 530.044061 469.848679 516.444451]/Subtype/Link/Type/Annot>> -endobj -1156 0 obj -<>/BS<>/Dest(media)/F 4/Rect[315.473923 516.444451 374.488816 502.844842]/Subtype/Link/Type/Annot>> -endobj -1157 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[455.830125 516.444451 514.845017 502.844842]/Subtype/Link/Type/Annot>> -endobj -1158 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[408.95366 502.844842 467.968552 489.245233]/Subtype/Link/Type/Annot>> -endobj -1159 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[312.014695 489.245233 371.029588 475.645623]/Subtype/Link/Type/Annot>> -endobj -1160 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[384.797654 464.895623 443.812547 451.296014]/Subtype/Link/Type/Annot>> -endobj -1161 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[371.448533 440.546014 430.463425 426.946404]/Subtype/Link/Type/Annot>> -endobj -1162 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[411.313523 416.196404 478.418015 402.596795]/Subtype/Link/Type/Annot>> -endobj -1163 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[401.16655 402.596795 468.271043 388.997186]/Subtype/Link/Type/Annot>> -endobj -1164 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[379.207078 388.997186 438.22197 375.397576]/Subtype/Link/Type/Annot>> -endobj -1165 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[340.690476 364.647576 399.705369 351.047967]/Subtype/Link/Type/Annot>> -endobj -1166 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[371.666795 340.297967 430.681687 326.698358]/Subtype/Link/Type/Annot>> -endobj -1167 0 obj -<>/BS<>/Dest(table-2)/F 4/Rect[65.905512 320.948358 99.301752 307.348748]/Subtype/Link/Type/Annot>> -endobj -1168 0 obj -<>/BS<>/Dest(name-jscontact-properties-with-c)/F 4/Rect[104.760492 320.948358 305.399408 307.348748]/Subtype/Link/Type/Annot>> -endobj -1169 0 obj -<>/BS<>/Dest(prop-extra)/F 4/Rect[420.243167 216.450311 487.347659 202.850701]/Subtype/Link/Type/Annot>> -endobj -1170 0 obj -<>/BS<>/Dest(table-3)/F 4/Rect[65.905512 183.501092 99.301752 169.901483]/Subtype/Link/Type/Annot>> -endobj -1171 0 obj -<>/BS<>/Dest(name-jscontact-properties-with-r)/F 4/Rect[104.760492 183.501092 305.296869 169.901483]/Subtype/Link/Type/Annot>> -endobj -2188 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2187 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2186 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2185 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2184 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2183 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2182 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2181 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2180 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2179 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2178 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2177 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2176 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2175 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2174 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2173 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2172 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2171 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2170 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2169 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2168 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2167 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2166 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2165 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2164 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2163 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2162 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2161 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2160 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2159 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1848 0 obj -<>stream -xœ½]K·@·Í!0b[v’ÃÇ -lºù&/F(ÒZ1d=-'VAå² -`'? ?=ÅžÙaU7É©îæÈëÕî6›õÕW¯Éî™Ý½ÜðñEúŒ!DïÌþo¯~¼ÞŽƒ·_ǃ?^ÁOÞíу~¼Æ ÑØýOÿ¼zuõï+¹O?ýëêË¿K1ìÿõŸ«4ßÇÓ)•VFÆ9o®žÂ˜–áö @y;BÙýÍò†Œ§Ÿ_ýÀDØþÇxgœ<&à ¿ùÝÔhÕíøèúùæð³D?ãyèø…ÝÅ!íÍ mÂ>a÷Òja}”ƒÚkðÝ9iŒuò6e+¦ˆ(µWv@§øíòPP‚Ñj)ýÑgÄàœà”^8á.›Á‰AFõÁ£Ðƒ—>T\^8á.“LKåDL na‰ð'Š®š8(¹/»©P° Ê…?íî£@~,)þ´ ¸Oë Âe#£ÃÒbO¼p!?–{Ú… (û±¨€ØÓ.]@Ê:_Å…ÄŸxÙÂ~,( þ´ËòcIñ§]º€´ŽPÊ6hëÀÂF8ì‡jñ'^¶€°¹ÊVM»l!?P%”Ý_5íÒdà”膨ýBâO¼la?(Úe ù±DøÓ.]@@£µË/aü‰—- ìÇ‚âO»l!?–ÚÅ (zBH–{â… ù±¤€ØÓ.\@ÙEÄžvéòN‰ -ÕÂâO¼la?Úe ù±¤€øÓ.]@Ayá­rƒYX@ü‰—- ìÇ‚âO»l!?–Úe£ÍþíU5D·÷7“#é&8žƒnŠ»ôø²/‹}›¢H i;Tݼ›b¢ñ/$º_NnÄ‚÷”ÍÜS|þ:Ï)*·ÑoŠ‡F‰×~° ΃éÑkÊbî%>×!UY8TÙè5ÅC£Äk’ 5k÷.‹5šGÐìÕ3À>”6ˈLO9²šÜN.sB#7Õ8ÜP[ý"ôfŸ LF¿¶å(Ô;›˜–‘}…YVûËÜö ©St|¬IÚ‡äç¬(Ò¼>)r½:‰G(_å<ÖóÒY¹¡(§,6Š¨•ŠªÝ…7’­õìÃ3ŠƒÎä) 5Îydª<˜±Õ‘qFo+OÆä(f[ŽB±³‰i¹¥<ˆ%CypEr•¾¬ßƲŒÜT$VõQ>Ëy®ç­Ó2rK™2O™¢úð¸­Ù¥7’­õìÓsÊ”Ïä)S”5ÎydªL˜±Õ‘qFo+SÆä(f[ŽB±³‰i¹¥Lˆ%C™pÅ -•¾¬ßƲŒÜV&NõQ>Ëy®ç­Ó2rK™2K™”‚P:cƒnwi` k=ûôœ2å3Yʤ”®pF#7Õ8ÝP[ý#ô¦2!L†2¶å(Ô;›˜–‘Ê„YžW&RÇD±d¥/ËÇ7²,#·•‰S½ÄC”ÏržëyëÇ´ŒÜP&„ÇS&ë…>¼Â¤Ù¥7’­õìÓ3Ê„Îä)“u5ÎydªL˜±Õ‘qFo+SÆä(f[ŽB±³‰i¹¥Lˆ%C™pÅÒ•¾¬ßƲŒÜT&VõQ>Ëy®ç­Ó2rK™2O™B>º0¾K¡Ñ¥7’­õìÓsÊ”Ïä)Ì®pÎ#SeÂ̈­ŽŒ3z[™2&G™0ÛrꌈMLËÈ-eB,Ê„ë˜(–«ôeåø6–eä¶2qª—xˆòYÎs=oý˜–‘[Ê”ñXʤÍkÉñE•Í. ¬d­gŸ{+é«îÉ¡7• a2”‰°-G¡ÎÛÙÆ´ŒÜP&Ìò¼2‘:&Š*}Y>¾‘ey^¿eOêÕ‹=Äù,繞·~LËÈ eBxÎg9Ïõ¼õcZFn)SÆc)“Qiù8¾ Ù¥5‚¬õìÓ3»9t&k7—Þ;QæŒFnªqº¡¶ú1FèMeB˜ e"lËQ¨3"v61-#7” ³<¯L¤Ž±>àZ-÷79¾‘e¹¹›cU/ñ峜çzÞú1-#7” áñ”ÉZ•æÏ©h—ÞH¶Ö³OÏ(:“§LÐÎÎydªL˜±Õ‘qFo+SÆä(f[ŽB±³‰i¹¥Lˆ%C™pÅR•¾¬ßƲŒÜT&VõQ>Ëy®ç­Ó2rK™2K™\ -Åá­sÍ. ¬d­gŸ{ !¬ -θ¹.åó€&=q®Jé­‚e¾h䦣j«[„ÞT%„ÉP%¶…:#bgÓ2rC•0ËóªDj˜¨•©ôdùøF–eäií–ý¨U.ñ岜ãzÎú±,#7 áñÉ%“…çS´Co$[ëÙ£gÖJèLÖZ ê»Æ9LU 3#¶:2ÎèmUʘUÂlËQ¨3"v61-#·T ±d¨®c¢VªÒ—•ãÛX–‘›k%VõQ>Ëy®ç­Ó2rK™2O™búð.ñf—ÞH¶Ö³OÏ)S>“§LÑ×8ç‘©2afÄVGƽ­L“£L˜m9 -uFÄÎ&¦eä–2!– eÂuLËTú²r|Ë2r[™8ÕK“¥LpyªpF#7Õ8‘>îÉ¡7• a2”‰°-G¡ÎÛÙÆ´ŒÜP&Ìò¼2‘:&Šå+}Y>¾‘e¹­LœêÅâ|–ó\Ï[?¦eä†2!<ž29-ôá£4»4ðF²µž}zF™Ð™¾‘e¹­Lœê%¢|–ó\Ï[?¦eä†2!<ž2¹AøÒc*Ú¤7r2Ö³KÏè:“§K6VŸ¦ª„haCÙž Û’tBä(âY¤_%ƒlâX„m‰QæÇÐ"T¹D¢|¥+Ç71,7•ˆU¯ø|”Çbz« ëƲÛ¡Oƒ¢2˜g¿¡‘´d` d[»òœNä)PT5¾ydªA˜±Õ‘oFoËPÆäèf[ŽB±³‰i¹%Fˆ%Cp ãã¨P‹MMoãXÄm‹£r‰(—å×sÖg¹%H¯¬HBêôß~ú£þáÅÕéo2Fò;Ž¤q°Q™ý‹·W_þñÉÓÇOí¥£ gí_¼¹úá³Þ½Ü=Û=ß]Ã×W»×¯wwvrw÷dw}ïo/eëÊæßFl—møôåùÔˆ‘ùO1Œ| -žÂ×»v¯¨%JÖ¤_1®?îòßÇ×ýúO(ñM¿Ý}ÿ^ïÜöøé|÷]ðÔ>Øù|÷p÷ÕNU­ý¾Î¼`íSùK°xg÷³qÞŸ^ÌÓÓ}L€Ÿ^᧬ŽnY$’¿ ºßŒ1¹³û`÷ÞîCøü êA.@ oÓßÅ0ƒIoˆ[ÿúM+£aA%Ý1@Ï < HOÁÝ¿Á×[·! õ´M8˜örÌÖ£zv¦“|¤…ÏðâàCZ­J’…˱å×rº0IÁçû+VNÃ-.L#ÕLÔîçõÐ)H›†­À­æ—ªÝ¦Mú M^› ÔŠ«Àª€)#´“:Déø´kÛI¸¢HoC¹¶ÁÿcÉ>Ÿ.±qO°ê|:i^çë¤Ç[1èkÍ Äʪ~©üÀÎÛÊ! †Ÿª:ï¬ÖñvJB7KîJÞõLù(Œ6ïHp/Pz{`€ÂI•35½¶Ž9ìa“ìjuö±f¾—¶W–‡†õ{ˆP®Áø•´ëé2ÐΨÓñ¶£–ÞB"LmžÎ0^á¿úX¹v2Bª!"l䚎,® X9éŒ ‹YËqËôx¼;{Ô‡3ä¼0Ñ“gUÕvjqÅ`‹à.€?ƪþŒo¥àz὆bµIH6†cÍ;X`§ßR4¨B~W+/H¹S1„Ûkr¾%½nñ›^Þ`äàÃÄô»¸¿l”ðÊ»Aò±µrxˆý>¿÷+oôháäñ.à:öÕ<9Øëy§\´Hr?X!>Hr©ÍóAJwÿ<Êî÷ÇÆzÔk5“¢åaËâÆËÛ±RåÜ]ÓYPµ®³@·ƒò^=]JŠm~~ö D,=€»ÿ^ÍE}‡¸­ˆšrBšñ>=l¸ýþ1D‹/ZÖ -é\jl6Öq÷p5Ð:}¸£¿ˆÚG+tÃI+Œ4RY>Ö{GRå[ÎŽÏð3ÂÃú5]…^Ž-4]áÖŸÎŒ¡ûž»¯jKå{_„øYã±âÌj¯ÇŠÔð»XbçÇŠlìæ¨t ÊãÇŠéêð°ù¢•Ù$ÎÝéÙ¤nI †&!õÑ/7$‹ÝL‚—QÀ¾)ž¶„Ïé%ºšˆÙÄÛGíô -_7¾ã>,»ý=;¤Ï|²úÞ`T®ui GaV¬¦÷‰‡M —Ö8>v;EtXm Q•„çÛñE@IáŽÁª'j:êš=;÷Š¢™¡^]D ¯è¢_­ï"6v;EÈ(X˜úYŠ -ëMœœéDšœßÀägã­âûíÔLÍL³ºò;(Œ³*º À»H¬ƒ¬•ápc… ßÌR€€¹¨ôiök¥ÝZ4ÌLT·„¯çsf¶W«QÃï`ÉZÝN¢‰¾ƒª<%Ýs¨'j:³n˜Mê|¯c¼«ë4¤fõ.^–OOœÙØíÄ ;qã¼9%æÙøZõOZý3DõÿÔè–©‘Mâ“6&Áʉáwô(vE"i‡itÎ'@ž?~„a4Y{?„·PÂÄñ÷qÓŠ:šµ»×÷@zîì~ ¾ò† ]„òpÞɳ@_@oßÍ^$ðjRº¯ åÍy¤awÿö…0)M¿€Ï»ËÀÀpôéý€^[YÄpãÊìùx;Ÿ,¼þïø áÙë7ÿ;îKŸ-Œ%…LKsÀ,?WÐ~÷r$Bûxah½*DgϲÖÇñ¨”§åøôêÿ8LÃ' -endstream -endobj -1750 0 obj -<>/Font<>>> -endobj -1101 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[340.690476 741.290154 399.705369 727.690545]/Subtype/Link/Type/Annot>> -endobj -1102 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[339.370652 716.940545 398.385545 703.340936]/Subtype/Link/Type/Annot>> -endobj -1103 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[340.690476 692.590936 399.705369 678.991326]/Subtype/Link/Type/Annot>> -endobj -1104 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[340.690476 668.241326 399.705369 654.641717]/Subtype/Link/Type/Annot>> -endobj -1105 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[340.690476 643.891717 399.705369 630.292108]/Subtype/Link/Type/Annot>> -endobj -1106 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[411.313523 619.542108 478.418015 605.942498]/Subtype/Link/Type/Annot>> -endobj -1107 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[401.16655 605.942498 468.271043 592.342889]/Subtype/Link/Type/Annot>> -endobj -1108 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 581.592889 423.383103 567.993279]/Subtype/Link/Type/Annot>> -endobj -1109 0 obj -<>/BS<>/Dest(name)/F 4/Rect[466.058396 581.592889 500.70488 567.993279]/Subtype/Link/Type/Annot>> -endobj -1110 0 obj -<>/BS<>/Dest(name)/F 4/Rect[312.014695 567.993279 341.873338 554.39367]/Subtype/Link/Type/Annot>> -endobj -1111 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 543.64367 386.137254 530.044061]/Subtype/Link/Type/Annot>> -endobj -1112 0 obj -<>/BS<>/Dest(name)/F 4/Rect[428.812547 543.64367 495.917039 530.044061]/Subtype/Link/Type/Annot>> -endobj -1113 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[377.567918 519.294061 436.58281 505.694451]/Subtype/Link/Type/Annot>> -endobj -1114 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 494.944451 423.383103 481.344842]/Subtype/Link/Type/Annot>> -endobj -1115 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[481.145554 494.944451 515.792039 481.344842]/Subtype/Link/Type/Annot>> -endobj -1116 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[312.014695 481.344842 333.783738 467.745233]/Subtype/Link/Type/Annot>> -endobj -1117 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[398.12407 481.344842 457.138963 467.745233]/Subtype/Link/Type/Annot>> -endobj -1118 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[315.473923 467.745233 374.488816 454.145623]/Subtype/Link/Type/Annot>> -endobj -1119 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[454.918259 467.745233 513.933152 454.145623]/Subtype/Link/Type/Annot>> -endobj -1120 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[384.257127 454.145623 443.272019 440.546014]/Subtype/Link/Type/Annot>> -endobj -1121 0 obj -<>/BS<>/Dest(links)/F 4/Rect[479.61699 454.145623 514.263474 440.546014]/Subtype/Link/Type/Annot>> -endobj -1122 0 obj -<>/BS<>/Dest(links)/F 4/Rect[312.014695 440.546014 333.783738 426.946404]/Subtype/Link/Type/Annot>> -endobj -1123 0 obj -<>/BS<>/Dest(media)/F 4/Rect[378.097459 440.546014 437.112351 426.946404]/Subtype/Link/Type/Annot>> -endobj -1124 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[315.473923 426.946404 374.488816 413.346795]/Subtype/Link/Type/Annot>> -endobj -1125 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[455.830125 426.946404 514.845017 413.346795]/Subtype/Link/Type/Annot>> -endobj -1126 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[348.030808 413.346795 407.045701 399.747186]/Subtype/Link/Type/Annot>> -endobj -1127 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[467.708543 413.346795 502.355027 399.747186]/Subtype/Link/Type/Annot>> -endobj -1128 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[312.014695 399.747186 333.783738 386.147576]/Subtype/Link/Type/Annot>> -endobj -1129 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[439.281052 399.747186 498.295945 386.147576]/Subtype/Link/Type/Annot>> -endobj -1130 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[394.605515 386.147576 416.374558 372.547967]/Subtype/Link/Type/Annot>> -endobj -1131 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[439.79155 386.147576 461.560593 372.547967]/Subtype/Link/Type/Annot>> -endobj -1132 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[340.690476 361.797967 399.705369 348.198358]/Subtype/Link/Type/Annot>> -endobj -1133 0 obj -<>/BS<>/Dest(prodId)/F 4/Rect[340.690476 337.448358 399.705369 323.848748]/Subtype/Link/Type/Annot>> -endobj -1134 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[369.438767 313.098748 428.45366 299.499139]/Subtype/Link/Type/Annot>> -endobj -1135 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[340.690476 288.749139 399.705369 275.149529]/Subtype/Link/Type/Annot>> -endobj -1136 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[357.648972 264.399529 416.663865 250.79992]/Subtype/Link/Type/Annot>> -endobj -1137 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[340.690476 240.04992 399.705369 226.450311]/Subtype/Link/Type/Annot>> -endobj -1138 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[384.797654 215.700311 443.812547 202.100701]/Subtype/Link/Type/Annot>> -endobj -1139 0 obj -<>/BS<>/Dest(name)/F 4/Rect[346.131638 191.350701 413.23613 177.751092]/Subtype/Link/Type/Annot>> -endobj -2227 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2226 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2225 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2224 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2223 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2222 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2221 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2220 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2219 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2218 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2217 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2216 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2215 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2214 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2213 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2212 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2211 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2210 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2209 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2208 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2207 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2206 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2205 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2204 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2203 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2202 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2201 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2200 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2199 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2198 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2197 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2196 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2195 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2194 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2193 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2192 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2191 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2190 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2189 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1847 0 obj -<>stream -xœÅ]K“äÆq†ER²}èE“ -¬÷ãâpÈCíhIïî,÷!Y«ƒÃ¡Õ¥©ÊúúéÎB÷teUÕ  z¼#j¶T~ùåãC€Æîå^ÀÏWéW0r!zgöÿóÃÍ7ƒ·ã·ßãÆoà“w{gôà…ðÁƒ1"»ÿëŸnÞÝüåFîÓÏ_ÿ|óõËAìÿü¿7i¼ç!R*5X]Ç|¸¹‡0-ÃÀòÃe÷‡äìOŸßýÀ†°?þã]pòh˜ìöh÷‡_N݉V=ìÝBŸÇÏ}ÆãÐö+»‹B´7BÚ Â>šÁî¥ÕƒõQ -µ×à»sÒëäCÊV ¢Ô^Y!Nñ¯Ë @A F«¥ô'œ„s‚Svzá€+¸l„„Œ6ê£*ÆA /}¨¸¼pÀ\&™–Ê 1:œoiÁ©hƒÖ•á"¸i¢Pr_þë¦"Á^äÌ—œ_1è -®£Ü#/P”\_1è -®“ìküQû…ºÂxÝÂÁ~,Ðþ°ëòc‰Þð‡]»€à÷¢V*â:°b°1DëEµ€ø¯[@Ø\ e«†]·€¨Êî¯võ -f%O/T þÀ+òcñ‡]¹€²Kˆ?ìÚä„TˆÂ©…ÄxÝÂ~,( þ°ëòcIñ‡]½€\”’Úš¥ÄxåB~,) ö°+PöcQ±‡]»€¼ƒ‘Qy¹°€ø¯[@ØÄvÝB~,) þ°kPÐvÐVZ·tÄxÝÂ~,( þ°ëòcIñ‡]7úÑì¸ ~èªßþ0Ù’®[â1è:¦KÀ—}ù¯Ø·)Š´¶cÕ‰äÝíÿJ¢KœäÚxOÙÌ=Åǯóœ" rý¦xh/ñÚ ;å<˜½¦,æ^âã×yMR•…c•^S<´—xMr"•?–§+×LhnA£{TØkM›eŠD¦‡œXM®–9¡=‡jÔV?†½Ù'“Ñ/„m9 -uFÄÎ&¦eäF_a–Õþ2ýBêmk’ö!ù¼‘Eš×'E®W'ñå«œÇz^ú1+#7á±”EÐ2úØîÂÀÚƒ¬õìCµ'Ð5öš7_ÉÉsÕQÁVø¢=‡jŒÔV?¶½©:“¡:„m9 -uFÄÎ&¦eä†ê`–—U‡Ô0Q#WéÉòö,ËÈÓÚ-ûQ«\âÊe9ÇõœõcYFn(Âc)’ÖIÁÆ»$Í ¬=ÈZÏ{+éU÷š?@tzè\•Ò¡2g´çPÓÚêÇ¡7U a2T‰°-G¡ÎˆØÙÄ´ŒÜP%Ìò²*‘:&je+}YÞ¾‘ey^¿eOêÕK½°šCG²Vs©pÎ{¦Ê„™[gô¶2eLŽ2a¶å(Ô;›˜–‘[Ê„X2” ×1Q,YéËÊöm,ËÈÍÕ«z‰‡(Ÿå<×óÖi¹¥L§L°Ê5Çgáš]x{²µž}za΄ŽäÍ™‚©qÎ{¦Ê„™[gô¶2eLŽ2a¶å(Ô;›˜–‘[Ê„X2” ×1Q,YéËÊöm,ËÈÍ9«z‰‡(Ÿå<×óÖi¹¥L¥LVz˜K3¿GE»4°ö k=ûô’2å#YÊd¥«pF{Õ8¨­~ŒzS™&C™ÛrꌈMLËÈ eÂ,/+©c¢X¦Ò—åíY–‘ÛÊÄ©^â!Êg9Ïõ¼õcZFn(Âc)SzüÛÿnvi`íAÖzö©Ø§=ògTçT™Ð‘@tzè\™œÐÎhÏ¡§µÕ1Bo*Âd(a[ŽBÑ䋘–‘Ê„Y^V&RÇD±\¥/ËÛ7²,#Ïë·ìI½z‰‡(Ÿå<×óÖi¹¡L§LÚÊZmviàíÉÖzöé…9:’5grÚÕ8ç=SeÂ̈­ŽŒ3z[™2&G™0ÛrꌈMLËÈ-eB,Ê„ë˜(–®ôeeû6–eä有U½ÄC”ÏržëyëÇ´ŒÜR¦ŒÇS&üÆS³KoO¶Ö³O/)S>’§L.Ô8ç=SeÂÌ&_xëÆ8£·•)cr” ³-G¡Îhòݸ LËÈ-eB,Ê„ë˜(–«ôeeû6–eä¶2qª—xˆòYÎs=oý˜–‘[Ê”ñXÊä…d_õÔèÑÀÚs¶Õ³G/©R>’¥J^È"ßóöC%>j¥Ó3nS‹Îx %B K¼k<ˆ… ìJ˜ ýÉÌ.«ªU¢I¡Òyåí›Ø•qÛÊéPâß9¥¬Ö2Õ‹a ³¡7g,žÚx1Äãwý8Û³¥~=(öI=µô^ëÂU£óq@pz`AiÒó[e®yÏTm0«É÷µ»±ÍèmÍɘÕÁlËQ¨3š|µ{Ó2rKK†áú%Ê$‹}Xܺa u^·%/êU‹Æy,ç·ž¯~,ËÈ-Êx,% -°RÕÁ9{>‡vg`íAÖzöç…¹:’5÷ é¹­"g´çPÓÚêÇ¡7 a2‰°-G¡ÎˆØÙÄ´ŒÜP$Ìò²"‘:ÆÚ€kµÜßdûF–eä漈U½ÄC”ÏržëyëÇ´ŒÜP&„ÇS& ®ßMÑìÒÀÛ“­õìÓ Ê„Žä)“65ÎyÏT™0³É«Iº1ÎèmeʘeÂlËQ¨3š¼ÅdÓ2rK™K†2á:&Š¥*}YÙ¾e¹©L¬ê%¢|–ó\Ï[?¦eä–2e<ž2ÁJ6Íç÷šh—Þžl­gŸ^R¦|$O™œ¯qÎ{¦Ê„™[gô¶2eLŽ2a¶å(Ô;›˜–‘[Ê„X2” ×1Q,SéËÊöm,ËÈmeâT/ñ峜çzÞú1-#·”)ã±”) -1ø4»Ý¥µYëÙ§—”)ÉS&L…sÞ3}—f†ßœÕ“qFo¿c,cr” ³-G¡Î¿mkÓ2rëdˆåee"uLËWú²¼}#Ë2r[™8Õ‹Çù,繞·~LËÈ­·µe¼²2 R§?ûéoŒúë×7çô%’÷I;Da£2û×?Ü|ý/|¶—°€ÿÀQû×nþðÅNïÞì^í¾ßÝÁïw»÷ïwOvrw»{¹»ûò¯ŸeëÊæ·xÛe>ýú~jÄÈüj)†‘ÏaÃ=|¸Ûýa÷ŽZ¢dMz!¦^h©F¾Ïïþë·ßüºÄ÷û,¾¨Ó›ZƒQ¼x³û¼yVgT÷9 ½´ûÝSøÛàô“qü7¯çéé—JïÉ€ ãÄš §ìø4â¦p~7FñÉîãÝG»Oá¿ŸV=Ȇámz•¤+ØEðï?ìþaÌá›c)¼7†/•øܳ»"Î@´cpq™+$õü97XaBЧ䥀ý|EÀ@¬aL fbór´þ||sòöÕ1r«e•œJ¾ ¥zIô?^H?=º¥óF-£_OL2Ú§¬óþ Ч[pôÅî³±¢žÂO -Û[øY/)‡`¼Oñ"h ãõÉšþŠb°Ú¨/.ö©\¾%éùÊfÒaˆÑ(1ðæNRB p· Í´“>YßIÔæåÐðô)øy»² `â"á¼l,¹Ö@Ÿ.-ˆ †s<³Vüb,Š»Ñ7»ßçß4ÎÃJ 8CÐYkÍ9 -Ì8-C s‹+zh©æ˜ôîe¨b%ÁŸ¢¦ÇH½}Hçë_Áïߧum%Òé2ê‘øçÅã|DšW-D½F4ØÔÏsµoG7ïVNhÒúÅHó]jzE¥,•k £”wBò±OeâÀoGYùÝ©ÉžÍÏ?õ Z?H’¢té2bnÅ4pK‹q±!päg®·c?½gîÆPb§à¤½¢Ï &ÅfA,~z⾸© ,Рftäc=)IÓþÔpÕx;€Qo/µŸ­I+:År±>:‘*¯Æ´ðƒ+»c$žA×ÜÂÿ×ו³œU×lÐçãBëéJe²fPVG7¥±°ÁÆl,U&­†h„‰Š}ž’ké;8…­\dÈxÜ4#›ç…Z¥5¿ðÒ¡yá'+ú-µÙ U«f-¬& Nkö¦N­Ë³!¬jê:õ°ÂND£§Þ=¼ÃÂBGW|øvV`eàèó:âÅi½ó¶ž•é_üÛy¡ôïõÌLvÓbxÅòañ é»™£4¤6JkPÞ‚§Ÿ51Æýw O÷ã*Uú»j:fÃ{]I_ÆWJ§¥.Åx„+#ÖAfäxU†Ý^¢Ôãgä``â\—Ù&5÷r‚f›lìv{=)³Â¿OoÇbþ#ü>OFë%=54FFÒAí¾Ùýç)uÅ™™ë¥8ÔðÂdýÓš+XYqØØÍdÁ´NFÙ1~ùp5§šœÙ£ðçË@õD̆öJ5üWŽr"ØØíDhø¤…9Ϯω¨ÜáÁ™ŽåLfƒzßA¡{û„}å{'ëbPÏ™MÿµVdZ¿ñÆ µùÿrã„íÂnœ,¥šßÖSK{Wì2 æaN‹¦lìN7`%c„ÖAmg½ø²“öƒ1 -·ˆ5ºäV/ˆóO‚‘§‚8]™[Q:<ÕfbtA€Ö^—³’c…²žýQãtçˆÁE Nw/ÇçÞ4&†³atbø `ùj<‰¥«4õyÈÌL¯y5¼âRÖÏ×ÏCØØÍyˆƒ.”Næ;/O†|[OÊtȲèl¸“ñnT’p¾¹LY—šhk­Wn³baµx:â¡,ŒR&XmùðíìD83(¯üÃÙåþÂD³ÅGŽp6¦ºµ1¼0þí±8F|h >~3^i8;¤g˜ ˜ àÌÍgƒŽ7¿~—Úpœt­¼L”MNV4Ãò›~° ùاi…ï«?ˆôÚG0`]¢Ý"|ÞœÜ §C§ôùä¡^7Ü¢69#¼±MçȧÀŒ“£Õe¡„Òlg½ô†]šÚ¤W”ÁÔfë–ŒG™¤Pžt»ŸˆL} -:z¼ü5U©úäsf ×–^‘–ÅWÙóä“ÝLKPéÖ–ÔçµÒ=xø®qv àœ]gƒäemÒûó‚4S÷㬠- 0Þ8/ùØíX7x˜¸žF§4úa6ä¡Žë}0Ø«¨áGJéØØí4„8Þ:;/‰îaîwZ×1Äê…é ~œQÓûÀû”¹?ýü?b4Yûú‡·{8 ™8þƒvTïÔɬݽÿêùÉî_v?ƒŸO0Èe€ôÏÈ３¾‚è=|yã6Eq’ƒt)¡`®uIìnÇEÈx½÷ãÝ?Ÿ.Ãѧ—pzmeÃ’ñý8“½Ÿ¶~ÿ·ñšë«÷þ>^u~zºÒÆ¥é)2o5üö|÷ãéø€»‡~K¤ShŸ/ ­·ƒ -ÑÙ‹¬õéY¢'©V¦åxó[œL -endstream -endobj -1748 0 obj -<>/Font<>>> -endobj -1056 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[361.218797 741.290154 420.233689 727.690545]/Subtype/Link/Type/Annot>> -endobj -1057 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[484.574021 741.290154 519.220505 727.690545]/Subtype/Link/Type/Annot>> -endobj -1058 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[312.014695 727.690545 333.783738 714.090936]/Subtype/Link/Type/Annot>> -endobj -1059 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[393.495164 727.690545 452.510056 714.090936]/Subtype/Link/Type/Annot>> -endobj -1060 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[383.885789 714.090936 442.900681 700.491326]/Subtype/Link/Type/Annot>> -endobj -1061 0 obj -<>/BS<>/Dest(links)/F 4/Rect[479.245652 714.090936 513.892136 700.491326]/Subtype/Link/Type/Annot>> -endobj -1062 0 obj -<>/BS<>/Dest(links)/F 4/Rect[312.014695 700.491326 333.783738 686.891717]/Subtype/Link/Type/Annot>> -endobj -1063 0 obj -<>/BS<>/Dest(media)/F 4/Rect[378.097459 700.491326 437.112351 686.891717]/Subtype/Link/Type/Annot>> -endobj -1064 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[315.473923 686.891717 374.488816 673.292108]/Subtype/Link/Type/Annot>> -endobj -1065 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[450.239548 686.891717 509.254441 673.292108]/Subtype/Link/Type/Annot>> -endobj -1066 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[348.030808 673.292108 407.045701 659.692498]/Subtype/Link/Type/Annot>> -endobj -1067 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[315.473923 659.692498 374.488816 646.092889]/Subtype/Link/Type/Annot>> -endobj -1068 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[465.637986 659.692498 487.407029 646.092889]/Subtype/Link/Type/Annot>> -endobj -1069 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[312.014695 646.092889 333.783738 632.493279]/Subtype/Link/Type/Annot>> -endobj -1070 0 obj -<>/BS<>/Dest(language)/F 4/Rect[340.690476 621.743279 399.705369 608.14367]/Subtype/Link/Type/Annot>> -endobj -1071 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[480.50615 621.743279 515.152634 608.14367]/Subtype/Link/Type/Annot>> -endobj -1072 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[312.014695 608.14367 333.783738 594.544061]/Subtype/Link/Type/Annot>> -endobj -1073 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[379.207078 583.794061 438.22197 570.194451]/Subtype/Link/Type/Annot>> -endobj -1074 0 obj -<>/BS<>/Dest(links)/F 4/Rect[340.690476 559.444451 399.705369 545.844842]/Subtype/Link/Type/Annot>> -endobj -1075 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[363.167771 535.094842 422.182664 521.495233]/Subtype/Link/Type/Annot>> -endobj -1076 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[315.473923 521.495233 374.488816 507.895623]/Subtype/Link/Type/Annot>> -endobj -1077 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[340.690476 497.145623 399.705369 483.546014]/Subtype/Link/Type/Annot>> -endobj -1078 0 obj -<>/BS<>/Dest(media)/F 4/Rect[340.690476 472.796014 399.705369 459.196404]/Subtype/Link/Type/Annot>> -endobj -1079 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[361.218797 448.446404 420.233689 434.846795]/Subtype/Link/Type/Annot>> -endobj -1080 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[484.574021 448.446404 519.220505 434.846795]/Subtype/Link/Type/Annot>> -endobj -1081 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[312.014695 434.846795 333.783738 421.247186]/Subtype/Link/Type/Annot>> -endobj -1082 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[393.495164 434.846795 452.510056 421.247186]/Subtype/Link/Type/Annot>> -endobj -1083 0 obj -<>/BS<>/Dest(links)/F 4/Rect[315.473923 421.247186 374.488816 407.647576]/Subtype/Link/Type/Annot>> -endobj -1084 0 obj -<>/BS<>/Dest(media)/F 4/Rect[418.802537 421.247186 477.817429 407.647576]/Subtype/Link/Type/Annot>> -endobj -1085 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[329.8228 407.647576 388.837693 394.047967]/Subtype/Link/Type/Annot>> -endobj -1086 0 obj -<>/BS<>/Dest(members)/F 4/Rect[340.690476 383.297967 399.705369 369.698358]/Subtype/Link/Type/Annot>> -endobj -1087 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[371.666795 358.948358 430.681687 345.348748]/Subtype/Link/Type/Annot>> -endobj -1088 0 obj -<>/BS<>/Dest(name)/F 4/Rect[340.690476 334.598748 407.794968 320.999139]/Subtype/Link/Type/Annot>> -endobj -1089 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[351.618943 310.249139 410.633836 296.649529]/Subtype/Link/Type/Annot>> -endobj -1090 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[473.727586 310.249139 508.37407 296.649529]/Subtype/Link/Type/Annot>> -endobj -1091 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[312.014695 296.649529 333.783738 283.04992]/Subtype/Link/Type/Annot>> -endobj -1092 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[410.863816 296.649529 469.878709 283.04992]/Subtype/Link/Type/Annot>> -endobj -1093 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[315.473923 283.04992 374.488816 269.450311]/Subtype/Link/Type/Annot>> -endobj -1094 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[410.403123 283.04992 469.418015 269.450311]/Subtype/Link/Type/Annot>> -endobj -1095 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[340.690476 258.700311 399.705369 245.100701]/Subtype/Link/Type/Annot>> -endobj -1096 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[340.341111 234.350701 399.356004 220.751092]/Subtype/Link/Type/Annot>> -endobj -1097 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[340.690476 210.001092 399.705369 196.401483]/Subtype/Link/Type/Annot>> -endobj -1098 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[348.030808 185.651483 407.045701 172.051873]/Subtype/Link/Type/Annot>> -endobj -2270 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2269 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2268 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2267 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2266 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2265 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2264 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2263 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2262 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2261 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2260 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2259 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2258 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2257 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2256 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2255 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2254 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2253 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2252 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2251 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2250 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2249 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2248 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2247 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2246 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2245 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2244 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2243 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2242 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2241 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2240 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2239 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2238 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2237 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2236 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2235 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2234 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2233 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2232 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2231 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2230 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2229 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2228 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1846 0 obj -<>stream -xœÅ]]o·ÀoêCQ4‰]´ûº±‘LH?_Š"UlÙ5dK¶£4QPE—u¤ýýé½ä®–—3$÷Î ×bÈï¹ç~’³»Ö†o|}á¿YÉ{kÑró÷g?õF…Á»ïáâOgð“Ñ-‡Þ0f¬ÙX£z)™“jóó?ÏnÎþuÆ7þëçϾü;ïÙæÇŸùùƦp.D¯¸Ó6Ìywv_`šÛ»;å}€R›ír›ŒûŸoXo7»ÿ1Þ'w†“aƒ†ß=»ã”¸n¡Ÿ·»Ÿ9úÏC×Oì.þ²¶Œd\Yf7NöjÃÕÐ+ã8›|ךK©4¿KÙ‚)½ãƒŠq “ýëüP‚N œ›½ZöLk ÁÉ;=s \–L÷Œ;冹~`†y愸œdš Ý;ªg–}bïÀUé˜à›ü_W -öcF¹Ð§À}TÈ9¥CŸv÷Ó:p°l8+;·€ÈO\@È9DžvâŠ~Ì* ò´S0JyPRÌ, úÄÓöcFѧ¶€s -ˆ>íÔ4(Û3aõì%Œ>ñ´„ý˜Q@ôi§- äÇœ¢O;uI¸Åiæ3³€èO[@ØDŸvÚB~Ì) ú´SòN Íf/aô‰§- ìÇŒ¢O;m!?æ}ÚÉ Èºž9>ÿFŸxâB~Ì) ò´PôcV‘§6úNnÞŸYÓ[ôg³]ñ ðôHJûÿÀ—Mþ¯Ø·1 -W¶]Õ1ïÝÁÑÓªä1xŸ²™zŠï_æyŠ€Ê-øâ¡ÑÄkÃTo…6`:x²˜z‰ï_æuŠà«Ìîª,xâ¡ÑÄë$'\˜]yê|ÍØê4»Eõ°Í0¤Í2Æ"ã[ö¬FsòœÐȶ‡mj«C„^í„Iè—„m> -eF‰ULóÈ•¾Â,‹ý%ïú%©St=ÔdÚ‡ÉÏ+Y¥HÓúL‘ËÕ™x„ò•Ïc9/í˜å‘+Š‚ðhÊ¢\ï!œ¨w¡¥Dk-ûðˆâ ;iʇØç82VÌ,±ÕqD¯+OĤ(f›B™QbgÓÏå¼µcšG®(£)“ ÚîõÝj—ZÚH´Ö²OÙFñ^9ë”aeBwÑñ­e2²Ä9ŽŒ• 3Kl5dÑëÊ1)Ê„Ùæ£Pf”ØYÅ4\S&Ä’ L¸ŽÅ -}Y¸¾ŽeyZ¿yOÊÕ›xˆò™Ïs9oí˜æ‘kÊñHÊ40Ó;á´œlÒ.µ¤d­eŸÙ3¡;I{¦•çŒF¶Å8mS[í#ôª2!L‚2%lóQ(3Jì¬bšG®(fy\™’:NKú2}%Ë=²gBw’öLƒ2%Îqd¬L˜ÙèmÍGôº2ELŠ2a¶ù(”Þü¶‚i¹¦Lˆ%A™p'Š¥ }Y¸¾Že¹ºg"Uoâ!Êg>Ïå¼µcšG®)SÄ£)“c½sÒL_§J»ÔÒF¢µ–}zdÏ„î¤í™¬+qŽ#ceÂÌ°­–Œ#z]™"&E™0Û|ÊŒ°uLóÈ5eB, Ê„ë8Q,SèËÂõu,óÈÕ=©zñý8Ÿù<—óÖŽi¹¦L¤LRøP„wñV»Ô’Fµ–}zL™â$eòï\ÎsF#Ûbœ¶©­vŒzU™&A™¶ù(”%vV1Í#W” ³<®LIc}ÀµšïïäúJ–yäº2Qª7ñå3ŸçrÞÚ1Í#W” áÑ”I)ØK6}*íRK‰ÖZöéeBwÒ” Ú¹À9ŽŒ• 3Kl5dÑëÊ1)Ê„Ùæ£Pf”ØYÅ4\S&Ä’ L¸ŽÅ…¾,\_Ç2\U&Rõ&¢|æó\Î[;¦yäš2E<’2ù®¨ÝWª]jI#ÈZË>=òœ ÝIzΤ =yÎhd[ŒÓ6µÕŽ1B¯*Â$(SÂ6…2£ÑGœV0Í#W” ³<®LI'Š% }™¿¾’e¹úœ‰T½‰‡(Ÿù<—óÖŽi¹¢L¦Lƒ…½¤àvr²I»ÔÒF¢µ–}zdÏ„î$í™Ô`JœãÈX™0³ÄVCƽ®L“¢L˜m> -eF‰ULóÈ5eB, Ê„ë8Q,UèËÂõu,óÈÕ=©zQ>óy.ç­ÓÏå¼µcšG®(Â#)“±¼—P -BÕ»Ô’Fµ–}Ê 6Y?8e‡a¢Kè> ™Þ8U%cY/Ùc´Mmµc‹Ð«ª„0 ª”°ÍG¡Ì(±³Ši¹¢J˜åqUJj8Q+^èÉüõ•,óÈãÚÍûQªÜÄ;”Ë|ŽË9kÇ2\Q$„—W¤žþ¿Íø;FýêÍÙáß±vÉ'Ó¸êSNÈÍ›÷g_þùÕÕå«ç>ôÁÆwmÞ¼;ûþ³nèÞv×Ýëî¾ßt··Ý½ŽwçÝ«îâÑožGëBÅOn&¶ó6ŒÿözlDòøqA‚‘‡pá -~¸è¾ïnRK)Yéÿa(Á ƒp¾—ß=ûú«ß'`ó žv/Àöy°þM™êØ2XÐ0çm˜ý¼Ì.3ïÓG‚}¸Oa6`Â×½îÁÂ×o¦Évþ›pÆù|ã4K£z6X@˜Å[æðüEˆé½îãîWÝøó‘ÿSô"–vAö(Î,“³\¸}WË!4¬àz.Ÿ¨oCúßújðµð´V”ãù¤4' G Äÿ!ATüjv„ŸÀä Å!;>@»öyZLÊdšíLˆðÃîûÉOÄ¥hbâ!Lôí»,1°7jpzLifb|R>™›”AôN2é· TìÛwÝ/ƒ"_‡`-⬬è¹`FVqþíÎoË4¨ÃεB”ª7°jÃ_wåðtWGåOBýxjçÝËCþ­l@°PAh‘”ï‹äá&¬•¯Ëå;†ÿâyÓÿºo‚3a±[’Yç51Xë »S¤¹-2¾®8“\Ò±ë¹uº´ƒhÌmP‹ÛÛrvÆs,pú¸=‡ï MÝç~ )§g<=_Ë´Æ©^)ØÇê̇È“BH«E‡¯¦gðÓ ô¡ `9îžA„¾…HÝ×_ûè…”ù¸Á6«˜·‰1Êr=™Ô~¹N!>ürMÆ?¬ a¯¾Œ·?hIÎ!¸ y—3%ý/i°ò°»÷áùxaxü{„,T/›ÄîâJ6®—ƒTxwîÏo÷Ü®C%ÖÎ9 Ÿƒ?‚d¤v@ÛÿTSÆL«ýÍÄöÌbþÏØò-Îøj² @aý…ÓñD_@ÁŸƒ«/+ù™LÚ%çö³ÃÜ©t”Ó4±Ö*G©á™ úd‰ÒÄ‘±ëÙ‘–mÛógûcÁ·»¸–34žˆÈÔïÃ1ýe0vUKÍØÌÐý%Ähé¢í«IÎ̘ڂäÌ> HÑa4ãtìzrŒáØaóù,¬Õ/ËIO ¬Ê“IíWåâïÊdüÆ«ò2ÞåL9ÿ‹K`ߎ–›F óÄôÒšUþŸ^¸;ìÈŸv”¯‚x{’OÂîü1¾ -»Ðò>sbŽRÑ™I¯ƒ]væ‘_®á·´ªè•ULŒafVµÿsö©€÷Âp%5»ž,åü¯Râ‡jzaai¼Í_~44™š(~95ãiíÅ&…øðbCÆo,6Ëx—3e,D”¹ÖG€ÔîÒÊÕœõÒ™äýe(¥ ¿eÿnÿAyÿ’3°l “³Ôjƒ9±½àÙÊCÀøzº¤ÿ…7C|PÂ\–—ÉŠîO&MÅÅ¿ ñ -VƒÝÓ¿:±ìÉ´ÐvÂ2](7ss¤½Î´GêˆÜ”C§yÏœfÂú9gŠôaŸs’±÷Òü0ìSv»”óñ.GËBX+ù>zKº^°^|dnfˆî/‘gÿ+`¸•‚Ó±Qˆ+o#¨]ùXÅù£›) ;(­˜Tãô-n!gàÌǵ’‡EàíîUtÿ$©‹ÓÂ}gx…Òà¦a-x24ãz§ƒ Ïã2}¢V !ìma½‘ñqþº>JÍ}€çg¨ÈØû(}ֶ˥}dzcüËÄë9Ï~‰0üËýPžz6g^áyÑ— bzhTa\›‚HÌ-Î\‘ÁAÅ íX´ðoí¶ -Ë¢PÎìÚŒfÌñÌAavŃBj÷xÀ†ýNå:¼/èexåðü´¬£”rôŽìGiÃ2{eœ%­^ÿÂöß²”³¥ý)Q8&ÛtTbnÁ3+:ŠŠ Á¹wsµÿú ¾X0Zz?ž#µ= ŸâW „ØVÝí#hÐ{Ýï`'ÿ J' `ðþm4? -ôÄïîÝtç>Žó´†%FGb‡×ìC’~ îÏÃÎ8ÁšAñ,†/Ê¿çê‹°æÝþ',×·ïþ»{îÔ]ÏŒ¥b=‡ãìæàçw;zÿˆ ´ÍÝ3Ê'ÝåÌÐÕ ë´:ÊÚ¿5áyxÎó éîë‘ùWÍ -endstream -endobj -1746 0 obj -<>/Font<>>> -endobj -1022 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 741.290154 423.383103 727.690545]/Subtype/Link/Type/Annot>> -endobj -1023 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 716.940545 423.383103 703.340936]/Subtype/Link/Type/Annot>> -endobj -1024 0 obj -<>/BS<>/Dest(created)/F 4/Rect[340.690476 692.590936 399.705369 678.991326]/Subtype/Link/Type/Annot>> -endobj -1025 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[436.590134 692.590936 495.605027 678.991326]/Subtype/Link/Type/Annot>> -endobj -1026 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[377.567918 668.241326 436.58281 654.641717]/Subtype/Link/Type/Annot>> -endobj -1027 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[371.666795 630.292108 430.681687 616.692498]/Subtype/Link/Type/Annot>> -endobj -1028 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 605.942498 423.383103 592.342889]/Subtype/Link/Type/Annot>> -endobj -1029 0 obj -<>/BS<>/Dest(name)/F 4/Rect[466.058396 605.942498 500.70488 592.342889]/Subtype/Link/Type/Annot>> -endobj -1030 0 obj -<>/BS<>/Dest(name)/F 4/Rect[312.014695 592.342889 341.873338 578.743279]/Subtype/Link/Type/Annot>> -endobj -1031 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[340.690476 567.993279 399.705369 554.39367]/Subtype/Link/Type/Annot>> -endobj -1032 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[340.690476 543.64367 399.705369 530.044061]/Subtype/Link/Type/Annot>> -endobj -1033 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[348.030808 519.294061 407.045701 505.694451]/Subtype/Link/Type/Annot>> -endobj -1034 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 494.944451 423.383103 481.344842]/Subtype/Link/Type/Annot>> -endobj -1035 0 obj -<>/BS<>/Dest(name)/F 4/Rect[466.058396 494.944451 500.70488 481.344842]/Subtype/Link/Type/Annot>> -endobj -1036 0 obj -<>/BS<>/Dest(name)/F 4/Rect[312.014695 481.344842 341.873338 467.745233]/Subtype/Link/Type/Annot>> -endobj -1037 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[369.438767 456.995233 428.45366 443.395623]/Subtype/Link/Type/Annot>> -endobj -1038 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 432.645623 423.383103 419.046014]/Subtype/Link/Type/Annot>> -endobj -1039 0 obj -<>/BS<>/Dest(name)/F 4/Rect[466.058396 432.645623 500.70488 419.046014]/Subtype/Link/Type/Annot>> -endobj -1040 0 obj -<>/BS<>/Dest(name)/F 4/Rect[312.014695 419.046014 341.873338 405.446404]/Subtype/Link/Type/Annot>> -endobj -1041 0 obj -<>/BS<>/Dest(keywords)/F 4/Rect[340.690476 394.696404 399.705369 381.096795]/Subtype/Link/Type/Annot>> -endobj -1042 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[411.313523 370.346795 478.418015 356.747186]/Subtype/Link/Type/Annot>> -endobj -1043 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[377.567918 356.747186 436.58281 343.147576]/Subtype/Link/Type/Annot>> -endobj -1044 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[315.473923 343.147576 374.488816 329.547967]/Subtype/Link/Type/Annot>> -endobj -1045 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[411.722947 343.147576 470.737839 329.547967]/Subtype/Link/Type/Annot>> -endobj -1046 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[367.796677 329.547967 426.81157 315.948358]/Subtype/Link/Type/Annot>> -endobj -1047 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[315.473923 315.948358 374.488816 302.348748]/Subtype/Link/Type/Annot>> -endobj -1048 0 obj -<>/BS<>/Dest(links)/F 4/Rect[410.833787 315.948358 469.848679 302.348748]/Subtype/Link/Type/Annot>> -endobj -1049 0 obj -<>/BS<>/Dest(media)/F 4/Rect[315.473923 302.348748 374.488816 288.749139]/Subtype/Link/Type/Annot>> -endobj -1050 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[472.199021 302.348748 506.845505 288.749139]/Subtype/Link/Type/Annot>> -endobj -1051 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[312.014695 288.749139 341.873338 275.149529]/Subtype/Link/Type/Annot>> -endobj -1052 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[417.62407 288.749139 476.638963 275.149529]/Subtype/Link/Type/Annot>> -endobj -1053 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[315.473923 275.149529 374.488816 261.54992]/Subtype/Link/Type/Annot>> -endobj -2302 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2301 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2300 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2299 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2298 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2297 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2296 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2295 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2294 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2293 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2292 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2291 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2290 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2289 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2288 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2287 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2286 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2285 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2284 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2283 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2282 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2281 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2280 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2279 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2278 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2277 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2276 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2275 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2274 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2273 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2272 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2271 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1845 0 obj -<>stream -xœ½]K·n`o›C Ķ8‡â8–aQ|?.Fଽ+YÐc¥Õ:ñú‘/ëvòòÓSä<ºØCrHvÏx,¯fzX_}UůùêõŠ­(¼ûV2b­3Z®þùóù/çĨpqû3|øË9¼3z¥¥ †RcÍÊE¤¤NªÕ¯ÿ:¿=ÿ÷9[ùׯ??ù#tõÓÎ}{ãvMãœ(æ´ mÞŸ¿†˜fvû @ù9@©Õýò>ºîßß~`Ä®Öÿb¼N® G— ºüþ‹©;Nñíõàz¿~ÏÐ{Ü}~dwñËZ"Œ¤LYjWNµbJe£|%Àw­™”J³mÊ:šÇ„áŠ2 “ük{p(A§cfã–„j-!8i§ÁeI5¡Ì)'Öp爠†›q¹±Á\Ž2͸&΃ê(ß’Ã…S6S µÍˆ7¥£œ­ÒU$Ø ”ù„óŽà:Ê=òW@ÂõŽFGp=ʾ¢”0¥y«¬T·;nÙ 7¦ºÕq gt£Ejª[½t´"ÔZ%ykíT7¦Íw¯ú†G. äGKU7;r~4Pu³ãFßI˜ZC,š,Áä.þÄO÷p4ýÓþðe•þ+ömŠÂ¤m]uÔ{7ÅD×343Œ¦à}ÌfßSüý>ÏcTnÁï]¼6T˵ÓÁë˜Å¾—øû}^ǾÊìºÊ‚×1ºyå„q³.O®[üµ^¢zèJˆ¸³LñÈô+V“éSšºrŸÃ}lk9†½ØOfE‰Ø¦£gÙ™Å4\èW˜e¶Ém‰ê}j2î‡Ñû™¬b¤ýúŒ‘óÕy„ò•Îc>/Ë1K#áU)‹Ô–0GÝ»ŽÐV]AÖ–ì‡Q¨Èqi"çÏlôÅ}Õ‘Údø¢+÷ÙÝǶ–c‹Ð‹ªƒ0+T'b›ŽBžQdgÓ4rAu0ËêÕp¤F:Ó'ÓŸÏd™FžÖnÚ\åFÞ¡\¦sœÏÙr,ÓÈEBxUŠäW˜tXa*vP[ue4¶d=0B߬ IKšñîÂ}.F÷Ó•Å¥Øî ‹r4"Ö¨♤Ÿ%3Y€ì瘄-âwX‡påFòd21ýù<†ià☨ª^ñ÷Q“éÍ&l1–IØ‚huA€ ¼p{s“¨KÚš ÈÖ‚½òí¾X¥@Jð _teªA˜Wdk9¾½,C#f…ElÓQÈ3ŠìÌbšF.‰bY¡F¸†±* BMv긛Îã˜Ä-‹QEåFþ¡\¦sœÏÙr<ÓÈ%AñêI+¢Öû&Åj뮌֖ì£D }³N• È3œÇ+SUÂÌ&Ûf‹1Ñ˪4bÖ¨f›ŽBžÑd‡mÓ4rI•Ë -UÂu©ÏôËÌçóX¦‘‹ÂTU½‘‡(Ÿé<çó¶Ó4rI™F¼:er–P³<[îÊhmÉ~zH™ÆoÖ)“39Îã•©2af‘­èee1k” ³MG!Ï(²3‹i¹¤Lˆe…2á:ŽKfúeæóy,ÓÈeeª©ÞÈC”Ïtžóy[Ži¹¤L#^•2ù£j}T ØKmÕdmÉ~zH™ÆoV)“æ.Ã]¹ÏÆ)êÇK2FèEeB˜Ê±MG!Ïhr¨dÓ4rA™0ËÃÊÕq¤X&Ó/ÓŸÏd™F.+SMõbq>ÓyÎçm9¦iä‚2!¼:eÒœ8 ¸®ÜKmÝ•ÑÚ’ýô€2¡oÖ)“f9Îã•©2af‘­èee1k” ³MG!Ï(²3‹i¹¤Lˆe…2á:ÆŸãZM÷ïøóy,ÓÈEeªªÞÈC”Ïtžóy[Ži¹¤L#^29Eäút\±—Úº+£µ%ûé!e¿Y§LNæ8W¦Ê„™E¶d<¢—•iĬQ&Ì6…<£ÈÎ,¦iä’2!–Ê„ë8R,–é—™Ïç±L#—•©¦z#Q>ÓyÎçm9¦iä’2xUÊd¸!Ž9nX¹—Úª+ÈÚ’ýô2߬R&ãŸÓJrFWî³qºm-Ç¡• aV(SÄ6…<£ÈÎ,¦iä‚2a–‡•)ªãH±d¦_¦?ŸÉ2\V¦šêÉ€YE¶–c‹ÐËO8Œ˜5O:`¶é(äEvf1M#—žˆ@,«RTÑZéLŸL>“eyZ»i?r•y‡r™Îq>g˱L#—žñÒŠD˜ðÿ¬¦?1ê×oÏw¿¥ÃE'¨™"Ž*ÇåêíÏçOþúêõ‹WÏVL`CÀ·Voߟÿðù †›ázx3\ÁÏÛáîn8Øp1¼®ýøöÙh«ñùÈvÚ†ñ?ÞLH6j¯0ò|ðÞ\ ? ·±¥˜¬ôâqj(ÜÈßWúÍ×)¾\ßs 󛚃fšÝ ÏÁgyJ‰vŸ>âôóá^7@ã¼Î†ß ß¼ÝÏ°ó?¸Ÿ&@’qn¥Q„ - Md5`~ ž?<> ßüŸ¬caÂŽ£ÖŸßnpáîýðÛ|Ä´&ŠJkE6\¾^Aº<«P ]Tà²dž€vFïÃÆèiw+GµŒ°¿:+ …×6tàãkðõo¡½ƒ>|³îE=Ñ¢0äÂZÇô©1^ŸôTšå„1*™¬Çö±Èuý|N|NÜô±×RÁ¡¾‘ͧœ¸í€l­ó¶ÒGQ‚A:¡R:+'6Gé³P—R3í¨t¼7U]dÀ6 ‚áÎ/ƒ‚\zöùüp -÷% ŽD¼'J`F fݷب‡ò'.]rÖ¿‹ÕÍúy nÐ¥®úµÄ*¨‚[ëìHü¾#Z b§J6G"_#ÂÁÝXà¦@þ nÞl¾ž¡»´†sáµ&ÆèTëJù]˜41[½©—»Ïá}¼Ü¿çƒ¨ aÚúßS¶H/‹Ì5Æ룙]¬{¯',HÂ}êþ{†¾WÃÓλõûñÜøSÇscð°µsAß6ÂA¬4maÈ× uá»FmoO°ûÅpÖQ~Ô§´ÔÇf;úSëýRB˜äZø1T5ú¦B(8q .\ôj®1š²ù¼›kæ ŽÉ°ÐÂ:_£B*<­ÚLQ;UV3€[«Ø¾íÆudÜŠ,SÔ4¹°©Ž-û½¹Q6†0¯%J±›hÍÛØ\gÌšoPŒÂ@B*¸“WãïöÜx.Ì(åüÍÙ5áçø7O¿9ƒÔ7ľة€¡ÿµ6l7}dàámwR0Ȳay"6Ü1[lÖYÿk~ŒÔ†ÕcoÊ‚ðËpw¹ -îÜÀäÙJg´„N ¤UBu"Ÿ0iˆ…fѼñ£ŽRBóÆØfM¼n`¼r–~„ŸcòºVd|=~ªö#×ZkFó°ãG*}1°!½ÕŠ8­ìr³È=‹'â¶Ào"%Â*Ãmż„)ÒE¿¾(G ×ʯžÍCÏ‚”Ö–8Å7 B­¡È Ìö¨³z7›¥»ëp£z9| ?ŸÂ»Î5¿ySóHAЮ‡O»û˜„r¦¤nrd±nÓC-Õai¦#\xêå6ÌšÞäÓ§4ÑÜÙ…&—±¹ÜÞqw«ÅFAº û -Ýc`N!”rë°3Ù<VÛÉÖg…}xiÜn5ånSù•`´ß¾×¬f³}¯Qiº3;Ð… ó6ev‚Õe?âUBrÉë±ïÞr£¸_6àÌÈTnü³ùÙkú%4ü*å¿d³µgbÞ¤‚á¥NOiê(Dajÿ MªñËÉñGÖ¸6/ûùÏËyJXÙ¤*}6 ¯„©ÅR6µ}Š#‚'æu |9iVÃ=UJ­wÛ<ÈçhÚhrb!Ÿ‘iÃ¥ìbç]°«Æ.&B3˜žkªw•úm¼×_è2{M×ýerX ÐQö ,ÕKbÃ'82€ºH5v9-þÿoÅõ¸‘7M‹Þ~’OÏÔDÍÈ`¯Ñ‚ QÒ)¢”ñŸÀœBà ‡ä|½¼\ _Α0äŽÊ]Ž¦Çí -gÚ¸æôÞW¥ÎtØàÜÓ“1ÄéNVãÓf fBùCXiÛkœÝN,&+kfîžlløT›‹ã†l5~9EÞAÔwlßâÃÌ¥ôL"̓„ü Ì\õÄBz¦f–ïK1ÄéûR5~ú`ïê2*‡4ëNþùŒi 5`ã¾®ÃãXlóÔ'ÿ%~œ½ÇíÇþ¨ƒ2±Úw¨Æìæ˧ÌB¤]p›oÏâ Nþ¡õ¯øŠÃ½'Ú4 ²Œ†+sÃѳôâµq 9Iä·w«ÏRvî¶ú=¨'BÂœVM€NpP9Ói7ÌzìÝ1ÈÍÁ¾ÞÝi·GûhçÓÅ t¼Ñ×sIqlóøG©$Œ;Ä¡y©#€þË´„il+ëÉI­|†Öé_j‹/6w‚]Hs«±tj‰bŒ€õÓÊYè9Ž¤ý¦”OsÚ-µÊÍã§ð–=¸ƒp(›)Ö åø53ª×•Ó¿ÔÙ -Ó4F…ëçžÏL-ŒBO.p¼"¶yúãÕøG8^ÑÄ=Ÿ'ˆµèAÃ#1P8nžy Û±þÙ,D\„iÂzüb÷À?x¡xŽjù½´ü}ËÁPrôø_ìþ»®§ #Ú ¯±ù‚Ûl¢Ô|k§”sA—¯Æ: Ê{ÙCM Fœd~$ÑDí㮕êÿêF²ÕXFR¯7¯_àEƒÍ܃úFÁ¨™HsTaâúâ»j¸{“ñ³á@åãQë„vj×hvè1àö1û _ˆmHþaN¹‘‡‘èpD"¬&|8üþ>/Font<>>> -endobj -961 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 741.290154 423.383103 727.690545]/Subtype/Link/Type/Annot>> -endobj -962 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[411.313523 727.690545 478.418015 714.090936]/Subtype/Link/Type/Annot>> -endobj -963 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[377.567918 714.090936 436.58281 700.491326]/Subtype/Link/Type/Annot>> -endobj -964 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[484.745408 714.090936 519.391892 700.491326]/Subtype/Link/Type/Annot>> -endobj -965 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[312.014695 700.491326 333.783738 686.891717]/Subtype/Link/Type/Annot>> -endobj -966 0 obj -<>/BS<>/Dest(cardtype)/F 4/Rect[371.017869 700.491326 430.032761 686.891717]/Subtype/Link/Type/Annot>> -endobj -967 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[315.473923 686.891717 374.488816 673.292108]/Subtype/Link/Type/Annot>> -endobj -968 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[438.829148 686.891717 497.844041 673.292108]/Subtype/Link/Type/Annot>> -endobj -969 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[363.167771 673.292108 422.182664 659.692498]/Subtype/Link/Type/Annot>> -endobj -970 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[315.473923 659.692498 374.488816 646.092889]/Subtype/Link/Type/Annot>> -endobj -971 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[455.289597 659.692498 514.30449 646.092889]/Subtype/Link/Type/Annot>> -endobj -972 0 obj -<>/BS<>/Dest(links)/F 4/Rect[336.342088 646.092889 395.35698 632.493279]/Subtype/Link/Type/Annot>> -endobj -973 0 obj -<>/BS<>/Dest(media)/F 4/Rect[439.670701 646.092889 498.685593 632.493279]/Subtype/Link/Type/Annot>> -endobj -974 0 obj -<>/BS<>/Dest(name)/F 4/Rect[346.131638 632.493279 413.23613 618.89367]/Subtype/Link/Type/Annot>> -endobj -975 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[315.473923 618.89367 382.578416 605.294061]/Subtype/Link/Type/Annot>> -endobj -976 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[445.672166 618.89367 504.687058 605.294061]/Subtype/Link/Type/Annot>> -endobj -977 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[340.341111 605.294061 399.356004 591.694451]/Subtype/Link/Type/Annot>> -endobj -978 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[480.697312 605.294061 515.343797 591.694451]/Subtype/Link/Type/Annot>> -endobj -979 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[312.014695 591.694451 333.783738 578.094842]/Subtype/Link/Type/Annot>> -endobj -980 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[410.863816 591.694451 469.878709 578.094842]/Subtype/Link/Type/Annot>> -endobj -981 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[315.473923 578.094842 374.488816 564.495233]/Subtype/Link/Type/Annot>> -endobj -982 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[442.699265 578.094842 501.714158 564.495233]/Subtype/Link/Type/Annot>> -endobj -983 0 obj -<>/BS<>/Dest(personalInfo)/F 4/Rect[379.207078 564.495233 438.22197 550.895623]/Subtype/Link/Type/Annot>> -endobj -984 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[482.796433 564.495233 517.442918 550.895623]/Subtype/Link/Type/Annot>> -endobj -985 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[312.014695 550.895623 333.783738 537.296014]/Subtype/Link/Type/Annot>> -endobj -986 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[394.44658 550.895623 453.461472 537.296014]/Subtype/Link/Type/Annot>> -endobj -987 0 obj -<>/BS<>/Dest(relatedTo)/F 4/Rect[315.473923 537.296014 374.488816 523.696404]/Subtype/Link/Type/Annot>> -endobj -988 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[479.98613 537.296014 514.632615 523.696404]/Subtype/Link/Type/Annot>> -endobj -989 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[312.014695 523.696404 333.783738 510.096795]/Subtype/Link/Type/Annot>> -endobj -990 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[399.76616 523.696404 458.781052 510.096795]/Subtype/Link/Type/Annot>> -endobj -991 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[315.473923 510.096795 374.488816 496.497186]/Subtype/Link/Type/Annot>> -endobj -992 0 obj -<>/BS<>/Dest(titles)/F 4/Rect[410.403123 510.096795 469.418015 496.497186]/Subtype/Link/Type/Annot>> -endobj -993 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[383.885789 485.747186 442.900681 472.147576]/Subtype/Link/Type/Annot>> -endobj -994 0 obj -<>/BS<>/Dest(address)/F 4/Rect[340.690476 461.397576 407.794968 447.797967]/Subtype/Link/Type/Annot>> -endobj -995 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[340.690476 437.047967 399.705369 423.448358]/Subtype/Link/Type/Annot>> -endobj -996 0 obj -<>/BS<>/Dest(notes)/F 4/Rect[340.341111 412.698358 399.356004 399.098748]/Subtype/Link/Type/Annot>> -endobj -997 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[340.690476 388.348748 399.705369 374.749139]/Subtype/Link/Type/Annot>> -endobj -998 0 obj -<>/BS<>/Dest(anniversaries)/F 4/Rect[371.666795 363.999139 430.681687 350.399529]/Subtype/Link/Type/Annot>> -endobj -999 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 339.649529 423.383103 326.04992]/Subtype/Link/Type/Annot>> -endobj -1000 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[346.131638 315.29992 413.23613 301.700311]/Subtype/Link/Type/Annot>> -endobj -1001 0 obj -<>/BS<>/Dest(address)/F 4/Rect[356.278611 290.950311 423.383103 277.350701]/Subtype/Link/Type/Annot>> -endobj -1002 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[481.145554 290.950311 515.792039 277.350701]/Subtype/Link/Type/Annot>> -endobj -1003 0 obj -<>/BS<>/Dest(calendars)/F 4/Rect[312.014695 277.350701 333.783738 263.751092]/Subtype/Link/Type/Annot>> -endobj -1004 0 obj -<>/BS<>/Dest(cryptoKeys)/F 4/Rect[398.12407 277.350701 457.138963 263.751092]/Subtype/Link/Type/Annot>> -endobj -1005 0 obj -<>/BS<>/Dest(directories)/F 4/Rect[315.473923 263.751092 374.488816 250.151483]/Subtype/Link/Type/Annot>> -endobj -1006 0 obj -<>/BS<>/Dest(emails)/F 4/Rect[454.918259 263.751092 513.933152 250.151483]/Subtype/Link/Type/Annot>> -endobj -1007 0 obj -<>/BS<>/Dest(preferredLanguages)/F 4/Rect[384.257127 250.151483 443.272019 236.551873]/Subtype/Link/Type/Annot>> -endobj -1008 0 obj -<>/BS<>/Dest(links)/F 4/Rect[479.61699 250.151483 514.263474 236.551873]/Subtype/Link/Type/Annot>> -endobj -1009 0 obj -<>/BS<>/Dest(links)/F 4/Rect[312.014695 236.551873 333.783738 222.952264]/Subtype/Link/Type/Annot>> -endobj -1010 0 obj -<>/BS<>/Dest(media)/F 4/Rect[378.097459 236.551873 437.112351 222.952264]/Subtype/Link/Type/Annot>> -endobj -1011 0 obj -<>/BS<>/Dest(nicknames)/F 4/Rect[315.473923 222.952264 374.488816 209.352654]/Subtype/Link/Type/Annot>> -endobj -1012 0 obj -<>/BS<>/Dest(onlineServices)/F 4/Rect[455.830125 222.952264 514.845017 209.352654]/Subtype/Link/Type/Annot>> -endobj -1013 0 obj -<>/BS<>/Dest(organizations)/F 4/Rect[380.536423 209.352654 439.551316 195.753045]/Subtype/Link/Type/Annot>> -endobj -1014 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[484.125779 209.352654 518.772263 195.753045]/Subtype/Link/Type/Annot>> -endobj -1015 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[312.014695 195.753045 333.783738 182.153436]/Subtype/Link/Type/Annot>> -endobj -1016 0 obj -<>/BS<>/Dest(speakToAs)/F 4/Rect[394.44658 195.753045 453.461472 182.153436]/Subtype/Link/Type/Annot>> -endobj -1017 0 obj -<>/BS<>/Dest(schedulingAddresses)/F 4/Rect[408.95366 182.153436 467.968552 168.553826]/Subtype/Link/Type/Annot>> -endobj -1018 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[353.770066 168.553826 375.539109 154.954217]/Subtype/Link/Type/Annot>> -endobj -1019 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[398.956101 168.553826 420.725144 154.954217]/Subtype/Link/Type/Annot>> -endobj -2361 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2360 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2359 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2358 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2357 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2356 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2355 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2354 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2353 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2352 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2351 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2350 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2349 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2348 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2347 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2346 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2345 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2344 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2343 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2342 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2341 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2340 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2339 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2338 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2337 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2336 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2335 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2334 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2333 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2332 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2331 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2330 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2329 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2328 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2327 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2326 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2325 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2324 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2323 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2322 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2321 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2320 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2319 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2318 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2317 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2316 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2315 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2314 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2313 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2312 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2311 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2310 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2309 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2308 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2307 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2306 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2305 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2304 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2303 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1844 0 obj -<>stream -xœÕZËo#E/ÉÊÅshvØUЀÔÔû!í œØ f’؉ æÀ®6\f`÷¸þt¾úªºÝÕ?& ÒNOÜérw}¿ïý«ê¼`p|NNqꜷFÿz7üuH­Æ/Ë3þ:„+k -£$µŒYg g5UŠy¥‹ßþ=\ ò"¿ý<|õ§¬øù?Ãð¼õÕ#œ A5÷Æá3÷Ã+8`jîÊ;@Ê;¥‹·IäÛìûp½ú„QWÄÿuy;@Ɖ³¯míëû/›p¼å÷«vý6^óÚuý¹ÚøÃÍÊeøW4Ïu±ß\+ÿ;KUŒkÇ\Á™£Bz¡]qýnøêõôîì䛂KŠsH¸«¸¾þð‘ä†ÌÉ‚Lá¼"ë5Naäo£¯Ï‡'×ɹ…äÁ’Òr«‡ô®àbJ~€ÏÇÅ%´¡š aý\_%WdŸ€åÈ’ŒÉù£›J8MA°Ýé=Cfç ˆöm £Á^ JjF¥1Έ ÚiF.þPŠCšI¨Cf¨—ä;pÕ:kO!Ð.à˜`-µ;5?CÓÊ•s¸Ïá÷%ŒÜ€åhÑ–ý…È=–ÖXÁ÷­ëÑH#¦E–›3D8 wðÛ - <ÀpÌsä¶Ê‘ W¸kŠ3­’Cäu_âø|ꈧ;f8üŒÏbMX¤ Ï67¢a6ª²äSpa¨´‚Y&9/hµh™‘ÞJ&) žÃðoà\-ñ»pÏ)™­ÿù¿¤u˜aPzªå%NÂCÅGÕýp)WR+Û½µ ñe„ ÈGäCò1ü<ïE°‰“L¼õÔÉС¸Ð!øûFôOÓ´™!s'éa*åµìtÒ€œi¿[•‚­œ“éöà•s –UJ¨ÊUð‘¯Á\eþÑlµ–·„ÙD7ep³\hFm§æ!b.ñÆãŠ70zqÔ6ˆUÔ#˜l«·ÃPpŒ´ÆëtûFV€s‚‘;,ƒ¤VäGpž£Æ}¸f`•1<êâQÐ;*ÀÿLJ-x£§ƒÐÏ`šS˜îŽ1ùí³€ßnFì6FÇK]$ë–)Üå”9@ø>Ev-„BÆ=;<µ´õ°šý™H3¯BN}òye˜¡^ŽÁôþÒ×÷U™\%³Fó€çzÃ@0Oµñ*|ïO‰iTX +e:Œél’½‚µ_}ab—óIÀ¾1Í$žIm|¦`dŒÑ‹ºG¸G8P:øMÛV_;‹ŽO†Ð^"÷˜bJt âžQesÂKÕ`„ª,¶]‰ó&#\ƒôy‡]òÛt_PÀôíÐÆ®°¥—3Ä|‚ý.hT/÷ i -”€%)T4UH0±’J· -|B˜÷ó)Ö£ÀÍæ€<†â&–­{›:wh¶O#hñÕäØŽžÐ‚Rpˆq+«ºý 6}>À¥¢Å”ái·” ;’Xjc¬8°XqÇAç …ö– ¥ªÀÀ‡=7AB¾t80zÇàçU"{Æð]"fÍ4›¿WÞ ïžãù£cÕÒ@*€í¸§G•÷¦jteäÞ¦Œ(Ãë"5¹›–&Ë,k¶/’²j -?³ qÎ!jí(V/T?Ä%jŸ -PƒnhE™ÐÁÁ½cnöG»3@;„ª*úÿQ -"ñþ¹vsÓN‹†ž07¡Pð™p~™]¹)DHH«Žä+hÜ~‰¶+{Ç F`ŒÖä†Øà)¬g•:g5q¼¼ªz÷IL}¾‚û7%9ˆXÿ‚ñÑîE½q¨¤„R¥lÕµŸË¿"ëPkÖ#t‰N‡—(à Cì²bóHI=¦Èv:­”ÛKíŒn,÷>Aâ2Å Ÿt.æ9¤@­nAØI* c\GÇ ®óÐX»ò=ƒ»ªª%eúMå€Yx»u9\õüÖÚ¶,bñëK,€«”š§˜ÛÄÐƸ¬<«BMí Ÿ¢ê1– -E-Û«¥‡T~³|*·Ê}Ÿ È;Me)záæT‹”ÇäÆ]‹“öÄEsUV\&,Ê[jm_jn¨5b³* Ѳ©Òñ¡»^†A“ú̺6 ¾½¼z}y^„«ûH¥1È€íƒåJOæZëÆJù)…*e©öÒ*ÑXÊtýldAä?*²Þk› úIík4·*Õ¤oO)´®lÆGZB9äR-Ósí› j›žuÀpŽYy€ UšòÀüx£¢<] gÛãZAö -2¡mö¶\^„-—Ž†”Ã:«Æté]M$ cì4›He{ɹg‘ÌßC•{Ýzë:PÁâÉH®™lcjÀÏíaÂ9Åw1Èø,½¹˜ãæ{¹]½a–å[}ã|Ö0Jß.F¾i_Ò²Ò¹áº9x—éú7V·ÙÅ^Åó&#f¹ä]o%êíwûk²’êá¾ù_joöY¨ÅgË-Ô¸Öª?¿ûÅÓ ýò"³á¯)U1ôœØ׈bE¨v3Æøúâ&ãíÕãŸBν¹WOú2ñ¢ìKs«Ái€×0è“:‹fQ½òÊÅ4+ËvÒ@^Yc ß)¨š‡I2’’ «vKÊöŸC='=LXøk©ÐVjÞ)Ã`ýZ ³§äu §ÿ…Wd¾¾ÿ=½î˜hKèìÜ8«å>Âc”… ™`øØj[ÿ”¼>дØ…óFïÔZV…èÅfßýª:þ9$ -endstream -endobj -1742 0 obj -<>/Font<>>> -endobj -953 0 obj -<>/BS<>/Dest(type-signatures)/F 4/Rect[300.85766 757.790154 359.872553 744.190545]/Subtype/Link/Type/Annot>> -endobj -954 0 obj -<>/BS<>/Dest(iana-type-registry-contents)/F 4/Rect[396.175287 708.991326 455.19018 695.391717]/Subtype/Link/Type/Annot>> -endobj -955 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[102.172846 611.39367 136.409174 597.794061]/Subtype/Link/Type/Annot>> -endobj -956 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[482.254389 562.594842 516.490717 548.995233]/Subtype/Link/Type/Annot>> -endobj -957 0 obj -<>/BS<>/Dest(section-3.5.2)/F 4/Rect[65.905512 439.897576 99.092035 426.897576]/Subtype/Link/Type/Annot>> -endobj -958 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsco)/F 4/Rect[99.092035 439.897576 361.223627 426.897576]/Subtype/Link/Type/Annot>> -endobj -2367 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2366 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2365 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2364 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2363 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2362 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1843 0 obj -<>stream -xœ½[Ks7F+^\®8Ž›­9¤RVÃx?ªö² %Q²"‰’Hú¡²[ë\ä­Jv{ØŸžæ`0áHÆŒ$fÐÝ_?L§ Ï+÷ÇŠ±Z‰âŸŸ¦¿M±–þfý×þ6…+­ -%8Ö„h£ £%‚X!‹ßÿ5]Oÿ=¥…ûüþëôõ/“â×ÿLÝ|m›)”2†%µÊø9§ øijê'€Ë'ÏJˇ辻^ Ì°)ÊÿB~„, G·upûã·©8V²ú¾+¸~(¯ipÎ Æ,nûÁ”»Eú7dùÃÝ´±½ÑØhA¨4Ä” ¬ˆ!ðõîÓôõ׋Ëëó‚ªâîãôÃKô=E_ÂÏäèç»ó–es¦(8OL¦|ƒ–hŽfh.Ð Z  ü>ƒßkôÆ'èRðŒ»³†§Nà÷Ù#E^ÂÝ%Z5³$\ŸÃÕ -žX¢ûûX¡4–Âf(“]!ycÈ -”Â-“%äËùû³ã€öjãðTþ{ô5¢ð3Ég Ǥ­±ÍÑi€é³q¨Ž\w–)6 7@ËHWoÑ[¸q “VþºUá…d£ï3„`¨|` S& ãüþÿsOéC[L5#šs°g©¿Ø ]Áçx•€ßù‘·þÞòˆÔ3 ~ȘSÄ5|û Æ–žâÂSºAÕØ»Äô àpŽ«Ñ§²3J°â†9‡õ‚× -Ì(fîeZÂàÜ«h幯~sï¤Â\éráE^ÁðÜ ~ááNüÔS?e‚Ž½"ü„Ö!H€¹ßNàêÊs_ 'µv†ð2H6šf+¼)¨÷ðÍ áàÞaf¼8‡VIkò†  …-áP·*è¡î}DÌ•µI7úÈ-|¹ñÈV^e0Ý—5ðºðqwZkÁó<¾ë&`ëþ0«­ËÁaêåDbk9•*‘j )`ydS—’Ÿ÷²nsÄWsl,—Bçû´æ±êÍNµ† H4Ê -¥6°tVôU*ØnBY…)¡zc5øØŸ{ÏYùôæXÈݤ°¨àŠ[U讀u­~–©×œaX„i*r0í±õØU«#¸¹*ËbÌ—ÃÊÅkïòME´P¬„äx?©9NVq•*«ÒlDeªB®6ïfÄB+9IY¢RçvøüÔ’uYÈ/|¿K•DIenUpXÕp†ªÓû…—vî+ì²kW&4Ö؆Y.WôãP~Z×Ñnúê¯ÚgÕxðÏK°Úûà -*0ãBJC‰¬dî·H ,ºÁÀV–^m†Ÿ=­›ªNeÍRåõHß°ü»ò%4^“L`¬®k¿<\4”ÃÂ[.êu[¿ <ÁôÜÔ±dæëTm¤‹‹§vîjÈ(ƒÎÿ´-nM²RƒY¤Ô¦ñ\g0Öd{ƒ”_/è]™Â:âQk•ñ­Cò¶P°›ãârdÂþb0aÇäü¶dQùlécuŒ–KÁÕÁ6\`On)Õ‚Ó®PC.a,6œËrÑ:"ŸŸù•]¹ï¨W—Nöcu« -kò"ÑJ.ߤûœUnaĈ…-¥°°’ÖRAݹ‡ÄN[0 -æ÷§BHEës“GNÖrÍ$¡¦ÈÝþ$†3» -ØI›Hˆ`j%‡€É‹ÿ¨i_XXUk¹&”ì,ãþ„ À#'Bè ‚`”Tl;= 3),a´ÈÝÍ9¶q ÑÓ ~è­[:ÐlpeRºò'ðƒe›bªñ‡xÜ´ã`¼:ÍTîÈY俆rç9S¨Ð¬ôMâäÏË<õŠ‡žIÀ6(óèûÑDtvB™ç¸°G™—#x*B)„õ’t»¦e}?šˆÎN(󜡬ÓÆÏ=μ$ÑsÒÐú?²ŒŸ!¯µÇ[:ûóZRp‡q^·åM¬†Àmi;þУ™‡4eî iËy(>[~câ3D™Gß&É«; ÌsŠÏeo|Š&®B¯ ÇCïÌÇs<¾Ê<ç®×æ%é÷ÚðùОy;÷ÛmHóœ‡3QËq\&Ò [Ë4ì\†âÓnoéì/>‡3QûܸLäöè9¤íøCfâØÝÒ–óP&jùÉD!Ê<ú~4Pæ9e¢åˆLzm8zg>žãñÝPæ9g¢1^IØ3oç~»íižóp&j9öe¢íO¼Úèg[¥xù‚làÜiø]`|€Ï[wŒÈoûB$&+I«“”¬;†:óSÝÖIzZVî•_e=ë‘€G?ï4}T¢û#ô €ý zŸç‰œAº23[¶òüóÍßW—Wùó/ÿ>¥=çz–žts(Ùœ™”$Lýªs,®¥*"»ïéDI Qj¸írØùø8:@TÌ­U” Ñפòb°I%&ðÈ&îßÜz­›îtd!qöð® CG¦ -L-¬¡”¸G%êÏìPiL†”éUqb™HÞŠ5¢W'´ÇpçÊŸ{>¥Hsô¡:¯»åžÓÈ ù©zç>Ü|VÅÄj"¤±é+·­úOœn½Ý™ózo-¹sô°kbåÒ˜;v‚Ô‡cÌŒbƬi^UQ̽K§q­FKøI–lô®Â¥l9™{™¬¦ÆOW^椿e¥ô8§ç÷/ƒ—oý -¯5ºhuÖªrÐä’aeUÛ³E/Iý*nDÇmWE{n9ÌB–Ö‚'þÀ-'ÂBö•Ú½–Íwÿ-'°Îƒ<*%ÙÔÝ‘ñÕÚ³÷×Ê¡añ©lWäˆ7ƒ/6¶rÄäzêú¸ª…Æ4s€EÁˆŒ¨.çtñA¨{! o¶™£T{Z’ÓPÉT¤Ž Zɪέ(1J&âù~—<ÊzZR9îDx¹:Mõ‚ú®¹Z1ÃlPÚð²N1,=“Ãme°«†s“ ‚Ê>&Óºì<:§™be¯ª˜ÖáïTÌ*^Ë~ÄÒ‚GPˆ† -n?–t=/°”°à]å¢æšç¬’±G•\¡>Þü³…Xç}£í”¬õ¸j<¯ö›¿zÊö×ò%ñ“~ hízì\—vÜCÛ%Ûéâü¨”ë^î™x\…ŽøÖ×ÌSáMÕÊÑòšû·Ý‹j±BmÉÌów«s_^Vûhóp»[åÚÒPj·ðÉ•í§õ‚¡Æ ìBbÿÉðõ‘–۹ˌ®$åÒ&öÛbR3&žb ;7¨ÝP8-×2Êž5ýì4@6Ì€+ Ϋ@eu*Ëvœ”˜¦ÅfNÍÚôøú~¾ÜŽ™û4À,Lj.i–‡ò)ãÖGÄ]ºuãá×ktãòF™Jn¶Ô¥$˜*£%ü\äÎü’såKXuOÐå–ªÕ3c•Üˆšù²SÿEu²¸ãbú£Øn -endstream -endobj -1740 0 obj -<>/Font<>>> -endobj -937 0 obj -<>/BS<>/Dest(section-3.4)/F 4/Rect[65.905512 753.389764 95.494623 737.789764]/Subtype/Link/Type/Annot>> -endobj -938 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-v)/F 4/Rect[95.494623 753.389764 350.661615 737.789764]/Subtype/Link/Type/Annot>> -endobj -939 0 obj -<>/BS<>/Dest(iana-registry-policy)/F 4/Rect[229.494867 643.791717 280.42016 630.192108]/Subtype/Link/Type/Annot>> -endobj -940 0 obj -<>/BS<>/Dest(section-3.4.1)/F 4/Rect[65.905512 618.692108 99.092035 605.692108]/Subtype/Link/Type/Annot>> -endobj -941 0 obj -<>/BS<>/Dest(name-jscontact-version-registry-)/F 4/Rect[99.092035 618.692108 283.432367 605.692108]/Subtype/Link/Type/Annot>> -endobj -942 0 obj -<>/BS<>/Dest(section-3.4.2)/F 4/Rect[65.905512 503.194061 99.092035 490.194061]/Subtype/Link/Type/Annot>> -endobj -943 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsc)/F 4/Rect[99.092035 503.194061 346.45434 490.194061]/Subtype/Link/Type/Annot>> -endobj -944 0 obj -<>/BS<>/Dest(table-1)/F 4/Rect[156.401223 412.145233 189.797463 398.545623]/Subtype/Link/Type/Annot>> -endobj -945 0 obj -<>/BS<>/Dest(name-jscontact-version-registry)/F 4/Rect[195.256203 412.145233 319.092629 398.545623]/Subtype/Link/Type/Annot>> -endobj -946 0 obj -<>/BS<>/Dest(section-3.5)/F 4/Rect[65.905512 384.045623 95.494623 368.445623]/Subtype/Link/Type/Annot>> -endobj -947 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-p)/F 4/Rect[95.494623 384.045623 368.384027 368.445623]/Subtype/Link/Type/Annot>> -endobj -948 0 obj -<>/BS<>/Dest(iana-registry-policy)/F 4/Rect[322.092768 288.047186 373.018061 274.447576]/Subtype/Link/Type/Annot>> -endobj -949 0 obj -<>/BS<>/Dest(section-3.5.1)/F 4/Rect[65.905512 262.947576 99.092035 249.947576]/Subtype/Link/Type/Annot>> -endobj -950 0 obj -<>/BS<>/Dest(name-jscontact-properties-regist)/F 4/Rect[99.092035 262.947576 298.201654 249.947576]/Subtype/Link/Type/Annot>> -endobj -2381 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2380 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2379 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2378 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2377 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2376 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2375 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2374 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2373 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2372 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2371 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2370 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2369 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2368 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1842 0 obj -<>stream -xœµYKÛF& ä¢ËÄHâìa±Ñ"†ã1šì&»É=8íè5¢f&ÚÃ&XçbH²Ç]`zª«ªÉnŠÓÒÀHøìz}UõU{”Žø|c~Š,‹¢Ô*ýô~øë0Ö9Þ´¿xñ×!œi5R™Œu’èB -ÇY–”Y>úíßÃýð—a:2Ÿß~¾ùW'£Ÿš÷uÙ¼’¦BÄyZªßy;\ÖN ûHy¢òÑ;ùλoÎ÷¯AX\ŒèWÞ %iaï¶vn¿}ÝU§Ì…½j9çïèN|^còà¢6€ªIà ØÈY+Èb¥ò¬ÕŽsx -ºïZí§¨ŸÐÌcõ®› ¢`P°Â—I9Ì©Vk÷ßÐ^w‹’x*f¤÷¡`ÜÏ…ÌÖY,U™)Õ vX,!q‹el-3kß Ë›EÅ 6¹eºðôF'¡Mè¬LRÕm¶Í .ýITD -5Ð*Ôó•L s˼ÐâÌîúY°»úËÁkÊÂ鞷˜SµÓC¾Ž^@k{á/*Ê ØE¦R-j¦Rk”¹¢Þh¦y ;OÓá1Æ;ý}m€£/°e˜*ñesÔ6©†Œo¬Êâ2ÉÙÜèy8zÞrðÚWh?ujƒ&{¯ Íc9j‚ÚO‰’C‘ô¬ aQÆ »>ɇtÓ—v˜‘ u£r6E×Gmì+cíJ[.N–=Q/k›Áûõ2[ Û*^¡˜)¦ ¡¹Ó¯—š€2|–»È=S´W ðzʸU‹ró¼úÒzg »pJ8aUpoS=7†A­B„°¶÷vp’¤Œ[’üX-Óu‡·ÿgÖm¥®™Éí°ÖSYXžë8‘2oH’ÑÊÀe ¢`彎RáÙ,H%‚~ -˜•¥Ò¶[./³äUÓüZ®dLûÖ«Ov5—ºx°¯8…§Ï©Ž!P?þV]ñ»cF‘12À -½í#Ò-Ÿ $`iž¨XI‘ÁähýzϤ¼]žô©žwhä™|¨t¿cwtñž#úµD*:ÀÔßٹµØúÍB½b“*téÚLa!«t4`²hb_ÿ9¬YëM¸Æ#õO;LÑÏ÷¾:°t‰zF̜ʼnþÚ8G¨¥Æ•!|æÈ&Ó :²?2°ƒ0K Ú‚vvžru6uÈ£TçP4¿+»õε—’eÝ3,[)3D~SÒCF#—ÌÚAøƒÆÞÆz;'hOQÅá¸ã¡FVìO:7kÑ ºr‡Aú ëOgúw_a­Øy [ -¨@Ú½ÿÁï.LQ $MÚ°%¢b²d²Ó7íø ³•˜¬¼æÊ9`’hûò†ó -Â…ÓÖwÌÐÉsøT<‰ÚþLp1 ÿ`åìVi+Q¶Ãwg>÷3xæ:„01APm¸ò9®[¯fúEhÒ°— 2¨®÷Á1Ëd\fBên“ M H‰?aÂ0Û„ªT¢(Ï䨟9ª¿¼ö äA0Àݼ :~Æ]£Óˆ„‚9Kvy¼Tˆ”*UÄI©xÃ$@J3OªBßÀôá¸çÒÝ»}3Gµï î–Ä5g¾ÁIÅ£ñqawÒÑ·íûþ±ºì˜ÖvÇ÷ -¨ÿ¢h÷PŽ«1mÊ´Ò(1œM“3kÞ73Šøû -–5m‚èöÁ‡£ :µcg]±Á»sÞæ]l…ÉÊ~Úîœ<­/Q »kö;È­Y5·ò®¿üuBÍXË<.„Ö ™8 ´#ÎOÜÅöŠª°çNb÷@fÑ߸zÃ5 ãÂÁhíEf̱ZãºK”3gˆM"Úd§YköXÔB&çPÖT¢šÖdÃk‰°OÝ}Éç3 ü„7mãðzX?l 5 ñ¤–Ýñ¢"Ö¼ñQ4 f°d‡Q[¿î8ª%Há6¬µ€R#3‘5Dq‰¾ßÙ†FÝ´¡êi°ínD·Ö;/çyéÍžŠY/¶<ê…ûŽÓÚ Þ'T=vN9‡_«ý]ÓOæfä#ZÑúdôx!RèB6ÀB©æá`ƒ `w_0/i¹ ³;Äò®áj}ûæmÕ®yüj|êÓ¦ÚCQ×ÓÞv«yS d ,¡\äii¹û9“²š½ljõ·[ý½k*x6& N¼‹3Š\ǘI“Ák\œ°m·ÖéeJÁ]pÄ,`t/á(±¼ÝîïìqY¿n=4 ”&õŠ½k¹‘´v[DôÖx÷ÔRv¬ìëŠ.³$,A;£\@gòÈ»‚¡s¢ˆfÃóp Y9ˆþý>Ï»,/,@*@VZ¥'eÿÓ$)•Å":;-)q¡óYô |?š0óoåZÇ"‡†šöÊP˜'[p…#ùá?ðçM´1{MôÍ}™'qª -hhç§ÊT¤"N7ÉjÿIñ|×ê<º«ò“VKnm@Ê']8®‡TOk -endstream -endobj -1738 0 obj -<>/Font<>>> -endobj -927 0 obj -<>/BS<>/Dest(section-3.3.1)/F 4/Rect[65.905512 756.389764 99.092035 743.389764]/Subtype/Link/Type/Annot>> -endobj -928 0 obj -<>/BS<>/Dest(name-preliminary-community-revie)/F 4/Rect[99.092035 756.389764 261.554926 743.389764]/Subtype/Link/Type/Annot>> -endobj -929 0 obj -<>/BS<>/Dest(section-3.3.2)/F 4/Rect[65.905512 621.692498 99.092035 608.692498]/Subtype/Link/Type/Annot>> -endobj -930 0 obj -<>/BS<>/Dest(name-submit-request-to-iana)/F 4/Rect[99.092035 621.692498 221.028559 608.692498]/Subtype/Link/Type/Annot>> -endobj -931 0 obj -<>/BS<>/Dest(section-3.3.3)/F 4/Rect[65.905512 578.592889 99.092035 565.592889]/Subtype/Link/Type/Annot>> -endobj -932 0 obj -<>/BS<>/Dest(name-designated-expert-review)/F 4/Rect[99.092035 578.592889 231.626703 565.592889]/Subtype/Link/Type/Annot>> -endobj -933 0 obj -<>/BS<>/Dest(section-3.3.4)/F 4/Rect[65.905512 369.497186 99.092035 356.497186]/Subtype/Link/Type/Annot>> -endobj -934 0 obj -<>/BS<>/Dest(name-change-procedures)/F 4/Rect[99.092035 369.497186 196.702631 356.497186]/Subtype/Link/Type/Annot>> -endobj -2389 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2388 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2387 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2386 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2385 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2384 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2383 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2382 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1841 0 obj -<>stream -xœÅZKoÉDÐ… Ä^$¶³È&àAØX†=î÷ãR¤dÆ¢(iDÉÜC6ˆöb/°›œ‚òÓS]Ý=ìžIÙNLK"çÑõúꫪéÀë•ûc-±Z‰áß> ~”ZâÉøþ4€OZ •à¥&D=4Z–B+äðç¿n?èн~þaðú¯´$Ãþ1p÷k[ßB)c¥¤V¼ç~p/XššxHù€¢äð}ù>;ï>ß¼a¥úÿ©¼-Jú…³Ó:9}ÿ¢©Ž•,žGµ’Ïïýgš|NïKŽfuóWI¹û7lþMÅ~{5¨ãoti´ Tb†”˜’qˤ^}¼~;½;;¤¼Ä58\5¼º¼{^|S¼)FÅEqVL‹ƒâ¤XÀû›âþžÃk -ï~wüÝÕÙ`|…!ÞW)æ<)¨dvw•^«ç….VÇÅA*úã}"LIœ2øóüâíülHUû´ø²x?^h½eºäLQHª|tÞ5¸h›¡ãà÷)ü¾§:w¾*\ã]:çÞÀ1 gÎàú -ݼZÁ¡èïeq™K$«mKn(™Û©E)‰DluôQAáç1Paü£AÓb’rØaÊ!¿nsq®„0ú.à÷]÷ “bºúþßpŬö£Se†þŒ -œ@.`wæ¬Ï~ËJÅ s‘EgU°ÄI¶ø;(Æpæž¡°E9ÂP%¦|R 2Ü£9pèF >íb¾ÜÒ*Ž›áøÑ帋hžï-<Áh/18Uƒh^Z©x[h!ËKKWl ;4wP¬àШ9‡ÓrU˜YMRNm§~C ©#´P„54qjà kT”W°Ð ßÐõäM¸†< KvåùÞýŽ]Ãû[$Òªf ´Tß#wx´_w¨èî;÷îij;j\žâxŠŠ8wu)òeŸV–TY µÊÛ3¹#ƒ/s¨aÛãØéø ¼¹Ÿ?Fªó¸ƒ"aÚÚ`žBQ.GF°ô=:fäyÂÅù’ -º0†Z ®î3ÜÝm) 6¹p‹qz.U© -d9 -œ9¢=É -–ÌB0é°QCÙÖThÝ^×Ùا‡bzTûŠŸ`h‚¨öf­‹Í´x‡z^c¼¿(þàúá¯íÃ}ÎüÓüþ÷f¸w ¤…ÁIB•©ó{Ým€ð9Tk¨Ô±äÜ4ê^7bÃU Ê5¦’Q(û]+;PÙcÀÌW¼æXЮëúéËy”;ôjÕgŒµ÷šä-ІG™_ú³1÷2øYç~?)Eß|‡GhïïJÔ$X…—\Âë¼ßDA¡B­ &ÎÁu瘗Øó¶é7šîU›£â‘°F¡ñ»Ø”çžëïIßÛÜÁÍ3u€IYÕt^ù'(³Å}¶rC ÞS÷BËÕ÷ÿÂlòtþ}™u­Û©Êgάò¨^>mê0ÁLS=/ù7µà)Bg J¾é3]òR*iX–– ”ázže¢fºvCmÖÐÞaÃ¥˜ÃÍÚöÚ¼h>.ë^ô¶ÓÙÇ<ÑGªÂHà˜¼£MGÍUЙI4òÅ*)˜U´½”n/êNkŠð÷ì¸!£€=oàa(“ 0Ú¥Æű€Ï‡ôÃ:ÿ¯qÝI8î3ßß¹Öª`S”uØ´ŸRhQ† %U¥°fÝ„õ(+; ¸¹Ir:Ö¾ƒé÷»op…çGè—)T´¾Ky‡‡O³*¼OVaý -Í@ü# -o6‘ _ˆe±»œ„ÙZ±YÎKhØ”ÑZˆö2ëëª -[ç7‰ªšá\~œàDQßÕ’yÅF£JbT%±ši¬IcÖŒ<^ùù®ˆåùØA[1¤Ž,ni= C_Wx½\&,m6&mƬ©‹¥kgæEÜI9GÎŒÄ]e;E•–¡Ž¸Èø4K¯öIr‰ºÁ˜,pj]¢Òž¸ç¡fE–Zç}  -f9£¨Õ´­x z³Õ0_Ck§êú9‚èM8J³)â,zÇ۶Ė eúi‡µk?tûh]!–¡€ú•æ‘ê#Q72Pb£¢xFÊ´n+ú2!V(®[Üepöõ凂ž¸XÕ;;¾×ÙÄŒûQZZ>+ €ÃuÜð˜ÖnqŸ&MÎ8TIÍüãu•^®y,ÒÓf %B­·cZ¼x´µöÆ*1|ÇØiê‹z+)öC¾}ŠéqÖtmí6¬«›]Uj‚‰ˆi˜õ’ý¥œBöÎM7ZY®¡ón/ÿùˆÛ2›F6[md=!–µ¡šy‹'µF’º·yÙÅÈí»Mêfø>-ñÎ[<û "Ðî¶Æ˜¤a¸4’PÓVí ¦¤n_­w(.Ö˜n¶Ù#¸Ìݲ™¡ªI0Kbî¦}ZÚ`ŒåЛìDU™1Ÿ€ƒ²¦RØ`%b“ú.ý_GáMµ÷ùì2FÜÕù›‡ BŒCín KèG'§Â)Nq[f?-5õnàIåëÐu8—¿£º ^„Dô†F>™õgyÒ)¶÷—ƨuœ%'ØlĦdÑ;hèÜ%¼#Í•ÞA gºÝ›Vß!Åì˜#tº_¯SC|ŒÖ×X!ýÄßÖì¶w«Õ^*K´MÚÇn+š8=\|jpPËÂ?k€ô×{kù¬‚¦œo ?°OãÒ™Ô­ãÇŠ•5Ÿ}&2Zƽ˜Yômoh±æŸ×)UÓäËD—t{-uÆ™ÖéàÓð68n¶Ž6MÉÑ3)ȼ'bí®ó¾Ï^nk”2Û+ [%ž¶#AÇž.n¤P]×öV{².ò×膶žÍö,ac4E ֽ¢®Oþ¹˜ÓaÒg›4%1ñ'Øqé‹{›Áñc,›…ÉÈß÷„ɺ?ÌB[°é!Œò¥ šQ»ûó—12Ü[,N>½‹ÿœ‡\¯5ö<ûJµZ•0`hCw×&î>wIÉìÏáZhKÔî‚T‘><(~ IôõžJéæ)£ôîrW÷û$‘AÓ!µ…ŽºñÌ¡Gê÷w*#¶„ØX{g1Ò=³ÿ¦ø-xóIñÕžÞdŠC?©€a»Ëü“Ëܘ§¡€íàE51ó,Å̃à lÈ=ˆòÇ+Ÿ8œB”T1JØîb>.œÖ”Z3!ùîK³:ŒNĨÝEuÅò«O@ÁnŽX¥4k?¼éQ§ëûûÌTûR3Ñn'ˆ3H5¹—¢#h -Ó·®âï#«#÷ˆgûZjx ‡áj/ÑOÓT›R2äÒØf¯¿îÁ‚,s´Â¶@çBýZtøÊ”ÌRk5z¾Å··:›¶Ð7;á¿üøï_Q`kÍmíÿ¿šûÒŸ×Ò=EçÞÙÞkŸ#ó´`ÿC§ä›‘Ÿ×#̪Ò2&ÝþM¶ãµ;4ö*ˆ)¹ÔТ76†¨ÁÕ7‰Ôr(¡-·ŠX®eæW–Úƒâëâ7ðzÚ´²_W&¥Ý*¨Udö“¤ :%±]I7}ž¿‚Ÿgû sßÉÕº„~KÚ)Cádu‰céôÕ?á×ëb±ºÿO {úRh“Œ†®eáÍm]w0QíéZèG™±Jnµš×cû³¼ûô¯ÿaFÄ4 -endstream -endobj -1736 0 obj -<>/Font<>>> -endobj -913 0 obj -<>/BS<>/Dest(section-3.2)/F 4/Rect[65.905512 743.290154 95.494623 727.690154]/Subtype/Link/Type/Annot>> -endobj -914 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-r)/F 4/Rect[95.494623 743.290154 343.042231 727.690154]/Subtype/Link/Type/Annot>> -endobj -915 0 obj -<>/BS<>/Dest(section-3.3)/F 4/Rect[65.905512 679.990936 95.494623 664.390936]/Subtype/Link/Type/Annot>> -endobj -916 0 obj -<>/BS<>/Dest(name-registry-policy-and-change-)/F 4/Rect[95.494623 679.990936 331.919672 664.390936]/Subtype/Link/Type/Annot>> -endobj -917 0 obj -<>/BS<>/Dest(versioning)/F 4/Rect[239.555414 658.390936 357.662836 644.791326]/Subtype/Link/Type/Annot>> -endobj -918 0 obj -<>/BS<>/Dest(versioning)/F 4/Rect[363.72143 658.390936 414.646723 644.791326]/Subtype/Link/Type/Annot>> -endobj -919 0 obj -<>/BS<>/Dest(RFC8126)/F 4/Rect[157.034174 617.592108 197.991938 603.992498]/Subtype/Link/Type/Annot>> -endobj -920 0 obj -<>/AP<>/BS<>/F 4/Rect[206.690912 617.592108 257.616205 603.992498]/Subtype/Link/Type/Annot>> -endobj -921 0 obj -<>/BS<>/Dest(RFC8126)/F 4/Rect[183.121576 603.992498 224.07934 590.392889]/Subtype/Link/Type/Annot>> -endobj -922 0 obj -<>/AP<>/BS<>/F 4/Rect[232.778315 603.992498 283.703608 590.392889]/Subtype/Link/Type/Annot>> -endobj -923 0 obj -<>/BS<>/Dest(iana-version-registry)/F 4/Rect[174.822504 566.793279 305.89599 553.19367]/Subtype/Link/Type/Annot>> -endobj -924 0 obj -<>/BS<>/Dest(iana-version-registry)/F 4/Rect[311.954584 566.793279 362.879877 553.19367]/Subtype/Link/Type/Annot>> -endobj -2401 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2400 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2399 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2398 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2397 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2396 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2395 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2394 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2393 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2392 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2391 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2390 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1840 0 obj -<>stream -xœÅZYÇn€ð D"Å1lbZÃnõ}äÁ^ZÑÚåäZ¢’ ëÉ€í<ú!?=ÕÕ=WÏCj¹Ši/93쮯ª¾ºšñƒ×7áÍ)NóÖ¨Ñ¿Þ R«ñañŽ7•5#£$µŒYgGÎjªóJ~ý÷p=üyÈGáõëOÃçÿà”~úmÖ[_.á\ª¹7×Ü—ð‚­¹+¾RÞ¡(=z›D¾m<×ë¯@u£øo]^ȸqã±­=¾ý*‡ãµ(ž#¬ÚõÛxÍk×õuµû÷ ·zQ.Ã?£ü½.ò»«aé{g©³Šqí˜q%¨Þ2;ºz7|þ÷óå«óÓ÷TŒ®n‡ož‘?‘‡dpòãÕiµÜ:©T¶¬øš|I8ü7 OÉY’Y™“ëÁž‘1YÃ5Þoî*$\{md{Ë`r•˜s½¸Š{geÔûÕüõ‹Éw#.)î!á[IK6r ðyLÎáÓ9š»!±žzï7=H ¹!°Þ=ã‘ ø yÁë<D_¦¹†O3t € -/`ëàuðÿ‘*F…‘Àz -TmLÎ>@%=U†[íznž²)à›Ê%9„ÓÝ!sl¤ÎPéS¾—{s€vÆZD~h¤škˆW©EÒ¯Axtë†IlÀÎþ_è 7T %z!1ÆÎy™¢j…zLÉbóÏßá­BydŒJS)dFüð\"ÆiÃdøüï @‹¦¨pgÏÎQ›<T9ìÈxA…6¬—#›“Òã§l‰ #Âg4uàЇ&Š…ÔÁ^*ÝëÄ2C«6Ó\H&/àú”;"]8KPÍÈZFVÊô-†6T õêMаƒé6·ÇÅä p9 õ´ßý!~ÎÉÌÑÃÑ£÷Í1C½`Ì÷•¬`®)úo hB*ž¥`*K,ó£amÐIM-÷ZíAB™*h0Ý€lþƒ6 ¬[ ÇÈÏЬR†¸(cjº†À‹\ ï¡Â¬1ó]ß›Êf“þX–%~–’\`÷±ó˜ƒÑIr×_ë4ÚuUyÚÈÄÑ÷ЇV;ÆúÊYLQ7èÒàÆŒ»Í-¡k6%„bn1µ©åqÇä",Ô8¨Æ*ÛC¯*Pµ¦?ØøkØ:Ïþùü¢`o Ù»½w£Ùÿ³ÐƒùþÞÀ–µtÒ§˜L‹Ò” yb‰„ ·Šµ¢B¿Æêy†|]ÞÓ,2g¨í¸\ãp`, ëL|3[ÃP+•Ñ&¶Þvµ¹³<¤!Ëœ0ÙŒ|è›Yäx¯c%ÕKëx>ÚÀ6ÌóЬqÎŒ0BdÓ¬ù!e¼ -Ô2¾´<Œ° tZVy¯{)²bØœU´SÁE ‰Ü/jOw»-º¨øîË6Àˆ@Œ@j[çV3ÚSèB¼tmUH?¶ëïz¯ I…Ëj¨@ÎF½Î$Hn©ò\0Ù–0H6Å€,öÜfŠJÑ,ô ÃQæ5S*›E<\4H¶J›[ÕïÏQ+›wù£2NDYÛí¯-ÕþJoUBߘ…jI(3±T2eœÕ»´ê‚Ð’:¯4Í‘8¾óêªUµ|xºN(\õz%¬U VªCçì2!’O¶Š­Še]¦„ÖÍÃðàÄþ2 éÐ?…Ÿ“?ëãàO2A=‡Œ¨²yvù+òêlkJ**×™sŠ¥jVv„c ó2j€<œàwnÒdSµ8GÞ¤ðØÅ-e(ô²ÌÚ—ØNÑùK_‘:ªÔ#;ý¾û}rÈ -K`ˆÿs|R5©ÝÍlŒã¢å}T[Û6Î4Oe¤ ëv%Ãq³ö\¼®æoˆÖÍía¡MH¾—©Ÿ'éõ -ƒvB8ƒ'§)ŒÏÕ%®Øæ°˜åL”^—ÜÖ½$ëíZ̽1eóp†ŠuÖpãÜã;Ž›ÅédL“óTkªòù™×ÅÕÜñ°/f9LëÜdVæásÔ0’¹föhâ³´&-ß®$´„V(k‹pjí´-Ÿ®>…óÂ<Üq™‘€ý¢…˜Çö=ýê`~?+Ê7i Ûmd9£Ò¹ªî¨ÛBCÝŽsÛþz›ZPä}8¤ÐÙiöõ‚ ò -¦2Ë¡ð5Š¶.ðŠr+ Ìe8Û( ~p´ÏP`MÌŸ!¯¿ý &Ê5\<Äè=mɇrò³Ù)ìõ|Ëà…n<Ðʘ»q’° 6WžZeÁÜÙd_u?eX|tâX{®_‘ÍÏð°:‘,N|ÂßRv®÷5=Ç* ×£lÆòÁ¥<#åY›#[€À‰ˆŸ{4¾n F@;锄þ³9íhÃÚsåþmŸh•µuûËïi wÔ@äÀð²· {"Ó/0±;|r¨r&¬X©`o™›Û»òâ˜*k´ÖÙ˜¶‹GGàw’êÛ]“ÇšY(G¡£´Pžµ­»²p'C Ûœ¦ÔPV½a>dõº<Ñ´`YÍr¾ì aÌqÖXÃ{µF–Ã$…| -­…Uý’X½ý{ÄxRHìm7o-t§VjÞ)Ã`_z‰Í"éW¤çä"L%ñ-¹8ЖšQNä>ÂÇø“vøØÎÚ²=žÂ”p˜i-Óy¨}‚eúaf@>!Ÿåt\ÿ˜^¯ -endstream -endobj -1734 0 obj -<>/Font<>>> -endobj -900 0 obj -<>/BS<>/Dest(section-3)/F 4/Rect[65.905512 749.789764 89.131635 731.069764]/Subtype/Link/Type/Annot>> -endobj -901 0 obj -<>/BS<>/Dest(name-iana-considerations)/F 4/Rect[89.131635 749.789764 241.619672 731.069764]/Subtype/Link/Type/Annot>> -endobj -902 0 obj -<>/BS<>/Dest(section-3.1)/F 4/Rect[65.905512 719.369764 95.494623 703.769764]/Subtype/Link/Type/Annot>> -endobj -903 0 obj -<>/BS<>/Dest(name-media-type-registration)/F 4/Rect[95.494623 719.369764 243.243891 703.769764]/Subtype/Link/Type/Annot>> -endobj -904 0 obj -<>/BS<>/Dest(iana-property-registry-version)/F 4/Rect[422.173822 560.172108 457.950434 546.572498]/Subtype/Link/Type/Annot>> -endobj -905 0 obj -<>/BS<>/Dest(iana-property-registry-version)/F 4/Rect[464.009027 560.172108 498.245356 546.572498]/Subtype/Link/Type/Annot>> -endobj -906 0 obj -<>/AP<>/BS<>/F 4/Rect[137.988275 509.373279 186.413813 495.77367]/Subtype/Link/Type/Annot>> -endobj -907 0 obj -<>/BS<>/Dest(RFC8259)/F 4/Rect[204.670893 509.373279 245.628656 495.77367]/Subtype/Link/Type/Annot>> -endobj -908 0 obj -<>/BS<>/Dest(security-considerations)/F 4/Rect[209.159418 487.77367 251.995111 474.174061]/Subtype/Link/Type/Annot>> -endobj -909 0 obj -<>/BS<>/Dest(RFC6901)/F 4/Rect[96.753656 319.777576 137.71142 306.177967]/Subtype/Link/Type/Annot>> -endobj -910 0 obj -<>/AP<>/BS<>/F 4/Rect[146.410395 319.777576 189.246088 306.177967]/Subtype/Link/Type/Annot>> -endobj -2412 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2411 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2410 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2409 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2408 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2407 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2406 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2405 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2404 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2403 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2402 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1839 0 obj -<>stream -xœÍZ[oÇ—È 41ÚÔA`§ÛXð­Ñhî /u)…¶T‰¢%ÒNiåAv'}¨>ägäçö›Ù w‡»\R¾ÀZso³sÎwîgvñŒaÛ §8uÎ[£²ï_ _©Õq°<Æ›/‡¸²&3JR˘u6sVS¥˜W:ûù‡á|øÓgaûùÇáÞwœ²ìÇ_†a¾õÕÎ… š{ã✋á)6æ®|\^DV:{^°|Þ×ó`F]–ÿ«óë™n ÛÚðŃŽ×¢°j×Ïók^»®Ï«ÝËp›å2üeé±ÎöáÙ°²¿³ÔYŸvÌeÜ)ª™rNfg/†{Çã¯í?̸¤‘†ÄSÙÙÅð›{ä6™“Å‚:ˆRÄÇa¥óèÅ¥«GY»¡À>ÒxeLã0š» -€Dz»› dš:©M%ØQWy”Í Š§…þë#+FvT -n˜M -YÍȹï>í3hBXij—Nx©’ÊS£½¬4ýŠÇðá7ïq‘Û¢˜©êŠ)©ô~'¬ANñ^ËLÂZB"»ø*š¶ó<Åuè۸ו¹CI:\cPø9åÆHÅ‹)“è^Gà9Y7M;j¤P®TkžÇRÙ«„PIemäúi¬œ]9}óZÛc^Ù7¯Ð%½0÷¤3äu,Q\©Rs›eõ2Ÿª ÿ,2/AÌpg’ä«fŽ.SKµ‰µºËœùa‹¤èEºå‰@‰*Ä:³;wœJ²ïê¤2»—n5Ž®ž+  þ6Þ™F´ ÄO¢užÄXÛÆ’y„0¨ CXž µ`ì4C·v”¢¨jÌÖ2v½Ãë5Zó§þ8Šoâ½yUÙgxò DbåÕ(|µ*tdö“BeâY*ê#<ñ$zâQ(#m¹ÐP#â4i‹ÞåÜg±ïŸDG*Ä\‚qåèWú?Â[ZÀzç‡ÊIVÖ[t)›·§¦ˆ©Ò þŸà÷q'‚eZg¯4C– -c›ó¾¾”óª=¹BÕçœãÓ5í?&§Ç“ÇYð¬ÈŒaµ`b½°½LJnå2c,tc¯\ƒ#=uqŒòÖxKEk§©Ò^²´M[Ã+í -<¨–V »9£6oú4xÔ–B‹^‹Í7罸hÚ5'Ƴ]ÔϽe³x˵õ²jMŸÙ éwHümaj4œï fú  +Ec­¨4»¹·ÑÀa™½ÒJ¾é€äHÅ9›3zS),¼:ö›ó~GÙl¿ßço6÷ï Æ²á5£±-zglÒ$¾VAîaª £Ò{HÛÏtç¾Ë/S–Í—{X6iø8–¯†[êµ°©sÌ@Âò;Èk½At¸âL˜Âoÿ>;>i£û±ñZ$ªÐùÞ 7’¶Z…·“ž't1ÿÖÊbCƒ ,Ä[^ÜÃz|Tµ¿ƒb¥Ð½2\.Ñd°Þ±7㘧WWž÷²ÍPæŠ=» Ö®VØãŠÓhHl–géfÜä»V-c·ŸÖÝ˨:@±¨—M àÖ]<ظx1^¦ÃÃû¤ö>/Font<>>> -endobj -1627 0 obj -<> -endobj -2413 0 obj -<>stream -H‰t”ËŽÚ0†÷y -wÄ,(vH¦ª‹¹f]&¶C#Aå²àíŸß™AUY óùüçj;“ooÇÙ“¶¹™ÉïœLkûF™Ùæ9«ƒÉdkU1U÷bŒ6z´¶?Ø[cÕÑtlºÙo÷UÙ= â}¥Î½6£êÿ¢µ9•Õ—ÄåaÓ_¿?öëô`sÛÙÙ³­ììÃœþ½ì΃©ì|ÎZvÏÌ]Œ´Ò{q}´A0÷Å°ùX^QVºñ±ÜÕ"dºT݈´¨Ë0ò?^ÛÎ\öUa™„N÷µ×26? Ú®¹²)ª{`ÚÎðÚhÓ”Õé~Ç£òØ×õÙ¸’§=SiZ‡üƒî%»6¿×´Ó‘ìýZÂO¢>eµiëL™&«N&øÉ9+6,…^ $„v$TìHråH -³rüã+#„Ì õ'knB…Ü9óE ´!ZrP -Z-v ¶-ÈG ‰b¯\ƒ \@'D±·=‚¼M! -l ê”°%P†Èždˆ‰:ï· zDöð „|á„(z/hŒ<7Cå)åˆ)× QF1#Ê)J$=å 5Hƒ%§yFÍE¨ƒbÐææ#AJ)$hòù8(-@ð“)¾?åx<ó¯ûC©‡‚Ð?N¾|ˆä–%6%Æ'qÓÙH‚(£#ÜC? ÚùeùvôxC©cîkEuîκGûùdTß4Û¢';ßJY™Ïç_ÛÚyÑ_Žñ[åèuü`¹;c„ -endstream -endobj -1626 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1625 0 R/Subtype/CIDFontType2/Type/Font/W[1 63 600 91[600]95 98 600 102 103 600 107[600]116 121 600 124[600]129[600]137 138 600 140[600]150[600]152 153 600 253[600]285[600]396[600]422[600]436 437 600 441[600]443[600]445[600]447[600]450[600]455[600]780[600]787[600]793 794 600 796 798 600]>> -endobj -1625 0 obj -<> -endobj -2414 0 obj -<>stream -H‰ìW{PSÙ?çÞ›@b¬AÁ˜äÞ$„< (bÑŠ¢€$䥀®+¾Z·uZ-θ¸â«>èT]ñ¹[·ÛéØvgÝÛîtZÝî:cµ3;]í¶Ê ýn”ÝÕgûG;½¿ûÈwîùN¾ïw¾ó;sFE¡D"ß[S·9f_´ü.Ëê5+kZ³ñs„p,Büœ•M5-Ίåð*l!´9ëWwûþqrÀƒPø„´´ˆ²ó>F(ítRú›:ºØW -‚} ¡È®¦š®R‹ÞA(û;ð~ÖÊu³PðÈîâî¾–ú¦©vK›·eªÝ\ÓäM>í.Ùx´eM{ÇXò"”ÛÁ· ÜÖ)þl'تC\n$Bkß)}k…(ó!…G{ûS±ž{~´âÞ&”ÐR'ø=` -¦3P7ú˱{ð|ÿ…6¢€ð=ÄC2…ì'a -—‡g‡/ ?~K l|#š#ŽGÜŒ¸/ Â:ááo…w#S"÷G^ˆâEÕGuG‡G¯ú†Ø1Ž¾èŸF_þÕ8~}'ú -\¢m¢^Ñ Ñ½g‹&±êKèŽÙ³CÌ<E€§õþŸàðˆ¡ÿ"®<Þ&Üy2$™ß_ƒAÉ•qܔ܌å©ATObï·øÿèûŽNÁéس€Ë±?—J`ï B;Š…;>)¬…g&š…(ØYf#e ,”ƒ*QZÖ£ h#ºþJž§¦QÏQI”‘2QfÊFePNÊEÍ¥ŠgKÇƸ©‘#è‹–‚wͼÓƽ³¨œ)ÞÜÁG ÊCKÆÞâ6ó±‹cìØ(Ded?a7³Ü¾ˆØ ì†?v@™ðo®);äôõG -ÒOþÆe#Ú‰ö¡´ý=1×£jô"Z‡¾:ñer9“LÄWƒì•"D½ÊFa(\%&¬À&‰U"!½íçiûÚ‘µi×ÞÄÝïñ†ypw?ÑÅî®À¯üØE&¹ÅbµX˜tš¡iÆ4¬– !—ÈãââãâÂbùa|~˜\,6miÈÀ7ª†ÜnfrŸÕ\””¨ÀØãvT\ÀL†¦“±A­ö;f-õjÆ`d˜ºtl3§¿æËmÑiò¢ÈøtZµÜîÛm0èðè? ¥|vµ3«Z.Waâ~Ëf,ʲ/š™˜„ƱûTïm” ù*ø\ ŠÙÁ@iÚlNn1¥q!Æ›‚ÍŠÙÁHá”#‡Ó”Æõ¢ªF)*UãçjÕhõÉ´ªÖfm·üÚÒnµÖªTÉ©ÉÉm.ÿ€3ËmÒé6(½^z  `½Ngrgež€9ÛÜ·÷R”<É<œf3=ž#7MD/åOD¯ØKÎä5+*̨4/.Éé­ ]Ú›ßap-MJ1Ž_`1mõìÅF]òú¢‚êƺáÂÅÛ5‰r¼Ï”)ZçX6æ5¹7˜s” -šãóD“ÑO³\,¿ÈwكĥÑ/°DþàÀ#OAqõ •Ge‡àß&1ù;öqmtËEbkþt&¶r}ëÆîQË`¶Ü©H¹TNSa&3}æ‹ ÎØ22 Æj">aÊi—ŸQÛ¦Mã蘘4šö¹òý´J/|CP’“3à[¶Ç‘±p7oII‰•™™½•KÍÑ_%â^ ŒÈ5‘‘áëhºÎf[k=eé°Ù¼4­K¦éÆlßÑ G¶EoØTXØ_z¢¬^á zƒcö¹\Èé%È?;Ę\¬s— îTö{jp¨à ³/mÀ@?»‚ã`ú'†úK¤À—4Äñ ®œ"[‡qo¸ÿñ®ƒ©5ý\ÿZ¨ð¸àÚDX<µÂSj×*&—ŒRåwåÔCÕ‘—…άû¼§²³ç¼áQ¡sV›ªeh–÷°ÝáÌwfô’¹ñ¹µÆ›0HFX0BˆÏßfocöv â¥Ë—‰#ì2ÒDldï¿í¸ÏùÂ7 5|y0Ÿ\îf¼i„ÜÜÇ“@upïá{‚*†÷ÑÜêäÊ$‰„'ˆB÷'gDŸ¯ÂQ¢3wƧFD>QÄòÈö {8Ssþ¯€¿3T[À+É!Á”ó"É^¿t‘$̼áÇ?£œâéñ5ºßKåÚÞßbít8@, ÁÈÑiÙbétØý°éµßî脌ϿmÀo,R×…™bów>âUœx ®gÖ)•šùî¼3¾@ÅùÏÜ­Þ¨Ñ6;‰2v0’h–ëæ6¶X,×eû=V*” s\^è8Ôü:¨áàzüoìS–ûx¡3ý)‚)Ë8òxºFÓ`ÉkOI± .“ó]…¿ô/ÌÏ_\êr*M]c0:a[f¼fWMëïeyyÃ+t»ËË]¹¯Ï7·ÿÅxµÆ6užáœsœ8iH|9>¾ÛçØǷر±ãË9¶ãø'ÎÅI(#$ N !ÜBHJa[§RuSC!LÕT:’N¢-£$´+­#­ë  .?ªµ Mª´_kµÓ¤i[{O.p ª´ü°Žï;ßó>ïó>ïû¹#ÈÁÚ.­Nc6›F’ýg‚‰FÇýëÞô2)•È¦×wECÝz½¾ -R|'Œú½Þ7ûû§¼5)•ÄNR½]x}ueBáºÁ)xuù&rõÅÒÙÙ‡ÿ,–ru?$`•Žó Œ/!ŒÆø<ba¨ÅdÞ›Jí3™­ˆ`Eëê.íÙ})mã³Ä¸62¬Ëu$ŽÝdú(QŸn«O|8§¤ËËpJ)¸ 7* ­âóÈëùÏäDþó`/ךS‚(¬…lfa-ÀóÂH¥À½8 98ÜÇÃÏ>,îò//Œ””_ž_,/Y”×E–ÿ äµaì{ø a?À{ºà=§Öú+É.ç¹èXþö=äÝ|û¤Iü5ß¼{›@Ã9WΈ6æ–п¡_ÁîÈZÕ—®î°µ'ÿñ]ä:vC®…~>xt ÷Jb§aý!XϬú'Ì@7¢n@¿EíBoæ(vmFðÚ³Ë?Ÿžáêü,ð´ù¹x ^(t¿ÄÇ«t/OkÁ—ÙšŸÊåæ•<­–¹×»êØÄŸ¥²D04Û»ëÆ‘%ˆ… ï0L·Ç>‰ÇS~{j«¿ß^Õ Å*ò_À4¤Þ~*sQÌZ¬ýbçKä?=¿r9¬Óu(lŒ*Z½FÛî鬮v¾¶-9awÔÈq¼FkŒѪ”I›=¡4PaXÇŵqÕ—A-×sºóú×»‚¬Ðº$O™V½V£N:Ü“lÆF±Šì…2©MîoŒŒTGº42"»¡B°éÓ.÷&ŠòH%ŠÜä®nÒÙCÒŠ -TBtž‰²=”Ñ"'$uhèaÑ1…ELõë‹­Á㽄»×æߪ•+T -EÄ„Ü3Er•Lªêö;¸¾ñx!O^È«‘ç«ë.ÀËQŸÕ=Ö5A›HÒdšØÊÐt²…ç3Ç>ÔÁ_äÓc[g#‘fdqšÍ;^i`™©”½ñu–i° ]žÍÓ~_¤»¥õ‹QûÞk-­ÝáÏñ&g›VGq\sµ«®Ü<‹?9]m_²ŽJñ¯dã©:–=÷Âào¥²þÓ;çØ`$k4ÑÚ{ŽšLGûÚöÓ&#j!ßjiÙ’L*)Ê}YßÜÜ|ç$ÑqŠ Ä:ùçR[¢ÀIÇ/Gpd„_Q1°>N¦ßà–!|MÕ«½=1ûm`ÌûöÎÖŸV;»}¼¦¬uÜf­â¼í-¨ÉÑÜF¡Â¸qù  ß½ ®\¯.!óù´‘ˆÖí«’«kT–v[æ,ÃFòß vì÷§ÒÉ!Š$‰Ê3ÂòbaÜfv§OAô'ò[º•Jî(ÈGð»Šï¦ZÈC (Ðôë÷x¦:ããn};ƒ?,¤”_¦Ö"4M ÄrèûûÎù|èÑéêœÔY| Ußß1Ç!_Uwƒùiìõü¹¿0,ÊÅ6µºªB,„æs¹9ìmD묭uªì•0ÅTˆìðî»ùV¬Þ­+â„ïþñD=>CȈÕhìõUzÔŸ¤BåRhCäà Þ °+8õQ¦m„¢4Šco „(Š™ÀÜnAÑ9#§3å˜\„øö“Oß!o|Ÿ"W¾Ëϼ´´„ü7/D_D®åϾ‚]|X„Lr{W¸½e|fóPR4¿Ÿ›+ÎÀÊ>nºu†ÖîÙT?dµ0„ˆ’‡dH.WSju=:ærùjŽñDý.³%€‹Ìr¹"; ‘UÇVîc4g.~Z­¼Äù¹®Š.åÿþ?Æ«=¨©ôŠßïÞ°®/„ðJ€ÜÜFC}€e­ºÓþѺm·í̺kg©vwgºh¶[g§ÛYVrÓs\¡´3IîܹßwïwÎïüÎ9¿ƒ„&¦×¯Z+—ç%¥Æ™Ò3˜tE¡P(B§ØÃ~÷Vh¢¡?K­X° –¿¤|Ç‹MHI^塉™pf™‹ #½šŽ›sýÜ¢çÒí¥êtIÀi* -…\Ò¿Q±õ,”Ýéoi?5MH‹»×áB½;¯X,¦õeðíĽ¾=gúÈèG·~Æ~¼<ŽýíÏá廡ƒ½ `È‹°w9·wÞô\ƒGžß!H»ÜsEø£óøÐ¥K¡-dnhåè(~=´òäIü:çQ{¤òæΛ?ÚØ/?EGÙÀ¡›¨>eèè}<ˆBCŸsXá4žo{Ùbò¼ ½EqŸ1=ËШ¯°S©´ÅãÒØÇF;ùú¤h!œâ’-ѧ¤/Ïg‹Í™™›”äŸCy{úðÛO§'8ÓÒ”>DrƒbH:àœÈ܉РMèM¼ú0ÞÚEœ"D}ǧ½6„a6Qbx@ÕTb6N̦ñl–H¡±ÌI÷øÙ)‚ø$ÃØ×:;®Ù ãpŒut^µÛ™Ð -%ݘç®ÓŠ¤J#¸ìµb©æ¸W£Šƒ“EE%%EE“Ùœ,,.^QT89ZíŸM'õr…L&íð³¨eD/£$…h\X±¼¼ ÆÇÀt-“Š£y|i³4tõòÆþxjç¨$T¼;à¤Fæçù;ãßœ‘,:´ >© -IÑ«9õ2i–Ãj½ÐÜÉùs›–Ð-…ö1E'¦¦V2,=„.Ùw:{Ükß6›~‡ã\µ·].S*hºÆœµZ£m/}u¬Øþ1V¬àtÉì³frá¿T—ÿÇR½²ß×¥ÈTË%’&—«Y"‘ß*t:ƒµ Ó™Ÿ$L«)°U©LnîÙ@ã›Í}>VgsÔˆ(±L"mÉ'ôÇDUïõ5ŠÅ”„¢6Ykeg›AÙŒ4š4š¢¤”b•²JÙxBï2ç]m­¦(:#CTçÎ;×ÙŠãfˆÃBlID?rÒËg¸sâˆS„ºñá[¿›GWÒÑcâ×ÓKÛØ«hÕ~ÜÒ6ïûJámÈÑø$ó< :ñ?Ñቇx>y;E+x4ù­R©œÓMyÛãÆ–:#ë»/[-;ÓÆÒ*^âãd‰âE‹TY/z‹w©²´{_j6 …næúæö Æ•/KAû'8ŸúÁ*)o“c W/¹àsFÁ9-;j¶‘˜Ù¨#Ö-;õ¯ÊÞJÆ;ÚÙ´Z­:£q¤Í°AžéMq»ì7÷/ûÚÓ@Q"p¢Ámi’Ë5q¹2Ù:ÞøÚÊ^ö̵[ï•ú«Vz=Më/{½«!óLµ7ò\Ål¢E«ÝÉøwgeLFã`­S³B Hç¸ß qñGó#ZŒ¤:“H]üÏ¿ùìw_CîGпƒi±¬öÍï`1Ïï甘íë,~þ¯ç¤&/7w¤zãi‹•IVê,U"‘Øïrµ—\ÎBZDm°ˆ,I:óB"mr0§#ìv4K¥ -1hË*“y½ˆ‚ñB´Îl®¢DR2»fÐhäð¬1JOr²_­is4œœcÊ>QïhÕh -’—e&éö„κêÅb‰D,®w9š¤’ÌL8o¶TsŸ¤D¬ÖÀo)%®æX0Cϼƒebn¨¤4?Àò9rmîh+~žÛüèÚ?ñ´àE^žåBggÐáÁéVK\îLæé|Ö÷Ë=õ"J$¡Å nk£\¦Ž³IeëÏ_¨/Û*‚žž”yW—{}?m^wÕç«HJH0¥ãÕ—‹ô™M§ÛÍø{5êlK¶i¸Î®-¦e`8zþÿ=°€À–F§»Ù³~ýör`£Í4IÜŸ–³ohœNŽáhìÞ‡ý)ÒGL4GlÈP¼ïÃL]WÙ&ÕØO*Fò]w¹OÂ'P,×¥³g«'…þ‚ÅþBÿŽÜò2›}õšpÃÞ|² “aµ ‹Åj1Ñ£‡ìá€çrx¢ Za¥ÛqL>ÞBB}00™ÔM· q+p=1‰È­p'&C®¿$EÔõy‘^ ÖF”¹NCûÐ.t ½Ì;ÚÖËŽ rW΋FVIli  N/àr¾{ј>×K\LÕ2i}Ž¹Ã W”ˤÞÔdaº@¸F“áÉ ífè!25^ºð­é–Öq_~pµÑîzgcõƒÞ%û¾Ü´ùš[éMÞ% ø|×[Z§9°¡|ƆçJ3ö™–œW¸_´ZrYX®•Hs§ANåSªUi TJR¢O*¯TÊ 9æˆ ¾…Ç¿ÙÒvµÀn”Ý×ÚK>{uIÏÇUuçÜL c›°.ß7ÞÚ±a”ý aŽÙ àP9¬1³ÝèÍÏyþÖ?ó·kv‰gvñAÞAÙGƒ_|úcöO펽 {<ìâQŒƒë¿(gÄHñx†eHÎ+šñ.R>>á;Ë“SP{wwÇ¢D~…Ÿßx(K«z½¿ÿuZ{ˆ=Ò…3ýng°ç=ö½£Ž— zï"ÊO°|tàå´ïp°ì\žoÍ,Ì@†(fÏ7ÍéìYóçÔ½(ÚÈÃÒj² m¶øWm§’’ÔFõÁºÿšDþb.Å“)w§êµüä”UO»ðJç\Y0¿ILSh@¥¥6ØG×\ö9V`´Þð’ctåƒ kÙ2eªþ•Ò s·ÞÀ“{°#äFòF„­qQnäñ_Ýb·¢c·Ð±Ùµ7YúåMnžDm¤’¸ÌF‰ÏýIåtÑ ÿEï¾ËÖ9ß÷‘(’ÿS¬gñš ¡3½1ê©{°ú(ÜG|]%û¯½:Ûº£†ÌÉ -ÿ•‰(C#V‚ý›ý*êºÂ÷¾Åã…xf<ö,~ãÙÞl6ãe{<3ccƒñnL¼$ƒÁxÀ€í¦-( KZ*³„²9Q±‘Q - …ÒÐ0Tj~´EJI•PÚT­ÚþH›4‘"µö<÷Ü7gl ›P*îè›wî½çœ{îvî9´nV68Ãjfz¼„ ;°‹·XVWTt[ˆo¶@Ùm¶ðCé -¹›·ºrRDJ‘ŽoVaZx ºÕ"±ZyBžž.²zä -¹ðåï]aN7zìŽü|‡½'Ј8éˆ|¿ÁÒ¨9N­ Œµ†ã4ê@,³ñ3f ãÌ=»Á8sÐdœ9˜Ë(D{ÁåêÃUçã×…gœ%>o¼Ñ§`JP-Z;øâh¼ä.ñ$jõß2ÆO²ä¨^%¿‹mô½Á¯L¼¤ëHº*¼©ØÖ/ùË……5¯a'/\ïtÕë9£Ë™»¹ºåÅÂB¯R® -Ú¬îÅF«Ÿ /…°0M©(óèq¥ÖËÙšGAkÅ\³O•¡JIKsuö9©©x°í€ÏÌÖÉÚ¾ÛÞÞq´l6WÙííÅesó<®ü]­Îz[þ2O¶­>ϳQ¸j7›;¼ªoiÌÕ -‹3Ís”ôÎjŽ3qYê€AS¤Ñd-³V™u^¸åSŸ2{Øó¨ ÂÚ—L¯%KʸÎëOˆ#y4«Ì‰i‰Y©œ‘_ã/?VRÔs\'ÙèË´ÚæCãÝBû%ì+mËÑçdërž ¿ý(Üe²ðêLÓú:л©ÁÕl6>AÍ1¨L­î†«Õ¥O:ì¡L¿‹3Tª'sî }6™ã[dŽ`1)¼dφ/ÑcÇ&.ÓcÐúñýÇäôbà¡ûb]¼H)£Lpòï´X “ÿ&à‡=eìâ - l¦ïE¼L&]QX ÃØ'§(šfiêº@.]Ò»7/ے̲ï½Ä·çiø/ˆ~O.iro¯/ˆøqÉäò{ÒÈ)ƒ÷˜˜DNš#ûvEÂsñ͉Ëøw‚‡Ø³ø·¿ô‹3Ü6qŸºD><¹”'\Ã’V}\k‚Ã(†ê´g'ÃÂƼŽ‚Šngˆ–'º[T1Á؇²9LR’Åj\Z†CÂo"Ç<^O†R$ù -±¹´+QŠ"sUvæAÀQŠé:êƒãîóé.àºàŽËÖqÜSAá5ŠG&.û -òŸ[T³Õår1gs•¼u¾Ng€;þŒo•Dn3Ô¥L%áíhÚ70Я뻡¾@¬›ÄúV¨·ˆõ<±~FXÁÌësňô{™Fˆ;ínöÙµÔx¯ñŒŒ—”ÚÖ>È[F«u°­´‹çsñÙùÁÐØŠmÃeP·µý(®Ágq¾Í¶|ç‚Rÿžê¼…C¥þðд»[öûµu¿^—·þWµu!{×¢|H¨ÀxbJ^» 3¾Ž\ÈÊœ"-‰…Î$a1à À:À+€ŸÞt†?¬”x.~Øè•ø:[õ€=€j@  l¼ -8+ɞ݀£€—¤1®Þœ“èeRûVÀ™8®‘tì¼)ÙUèTFïZ%Ûê¿æ2ø)àú ØýÁ¬:Ø?f®S–{ûÄ=x6ÿ—c5 ppPI ÷Û÷Ê 3Ÿ¯Mþ)Ñ®/²A╾ä<•™Çå›)ä>âñ¯=ÊñU{8òpô<¼õ]'¾"ôaýã|%»äÆoÍj;)}ý³êkx†ï£ëä×±áqy\—Çåÿ±øÿsúîë³¥˜·Do…hsÉDh#Ú‚XÔ™Ù̼„ë2ô éaR€~§1RC-NS(]•hÑ%šAvœ!Ñ,ZˆK%: Yñó¨õ£ô]´­Ex6C¦çAEÈŠz -ZV÷¸V6L¨þûDªäúQ/ð¬%+Ð |×@ÛF´ êNQãfaXT¿ŒC8A_Hõ£ bk?ü"h=hêµo‰BQûÝq7H£æ>Àš€Þõ¨ ä¼ ½Hü…P5j‚_5P‰’wåògI>h®3¹Ú Fæ¸Vì7ÍÏ$ιøE-k€«O\'ì±8KÞY3y=tüLõ¢n„fç¬äA$µv±#¬Œñ/ý{ÔCÅ9R¦Ò.ø+¿[«njª†šÉ’•¼2v¡ä•Ô\ÂÇ›` &ÈžS|¼ÿ 05® -† -endstream -endobj -891 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[381.000238 692.590936 439.094477 678.991326]/Subtype/Link/Type/Annot>> -endobj -892 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[445.15307 692.590936 504.167963 678.991326]/Subtype/Link/Type/Annot>> -endobj -893 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[80.905512 564.39367 138.99975 550.794061]/Subtype/Link/Type/Annot>> -endobj -894 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[145.058344 564.39367 204.073236 550.794061]/Subtype/Link/Type/Annot>> -endobj -895 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[278.891108 422.596795 337.906 408.997186]/Subtype/Link/Type/Annot>> -endobj -896 0 obj -<>/BS<>/Dest(figure-44)/F 4/Rect[65.905512 187.242186 109.581293 173.642576]/Subtype/Link/Type/Annot>> -endobj -897 0 obj -<>/BS<>/Dest(name-example-for-the-personalinf)/F 4/Rect[115.040033 187.242186 293.718012 173.642576]/Subtype/Link/Type/Annot>> -endobj -2421 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2420 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2419 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2418 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2417 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2416 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2415 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1838 0 obj -<>stream -xœÅY[oÔFžhH‹TŠZ \‘¦$%“¹_Ôµ4!Ò$B!¢U“.´EêCz¿Û»ö¬7Þ$„b6kÏxÎùæœ3ç¶Ï®¹ðå§ÎykTöûëîÛ.µ:N–ßqðmOÖdFIj³ÎfÎjªóJgïþèîvßty®w‡Ýùœ²ìðÏnXo} çBPͽqqÍA·‡ ¤¹+ߗב•Î^,_ÕæÃóî,˜Q—åÿ«üZ@æ„kÓ¶2}0›ÂñZ”óVåùUþÌ+ÏÕu•ñ3†[¿(—á_–~WÙÞßîöõï,uV1®sgŽ -é…vÙöëîüúòÞÊâýŒKiH¼•mtŸÝ!ë3‚Ý!ËdŸì‘-ò˜,‘rƒtˆ!»xZ#=²J1·E6ðâF~ÄüEk¾­Ú„s5ˆzQ÷!Š:Äì -‘æ­Ú%gœjNQƧ›5¹“ê=}¼r¦OMüç*¬ò%™&QDY2GnŠ‘d‚üz¬i'©7†I]h|×K2 |´æÂM†ÛœÐ<žŸ&èåØ;5‚ûoÈyr…\¨ÓIE`sR–;•÷UßЫDëSw ï¤5g·xÿ—B(ËCó]œ­{„cããScULPÇѪëíxÆãqOóˆŒHrj¸Á’1¥— rÛ,‚ÛƃSò/:èâÚh4Ð1oYˆ`—"\‡¨Üç4ù¦·¿½îÇPºóTpÍBŽF¾€P¢AaÀ=QÆ> -Z gsЭÇ飙(TÍKÆÚÒ»^Œ¯Í&zær3¨áñâØÑ(ŸD\'Áxº¬(ÄFn=âY5ƒÆwiòu|®†t9qîY†–«„\Õ»&KLHÓµ|xIB]dVZ­Ç÷éeéÒT¬ ü}žd-ÄÑ…øf^›„Šå^:‹2¯µøî -›Ž+–†…QBÚQÆ-·ªØÛ––Á%TT‹äÜ=ˆæ…QŸÅJ¬6bÙTZÃ#0¤{kyØJD ¿â™42+¹ÌÁȦ£AíƲc7²-ŽmYé•8ª(C©T]—x {Ð’7 %¥ÎÅ2h-²Ì«¦!™ -é‚™¦UWVö”—d¥ 1“˜³¨ùêÁ¥Âl©°Aù¶Û{ñ^#³0›+¹Žv¬Q_ ô±2lº**8ja`ì-Ö=»`Ô8.¤íÛh¯1Ê|k½Ôºæ5o~óšw§è6ô"Ý:XioLË2)/“+'õO¨œsƨLËàlTA…=æ–7ú(Õãßÿq”†ôÒŒƒ¦R}s¬4Gm„WI0­l¯ žÃÖUµ½aÒR!ß÷(““X!íˆFº]?¥‡¼†c±¥º¶ÿÛ?Úýé[á‹3[i"~Œ~Æé’«šUž%ÛÊ^“Œî¤½ƒ§PÎ…ì 6ŒQÉ…ãòƒônB÷] @=QïæêÈÞMnKïfèåÖÞM5Õ£Y\Lk[ «£š5A~H\k¤¹ˆ[5ã.ûß5Fû@=(+½£5iŒS8*Þ:ÝÚ¤ÎÆîJ{ë¨cFé¤2Ù¶Ö‚¹÷HU\em}Ž §ñÑ·xÂð&¾Â5Enb`sÇ|P'È$¾Ã˜%ß# ™ØÇ™Ï?àóîΓÏQ<ÇÝ'˜¹Cr‹¦ÀatËÈ -Ä/[J®†ófä8¡ÞꃅÓÁǸÅuˆ;®Á ÌXüõ»~4SœiÁæL'±áù¸ñ¹vÃp´nq_ΓÁ }do‡ñ—£i†vŸlÇûÑKBO$»9âõФãÔgÓ^ó¡‹'”µm¥XîívúÕë]|?9h¶ÉoœÍ/aõ¸b‘¦xnÙ¸Õïµ#«ß:¹Ñ›Or%î©ôŠûOÕïW•ÇâÊQ„÷ƒãTÞ°è «Ú)c»F: ñN’/p]MüÑ $lØYc oe4”Î0Là<·rbd!†×X \!ŸásíxÌÂÕÖR¡­Ô¼‘‡‰ÁüQ¬7–ÉzøÕð/ü™'[ûÿÆzn©Ðíø²ÔŒr㬖ã0/Û©‹€l‘SÑ®S´VSá¼Ñ­»–ñgÖ<“ú25Ç^÷?¡óíN -endstream -endobj -1730 0 obj -<>/Font<>>> -endobj -881 0 obj -<>/BS<>/Dest(figure-42)/F 4/Rect[65.905512 660.755545 109.581293 647.155936]/Subtype/Link/Type/Annot>> -endobj -882 0 obj -<>/BS<>/Dest(name-example-for-the-keywords-pr)/F 4/Rect[115.040033 660.755545 279.098139 647.155936]/Subtype/Link/Type/Annot>> -endobj -883 0 obj -<>/BS<>/Dest(section-2.8.3)/F 4/Rect[65.905512 635.655936 99.092035 622.655936]/Subtype/Link/Type/Annot>> -endobj -884 0 obj -<>/BS<>/Dest(name-notes)/F 4/Rect[99.092035 635.655936 126.529291 622.655936]/Subtype/Link/Type/Annot>> -endobj -885 0 obj -<>/BS<>/Dest(figure-43)/F 4/Rect[65.905512 221.425233 109.581293 207.825623]/Subtype/Link/Type/Annot>> -endobj -886 0 obj -<>/BS<>/Dest(name-example-for-the-notes-prope)/F 4/Rect[115.040033 221.425233 259.541742 207.825623]/Subtype/Link/Type/Annot>> -endobj -887 0 obj -<>/BS<>/Dest(section-2.8.4)/F 4/Rect[65.905512 196.325623 99.092035 183.325623]/Subtype/Link/Type/Annot>> -endobj -888 0 obj -<>/BS<>/Dest(name-personalinfo)/F 4/Rect[99.092035 196.325623 164.545649 183.325623]/Subtype/Link/Type/Annot>> -endobj -2429 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2428 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2427 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2426 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2425 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2424 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2423 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2422 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1837 0 obj -<>stream -xœÅZIsÇmåà㊶Š-k’¨´ÐÖ°÷ÅJäDá‘w€”L—KN…:PJ•œ¢ªrÎ?È¿ÍëoÌ`€P´913=ýíËë&"á8Ç/¯Eê}pV'yÛ×O¡Áâ›n¾ëãÊÙÄj•:Îw‰w&Õšm’þÚ?éÿ­/’xüðº¿öJ¤ܧRi|rü¶¿¶;xù|ãY"TJ4žJŽÏûßîeÖ>GQ‹¦—Xø®¬Z¢Þ8äUè1lw?Ï´u(´4mÏéÆN~µÁþŒ³øØ'¸.ˆ¼ h8ç¤G)™.Ò(Ñ” ô@,Nþˆ) -½X‘La´Ø -F‡$À×IJNvI5*¹Ö²òËe_E™fJô&•°%€ ÄUsݨk ·éM*[Ôp„±#ú;¦§NHÜžWL?ÌG¶ñÑÈu|Fî4lÄóp¶ˆ•'¸ ¹ˆ×Ù RýËÒËC"Å9¤eÁÐË2?¬”ràl€±ìjT‘·´Y¢|2P)’ÓÕ…7& ~t²-|?3b#–À µ5ºQÀtMUÒG_ÆW5õç9K*“ZI®²*¹o‚Ð -Ñ¢ÜEu>$gœÔ2rHã¹_æ~Ö¬*œ¦z¼_.6èl¶Š: {,²8ׯ*LWhH ::X.Ût:BCqr©œ1F974ÆQˆ19v?wr4j´Ë&I<±ÑV^¢W6qœR¬”³öpÿ%i¶I¡3ÈëÿT#“Þk©+›Æ§Ré„v®=¥°G=U×Q3–Ȭu(¢‡ùبù‘Tì"û¹ {lTψ÷òšŸ2º‡Tš‹8Sw%t*¸eQÿ\Ö@ÍÄ¢Ý €ê#–oÏ+ŠÐ:¥F¦n¼ó ÈqD mxöý¿ðUíeÕ¦P¦ÄJ«~YSËì1u˜= )­©’^7MÊ9Ù‚R€ŠVSÀYŨžà«¹ã ­ÓXÓëQS'²˜3×s Ð*æSÒŸºìÍØ(Cå6–aWÏVÌðTYëm‘ƒ›dß9ZëÈEÜ ÄŽ)4XZىNJY™ r`3$ΩѪ*5ب¼@]Q¼l9÷(˜28¦\ØÇ:¤ê‘á«ä9Æ÷òrQúº†DïNø@XGÔ?ðkI0~mƒ,úbS‹%¼ukù:>¯è‹Ì0Ç|EF(<»žàôÉXÁ H¼…ÂCüâ ˆÏ^0x›ú€ïZz=¢¼9¥ðë±[ìúLÎü_ƒýè€ZzÇÕâL{yU:%›Hÿ,©Æybä ;Ö:¥Q6VÀ‡hÙ*\Ÿ¤eAa+/´'-ïÖëÌ…õ$È&kº9‰e¸A¯ç¡ìmx$Ë¡*íÎÂJTSjl… ÔŠ}«Z=N©NdûÈAµ/O&Ä==o´k¨;DZ¶¬^Yÿ½cßÄçÖ’AeH% ²óHßÅÙ_zÑ­­L…àÖ†æöOû»ûÛI mbÅ‘¸–×]–©‘:2UqýX[^\%Ó¸ñJ£Àõ*™ -›ë¥o Ã+eksÐQ½:Ö™HO—Oay*ƒ -èv ³1±üÞg¿b·±þlÉ‘à8JoXœá.«(ñJ(m[L¯Ðƒ•¬llÍ-Á´^¿%P¬‰Õ%±+t#‰ÐF(´-Þ|\jÓÎ[€ìà°p2Û·Ûùãxw¯£ “ôÕV\é´÷*ˆ6i¸ÓZ‹ðñ(¥ÓŸ?{ȾÉ[Ï^ óª-j^V¹ Õž×HÀ^Z9äTîeCz7Ý;®íƒ[ü¸Â;ÿç´4¾s"i~鋼ת”€é§Õàð¾& šhJy¨¸´Fç« #5@V£9Êob´‡s¼”YÉ?x1zþli”Zú ^çqyÁ>‹±‰ß{ÀL ðzŠ;q•à삽b×Ø?›kª $®E²úb±x Ç*ÞÓî©XR vÛÊÔbú½(ÐÝœÆ"ÿDZt»`ßͦxB¡sâ]è´º„²"Â7ô™Ñ “‘qìkö„…9YRå¦è˜‘C‚®FE3Å"ɯæS*5fŠzu)Ù“Ùd瞢âûÙSÞA5Ôx?OTøVˆ†¨Ñ¯_w{NT|ŠxSÂâ.¹£+,×€SmÑ°ˆ/ˆ­›iúÿ‚ˆf_”„.ÐìïEïÆZ‹ ö£seTkvfÜqPù¼$ŽH±÷-ý}†‘øŠî¼ÂDzOÙÅlvˆn¦˜džS¢@ª©éõ{-?_Ä’ñ=y³`Lýª>ÀQ¨úOp~i—ฆ%ÇZ~¾Æþb§?¿!Q(L¾Ã½,õ¯ÀSö;ú}6!îoÿlžy|Hí´Ò4;EÅçÆ´_Àe2n÷6ÈaÚnŽc°~™/\ÇÙˆŽÙšÝ›¦/§™³´sX'†4nÅ…ó*–u¸ÝCÜÆq³ ç3P6À~¨]¢“QkWk9NÖj¬~¥ÓÝœxu»÷û%>·–cÿÛŹˆ†•SyXÚ)9"<8`»q'öÙÞúÙù¿ó½ÕÃ%mix*¬wX}.À|½ÜýÜ"ðéÊ-£MÄÙr¦EÁŠÉšN­ãëàíˆßn†ãAÿ°‡ta -endstream -endobj -1728 0 obj -<>/Font<>>> -endobj -872 0 obj -<>/BS<>/Dest(RFC7529)/F 4/Rect[120.220453 616.993279 161.178217 603.39367]/Subtype/Link/Type/Annot>> -endobj -873 0 obj -<>/BS<>/Dest(example-anniversaries)/F 4/Rect[65.905512 487.395623 110.571527 473.796014]/Subtype/Link/Type/Annot>> -endobj -874 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[444.38891 473.796014 503.403803 460.196404]/Subtype/Link/Type/Annot>> -endobj -875 0 obj -<>/BS<>/Dest(figure-41)/F 4/Rect[65.905512 206.521404 109.581293 192.921795]/Subtype/Link/Type/Annot>> -endobj -876 0 obj -<>/BS<>/Dest(name-example-for-the-anniversari)/F 4/Rect[115.040033 206.521404 298.078119 192.921795]/Subtype/Link/Type/Annot>> -endobj -877 0 obj -<>/BS<>/Dest(section-2.8.2)/F 4/Rect[65.905512 181.421795 99.092035 168.421795]/Subtype/Link/Type/Annot>> -endobj -878 0 obj -<>/BS<>/Dest(name-keywords)/F 4/Rect[99.092035 181.421795 148.036859 168.421795]/Subtype/Link/Type/Annot>> -endobj -2436 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2435 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2434 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2433 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2432 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2431 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2430 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1836 0 obj -<>stream -xœÍY[oÇ•È Ä0ÒÔA¹[Ô°l!ÍýòR´.%Ò’*‰²HÙƒ )¢<È´5Ї¾æGè7³;{§HFP¯©åÎÎÎùÎí;g–ÏŽ½prŠSç¼5*ûûÛáCju¼™Îqð‡!®¬ÉŒ’Ô2fÍœÕT)æ•Î~üvx5ü~ȳpüøÝpÿkNYöÝ?†áyëËG8‚jî‹Ï\§8°4wi¤¼¢tö¦ù¦q?\_íBuYþ¿.oÈ|áÆm[»}½Û†ãµH÷#¬Úõ›üš×®ëÏÕÆa¸Õá,uV1®s™W™á–±Õ&–Q« W&9‹rþeísß³Ëa(Å¥²ÁB»ìòípÿø/óÓ³g—4®!1+»¼~ñ„,ž’rD^’ÙSÁž 䣧_^U+åÌIÏ[ëâùm2hMÖâŒå=“OÈdDÎÉ rE]çø»ó!ÆÏåK|¦4Àõ€pÌš“+üãJ /ðü„Ì0¾X4…+¦¨gJ8ßžã<¸\ÃBS¯Œ16ùbÃé4$«åYû ×­“pÔ o}ÖÿµÎÕ!¹®€É°µ5@ØÞ{õãŒS­˜qŠxjSÐÇ‹sÓW³çÏ2.¨‰ÿ¼SEÌÝ„¨û,DC†ï_“-ò¯V ÕÖ•’"š˜µ…·pÜ?FvpäcÁo°à6Ù#°æ†âÀy¸µóùüWŸã©Œhr³\œr”ii•,Ľ#_-Ÿl9nU -²ó#|v ‡®VΪDG¹}bW?ê5¼t«8nÈc €_§‚ts‹6¹ã´ÑLú΢mÅ‘]$h0÷#躋Uˆ×»–žï–O‡Ï¹]Ó y.M<ímé…`{Ä›Æ9˜`7@^íaÂ׎SÖñ'’‰ZÙë”zXü=üSMÃ݇1Š÷wï6“:O=\†!$ð:V•ð/g5½Þ%BœG Å»U\IR‘þz>==?Bšyÿ1¹O~‡O»b<«£¿i.€GEÂã8ÝŸ€ú§±PÄbP+'¡P4—• Ìc­¶»l AC …*iŒ–+q:yýü ·tZr ¹s`™Cúa‰o´“Å7ÿÆ×I¼ý¢ £Ï16Ãùu\æxâ">•*ãF'Å -ò* -xÙ#rëå,Îav’8ÃýQ¬Ÿ÷ëÎNýÈœ­œ¢Ú)çä -;p - ¯¢æhn4àä1ù¾;g± Æ„_GMêÎ_\wÕ¹“*Ú~’!s™X¡ÍcÛ½à\Ίžåý‚2Ì"…õ~¢Ó(~ÜLw­?ŽAp‘Ûô½[ÏÚ¹2ÆE,nÇôÙ<ºSÜù -IuÐy×—wŠKÔx˜çÒd„”8à [÷Kÿúï_wïѾ¡3+t«hmu¯çwKW4ñNsÇŒi²skâéßôpµ-žåª³àm™Þ\$´›Z&{iI”ÆPí9—0Ž-h3Òy˜hî9(¶)sÚœÆÍÅ$¢žb¼NΉ€ó;'=[”ÔÜÊ&Ó¨8=ºð\•àÜ…‹óòÌAăh­<ŽÆw-Þ$*‰î¤S<ÕÇXo–°g¨"äoE¥@Ò(*—d%Ïp\ %Êè«UÛ-CëÁ¤‘=ÄY3þÈèqŒå«ùWQr‘¢íW -”‹¼Š‰ð2|oíô¼E jÉûAÀÆñùž:öd™}> ÷0å$ ºêZ_„Ÿktú->®)šø7éÔ—ˆ 5ÕšrÐý`3Æ4—]9u+T…¾íDFÑèé±-qá%D¾ÀÀÌ¢©·‹}u5‚T¨‚±y—*Q†!â5ó)#¢ª‘;Šr`Ç…Líëë˜Lã"r“¸æèàç IfsV¶J[Íç‰Aq¼”¬äp)ã%1,aWY±=}¹è$>4(^”LŠr8+C*v¢­ØÑYÎ\‚” “HjÇG²àqä…\¹Yä„z-íB(걆 -”Á%ciŸ|QŠ;Ä÷ôB(·¨#6ºìq´D_;’uR³SÙoW›„6Áôõ‰úû{…)-×Ì8Ê”vuò)Yn^˜9§Ø²œ×Ø^‘[¦[­DÉí£V›0ŠçðÂ,µöãè´Ü¹Â'ee[ÂC÷¢ç5~¯ö©KIö«˜"FÃR;8n‘)ÊZßa‚ÛKšChpμ(·|ëyWÝò:_TFòÏNÅÏÛ±ÒTÖXP³´%‰m¢B‚v¯˜ ›D¹i༨¶Ç%úδ*ïÄXÍ®Ö(´Y§o¸Mc§©´F«ËŒ;ôä -eAdŒïÙË¥FWÝ!ب»])·ÿkC´r­tø`Ý[ðôËHG©3yœÐ¬ùöU‡6ÚJúdÚmÃ-ÂA K5ÔmÈ’(„hƒœ^_i½ Û‰OñùdC= XÛ‰MöÄ‹ë¦kóÅx¶ç¨ðÜ{ÁM?mlK[­åx~õaõóÃ/ ¨Ñý?j´m›Ú\¬ÄÆÄi£°1iö;ëR@ÌâŠËÄXiO•7ÌKÛt|Z_‡w»¡ùŒ|‚ã·mÍn ô°Æ¾RPg“µ™$캩`ªՒX½^|L>ÂçÁfÂÂϱõ/pï•a"¾ˆåu‚}Š×?Iü}pqýŸX%ÇäbC[jFA[VËu„ÊZ>ŽÏ–}HN74­ÕT8oôJ­C³sDò_^´Ãq:üúí¦- -endstream -endobj -1726 0 obj -<>/Font<>>> -endobj -862 0 obj -<>/BS<>/Dest(figure-40)/F 4/Rect[65.905512 591.929764 109.581293 578.330154]/Subtype/Link/Type/Annot>> -endobj -863 0 obj -<>/BS<>/Dest(name-example-of-localizing-a-nes)/F 4/Rect[115.040033 591.929764 303.678217 578.330154]/Subtype/Link/Type/Annot>> -endobj -864 0 obj -<>/BS<>/Dest(section-2.8)/F 4/Rect[65.905512 563.830154 95.494623 548.230154]/Subtype/Link/Type/Annot>> -endobj -865 0 obj -<>/BS<>/Dest(name-additional-properties)/F 4/Rect[95.494623 563.830154 227.008295 548.230154]/Subtype/Link/Type/Annot>> -endobj -866 0 obj -<>/BS<>/Dest(section-2.8.1)/F 4/Rect[65.905512 517.130545 99.092035 504.130545]/Subtype/Link/Type/Annot>> -endobj -867 0 obj -<>/BS<>/Dest(name-anniversaries)/F 4/Rect[99.092035 517.130545 169.144525 504.130545]/Subtype/Link/Type/Annot>> -endobj -868 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[336.085932 396.732108 394.18017 383.132498]/Subtype/Link/Type/Annot>> -endobj -869 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[400.238764 396.732108 459.253656 383.132498]/Subtype/Link/Type/Annot>> -endobj -2444 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2443 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2442 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2441 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2440 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2439 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2438 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2437 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1835 0 obj -<>stream -xœÍY[oEcžü@©*ŠÒ²‚(‰YÏýòHI75¹'nZW¥ ’‡^¤­Ä¿†_PBH¼ð·øfv×Þ]{}i(ª7ÞõÎÎœóû™MÄ"ŠcÝ_¬d±µÎh}û¤ñ¬f×0ø¬;£#-El(5ÖDÖ¨XJꤊž×è5ž6XäççÖCÓèüû†_oÜ` cœÇŠ9mÚ³Æ>f6›.O+=NY>.<÷÷½50‹m”üåùM™.<6¹Çgke8Nñìy€•»œÜ³Ü}~]nü Ã1þ•¯y–7Û3&c%©¶nÈ-œ{äv˜°Œ)Çd‹\ÂïMrãuÜà¼soty¶pÃm,Þ%]r?ðëbdŸœàÙ!Hbæc¼ßo:¬¾LêÍûGÛã¥ã*ÄôÒAŠ%¬>íÀÒ3Ù d=›vàÙtÁnH žrHòÆÚ/H“ÍšI¡Âs˜aJº*®Løi*°Wé èö -ZÛÀ´m(zçÎ]ÈuqĆÇZíTŠØXC"y½nÍÊÑ›å¤ÒB§an7ÈÜ¡tžmq7‚+¥±&¶FÂÉ-µ§2fT -œ%/ì~±G6†2¶ƒùz˜š,âáÃÓïNª3 yk#ù·'Å EÜJˆ˜s©)Eíã- ÑÓTq[%nÖŠÚ -À¶'©©› ­UCEÇß"þ7?ƒFwà­eƒ”ý`|›G£ÉÌù wÆù|–OcE˜ÊgKnœ›’ÈúÍàwB>«“«d±’ó0²§D2æÖP1;ÓQ?Îû¸÷Ó½ª¨Ý,zÓ^È_‡Ó<æ9 ) X3øjâB™vÂy˜Ý,Ù!ÇrâšI0$’I~aÐ>¥Oýân`z;Äpù Ü â¶CÂj‡ŸÓ.jjmmL%ãÂÌgêråõM=3Óɦî%í–Ìž³ñ0XRSM Œ×Ú6WFtû‹“ݱˆº¡|ú,P²§D2—Òr!çoT”IµY4«²ù Ý°Ì—²¹q;Á3Râ¼ÎP2‰‚ž•É‰±SÌØ&§ûƒ\ξ2âqZn:È]½Aêâ<ðפkM€±h“cÎq†-m—ÿ‡Nì÷RŸx〠-ÍÓÛ¨Ð"½ € -Ð<€æg+°Sç”(•üÖ—{û;{Û‘ÏÃ!B)’» Å”™¸u1Õ fblpŒÒˆÆF8é3p²·›g1S++£¨cSRÔ0SàùÂœKÆ}jˆébýõ‘>•YXmؘÉýU¤œA%ÍÚ•V!mg…Ô·Q¦)Êç–÷1«ƒVªRšHáò^1ây2”1ì±G` \âÙxÛ¨²m„ó›@J¹„åSó¼îºØïû ‹ÊW˜u–½{®Rÿ™w”–BG3„jˆÐÎ/öijÖtʲø€À%w¡ƒiíŸߺ¹‰8Šuø8+Sï|Qò­äHPƤF­áxäÝyÑ»Y„ß126ùši.EŽ@BäYó4>ó—&HáÔ"qJñÇjŠ -Ê£HsFÚM¼´—Q–Aïã”Ú#P^Âw% ~FDXA2‰sÞ#ëäk\kä%yPÍ}¡³%•Láþ X"b5ûþÓ0æL`}“0F©³A°@\Æïô°†gK0ѧSÁÀKc¡aE…›O ¶ëGª‚´€‘ËWðð<ª†Ê×óüT½„[…’:'Š,yì8DæÊcŠ»$X" -WïvÁ½3¿®Ž ¿ft ðGÐÆ29'ï ­L'å®Â;æ‰]iUŒîÙa)i”Ö…ÂX:‡NZKl¸‘Ó9Ñü‹ÊÈ|æcæÿbLÌ•Šå¡Ã«§ÃðR©CvÀ¨ÿCÒj÷Ï~ [î-r0§.…Ý­ÁFhæžñVúú÷$¼ÈÞzµÉÎœª5è­ÓjªÔbð~¡è)Éñ/ Á²Û -endstream -endobj -1724 0 obj -<>/Font<>>> -endobj -856 0 obj -<>/BS<>/Dest(example-localizations-replace)/F 4/Rect[65.905512 662.292108 110.571527 648.692498]/Subtype/Link/Type/Annot>> -endobj -857 0 obj -<>/BS<>/Dest(figure-39)/F 4/Rect[65.905512 360.137889 109.581293 346.538279]/Subtype/Link/Type/Annot>> -endobj -858 0 obj -<>/BS<>/Dest(name-example-of-localizing-a-top)/F 4/Rect[115.040033 360.137889 317.025873 346.538279]/Subtype/Link/Type/Annot>> -endobj -859 0 obj -<>/BS<>/Dest(example-localizations-patch)/F 4/Rect[65.905512 336.538279 110.571527 322.93867]/Subtype/Link/Type/Annot>> -endobj -2448 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2447 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2446 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2445 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1834 0 obj -<>stream -xœÕZYsTÇn3ñ˸Êxƒm–[˜ˆÍjõ¾8 8x$1 ,—Á®È€«püªòW~B~Lþ[¾î»Ì]gÆUá2šÛw9ËwNŸ>}Î$îoã{ßÙÂß<=$½ß=M…R(Z¡´¬‰Ö=0àµA|ùè(Ò=ÁcPÔ -š ¿%Ø÷ÆdTåRU]*­`–I.2V°ÚŒT·Acõ ì‡G?ü Ãé ¹X%͹¢Z1ãDÂ5ØH'¸É¨ÚLº/¦â×!Âåyù6Ñ‘ÜRˆœiïÁÞ»SóÜPì:Æ¢íùwȇu²e™­§’)iDMæûÇÍv·£Y@ìqf£]Ü<:ºá!Ø‘/qiRg«9ðÊÛd[!u¨}œÕ±™M"˜¢œID³ŒÀäÞ‚\,ùÅ~$· ²ûðØa!ú ê•¿1"û7 ^°½*(žy”¹ß~ „%Q„¦Úx›Š’2 È,&Êa´ÞnD4ŸhÁ†C°ás:RÙöÜ‹S/X7"'^¶Q>G!6"¹Ü}ks1z:˜v룑°Þ07œa#R>À¥q´úL¬Œ¦Ü¸ÒRz;þÅV5Õ6ÁGñÉÔt9Õ^ OVÃ0ºt3€¤Âoç:ö2A†™váÅõÈ| -}·¢¡”q[³•èG›:ë³å°%ûð%¼õ±\J¦Rà´p$×UXs)f,#ŽÞRéµÆÊ„¨¹0Óy¯“QEÍ2/Å°.Z½8#“­I¹ŸŸÒçÂgI=•C`1Œ+¿8ï£ãªISbj•ç¿QœYVù}ä­ä!ÿòVrßPÞ—ýJ¾/£Z8£°÷ -ù´Vƒ»åT(Ãq5ÛϾÑ~Jë ¬g**sﯓû;íÎ{sfáBîñ ù¼–G(ÏÃ|ä5ºxÿb#»Ò`âŒå-]'ßÆ o)Q¾OÚ/¥=Ó„³Gd&R9½«mG4Ãd•Æ¨&«Â/Û,øš€¿zì°È,pÂ×h¨fXžÔ¿a¸E*¥ÀØ~ZvlWËŠ©€z* , ¸´FØç/;9¨e‹¢ÄžÖ2ÏtºFíoÝ]Çd£&þóNeî÷,øDB.c_ƒ§äòÏš?•¨*F×VÈÌÈïàxFVA€’¯ÈŸæК2'¤ó%)‘H€¹p9£ñ o"—È.}ßMÒx*L®i…$ƒdW z G?c3ü”¼G> G¿bõyBnAíU²FnãÜ’;8þŒµÌá¸CÎâì6>éñB!i~o\%×È µÄ9ð»…a‚.Ad Ÿu ‹]€Ò5_ÍÒY¶Q5À¦ˆÿe.â -{l'Zái ~ â_ÁgÜ -Žç­jÐ÷u ÈPŒ_ãñxÒ Úk\`ˆf¯ 1(Î/àÊ¥øÈ*î?!Äß+3VðPÁjxÍX!náé*>9Àv>¼ÆQm[áhÀ{ ˜Ü&sF¢ –)Rø2ÀYÃçiàs'W óëˆP‚ó€ÜèÀ¡¿"ßãÎÜ{óS8>B‚¶B>Ç\øÏžB´×Â3q„©ïÆžÄcèÞ ^Õ0|Õùx(ûpYÂìUy¹>饺úú`Õ¼LQlQLôÎfÉiK]“‡å¬B îj±d†üv'-(bœe³ÄÙ,Úq jH“t“rMˆŠF àrÅ”Ÿ“ÛXü˜d%¾r"^Ô,Ó:Z{Av«T'Ùˆzm“ï2=§ÉAµ°S/å^|/”‚³Š` ;(0EžÖS´7¶¹ñœø•˜‡UUÉi-l‹NãýLõÛ0n¸¿eD©ÎýuØWEËõá£ãªVo¦ ²8ç˜ÒÕMvS›Ü—Ï´ø³ NØ0VÉÍ¡J{t,ØKV“D½6í *£°Xض¥\Ù¨OŽ™ÖÞÒhÓµz±Š{/î¶k1¨Øk 7 -ÂÊ¢\|[㮶„Tž:#þ5_íš¡î½Öék¹Òpe3¾W×äƒiy7ÌàneâÊsçÞƒª˜ãŒç£ÚDbâÅA1Éçš ­í×Û5Ö`×ä[¥èe]”^ >;‚O@©è1d[ pŸ¤q¤[gòdî¦dÀaÃSÚïjµd=†¦!z±è?j60ü\aÅ`¾)Ï¥’G´µ2¦^“v‚º55Šr¥¬ÍŒö˜T¨1WºCtêô3T.[g/>{/7M‰n·Dû³C¦#¬Õ>ŸH–’ÃæS¼)þTðíØÒ؉=“Þ“8BѧºZè´©™Û„Oƒ@]ö^ÖÅ[{7`ªºcŒ*ÎT±[^^ØYƒ“Èù­Ñ*÷˜•Hk#ö0²Äe'§t:뤔£+äŠ ’7Wgõ?AÄdžÁçÍkœ Çƒh¸aÅ\í˜ûÚ㬽s¯Õ!&±wR´Ø•iq€a©×Ò*¬SàMˆ_V‚ú’a¥é–ƒj|«–^Ú'ái’¶×‹M¸i I›®[êz&³sSDëlÅ,µ×ÆY‹ñ0C}*}á7“8C÷~£&o* “JÕÙă›zKÖ…vT9½ï×…1Tƒ¸ñ‹3ª×ÏfùÞ²Åu©tX­½‹ó®×—ÏÒeØñp/…«åÖ‘ÁÞU‡¬é´äD´µ‘–@«¨ú2=CíÛ'h›ÈPý‹?]Y˜%‚rž|JΑO—nMj+Ó‹3üúMÁÔÒc¢(iê‹à¬F`·5ßRS°ºô,Ó|[U–—ÅÊÍÄ"Í.F6Ô¨òÈD¥­ª,ªžÖ#àmçÉ'u?˜Í TY‘RXÃç2ZÅ4^É*ƒ¶–ãd°&¬šÏ‰‘ÁôçgÉÇøœ[ŽYø ŸEpÐVjÞÊÃÄ„e/®-Cr?”Æ~M÷uGÇÿŽËå&Ù]KÍBŸË"N,À<ÿIUÈs&1Ï{ÈX‘—ƒÖ"ü;oô\­e‘„#gëî8îÿ¥ivJ -endstream -endobj -1722 0 obj -<>/Font<>>> -endobj -1635 0 obj -<> -endobj -2449 0 obj -<>stream -H‰„’Ñjƒ0†ï}Š³‹B{á´–íbŒÁj[p°¶Ôîbrìš„$^øöK¢v0^È19ߟüù“ÅùŒß™¬0Þ<¦pA#;M1Î?‰Š‹¤]‹Â²©k^à¬%-ÑÂ2/v…àvåàBЦc8QÿC[¼qñ‹ø}`yÈ‹ýÇö(­ŒK"L\öm%“Å_¾ïeWn‡Ï@IÓ3TêWÜ –ËÖÎDQ2:„dò\sÁôh*o:ŠÖ0Ní4 …¶.¨ /{c±-D-a3p¬S# \ܱº‡å`r kß8i†š‹Ûl “ ì”jÐ;‡4Ì¡`¡:Ž;’!™‰Àã¾ö -!äëÁ-• "57Œ^Ó´bo0¿×Ÿþ¨ªjúMôΞöÏç½ÎGuwH;­ÝBPÉä‰ ¼‡®¤òªð ÷5=?:¢û0ãÅ -endstream -endobj -1634 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1633 0 R/Subtype/CIDFontType2/Type/Font/W[189[344]]>> -endobj -1633 0 obj -<> -endobj -2450 0 obj -<>stream -H‰ìUMkQ=of¿¨nÒRPq:m¢ ©é$MŒV°*ŒX(E¤eL§‰4CK»QD誗ѠPÿ@À]7¸R ‚»-ñ¼™I-AA7ê¢wæ½{Î}÷Þ7ïs tà&T\,ØÖäãõ{-oX’ÅrÎÂa"ˆË\Ér°IÊ}ùâÜTGýá{òòÑîbPuò¾B©6«.c‘ü }¾”¬Yϱ±]ÏÍÔ¤%xEÖSN¾´™;ÛÙ̧­’}¨>¼äqñÍ)WkÍ0íc2_v䈹ܸý”|–|rl -°x¢þbbÏÐg¨ê™gõÓ£¯R¿øxq¬‰°x';‘¾[òÅÝoîJ¨,!ÖÂÕtjy¸ÑlzõëWn»Œh­äìRF$2˜H&ãfWWg(è#ó°‚ݸåcg±àc ¼ôq±ÓÇAÄD§Q†ƒ9Tp yPãí`"†¤ˆ2l-Ó^„MvÓÈ¡Ÿh˜–"õ¥¨ªËlj›¹fXOÒó£k,:F`1ºê¢9”p•Ö"¹éFåqÌb¤É¨˜ûgïY>¢VžV–öѶ,¿Ó¯Þ3ê~y•#*3BÿÅ—Lû™£ô,3¶Â±qlcÎbHSÒ’&¶1E–÷Ž²5GÛŸŽEõ6@sIþŸ"šÚ-¸²Pæù÷>ïi1Sœ¢uW@Ñš¢hž»¾˜Éf3âd¸nx÷²UfZ»OéVŸ¹ÎîŽü.À Ÿ± -endstream -endobj -841 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[254.530512 771.389764 298.046625 757.790154]/Subtype/Link/Type/Annot>> -endobj -842 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[304.105219 771.389764 363.120111 757.790154]/Subtype/Link/Type/Annot>> -endobj -843 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[256.904047 718.090936 314.998285 704.491326]/Subtype/Link/Type/Annot>> -endobj -844 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[321.056879 718.090936 380.071772 704.491326]/Subtype/Link/Type/Annot>> -endobj -845 0 obj -<>/BS<>/Dest(figure-38)/F 4/Rect[65.905512 436.658279 109.581293 423.05867]/Subtype/Link/Type/Annot>> -endobj -846 0 obj -<>/BS<>/Dest(name-example-for-the-media-prope)/F 4/Rect[115.040033 436.658279 263.072748 423.05867]/Subtype/Link/Type/Annot>> -endobj -847 0 obj -<>/BS<>/Dest(section-2.7)/F 4/Rect[65.905512 408.55867 95.494623 392.95867]/Subtype/Link/Type/Annot>> -endobj -848 0 obj -<>/BS<>/Dest(name-multilingual-properties)/F 4/Rect[95.494623 408.55867 237.880365 392.95867]/Subtype/Link/Type/Annot>> -endobj -849 0 obj -<>/BS<>/Dest(section-2.7.1)/F 4/Rect[65.905512 361.859061 99.092035 348.859061]/Subtype/Link/Type/Annot>> -endobj -850 0 obj -<>/BS<>/Dest(name-localizations)/F 4/Rect[99.092035 361.859061 163.565668 348.859061]/Subtype/Link/Type/Annot>> -endobj -851 0 obj -<>/BS<>/Dest(language)/F 4/Rect[123.270258 320.259451 193.864008 306.659842]/Subtype/Link/Type/Annot>> -endobj -852 0 obj -<>/BS<>/Dest(language)/F 4/Rect[199.922602 320.259451 258.937494 306.659842]/Subtype/Link/Type/Annot>> -endobj -853 0 obj -<>/BS<>/Dest(RFC5646)/F 4/Rect[324.01684 293.060233 364.974604 279.460623]/Subtype/Link/Type/Annot>> -endobj -2463 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2462 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2461 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2460 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2459 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2458 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2457 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2456 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2455 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2454 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2453 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2452 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2451 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1833 0 obj -<>stream -xœÅZYoÇn…P6€#!–d:Æ#™”8ìû‚ ‘—7Cq—ÇJ2 [B?H - '‡äQ@þ@~Lþ[¾®™ÙkwgI+áhwzº§ë®êªZ%"á¸ÖâÍk‘zœÕÉßôÞöRgh±¸ÓäÛžœM¬V©ãÜy—xgR­yÐ&ùñO½QïÏ=‘ÄëÇzë/EÊ“þÒ‹û]oBÊÔˆ`=í9ï p´ðÅÀò†P™äuŽòue=>V,õIö¯Œo‘àʲ+-Ÿ¯ÖÉ FëDVéùuö,JÏå}¥ùLnõJ…ŠIý^Fûä¸7Ö¿w©wš ã¹O„©qÒ‘¿é­l¿ØÙx’• …·’ãóÞ×_²§lŸ²[Æ÷¶Ä<`´Ïvqßf[ì1î#Ìÿ‚ ÙFû¸XûÎÎÙõ•oŽw{ǤýEé•>¤†k)uwjÛUK dHTô,á{ߣ|} ó'mbfˆÑÙ&ãÄ)Ÿa´I¯íÓÖbS!ŠXdò)îÀˆí1#‚ç’· 9@ÃFsÁC¶Áþï=¬=@}NxwK˜O1{H£ZÛ"OHäÛ¸2žIÏZH€•l»Žñc"þó#öËö–‰¬*7ÑH-çÆù&7Kàf{:óCå%†Ùë{dG{ÄBFGŸ¨þ†f†D- OIG¸wÖÝil­‚·Ò4é(ľÝ*òª\æˆMç.œà2äxd›Ûħ%^FcÕŸà&h™Pr­„(À6yÞ v»Deü>Ì%u˜¿Ñ{Á5¼qD’Û?ûþï¸]Ï¥”{èE¢Šå>5Þ…øUµ‡õ¯‡»pÞÜ99‚‡]‘nzY¬@‘Zk¸5m¶ ]^q@ù›:Êj8ÄÉ%‚ Â%V¸Áß›H¡S‚v¡8÷.sU੆|0Œ”îýþôàik;[!Ç€-“´¢]ÝdŸÖìJÛTp¯«p±ÿNÝø…ohyùìKö5YXá_;d‰µX™Rø\as*_){Dµr!Žû6:ÇÆ÷¶]#¶¡a-àÏí ¥\|gs!'’úêì’Ϥ!êMWÒ>,›…÷õ„F3¡ÑUi¼_ÈfXiÙ8Ç©ª¹õ–Rå¼’ŽLsðüdçÉœNÿ‚×¹i¾b÷×XÂî²u¶ŠÑ2Æ)æ_²+ìoõØ7A Tj,œI庿‚«ææo×Iª°Vɱõ\ɯW8Ý–£ÏÜËÁ¼Ex\d‡o§CµÊ*¸®€äÄYï>€­³Gàó%{+#û;àQìvô GHLÜ…Hðø³÷p­ÁWq=À̯ñ¼Š—Þ#UJâ®ö¯ÙU {÷E’¿c@>g¯¦íàø²&Éw³¸„Û)!¬6†»éû¹ÒW<ÆÁV95D_7ÙPH¤­¯1Ó¦‡|bÊä_<54ð8ÿÉ~^ÌÄ|ƒˆºÏ¾Å+œ^Ý_dä'¸Ö²á³éEáüTß$ùqþyN´›ÖÌMMžïÊÔ ”ï_êÌÑ0qiCð®Cž?@z™eùõ fs¿û ù}•N‰ø lÕÔ¡Iç $-Ÿâssœ¼L$ å L;À¨‚+³WÛb F¨%4·Ô £úHÒ¦ÚY¨®”ZgÂ]¢´5_Íà¹ñ˜â)¦j#*7tÖRÎY-g†ù(ÛÏ(µ¿¨ý|TMú¦¦§HsRÍ¥ EzÚ¬‡ªÉo–4ÔPÑ«<õÖÇ:6º 0…]-UÊŸ, ?-Vmèj¬×’|çS¡6ª‰8JµOéðR–¸G¸±þyAuâ^Iœ1Š i ùø,eH9Gj_K}àÙ*•ž}be‹mGéJ ð´š.næÂX¤JÖ…qeUXÒý íój‘ZSí½·MàT¶áûêX3WI2û¥J±ém%j}Ÿ,Ê$J6¡¬Š‡uWÜ3Üä'¡.jhÓÎÍõͯv6v[éù‘3K+3;rVË”%§ÜípQ?YGΛzTb:–tiÊ}6µ)×=§/×öþÜÖ\¹®èЊƒH­°’«Vl³ºqQ¦© iS«bóIù0¥·ÀÎÿ[7.þ¤1¦qÒCU¡ñ"|]¨g-ÿs»q³®Åƒ-8|pbqÅ‹Ÿ=®ä•B˜VcQ»fë£Ñº[t´nS+hVSÅÅŒBìÎhÁnãñ!µ–^ÖQü{j;n&rœd\Ö¤²X;Ç©J^Ë»é¯G§%v?Lça%µqzÞÁ1Éâ'>žûô~“úúùŒ{Td q؉Rœ;¥’¼OeÂl&;2¨±Ö.u’¦¶z¼78ĽˆéjÞ´ÈjµHBµIei³Crùz¶VñfωÚifãPú„TËé÷Ʋ丞£`¶„@ð ®›õ$c6e£!XgÅ\DkÈö” ëÅ0Y ëãÒéù˜x¹ð¿Á~…Ï­ÅÅÿ¿â\*C ׊ÒΎèømjÍý•:uóóf·ØpAY$±ÖÇ¡ò>ofÑ„]©Kp° hI¥ÖÌåZü.™å-öqݽÿÄ¢k -endstream -endobj -1720 0 obj -<>/Font<>>> -endobj -827 0 obj -<>/BS<>/Dest(figure-36)/F 4/Rect[65.905512 559.716326 109.581293 546.116717]/Subtype/Link/Type/Annot>> -endobj -828 0 obj -<>/BS<>/Dest(name-example-for-the-directories)/F 4/Rect[115.040033 559.716326 284.378168 546.116717]/Subtype/Link/Type/Annot>> -endobj -829 0 obj -<>/BS<>/Dest(section-2.6.3)/F 4/Rect[65.905512 534.616717 99.092035 521.616717]/Subtype/Link/Type/Annot>> -endobj -830 0 obj -<>/BS<>/Dest(name-links)/F 4/Rect[99.092035 534.616717 124.039057 521.616717]/Subtype/Link/Type/Annot>> -endobj -831 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[246.561762 469.417498 290.077875 455.817889]/Subtype/Link/Type/Annot>> -endobj -832 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[296.136469 469.417498 355.151361 455.817889]/Subtype/Link/Type/Annot>> -endobj -833 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[244.434565 416.11867 302.528803 402.519061]/Subtype/Link/Type/Annot>> -endobj -834 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[308.587397 416.11867 367.602289 402.519061]/Subtype/Link/Type/Annot>> -endobj -835 0 obj -<>/BS<>/Dest(figure-37)/F 4/Rect[65.905512 254.964842 109.581293 241.365233]/Subtype/Link/Type/Annot>> -endobj -836 0 obj -<>/BS<>/Dest(name-example-for-the-links-prope)/F 4/Rect[115.040033 254.964842 256.962152 241.365233]/Subtype/Link/Type/Annot>> -endobj -837 0 obj -<>/BS<>/Dest(section-2.6.4)/F 4/Rect[65.905512 229.865233 99.092035 216.865233]/Subtype/Link/Type/Annot>> -endobj -838 0 obj -<>/BS<>/Dest(name-media)/F 4/Rect[99.092035 229.865233 130.658686 216.865233]/Subtype/Link/Type/Annot>> -endobj -2475 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2474 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2473 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2472 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2471 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2470 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2469 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2468 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2467 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2466 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2465 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2464 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1832 0 obj -<>stream -xœÅZ[sÔÈîÝS5TÙàÁ³¬ZÆ\duK}cSKÂŽ/|Áã½ÌV¦ÀVAò­ÊC^÷Gå¿å;GÒXÒHž±a7ˆAR_ÎùεO·dáz@7—ÈÐ9oMüí]û};´š;ó;7¾oãÍšÀ$qh£È:8«Ã$‰|¢ƒoµnË€®¯Ûk/e¯ÿѦùÖ§H©T¨¥7Žç¼jïáiéòàòŽYéàmÆòm©ŸÞî‚Yè‚ôo‘ß)áR·-t¿º[…ãµÊûVáýmú. ïÅy…ößîñʘþÕ{‘åãí¡í M"©]ä¹PÅ^i¼x×^{¶õý“õÇŒC¦cTðâUû‡;Š§bK´Ä±/žãÚß‹±'¶Ñ¶%~=±+ÐNcúKý}<§O-q„{K¢ÿ ~‡Ã–h¤Ž¸}-ÏѲçÁ$iض8\UÑt€à:SR}ô}‹§ <_^ýñÅvƒ”ÊÅ¡²R'ž¤üdÒlaÔ:þÝÄó3¸E˜[hèaHO;,ÞQÆîvQ¨p8cÕãá2úsXÄúü¾ -¤ÒØæ bÃ|a%±Q™Ø)š]èì9&ï E|Î=[L~OÏSΤÌã.wô1-7Øg‚l„¼õ™HjŠõY ¿o—]NÁÛ‘ b@ÚÁeµ $ü]§­Y^ù(¿VEiHÏ~ýôOýgÏkýz° -1¶I€Lç-1/ºe¥Tˆ@‰½¬ÐÅüë¢U¬ÁÄ+kîT|k:®øú±[°9È/É}Zéär¬¤®QHzï¢Øhå–y_o?bü`Œ±‘R6·Ì™'†´ÞXTï0é$kFèÉvÊ[Ô?]ùDs Q!š2Ä3H…l|‚ŸÝS"a ã\D†&1ôÈ9÷¾;|òx CüK2ç|#nˆ"÷Äš¸+¯D€—Í/Ågâ_¿+Ð7:tP‰Š3³†ë 9P‚D4ìx. -#éQ"h¤t"`º™x#–m C¼ÿŠKñõW°‰Å5âyn á‰p#ngbü*n‰%4¦¨¾i†ã“PE¹Ê28¿4WXÖb_ÐÀ/Å”T›–b¬ã&†ÕŒâ¢É•C¾Š•“ñ'ÉLÚÇJ{¦Ì´Ð˜™ÊtÇd¦‘Á›™ò…p3[ë3E¡ÃzdGœ”™bé¡â:Ó$ÑP÷µ©é3ÿo¹)VQ ã0=©Ø0žE®3e§8IB'¥I´Žìo“ bíh‰Š•mJPn< ‡Ò%ÞÇcÔÒÐ~/ñ»ÇÙè&PSÛM¼ŠÂ(R×=XýKèó:É‹@CÎ9™F"<™Î‘â-;ÅÀ–¸Ô ))Ž&ð‘.¸]bhËðQøÝ{À|Œ§¸C! »h_B&¢tq&ïÚ2îÓäË]Gº ¡o5%ÑEzíäIðûi¿˜k†mU˜xiŒ³‘ƒ|”ñ›!ë.@' º³EúLsD þS@¹æ96!Ñþµxw|`I’Ù4öVó:’xl–Gè™a3,¤Øf쨌ÀOøy¨ËÀõh9D‹`J|WÑþ0­à~ã(ý²óNá‘2"ef2 <¼-¨{ŽÀ.3rCÚ~ˆŸs€L“ßwOðoE¡3¸Ê4hΰ³L‰¯pŸÁý'€‰„|”“â"yÅtΡó"µÌsþüŠ}¾ÃsWpyNõN—ÞçpÝ,¯ fÜHƒ‘–&Övl>!ÖS¤— ¼ÈÑBÒâe…RÛ4£˜F^aO_¬,†Ü§¹–×Èk¨mÊvo®åu‡‰*¨»¶–ÿè“0£-êct2æ$lu/>mpQ|ˆ7:ó@µ ÞD*]©ô£\þ#:/âå`xhBûw(©tRòqðQúUgµov÷žín×ÁŸ—4—ù^Ý Ä*DmkeR!×$uy:ögØ(%*¶£Ó+œ° -µµ‰1“ë=?«×?íUH±tRF‡YùiÝÓs¬ÝÒ™U:<<*Ïmñ|ÚÕ UwÌt ¼Å„ñ=íÏãÒãÈ”BºZçí¤Ÿÿõ0psTó%SZ0S1JûËû~oe„z!œq8elA4‹©$bšr™˜<õ( ®ü ?%“9!Nã²`«ôÛI·ÍÏ;âÇBŽÊ=¿FÇrÓ >Œ(§¿”|Ÿû6ÐÒŠ~¬¡4#Ì4Ë#í’‚—oA¼müf2Ž—ã+ÿbq8lsèŒ=Ì )çü›H/£°ËêÛ;6ȨĹ7#5¨ÈbéÍ1LbõñW SÉœŸÀÓÒ˜Ü+Ø.ÿ´ÒÏ|z¿YbĪ7‰µùñlNü<“¨æ|5q }4÷Ô§Ù÷®ž¹C—¾´9lî>Õk rÔ‡,¯°ž_zÂg¾’À?*9 -rK(7B¬¹Zh2j½/•Ö$/#Ô1‘®I÷3‡-¯L3Uœbun\%ë²úõê—´‘±þ€±X&Æšj1Ö^yU?A{º(9Š Z)Õw“sDÜÈ¥$c‰‘2aÅΟB4“Y$/¯Àºô;¥:JBCzU“ó¼*Û3%&ƒ.T^z¯¤³ùÿ½8ínà¤ò§ÒçÓÇ'ï>6†³r -&⺔s¾Q™ -"¤Ã9Êþ>º(5©ˆ ‚-Q¡ŽU~bÎœG¿åõñøÓzþaÿ4A‡0÷–6os>cй0²ÕÁäŒê‚î üNt›/Eÿ£abÞ']¤¥ÕÖÁ9ÏêhMÅïÚÆ7OÖ·kñü—áœd•ßo©fúdxó؉˜e«¬J‰7‘­.P — Á*J¥XóÕà<™Al<5ÖȱŒÀ;o‹gxéé8C_¦•MÆsŠ°©VƒsüÍ {:fôŸÏ,UV6Ö²–‡áäÁ%5îÏèl—¾®¬‰ýÁ«ÿp²™••“ëRG¡4Îêxæùö“*Ü>o…ò¬¶]ÂéTkuˆ²Åè±RÇÙ&£…¥¼Suǽöÿmo½l -endstream -endobj -1718 0 obj -<>/Font<>>> -endobj -815 0 obj -<>/BS<>/Dest(figure-34)/F 4/Rect[65.905512 663.715154 109.581293 650.115545]/Subtype/Link/Type/Annot>> -endobj -816 0 obj -<>/BS<>/Dest(name-example-of-cryptokeys-with-)/F 4/Rect[115.040033 663.715154 311.998529 650.115545]/Subtype/Link/Type/Annot>> -endobj -817 0 obj -<>/BS<>/Dest(figure-35)/F 4/Rect[65.905512 412.441326 109.581293 398.841717]/Subtype/Link/Type/Annot>> -endobj -818 0 obj -<>/BS<>/Dest(name-example-of-cryptokeys-with-e)/F 4/Rect[115.040033 412.441326 320.238275 398.841717]/Subtype/Link/Type/Annot>> -endobj -819 0 obj -<>/BS<>/Dest(section-2.6.2)/F 4/Rect[65.905512 387.341717 99.092035 374.341717]/Subtype/Link/Type/Annot>> -endobj -820 0 obj -<>/BS<>/Dest(name-directories)/F 4/Rect[99.092035 387.341717 154.825678 374.341717]/Subtype/Link/Type/Annot>> -endobj -821 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[269.928217 322.142498 313.44433 308.542889]/Subtype/Link/Type/Annot>> -endobj -822 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[319.502924 322.142498 378.517816 308.542889]/Subtype/Link/Type/Annot>> -endobj -823 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[256.904047 268.84367 314.998285 255.244061]/Subtype/Link/Type/Annot>> -endobj -824 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[321.056879 268.84367 380.071772 255.244061]/Subtype/Link/Type/Annot>> -endobj -2485 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2484 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2483 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2482 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2481 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2480 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2479 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2478 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2477 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2476 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1831 0 obj -<>stream -xœ½YYoÅ.cÂà ±\HàJ‰Ý\‚c›LMí b¹7ØÇ1N¼'0qѵuå‰E,ú,}ñ¨ßÿív‚ˆî¤²¢>¢Ÿ? wìä­ÿ¯,?÷ÁÊò꟰ÔvLpéë3ÃßP]*Tv‚9|wjF^l‰©‘\¤Ÿ]­Wd℆#W¾¾Â<¢î0¬K¿tÔl‰^£0”¨Œ®ÙO[žG½„ãjc6Ó·åPŽUÚ¢D¬eQÉó-¸©bn±¦÷÷³j¤uëá<§p¢ãµ[ÒêA‡#šd^V©Íb©ŠW”Ð2þüzüǼٲ“]¡år®N˜eÁ,¸LÏÚƒïïlßßÄ<ðeò2ù'þª],aSCWX¢ci7ôÌÈ0¶±$¾í’=|?ˆ}'¿½ññõÚ6ž%wÁ7ôÁÁ}Xè~Ý&£ÿþ”µ½ær*Fï`ì NÍÀ-< ´yŒ•·zo‡qlˆy¡Í¶ÛpÇUwñ-|¡l€çQ2R{ÁôQºp=6û┸²M¨f×Jxãò¾  ôrÑpò–ë¹ Ç…â+ç|‡ì‡ü{À¿KhÖ»ÄÀahŽ’›÷>`ÖÏù7f<’k,~t\ÞÏùÀzêwÜ”`r¹+¼Zã¨W9*sNÊäÚ¶_qÎïÞºnRê¥vÈ2S+ÁfVWB³™µ’Cç7øÇ°Á¤ñkw-s’d=v’Êí¢J³Æs5¢e7‰“8˜+ /‹'sµà…ÃÌcþ?Â}ì­1ÆKQ/ºq@º—Ö+5´ì×ÉGYŒ™£µl3÷bÀ¨/i›?ƒUé¼sMòšâÑZŒEóéîÝk…X@°ŸíͶ ;ÃŽÅ…0²_ŒÜLÊF†N;lß™IâPx¤w©QU—¢¨¶¢èƒ©í %'"KýË‚bp‘ ScYc-ÞYI™9Š)_(¡( ¯BüôV¹”öXbÂœÕÖΰ5SÉ·!z¾þfܤæŒ:#kzÞ£ã²>Sb<é‡~÷^pxöŽxÖÒhÙÍxžya -ë`+œ€~”¶Ê6O\"Ûlh)ZOu°¥Ù8£pÜVusbdí,K\&¯àïµÙ˜…·êÖ†s–Ô¼–‡‰)Óº F£oÓ׳£ãŸcÞºMvg”¥f”#Vk9 óôÅpšùBò±ã"`ˆT>›h­¦Ây£;w-A~3{{~µjŽ;½¿˜±¯ -endstream -endobj -1716 0 obj -<>/Font<>>> -endobj -1631 0 obj -<> -endobj -2486 0 obj -<>stream -H‰„“O›0Åï| -÷){ 18&¤Š*%„U“m³Ñf{èѱ‡)1ˆ?‡|ûÎRUmhøá7ðæaO>OþÚgðÅgÎÞ .ÚJƒŸüP¥7™l ÝÞÀ6fX­¿°cUè4lšì¶;›7O(ÞY}m ª‹6pÉí(¡ï°éþû¯}úíP4…‚*ÏüdÿâïþOZ¦®÷¼¹¢úc!ÓêzU5ûXÄé}©5Iq£ÉjÏ›õöØl0œåÖT½Gv&Çž„ÌäºÐ}Ô\ÿé^7pÛÙ¬`¢Ó™¶ìµŒÍÞð¦nª;›vŸ˜Œ^+ƒíå úS[–W ㌻g`«èuu6û8R;ñû½vÝËΫ. Ô¥ÒP){oÅy&¾²® É8"¢‚‰ )”Ñ)Œ‚HNd–Ô'´QHÌ‚ˆŠ·’œs$) )Ò¡ARA¬‘”5í/?AÜÙ +y -endstream -endobj -1630 0 obj -<>/CIDToGIDMap/Identity/FontDescriptor 1629 0 R/Subtype/CIDFontType0/Type/Font/W[243[602]1414[1000]1599[1000]9562[1000]9577[1000]9746[1000]9814[1000]9827[1000]10960[1000]11667[1000]11688[1000]15578[1000]16087[1000]20480[1000]21295[1000]27693[1000]41356[1000]41772[1000]]>> -endobj -1629 0 obj -<> -endobj -2487 0 obj -<>stream -H‰|Tet”×Ý{Oúw™dÐ…àR¤ÅC‚CR(eH&I& .Å- -^¼¸--îîNK¶¸+ýÂ{ï×{y?îºg}äî»ÎÙ„‡Hiçt;;;\¡Í‚Z÷©ÒÉÖ?ÒîÊ‚Ze–È,çã›ie¦¯2ý,™E=¬€¥E+äÊ÷¦’Å·8ò"ŸéÿÞ§´–F >eM`¶ÎƒcÝŽ¨X[`t°ÓãtÙÝŽ[…p·;¦~Õªô·g…ù;£ªVô·eQ²EÄÚì6·Ë∲»úÙœ¡¶§3,Ò‘UÃÿCÄÖ6“¶-¨ƒíß¼ÿ øßßS¥IdL¸½ÃÜ<",›MXSgŒ3ÊêÌnÖÇžmöàÿÛ"Àm:ƒ³A[Ù£M#Ðürg˜Ëž]íÖöh{6P—IÍåŽpFÛ#Qô4ò,f-]Þ¿f݆MÚtìÚ#8<Òé4lä؉ñÉi3æ/[»iÇ®ÇÒ*Z”äôD?Ã;5ÊÓ˜RÝjÑžFckŽÜÜ5¬9 ¯EI)i Frz‚ŸQÙš`x5[îix-LLK32¦ÄûI éEYVÑÐO#Îw¨·á•”˜ax¾©äex×·qÅs{eõ¨dÍ0ÖÇ7V›'ÅlµÑ¼ ð2+ù©å­fF¸™17iVÊÔÃ+#ýÃ;æÆO‹OI1þUÓ{ARjj‚15ÀjÄOK˜:ň÷{9ÌÛ€9ׂð4çÛ9Á€r™ÓžÇ\|È(ˆB(Œ"(Šb(Ž( +|áJ¡4Ê ,Ê¡<>FTD%|‚ʨTE5TG ÔD-ÔFÔE=|Šúh€†h„Ïð9£ š¢š£Z"­ˆ ´F´E;´GtD'tÆè‚®è†/Ñ_¡zâkôÂ7è ;ú !p aGú¢"…h8ƒoá2·Öþ€„Á‚¡†áï0£0c0ã00“0qæ–' IHÆLE -R‘†tLÃtd`fb–©s0óð=æcbc –â,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFüˆMØŒ-ØŠmØŽŸ°?ãìÄ.ì6e/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nàWü†›ø·pwðþÄ_¸‹{¸xˆGxŒ'xŠgxŽx‰L¼Âk¼Á[¼ÃßxÏ,•-ô '½èÍÌÉhЇ¹˜›y˜—ù˜ŸX…X˜EX”ÅXœ%X’VúÒ6–bi–aY–cyS+°"+ñVfú³*«±:k°&k±6ë°.ëñSÖg6d#~ÆÏÙ˜MØ”ÍØÜÔÒ– `+2ˆ­Ù†mÙŽíÙÙ‰ù»°+»ñKvçWìÁžüš½ø {Ónjp0Cè`(ÃÎöe?F2ŠÑt2†ßÒÅXºÙŸ8ƒ8˜C8”Ã8œ#øGrG›>–ã8ž8‘“8™qŒg™ÄdNáT¦0•iLç4Nggp&gq¶©ûs9ßs>p!q1—p)à2.ç -®ä*®æ®å:®çnäÜÄÍÜ­ÜÆíü‰;ø3áNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞà¯ü7ù;oñ6ïðþÉ¿x—÷xŸøø˜Oø”Ïøœ/ø’™|Å×|÷|Ç¿ù^%Yä!OyÉ[9”SÉr)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤¬ò•Ÿl*¥Ò*£²*§òúXTQ•ô‰*«ŠüUUÕT]5TSµT[uTWõô©ê«ª‘>Óçj¬&jªfj®j©µR ‚ÔZmÔVíÔ^ÔQÔY_¨‹ºª›¾Tw}¥ꩯÕKߨ·ìê£`…È¡P…)\ê«~ŠT”¢åTŒ¾•K±r«¿h i°†h¨†i¸Fè;Ô(ÖÕ8×MÔ$MVœâ• D%)YS4U)JUšÒ5MÓ•¡š©Yš­9š«yú^óµ@ µH‹µDKõƒ–i¹Vh¥ViµÖh­Öi½6h£~Ô&mÖmÕ6m×OÚ¡Ÿõ‹vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†~Õoº©ßuK·uGèOý¥»º§ûz ‡z¤Çz¢§z¦çz¡—ÊÔ+½Ö½Õ;ý­÷Xh‘Åbñ°xZþ!  €U‡Ï¶mÛ¶mÛ¶mÛ¶mÛ¶mÛµG„D(„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?aP#HŠf€Á‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOATÁQ’Pp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýsu0ôlÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üÓ¿üÛü×ÿAAÁ0 ÿ ×Àxq±mÛ¶mÛ¶mÛ¶mÛ¶mÛF;¿„@þ¢¡aá ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒ1C1 Ã1#1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññA”Áœ!’¡’¢`h†aX†cxF`DFbdFaTFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcà@â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þSU0W…T(A”dZaVá^Q‘YQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÄAÌÁÂ!Ê0-Û‡v‡u8‡wGt$GvGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿@@Ð@°@ð@ˆ@ÈÀÁ°[ÅnÛ¶mÛ¶mÛ¶mÛ¶mÛ¶„Bh„AX„@Fá ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒ1C1 Ã1#1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññA”Áœ!’¡ša–á’¢`xF`DFbdFaTFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcà@â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þSU0W…T(…V…U8A”d^Q‘YQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÄAÌÁÂ!Ê¡ÆaÎ0-Û‡wGt$GvGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿@@Ð@°@ð@ˆ@ÈÿÁ°ì:|¶mÛ¶mÛ¶mÛ¶mÛ¶m»6„Bh„AX„CxD@DD@F‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒ1C1 Ã1#1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññA”Áœ!’¡ša–áž‘‘’¢`dFaTFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcà@â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þSU0W…T(…V…U8…WET$A”dYQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÄAÌÁÂ!Ê¡ÆaÎáÁÉ0-ÛGvGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿@@Ð@°@ð@ˆÀ‚à€ €Øm»mÛ¶mÛ¶mÛ¶mÛ¶mÛJB"B# Â"Â#"""# -¢"B0ˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹   Æà Á ÅРð ÇðŒÀˆŒÄȌ¨ŒFÍ£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrs‡r‡sGrGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚(¨‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢ ¢$+ èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç ê`îéPí0ëpïŽèHŽì(Žêh†iÙ8ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ù·ÿø¯ÿ‚‚‚‚Bü'؀ݶŠÝ¶mÛ¶mÛ¶mÛ¶mÛ¶í! -¡aá ‘Q Ñ1 !ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?aPcp†`H†bh†aX†cxF`DFbdFaTFctÆ`LÆ"HŠf€±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOATÁ\!R¡ZaVá^Q‘YQUÑ]1S±Q’PlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýsu0w‡t(‡v‡u8‡wGt$GvGu4Gw Çt,ôlÛq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üÓ¿üÛü×ÿAAÁÁÿ ‚À €Ùv=–m[˶mÛv-Û¶mÛ¶mÛº …Ѓ°‡ðˆ€ˆˆ„Ȉ‚¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€Œ$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!F Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a8F #1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññÁœ!’¡ša–áž‘‘™Q•Ñ1“±›q—ñŸ ’¢À„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,Ä de1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0çq$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ7ÿð/ÿ)˜‚+„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢+†b*–b+Žâ*žâ+ J²”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TX*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡ Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖýÕ?sp‡pH‡rh‡qX‡sxGpDGrdGqTGstÇpLÇrlÇq\Çs|'0LËv€:‘;‰“:™“;…S:•S;Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿó»€ º ;ÐE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#ä‘åÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßþã¿þ, x@ˆ€ÿ ‚À0`·m»mÛ¶mÛÖvÛ¶mÛ¶mÛF‚P0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$Á@R$Cr¤@J¤Bj¤AZ¤Czd@FdBfdAVdCvä@NäBnäA^äC~@ABaAQCq”@I”Bi”AY”CyT@ETBeTAUTCuÔ@MÔBmÔA]ÔC}4@C4Bc4AS4Cs´@K´Bk´A[´C{t@GtBgtAWtCwô@OôBoôA_ôC À@ Â`"C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿŒÁ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„ )šLÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌ@q‡r‡sGrGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’¢$+@I•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ¨ ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýs0w‡t(‡v‡u8‡wGt$GvGu4Gw Çt,ÇvÇu<Çw't"'vôl8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°ä!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^î^éU^í5^ëu^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèOþì/þêoþîþé_þí?þëÁ‚„øO<@Ì®eû±lÛ¶mÛö²mÛ¶mÛ¶mÝ…D(„F„E8„GDD$DF *¢!:b &b!6â .â!> !!1’ )’!9B0‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11AŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹ Æà Á ÅРð ÇðŒÀˆŒÄÈŒÂFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&'HŠf S0%S15Ó0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p 1ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOÁ\!R¡ZaVá^Q‘YQ ¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦ä‚(É -T -¥T*¥V¥U:¥WeT&eVeU6eWåT.åVåU>åWT!VU1W •T)•V•U9•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ× Ô i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;ŠÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ0-ÛNá”NåÔNã´NçôÎàŒÎäÌÎâ¬ÎæìÎáœÎåÜÎã¼Îçü.à‚.äÂ.â¢.æâ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®áš®åڮ㺮çúnà†näÆnâ¦nææná–nåÖnã¶nçöîàŽîäÎîâ®îæîîážîåÞîã¾îçþàä öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿À`ÁCü'ƒ fײ­Ç²mÛ¶m»–mÛ¶mÛ¶më! -¡aá ‘ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH €Œ@¤AZ¤Czd@FdBfdAVdCvä@NäBnäA^äC~@ABaAQCq”@I”Bi”AY”CyT@ETBeTAUTCuÔ@MÔBmÔA]ÔC}4@C4Bc4AS4Cs´@K´Bk´A[´C{t@GtBgtAWtCwô@OôBoôA_ôC À@ Bc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ18C0$C14Ã0,Ã1<#0"#12£0€Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š© ’¢È4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈA â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þS0W…T(…V…U8…WET$EV(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µ J²•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5HA¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«æàáåÐã°çðŽàˆŽäÈŽâGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§6LËv Ó8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x 9ȃ=ÄC=ÌÃ=Â#=Ê£=Æc=Îã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸýÅ_ýÍßýÃ?ýË¿ýÇý/0X`ðÀÿÁ`ÀìZ¶]eÛ¶mÛÖ²mÛ¶mÛ¶mÝ…@H„Bh„AX„CxD@DDBdDA¢"¢#b"b#â"â#"# ’"’#R"R# Ò"Ò #™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX•X…ÕXƒµX‡õ؀؄ÍØ‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8“8…Ó8ƒ³8‡ó¸€‹¸„˸‚«¸†ë¸›¸…Û¸ƒ»¸‡ûx€‡x„Çx‚§x†çx—x…×xƒ·x‡÷ø€ø„Ïø‚¯ø†ïøŸø…ßøƒ¿øÇ` Î ÉP Í0 Ëp ÏŒÈHŒÌ( `TFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦cz‚¤h23233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrƒ8˜C8”Ã8œ#8’£8šc8–ã8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿLÁB!J¡FaNáAI‘EŠªhŠ®Š©XŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ/ˆ’¬@ePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Rkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ÀQÍÑÃ1˱ÇqÏñÀ ȉÄIÌÉÂ)Ê©ÆiÎé Ó²è ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAò`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògñWówÿðOÿòoÿñ_ÿ ü?Að0»–mû±lÛ¶mÛ˶mÛ¶mÛ¶u‡‰P0‹pˆˆHˆŒ(@TDCtÄ@LÄBlÄA\ÄC|$@B$Bb$AR$Cr¤@J¤Bj¤AZ¤Czd@FdBf„`" ²"²#r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcb‚0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿŒÁ‚!Š¡†aŽá‰‘…ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌLÍ@faVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcà@bs‡r‡sGrGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(@QMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™Q’¨,ʪlʮʩ\Ê­<Ê«|ʯ*¨B*¬"*ªb*®*©R*­2*«r*¯ -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯j¨Fj¬&jªfj®j©Vj­6j«vj¯ê¨Nê¬.êªnê®ê©^ê­>ê«~ꯨA -Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýs0w‡t(‡v‡u8‡wGt$Gv8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³aZ¶ÅYÍÙÃ9˹ÇyÏù]À]È…]ÄE]ÌÅ]Â%]Ê¥]Æe]Îå]Á]É•]ÅU]ÍÕ]Ã5]˵]Çu]ÏõÝÀ ÝÈÝÄMÝÌÍÝÂ-ÝÊ­ÝÆmÝÎíÝÁÝÉÝÅ]ÝÍÝÝÃ=Ý˽ÝÇ}ÝÏý=À=ÈAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^î^éU^í5^ëu^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèOþì/þêoþîþé_þí?þëÁÿ€A³kÙ¶õX¶mÛ¶]˶mÛ¶mÛ¶u!¡aá‘Q€¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤H†äH”H…ÔHƒ´H‡ôÈ€ŒÈ„ÌÈ‚¬È†ìÁDäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ3C2C3 Ã2Ã3#2#3 -•Ñ1“±›q—ñŸ ˜‰˜˜I˜”ɘœ)˜’©˜ši˜–阞˜‘™˜™Y˜•Ù˜ )šÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄ æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?Sp…PH…Rh…QX…SxEPDERdEQ€¢*š¢+†b*–b+Žâ*žâ+*‘+‰’*™’+…R*•R+Ò*Ò+ƒ2*“2+‹²*›² ¢$+P9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç`îéPí0ëpïŽèHŽì(pTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvôl:‡s:—s;ó:Ÿó»€ º »ˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºš«»†kº–k»Žëºžë»º‘»‰›º™›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸû{€zƒ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üÓ¿üÛü×ÿƒý'ƒ fײm»˶mÛ¶–mÛ¶mÛ¶mëÁ! -¡aá ‘ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È €Œ@äA^äC~@ABaAQCq”@I”Bi”AY”CyT@ETBeTAUTCuÔ@MÔBmÔA]ÔC}4@C4Bc4AS4Cs´@K´Bk´A[´C{t@GtBgtAWtCwô@OôBoôA_ôC À@ Bc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ18C0$C14Ã0,Ã1<#0"#12£0€Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹ ’¢È<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈA â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þS0W…T(…V…U8…WET$EV(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)· J²•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5HA¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«æàáåÐã°çðŽàˆŽäÈŽâGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.ç6LËv ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x 9ȃ=ÄC=ÌÃ=Â#=Ê£=Æc=Îã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸýÅ_ýÍßýÃ?ýË¿ýÇý/ð?Að0Û¶më±jÙ¶mÛ®eÛ¶mÛ¶m[wÁ!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yù‚€‚(„ÂDE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ Å0 Ça$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³AR4X…X˜,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡ÆáÁ Žä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?Sp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~DIV€ -ª -+PETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ4XC4TÃ4\#¤‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç`îéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï†iÙpAraºˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºš«»†kº–k»Žëºžë»º‘»‰›º™›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸû{€z{ˆ‡z˜‡{„ƒ<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üÓ¿üÛü×ÿþ€A³m/Ûö#Û¶mÛزmÛ¶mÛ¶;Cp„@H„Bh„AX„CxD@DDBdDATDCtÄ@LÄBlÄA\ÄC|$@B$Bb$A’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ -¢ - £Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†b†cF"A…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX•X…ÕXƒµX‡õ؀؄ÍØ‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8“8…Ó8ƒ³8‡ó¸€‹¸„˸‚«¸†ë¸›¸…Û¸ƒ»¸‡ûx€‡x„Çx‚§x†çx—x…×xƒ·x‡÷ø€ø„Ïø‚¯ø†ïøŸø…ßøƒ¿øÇ` Î ÉP Í0 Ëp ÏŒÈHŒÌ(ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$ `R&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`Aba‚¤haQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcà@â`áPãpŽàH2ˆ£8šc8–ã8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿLÁB!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DJªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlʮʩ\Ê­<Ê«|ʯ*¨B*,ˆ’¬"*ªb*®*©R*­2*«r*¯ -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯j¨Fj¬&jªfj®j©Vj­6j«vj¯ê¨Nê¬.êªnê®ê©^ê­>ê«~ꯨA¬!ªa®©@i”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8ÀIÌÉÂ)Ê©ÆiÎéÁÉ™ÅYÍÙÃ9˹ÇyÏù]À]È… Ó²]ÄE]ÌÅ]Â%]Ê¥]Æe]Îå]Á]É•]ÅU]ÍÕ]Ã5]˵]Çu]ÏõÝÀ ÝÈÝÄMÝÌÍÝÂ-ÝÊ­ÝÆmÝÎíÝÁÝÉÝÅ]ÝÍÝÝÃ=Ý˽ÝÇ}ÝÏý=À=ȃ=ÄC=ÌÃ=Â#è òhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògñWówÿðOÿòoÿñ_ÿ'ƒ fÛ¶mתG¶mÛæ–mÛ¶mÛ¶mãî‚!8B $B!4 ,Â!<" ""!2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š EQ Å‚Q%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒˆ ÁP ÃpŒÀHŒÂhŒÁXŒÃxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üc0g†d(†f†e8†gFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!f°(‹±8AR4K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p q0Ä!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢U1DIV •T)•V•U9•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ× Ô V ‚4DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏÁÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØEà¢.æâ†iÙ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®áš®åڮ㺮çúnà†näÆnâ¦nææná–nåÖnã¶nçöîàŽîäÎîâ®îæîîážîåÞîã¾îçþàäÁt‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ù·ÿøï‚à0`v-Û¶mî‘mÛ¶[¶mÛ¶mÛ¶­»À†à…Ѓ°‡ðˆ€ˆˆ„Ȉ‚DE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D) £4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` !ƒ1C1 Ã1#1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññÁœ!’¡ša–áž‘‘™QÀ¨ŒÆèŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,Å@‚¤h–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ7ÿð/ÿ)˜‚+„B*”B+ŒÂ*œÂ+‚"*’"+ŠUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥(ˆ’¬Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤ Ö Õ0 ×Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖýÕ?sp‡pH‡rh‡qX‡sxGpDGrdGq€£:š£;†c:–c;Žã:žã;:‘;‰“:™“;…S:•S;Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿó»€ º »ˆ‹º˜‹»„Kº” Ó²]Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<ЃäÁâ¡æáá‘åÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßþãÿÁ`ÀìZ¶mÛÆÙ¶mcÙ¶mÛ¶mÛ¶îþþC0G„D(„F„E8„GDD$DF *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê!!åQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11AŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹ Æà Á ÅРð ÇðŒÀˆŒÄÈŒÂFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9$E³<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p 1ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOÁ\!R¡ZaVá^Q‘YQ ¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§@A”d•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ× Ô i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;ŠÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öåh˜–íò®àŠ®äʮ⪮æê®áš®åڮ㺮çúnà†näÆnâ¦nææná–nåÖnã¶nçöîàŽîäÎîâ®îæîîážîåÞîã¾îçþàä öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöŸÿÁ`ÀìZ¶mÛv{dÛ¶¹lÛ¶mÛ¶m[wÿ!‚#B"B# Â"Â#"""# -Ñ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•€ŒÊ¨‚ª¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†æh–h…Öhƒ¶h‡ö耎è„Îè‚®è†îèžè…Þ胾è‡þ€„ Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?cp†`H†bh†aX†cxF`DFbdFa£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+² ’¢Y™UX•ÕX5X“µX›uX—õXŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸ8ƒÄÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆéœÁ™œÅٜùœÇù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅßüÿü§` -® -©P -­0 -«p -¯Š¨HŠ¬( -PTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUR  J²*«Šªªšª«†jª–j«Žêªžê«ª‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:ª“:«‹ºª›º«‡zª—z«úªŸúk€j‚4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÌÁÂ!Ê¡ÆaÎáÁÉ‘ÅŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ4LËveWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sð@r{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û‡ú—û?Að0»–mÛ¶Í=²mÛ-Û¶mÛ¶mÛÖÝŸÀ¿ÿ Á! -¡aá ‘ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj@FuÔ@MÔBmÔA]ÔC}4@C4Bc4AS4Cs´@K´Bk´A[´C{t@GtBgtAWtCwô@OôBoôA_ôC À@ Bc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ18C0$C14Ã0,Ã1<#0"#12£0€Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYIѬάÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈA â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þS0W…T(…V…U8…WET$EV(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª)P%YÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5HA¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«æàáåÐã°çðŽàˆŽäÈŽâGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5¦e»ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x 9ȃ=ÄC=ÌÃ=Â#=Ê£=Æc=Îã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸýÅ_ýÍßýÃ?ýË¿ÿ€A³kÙ¶mÛÆÙ¶eÛ¶mÛ¶mÛº üø7ð‚!8B $B!4 ,Â!<" ""!2¢ Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q Á¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAÂ` ÁP ÃpŒÀHŒÂhŒÁXŒÃxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üc0g†d(†f†e8†gFd$Ff0*£1:c0&c16ã0.ã1>0!11“0)“19S0%S15Ó0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k1 )šµY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢EU4EW ÅT,ÅVÅU<ÅW%T"%V%U2%W -¥T*¥V¥U:¥WeT&eVeU6eWåT.åVåU>åWT!VU1W •T)•V•U9•WUT%UVUU5UW ÕT- -¢$«¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h )Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏÁÜ!Ò¡ÚaÖáÞÑ‘ÙQ਎æèŽá˜Žå؎㸎çøNà„NäÄNâ¤NæäNá”NåÔNã´NçôÎàŒÎäÌÎâ¬ÎæìÎáœÎåÜÎã¼Îçü.à‚.äÂ.â¢.æâ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®áš®å@ôl×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ù?Að0»–mÛ¶m·G¶m.Û¶mÛ¶mÛÖÝïÀ?ÿ!‚#B"B# Â"Â#"""# -Ñ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõ€Œúh€†h„Æh‚¦h†æh–h…Öhƒ¶h‡ö耎è„Îè‚®è†îèžè…Þ胾è‡þ€„ Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?cp†`H†bh†aX†cxF`DFbdFa£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë² ’¢YŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸ8ƒÄÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆéœÁ™œÅٜùœÇù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅßüÿü§` -® -©P -­0 -«p -¯Š¨HŠ¬( -PTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS  J²ê«ª‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:ª“:«‹ºª›º«‡zª—z«úªŸúk€j‚4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÌÁÂ!Ê¡ÆaÎáÁÉ‘ÅŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz4LËv}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sð@r{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û‡úׂà0`v-Û¶mÛæÙ¶[¶mÛ¶mÛ¶­»ÀßÿþC0G„D(„F„E8„GDD$DF *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !!!ÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11AŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹ Æà Á ÅРð ÇðŒÀˆŒÄÈŒÂFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#$E³1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p 1ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOÁ\!R¡ZaVá^Q‘YQ ¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤@A”d5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ× Ô i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;ŠÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐh˜–íÆnâ¦nææná–nåÖnã¶nçöîàŽîäÎîâ®îæîîážîåÞîã¾îçþàä öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô‚à0`v-Û¶mÛ6öȶ±lÛ¶mÛ¶m[w¿þ üøÁ!¡aá‘Q€¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤H†äH”H…ÔHƒ´H‡ôÈ€ŒÈ„ÌÈ‚¬È†ìȜȅÜȃ¼È‡ü(€‚(„Â(‚¢(†â(’(…Ò(ƒ²(‡ò¨€Š¨„ʨ‚ª¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†@„`4G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ3C2C3 Ã2Ã3#2#3 -•Ñ1“±›q—ñŸ ˜‰˜˜I˜”ɘœ)˜’©˜ši˜–阞˜‘™˜™Y˜•Ù˜9˜“¹˜›y˜—ù˜ŸX…X˜EX”ÅXœ%X’¥XšeX–åXžX‘•X™UX•ÕX5X“µX›uX—õXŸ ØؘMØ”ÍHÍælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄ æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?Sp…PH…Rh…QX…SxEPDERdEQ€¢*š¢+†b*–b+Žâ*žâ+*‘+‰’*™’+…R*•R+Ò*Ò+ƒ2*“2+‹²*›²+‡r*—r+ò*Ÿò«€ -ª -«ˆŠª˜Š«„Jª”J«ŒÊªœÊ«‚*ª’*«Šªªšª«†jª–j«Žêªžê«ª‘«‰šª™Q’Õ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç`îéPí0ëpïŽèHŽì(pTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvçpNçrnçq^çs~pAraqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7s aZ¶›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸû{€zƒ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üó?AðÀÀì¶mÛ¶mÛ\qÛ¶mÛ¶mÛ¶m&_ß?¿‚ †à…Ѓ°‡ðˆ€ˆˆ„Ȉ‚¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤H†äH”H…ÔHƒ´H‡ôÈ€ŒÈ„ÌÈ‚¬È†ìȜȅÜȃ¼È‡ü(€‚(„Â(‚¢(†â(’(…Ò(ƒ²(‡ò¨€Š¨„ʨ‚ª¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†æh– £Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ0(ƒ18C0$C14Ã0,Ã1<#0"#12£0*£1:c0&c16ã0.ã1>0!11“0)“19S0%S15Ó0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%IÑlÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆéœÁ™œÅٜùœÇù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅßüÿü§ -ª` -® -©P -­0 -«p -¯Š¨HŠ¬(ŠªhŠ®Š©XŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlʮʩ\Ê­<Ê«|ʯ*¨B*¬"*ªb*®*©R*­2*«r*¯ -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯j¨Fj¬&jªfj®j©€ J²Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9ˆƒ:˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†c:–c;Žã:žã;:‘;‰“:™“;…S:•S;Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿó»€ º »ˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºš«»†kº–k»Žëºžë»º‘»‰›º™›»…[:`˜–íVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^î^éU^í5^ëu^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèOþì/þêoþîþO<@@˶mÛ¶mÛøC¶mÛ¶mÛ¶mÛm?¿¿ÿA Á! -¡aá ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­Ñm@F;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?aPcp†`H†bh†aX†cxF`DFbdFaTFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[’¢ÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOATÁ\!R¡ZaVá^Q‘YQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVA”dµS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýsu0w‡t(‡v‡u8‡wGt$GvGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·uÀ0-ÛíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?þPÀ²mÛ¶mÛ¶ûC¶mÛ¶mÛ¶m[àgàWàwàOàoà‚ (‚!8B $B!4 ,Â!<" ""!2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #Áè„Îè‚®è†îèžè…Þ胾è‡þ€„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX•X…ÕXƒµX‡õ؀؄ÍØ‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8“8…Ó8ƒ³8‡ó¸€‹¸„˸‚«¸†ë¸›¸…Û¸ƒ»¸‡ûx€‡x„Çx‚§x†çx—x…×xƒ·x‡÷ø€ø„Ïø‚¯ø†ïøŸø…ßøƒ¿øÇ Ê` Î ÉP Í0 Ëp ÏŒÈHŒÌ(ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈAR4;±3»°+»±;{°'{±7û°/û±?p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ7ÿð/ÿ)ˆ‚*˜‚+„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢+†b*–b+Žâ*žâ+*‘+‰’*™’+…R*•R+Ò*Ò+ƒ2*“2+‹²*›²+‡r*—r+ò*Ÿò«€ -ª -«ˆŠª˜Š«„Jª”J«ŒÊªœÊ«‚*ª’*«Šªªšª«†jª–j«Žêªžê«ª‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:* ˆ’¬Nê¬.êªnê®ê©^ê­>ê«~ꯨA¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«â æàáåÐã°çðŽàˆŽäȎ⨎æèŽá˜Žå؎㸎çøNà„NäÄNâ¤NæäNá”NåÔNã´NçôÎàŒÎäÌÎâ¬ÎæìÎáœÎåÜÎã¼Îçü.à‚.äÂ.â¢.æâ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®áš®åڮ㺮çúnà†näÆnâ¦nææná–nåÖnã¶nçöîàŽ¦e»“;»‹»º›»»‡{º—{»ûºŸû{€z{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û?AðÀÀì¶mÛ¶mÛ6WܶmÛ¶mÛ¶m&??¿¿ÿA Á! -¡aá ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]@F7tGôD/ôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?aPcp†`H†bh†aX†cxF`DFbdFaTFctÆ`LÆblÆa\Æc|&`B&bb&aR&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaW’¢ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOATÁ\!R¡ZaVá^Q‘YQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUA”duSwõPOõRoõQ_õS Ð@ Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýsu0w‡t(‡v‡u8‡wGt$GvGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwuÀ0-ÛÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ô˼Ü+¼Ò«¼Úk¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüý?Að,Û¶mÛ¶mÛøC¶mÛ¶mÛ¶m·~~~~þþþ!‚"‚#B"B# Â"Â#"""# -¢"¢#b"b#â"â#"# ’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z"€Œ^è>è‹~èˆAŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹   Æà Á ÅРð ÇðŒÀˆŒÄȌ¨ŒÆèŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁž $E³{³û²ûsrs‡r‡sGrGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚(¨‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§‚(Éê¥Þꣾê§þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç ê`îéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé€aZ¶{¹·û¸¯û¹¿x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù?Að,Û¶mÛ¶mÛîÙ¶mÛ¶mÛ¶±}üü ü -üü ü üCE0G„D(„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE!ýÐ0ƒ0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿ„AŒÁ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡} HŠf?öçä æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?QPSp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_Q’ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏAÔÁÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ôl÷sð@ò`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògñWûO<°0»mÛ¶mÛ¶msÅmÛ¶mÛ¶m›Ià{àGàgàWàwàOàoà‚ (‚!8B $B!4 ,Â!<" ""!2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` Á„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX•X…ÕXƒµX‡õ؀؄ÍØ‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8“8…Ó8ƒ³8‡ó¸€‹¸„˸‚«¸†ë¸›¸…Û¸ƒ»¸‡ûx€‡x„Çx‚§x†çx—x…×xƒ·x‡÷ø€ø„Ïø‚¯ø†ïøŸø…ßøƒ¿øÇ Ê` Î ÉP Í0 Ëp ÏŒÈHŒÌ(ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAR4q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ7ÿð/ÿ)ˆ‚*˜‚+„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢+†b*–b+Žâ*žâ+*‘+‰’*™’+…R*•R+Ò*Ò+ƒ2*“2+‹²*›²+‡r*—r+ò*Ÿò«€ -ª -«ˆŠª˜Š«„Jª”J«ŒÊªœÊ«‚*ª’*«Šªªšª«†jª–j«Žêªžê«ª‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:ª“:«‹ºª›º«‡zª—z«úªŸúk€* ˆ’¬A¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«â æàáåÐã°çðŽàˆŽäȎ⨎æèŽá˜Žå؎㸎çøNà„NäÄNâ¤NæäNá”NåÔNã´NçôÎàŒÎäÌÎâ¬ÎæìÎáœÎåÜÎã¼Îçü.à‚.äÂ.â¢.æâ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®áš®åڮ㺮çúnà†näÆnâ¦nææná–nåÖnã¶nçöîàŽîäÎîâ®îæîîážîåÞîã¾îçþà¦e{{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú?Að,Û¶mÛ¶mÛ6þmÛ¶mÛ¶m·} |üü ü -üü ü üCE0G„D(„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ E!Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿ„AŒÁ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C HŠæ0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?QPSp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑPQ’5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏAÔÁÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔôlópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògñ×ÿÁ°lÛ¶mÛ¶mÛîÙ¶mÛ¶mÛÆøøøøøøøøø‡ Š`Ž‰P0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰B0Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ2ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrs‡r‡sG2@ÍQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¢  -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡‘ -¢$k”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ8¨ƒ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°‡x¨‡y¸Gx¤†iÙåÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâÿÁ°Û¶mÛ¶m۶ͷmÛ¶mÛ¶™| | |üü ü -üü ü üCE0G„D(„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒE!ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿ„AŒÁ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c HŠæ8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?QPSp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑP ÓpÐHÒhÑXQ’5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏAÔÁÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Ü#<Ò£<Úc<ÖôlóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògùO<@@˶mÛ¶mÛ¶mãÙ¶mÛ¶mÛm¯oïŸ_ß?¿‚ †à…Ѓ°‡ðˆ€ˆˆ„Ȉ‚¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤H†äH”H…ÔHƒ´H‡ôÈ€ŒÈ„ÌÈ‚¬È†ìȜȅÜȃ¼È‡ü(€‚(„Â(‚¢(†â(’(…Ò(ƒ²(‡ò¨€Š¨„ʨ‚ª¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†æh–h…Öhƒ¶h‡ö耎è„Îè‚®è†îèžè…Þ胾è‡þ€„Á‚¡†á‘…у±‡ñ˜€‰ c&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ0(ƒ18C0$C14Ã0,Ã1<#0"#12£0*£1:c0&c16ã0.ã1>0!11“0)“19S0%S15Ó0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"IÑœÄɜ©œÆéœÁ™œÅٜùœÇù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅßüÿü§ -ª` -® -©P -­0 -«p -¯Š¨HŠ¬(ŠªhŠ®Š©XŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlʮʩ\Ê­<Ê«|ʯ*¨B*¬"*ªb*®*©R*­2*«r*¯ -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯j¨Fj¬&jªfj®j©Vj­6j«vj¯ê¨Nê¬.êªnê®ê©^ê­>ê«~ꯨA¬!ªa®©Q­1«q¯ š¨€ J²&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9ˆƒ:˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†c:–c;Žã:žã;:‘;‰“:™“;…S:•S;Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿó»€ º »ˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºš«»†kº–k»Žëºžë»º‘»‰›º™›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸû{€z{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚':`˜–íIžì)žêižîžéYží9žëyžï^èE^ì%^êe^î^éU^í5^ëu^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèOþìÿÁ°lÛ¶mÛ¶mÛ¶ûC¶mÛ¶mÛÆö%ð5ð-ð=ð#ð3ð+ð;ð'ð7ðAÁ!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0#0£0c0ã00“0S0„`LÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üce0g†d(†f†e8†gFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0çŽä(ŽæŽå8ŽçNä$NæNe€ )šÓ838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿDALÁB!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ESDIÖ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖýÕ?qPsp‡pH‡rh‡qX‡sxGpDGrdGqTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvçpNçrnçq^çs~pAraqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sð@ò`ñPópðHòhñXóxOðDOòdOñT Ó²=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸÿl ÀnÛ¶mÛ¶m۶ͷmÛ¶mÛføøøøøøøøøøø‡ Š`Ž‰P0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰B0fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ2ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrs‡r‡sGrGs ÇrÇs'r's -§r§sg2@ÍYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¢  -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™ -¢$k–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ8¨ƒ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦†iÙžåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÿÁ°lÛ¶mÛ¶mÛ¶?dÛ¶mÛ¶Ýö9ð%ð5ð-ð=ð#ð3ð+ð;ð'ð7ðAÁ!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0#0£0c0ã00“0S0Ó030³0s0„`ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üce0g†d(†f†e8†gFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎe€ )šó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿDALÁB!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5GsDIÖ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖýÕ?qPsp‡pH‡rh‡qX‡sxGpDGrdGqTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvçpNçrnçq^çs~pAraqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sð@ò`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\ Ó²=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýé?Að,Û¶mÛ¶mÛ¶m»?dÛ¶mÛ¶±>¾¾¾¾~~~~þþþ!‚"‚#B"B# Â"Â#"""# -¢"¢#b"b#â"â#"# ’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæc"€ŒEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹   Æà Á ÅРð ÇðŒÀˆŒÄȌ¨ŒÆèŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆéœÁ™œÅٜùœÇù\À… $Ess —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚(¨‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡‚(ÉZ¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç ê`îéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^è€aZ¶y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£ÿ3Prža…÷½÷™™7¶m£1;icÛ:±mÛÆ<±m»IÛ6šÆ°>\ï‚ƒŸ‚Ÿƒ_‚_ƒß‚߃?‚?ƒ¿œ9:¹0çs~pž‹à"ºH.²‹â¢ºh.º‹ábºX.¶‹ãâºx.¾KàºD.±Kâ’ºd.¹KáRºT.µKãÒºt.½Ëà2ºL.³P -¡ÌCK¢•‡ŽD'݈î¦3˜/@_FÏ—‰¾’ž¯´ßך¾-Dú£ü1èð·§?<àïlþy>ÿ"X µ?P6¨Í£ü.‹ËB„0øàG" ""!2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;~CäD.äFäE>äGD!Æï(‚¢(†â(’¡·¥QeQåQQ àOTFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´G8: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1‚pX‚¥X†åX•X…ÕXƒµX‡õ؀؄ÍØ‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8¿p§ð7þÁiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á¿x‹ÿðïñÁª[ «iµ¬¶Õ±ºVÏê[kh¬±5±¦ÖÌš[ ki­¬µµ±¶ÖÎÚ[¸u°ŽÖÉ:[ëjݬ»õ°žÖËz[ëký¬¿ °6ÈÛjÃl¸°‘6ÊFÛkãl¼M°‰6É&Û›jÓlºÍ°™6ËfÛ›kól¾-°…¶È[Ðœ-±¥¶Ì–Û -[i«lµ­±µ¶ÎÖÛÛh›l³m±­¶Í¶ÛÛi»l·í±½¶ÏöÛ;h‡ì°±£vÌŽÛ ûËNÚ)ûÛþ±ÓvÆÎÚ9;oì¢]²ËvÅ®Ú5»n7ì¦Ý²ÛvÇîÚ=»oì¡=²ÇöÄžÚ3{n/쥽²×öÆþµ·öŸ½³÷öÁ>Ú'ûl_ì«}³ïöÃ~Ú/‚FR £~è1#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³ó7æ`Næbnæa^æc~`AbaþÎ",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJüƒ²2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=ÃÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¤ã.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1牺'y*¤î?<Í3<Ës<Ï !/ñrÈß«¼Æë¼Á›¼ÅÛ!‰ï†¾Ï|’ø1ŸðiÈâç|Á—|Å×|Ãù–ÿ…d~rù#?ñsHæ¯üÆïüÁŸü%ÈDIaòɯ€ !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$ÞÁ»xïã|ˆð1>Á§ø Ÿã œÂiœÁYœÃy\ÀE\Âe\ÁU|‰¯p ×q7q ·qwq÷ñññOñ Ïñ5¾Á·øßãüˆŸð3~Á¯ø ¿ãü‰¿ð7þÁ¿ø/ð¯ðoƒ1‹ )šc3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ßbAbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖàÛ¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<Éwø.ßãûü€ò#~ÌOø)?ãçü‚§xšgx–çxžx‘—x™Wx•_ò+^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãsÅT,A”dEŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlʮʩ\Ê­<Ê«|ʯzKUH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUCo«¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤^è¥^éµÞ8†c:–ƒaZ¶#ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çw¿å‚.äÂ.â¢.æâ.á’.åÒ.ã².çò®àŠ®äʮ⪮æê®ñÿ'Õt-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô;~×ïù}àý‘?ö'þÔŸùsáS>í3>ës>ï ¾èK¾ì+¾ê/ý•¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹¿ö7þÖßù{ÿàý“ö/þÕ¿ùwÿá?ý—ÿö?þ×ÿù…_ú•_ûM#ŠÅŠB„ˆ‘"GQ;ŠÅâEñ£QÂ(Q”8J%’EÉ£QÊ(U”:J¥ÒEé£ QÆ(S”9ÊeýAðÔ@0÷ð³eÛµlײm›Ë¶m·¶lÛ¶mÛ»C2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGü‰‚(„Â(‚¢(†â(’(…Ò(ƒ²(‡ò¨€Š¨„ʨ‚ªø ÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐcbc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVã¬Á¿øk±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿‚!Š¡†aŽá ’¢0#2#3 -£2£3c2c3ã2ã323 “ò&cr¦`J¦bj¦aZ¦czf`FfbffaVfcvæ`Næbnæa^æc~àŸ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Ê¿XÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùýù7p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5ÿáþËÿ¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø[!R¡ZaVá^%Y"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©þP2%W -¥T*¥V¥U:¥WeT&eVeU6eWåT.åVåU>åWý©‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªúKÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_k€jkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•Vë­Ñ¿úOkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿Â!Ê¡ÆaÎá Ó²8‚#:’#;Š£:š£;†c:–c;Žã:žã;:‘;‰“ú'sr§pJ§rj§qZ§szgpFgrfgqVgsvçpNçrnçq^çs~ðŸ.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®ê¿\ÍÕ]Ã5]˵]Çu]ÏõÝÀ ÝÈÝÄMÝÌÍÝÂ-ÝÊ­ÝÆmÝÎíÝÁÝÉÝÅ]ÝÍÝÝÃ=Ý˽ÝÇ}ÝÏýý·x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµÿñÿëÿ¼Öë¼Þ¼Ñ›¼Ù[¼ÕÛ¼Ý;¼Ó»¼Û{¼×û¼ß|Ї|ØG|ÔÇ|Ü'|Ò§|Úg|Öç|Þ|Ñ—|ÙW|Õ×|Ý7|Ó·|Ûw|×÷|ßüÐüØOüÔÏüÜ/üÒ¯üÚoüÖïüÞüÑŸüÙ_üÕßüÝ?üÓ¿ü;„ B¡ƒ0AØ \>@À@ƒ ˆD "‘ƒ(AÔ Z=ˆÄ b±ƒ8AÜ ^?H$ ‰ƒ$AÒà‚਀`æÃÏ6—íZ¶mÛvmÙ¶ÍåÚ²mÛ¶íÝ%Cr¤@J¤Bjü4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|ÈøQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}ÑýñþÆ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ÌÄ,ÌÆÌÅ<ÌÇ,Ä",Æ,Å2,Ç -¬Ä?X…ÕXƒµX‡õ؀؄ñ6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~3C2C3 Ã2Ã3#2#$E3`Fe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦æLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À?Y…X˜EX”ÅXœ%X’¥XšeX–åXžX‘•X™UX•ÕX5X“µX›uX—õXŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸñoà@â`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áR.ãr®àJþÃU\Í5\Ëu\Ï ÜÈMü—ÿq3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ·B(¤B)´Â(¬Â)¼"(¢")² J²EQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rjý¡4J«tJ¯ ʨLʬ,ʪlʮʩ\Ê­<Ê«|ʯúSUH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOýõ—þÖ Ô Ö Õ0 ×Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô?Z¥ÕZ£µZ§õÚ Ú¤õŸ6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~;„C:”C;ŒÃ:œÃ;‚#:’#¦e;pGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§öNã´NçôÎàŒÎäÌÎâ¬ÎæìÎáœÎåÜÎã¼Îçü.à?]Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜßùoð@ò`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJÿãU^í5^ëu^ï ÞèMþ×ÿy³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ùw"„ -Ba‚°A¸ |!ˆD -"(pQ‚¨A´ z#ˆÄ -bq‚¸A¼ ~ H$ -I‚¤ÿ@³ñð³·l»–mÛ¶e·Õ²mÛ¶mÛ6w‡?‘É)©ié™YÙ9¹yù¡ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úão À@ Â` ÁP ÃpŒÀHŒÂhŒÁXüƒ1ãñ&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7C0$C14Ã0,Ã1<#0"#12£0*£1:AR4Æ`LÆblÆa\Æc|&`B&bb&áü“I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùù ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±:k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?ÿæä æå0çŽä(ŽæŽå?ü—ã8žÿq'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óò+„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢ ¢$+P ÅT,ÅVÅU<ÅW%T"%Vý¡?•TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_©€ -ª -«ˆŠª˜Š«„Jª”J«ŒÊªœÊ«‚*ª’*«Šªªšª«†jª–j«Žêªžê«ª‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:ª“:«‹ºª›º«‡zª—z«úªŸúëo Ð@ Ò` ÑP ÓpÐHÒhÑXý£5NãõŸ&h¢&i²¦hª¦iºfh¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºaZ¶ÇpLÇrlÇq\Çs|'pB'rb'ñþÓIÌÉÂ)Ê©ÆiÎéÁÉ™ÅYÍÙÃ9˹ÇyÏùý— ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿ÿöô öõ0÷ô(öõ?þ×ã<Þÿy‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û‡ú—!‚A¨ t&„ ‚ˆA¤ r%ˆD ¢(p1‚˜A¬ v'ˆÄ â ‚„A¢ q$øŸ xê ˜í~6–íZ¶mÛvmٶ͵eÛ¶mÛ®Ý%E2$G -¤D*¤ÆHƒ´H‡ôÈ€ŒÈ„ÌÈ‚¬È†ìȜȅÜȃ¼È‡ü(€?Q…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐáo À@ Â` ÁP ÃpŒÀHŒÂhŒÁXŒÃxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJüƒUøÿa5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7C0$C14Ã0,Ã1<#0"#12£0*£1:c0&c16AR4Æa\Æc|&`B&bb&aR&cr¦`J¦bjþÁ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏü“Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùýùÿæä æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä?\ÅùWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óò+„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢+†b*–b ¢$+PÅU<ÅW%T"%V%U2%W -¥T*¥ÖJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ?UP…TXETTÅT\%TR¥TZeTVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_éo Ð@ Ò` ÑP ÓpÐHÒhÑXÓxMÐDMÒdMÑTMÓtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJý£UúWÿiµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶aZ¶Çq\Çs|'pB'rb'qR'sr§pJ§rjÿá4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|ÎïþÓ]È…]ÄE]ÌÅ]Â%]Ê¥]Æe]Îå]Á]É•]ÅU]ÍÕ]Ã5]˵]Çu]ÏõÝÀ ÝÈÝÄMÝÌÍÝÂ-ÝÊ­ÝÆmÝÎíÝÁÝÉÝÅ]ÝÍÝÝÃ=Ý˽ÝÇ}ÝÏýý—ÿöô öõ0÷ô(öõ8÷Oô$OöOõ4O÷ Ïô,ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô?^åýŸW{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û‡ú—!‚A¨ t&„ ‚ˆA¤ r%ˆD ¢1‚˜A¬ v€€A'ˆÄ â ‚„A¢ qä‚਀`¶ùðÃò²]˶–mÛX¶msiÙ¶mÛ6w‡$HŠdHŽH‰Tø©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùñ -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ªáoTG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?üƒþ€„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX±«°k°ÿaÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã$E3`&d"&æL¤LÆäLÁ”LÅ?™ši˜–阞˜‘™˜™Y˜•Ù˜9˜“¹˜›y˜—ù˜Ÿ± ² ³‹²‹³K²K³ ˲˳+²+³ -«²ÿfuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öã?ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Îü—+¹Š«¹†kù×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ·B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾ J²%PB%Rbý¡$JªdJ®J©TúS©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•Oùõ— -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªªéoUW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?ý£þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡µR«´Zk´VÿiÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†c:–c;Žã:žã¦e;p't"'öNâ¤NæäNá”Nå?ÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß¹€ º »ˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºšÿvu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷ó?îïèAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^îþ×+½Ê«½ÆkýŸ×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ùw"„ -Ba‚°A¸ |!ˆD -"Q‚¨A´ z#ˆÄ -bq‚¸A¼ ~€€A H$ -ÿ@³m<üܲÍeÛ¶m..Û6—k˶mÛ¶w—I‘ É‘)‘ -©ñÒ -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0þDE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ_€„Á‚¡øÃ0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°ÿ`Vc ÖbÖc6bþÅØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_øÍ ÉP Í0 Ëp ÏŒÈHŒÌ(ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLLÍ€I˜”ɘœ)˜’©˜š0 Ó2Ó33233 ³2³3s2s3ó2ó³ ² óOaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öcþÅÈAÌ!Ê¿9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+ùWq5×p-×q=7p#7ñ_þÇÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅß -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤Ä‚(É -”DI•LÉ•B)•J©õ‡Ò(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°þTU1W •T)•V•U9•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ×_ ¤Á¢¡ú[Ã4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´Rÿh•VkÖjÖkƒ6j“þÕÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_úíéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNl˜–íÀIœÔÉœÜ)œÒ©œÚ8Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿó»€ º ûOqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sÿåèAì!ê¿=ÌÃ=Â#=Ê£=Æc=Îã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+ýWyµ×x­×y½7x£7ù_ÿçÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßAˆ d*„ Âá‚ðA„ b)ˆD ¢Ñ‚èAŒ f+ˆÄ âñ‚øA‚ a(H ` ÀAð?AðÔ@0›[æÃoÙæ²mÛ¶k˶í–mÛ¶mÛØÁ !9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /òáoäGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôÅ?øýÐ0ƒ0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°ÿa –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~3C2C3 Ã2Ã3#2#3 -£2£3còþÉXŒÍ8ŒËxŒÏLÈDLÌ$LJÍ€Éø“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ÿf~`AbaaQcq–`I–bi–aY–cyV`EVbeVaUVcuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_þÃÙý9€9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹ù—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ·B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦þПŠ¥ØŠ£¸Š§øJ „J¤ÄJ¢¤‚(É -”L)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯òéoåWT!VU1W •T)•V•U9•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõÕ?úWýÔ_4Pƒ4XC4TÃ4\#4R£4Zc4Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´Xÿi‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†cúÿéXŽí8ŽëxŽïNèDNì$Nj˜–íÀÉü—“;…S:•S;Ó:Ó;ƒ3:“3;‹³:›³;‡s:—s;ó:Ÿÿv~pAraqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_ÿãÝÏý=À=ȃ=ÄC=ÌÃ=Â#=Ê£=Æc=Îã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹ýŸ—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ùw"„ -Ba‚°A¸ |!ˆD -"Q‚¨A´ z#ˆüüÄ -bq‚¸A¼ ~ H$ -I‚¤ÁÿÁÀWපjÙÖ9ß{ïɶmÛ®ßýζmÛ¶kÌma®¶ÜÖVCµ…=OD!@08xEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ‚P„!ˆD#1ˆEâ‘€D ÁP ÃpŒÀHŒÂhŒÁXŒÃxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃ'øŸás|/qp—pWp×ð¾ÆuÜÀMÜÂ7øßá{ü€ñnãîâgü‚{¸xˆGxŒ'xŠ_ñžáwüçx?ñþÆ?x‰WxñÞà-Þá=“ð~ȤLÆäLÁ”üˆ©˜šiø1Ó2Ó33233 ³2³3s2s3ó2ó³ ² $=Å",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈA a(ÃÎF2ŠƒÍÆ2ŽñL`"‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñ~ÊÏø9¿à—<Ï ¼ÈK¼Ì+¼ÊküŠ_ó:oð&oñ~Ëïø=àü‰·y‡wù3á=Þç>ä#>æ>å¯üÏø;ÿàs¾àŸü‹ó¾ä+¾æ¿üoø–ïø>H||$ ’ɃAÊ࣠U:H|¤ Òéƒ AÆ S9Èd B‚Ð ,"‚È *D1AlÄ A¢e¶,–Õ²YvËa9-—å¶<–×òY~+`­6-03gÞdE¬¨³âVÂJZ)+me¬¬•³òVÁ*Z%«lU¬ªU³êVÃjZ-«mu¬®Õ³úÖÀZ#klM¬©5³æÖÂZZ+kmm¬­µ³öÖÁ:Z'ël]¬«u³îÖÃzZ/ëm}¬¯õ³þ6ÀÚ ±P ³p‹°H‹²Ám1kqo –hCl¨ ³á6ÂFÚ(mcl¬³ñ6Á&Ú$›lSlªM³é6ÃfÚ,›msl®Í³ù¶ÀÚ"[lKl©-³å¶ÂVÚ*[mkl­­³õ¶Á6Ú&Ûl[l«m³í¶ÃvÚ.Ûm{l¯í³ývÀÚ!;lGì¨s=\O×Ëõv}\_×ÏõwÜ@7È…¸PæÂ]„‹tQn°‹v1.ÖŹx—àÝ7Ô sÃÝ7Òr£Ý7ÖsãÝ7ÑMr“Ý7ÕMsÓÝ 7ÓÍr³Ý7×ÍsóÝ·Ð-r‹Ý·Ô-sËÝ -·Ò­r«Ý·Ögð}&ŸÙgñY}6ŸÝçð9}.ŸÛçñ×üWþkÝßð7ý-ÿÿÖç¿÷?øýOþ¶¿ãïúŸý/þž¿ïø‡þ‘ìŸø§þWÿ›æ÷øçþ…ÿÓÿåÿöÿø—þ•íÿõÿù7þ­çß+‰>ЇJªdJ®J©”J©•F+­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©° *ÉÉK*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤…*LáŠP¤¢4XÑŠQ¬â¯%jˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœ>ѧúLŸë }©óº ‹º¤Ëº¢«ºö?AðEt¶móß{ß›mÛv[ͬÕV³m{µÕÌÂlÛ¶×9áx8N†Sát8Άsá|¸.†Kár¸®†káz¸n†[áv¸î†{á~x†Gáqxž†gáyx^†WáuxÞ†wá}ø>†Oásø‚ˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ€ Ž\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vø -­Ñ_ã´E;´GtD'tFtE7tG|‹ïнÐ}ÐýÐ0ƒð=~ÀŒ!ø ?c(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%VáüŠÕXƒßð;ÖbÖc6b6c ¶b¶cþÀŸØ‰]Ø=Ø‹}ø ûqqãü‹ÿpGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9’¢Ñ™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ_±5Ûðk~ölÇöìÀŽìÄÎì®ìÆîìÁoù{²{³û²ûsr¿çü‘ƒ9„?ñgå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*þÂ_¹škøçZ®ãznàFnâfnáVnãvîàü“;¹‹»¹‡{¹q?ð ñoþÃùóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó‹"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§‚ J2¹r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Zé+µV}­oÔVíÔ^ÔQÔY]ÔUÝÔ]=ô­¾SOõRoõQ_õS Ð@ Ò÷úA?j°†è'ý¬¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥_ô«Vk~ÓïZ«uZ¯ Ú¨MÚ¬-ÚªmÚ®úCj§vi·öh¯öé/í×Ô!ý­ô¯þÓaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}±Ñ"Yd‹bQ-šE·ÓbYl‹cq-žÅ·–ÐYbKbI-™%·–ÒRYjKci-¥· –Ñ2YfËbY-›e·–Ó‚Áh23·\–ÛòX^Ëgù­€´BVØŠXQ+fÅí°±£vÌŽÛ ;i§ì´±³vÎÎÛ»h—ì²]±«vÍ®Û »i·ì¶Ý±»vÏîÛ{hì±=±§öÌžÛ {i¯ìµ½±·öÎÞÛûhŸì³}ñÑ#ydâQ=šG÷Ócylãq=žÇ÷žÐybOâI=™'÷žÒSyjOãi=§÷ žÑ3yfÏâY=›g÷žÓƒÃérs÷\žÛóx^Ïçù½€ôB^Ø‹xQ/掄—ôR^ÚËxY/ç彂WôJ^Ù«xU¯æÕ½†×ôZ^Ûëx]¯çõ½7ôFÞØ›xSoæͽ…·ôVþ?AðÆ0¶ÍÆÆíí~؆mlÛ¶mÛ¶mÛ¶mÛvgêY}k` ­‘5¶&ÖÔšYska-­•µ¶6ÖÖÚY{ë`­“u¶.ÖÕºYwëa=­—õ¶>Ö×úY`m ¶!6Ô†Ùpa#m”¶16ÖÆÙx›`m’M¶)6Õ¦Ùt›a3m–Ͷ96×æÙ|[` m‘-¶%¶Ô–Ùr[a+m•­¶5¶ÖÖÙzÛ`m“m¶-¶Õ¶ÙvÛa;m—í¶=¶×öÙ~;`í¶#vÔŽÙq;a'픶3vÖÎÙy»`í’]¶+vÕ®Ùu»a7í–ݶ;v×îÙ}{`í‘=¶'öÔžÙs{a/핽¶7öÖÞÙ{û`í“}¶/öÕ¾Ùwûa?í—ý¶?…Ѓ°‡ðˆ€ˆˆ„Ȉ‚¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤ø É)©ié™YÀA²!;r 'r!7þÆ?ȃ¼È‡ü(€‚øÿ¡ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ã‡ðÊC{ëá<¼GðˆÉ#{êÑ<ºÇð˜Ëc{ëñ<¾'ð„žÈ{Oêy2Oî)<¥§òÔžÆÓz:Oï<£gò̞ųº9Ü.<›g÷žÓsynÿÛÿñ<ž×óy~/àý_ÿÏ ya/âE½˜÷^ÒKyi/ãe½œ—÷ -^Ñ+ye¯âU½šW÷^Ókym¯ãu½ž×÷ÞÐycoâM½™7÷ÞÒ[ykoãm½·÷ÞÑ;ygïâ]½›w÷ÞÓ{yoïã}½Ÿ÷÷>Ðù`âC}˜÷>ÒGùhãcša–áž‘‘™Q•Ñ1“±›q—ñŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸ8ƒ8˜C8”Ã8œ#8’£8šc8–ã8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›B!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DIõ—’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«L‹’eSvåPNåRný­”Gy•OùU@õ¯þS!VU1W •T)•V•U9•WUT%UVUU5UW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?õ× Ô Ö Õ0 ×Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖŸ D2„ÂaƒpAø B1ˆD¢QƒhAô F3ˆÄâqƒxAü A0H$’Iÿ'€:(fÛZÖ2~\¶µlÛƲm›K˶mÛ¶¹;$E2$G -¤D*¤F¤E:¤ÇŸÈ€ŒÈ„ÌÈ‚¬È†ìÈœÁ ¹‘y‘ùñ -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ªáoTG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?üƒþ€„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX±«°k°ÿaÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 ÿ`R&cr¦`J¦bj¦aZ¦czþÉ ÌÈLÌÌ,ÌÊlÌÎÌIÍ€¹˜›y˜—ù˜Ÿ± ² ³‹²‹³K²K³ ˲˳+²+³ -«²ÿfuÖ`MÖbmÖa]Öc}6`C6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaWvcwö`Oöboöa_öã?ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Îü—+¹Š«¹†kù×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ·B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’è%U2%W -¥T*¥V¥U:¥×ŸÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œ‚(É -”K¹•Gy•Oùõ— -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªªéoUW ÕT-ÕVÕU=ÕW5T#5V5U35W µT+µVµU;µWuT'uVuU7uWõT/õVõU?ý£þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡µR«´Zk´VÿiÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†c:–c;Žã:žã;:‘;‰ÿpR'sr§pJ§rj§qZ§szÿé ÎèLÎì,ÎêlÎîÎi˜–íÀ¹œÛyœ×ùœß¹€ º »ˆ‹º˜‹»„Kº”K»ŒËºœË»‚+º’+»Š«ºšÿvu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷ó?îïèAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^îþ×+½Ê«½ÆkýŸ×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ùw"„ -Ba‚°A¸ |!ˆD -"Q‚¨A´ z#ˆÄ -bq‚¸A¼ ~ H$ -I‚ÿ ‚  -€Ù¶­e÷ðkÙÖ²m»¶lÛæÒ²mÛ¶mî.)’!9R %R!5Ò -Ò!=2àdD&dFdE6dGäD.äFäE>„`ÈøQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ Õñj &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /úáoüƒþ€„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX±«°k°ÿaÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó3ÿ`FfbffaVfcvæ`Næbnæa^æ#HŠfÀü,À?Y…X˜EX”ÅXœ%X’¥XšeX–åXžX‘•X™UX•ÕX±k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ÿæ?ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Îü—+¹Š«¹†kù×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ·B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2èeT&eVeU6eWåT.åVåU>A”dʯúSUH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕõ—j¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯úéoý£þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡µR«´Zk´VÿiÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~;„C:”C;ŒÃ:œÃ;‚#:’#;Š£:š£;†c:–c;Žã:žã;:‘;‰“:™“;…S:•S;Ó:Ó;ƒÿpFgrfgqVgsvçpNçrnçq^ç3LËvàü.à?]Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\ݹ†kº–k»Žëºžë»º‘»‰›º™›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸÿö?îïèAì!êaîéQí1ëqï žèIžì)žêižîžéYží9žëyžï^èE^ì%^êe^îþ×+½Ê«½ÆkýŸ×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ùw"„ -Ba‚°A¸ |!ˆD -"Q‚¨A´ z#ˆÄ -bq‚¸A¼ ~ H$ -Iþ'€:(æZ6—mûág»eÛ¶¶lÛvkÙ¶mÛ¶Û# ’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ - #@!FE1G ”D)”F”E9”GTD%TFTÅ_¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†æh–h…Öhƒ¶h‡ö耎è„Îè‚®è†îèžè…Þ胾臿ñúcbc†b†cFbFc ÆbÆc&b&c -¦b¦cfbfcæbæcbc –b–cVbþÅjü‡5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_øÍ ÉP Í0 Ëp Ïüƒ‰‘…Qу1‹±‡qñ™€ ™ˆ21“0)“19S0%S15Ó0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° AR4baaQcq–`I–bi–aY–cyV`EVbeVaUþÅj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ü›ÿ°?p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—q9Wp%Wñ_®æ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅß -¡ -¥Ð -£° -§ðŠ ?Q‘YQUÑ]1S±[qWñ_ ”P‰ô§+‰’*™’+…R*•R+Ò*Ò+ƒ2*“2+‹²*›²+‡r*—r+ò*Ÿò«€ - -¢$+P!VU1W •T)•V•U9•WUT%UVUÕ_ª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾ꧿õúk€jkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•þÕjý§5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_úíéPí0ëpïþÃÉ‘ÅQÍÑÃ1˱ÇqÏñÀ È:±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸ aZ¶raqQsq—pI—ri—qY—syWpEWreWqUÿåj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~þÛÿ¸¿x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wù_¯ö^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßAˆ d*„ Âá‚ðA„à b)ˆD ¢Ñ‚èAŒ f+ˆÄ âñ‚øA‚ a(øŸ xã‚Û¶m{¿{±mÛ¶mÛncÛ¶´m;éL$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1`@Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽø c%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6þÁ¿øwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ð,„…´PÚÂXX gá-‚E´HÙ¢XT‹fÑ-†Å´XÛâX\‹gñ-%´D–Ø’XRKfÉ-…¥´T–ÚÒXZKgé-ƒe´L–Ù²XVËfÙ-‡å´\–ÛòX^Ëgù­€´BVØŠXQ+fÅ fMæVÂJZ)+me¬¬•³òVÁ*Z%«lU¬ªU³êVÃjZ-«mu¬®Õ³úÖÀZ#klM¬©5³æÖÂZZ+kmm¬­µ³öÖÁ:Z'ël]¬«u³îÖÃzZ/ëm}¬¯õ³þ6ÀÚ lCl¨ ³á6ÂFÚ(mcl¬³ñ6Á&Ú$›lSlªM îwƒ{ÁýàAð0x<žOƒgÁóàEð2x¼ÞoƒwÁûàCð1ø|¾_ƒoÁ÷àGð3øüþ0C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹4$Eg –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -þÅ¿¹’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›ÿð_þÇ;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ? -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â‚L(ÉUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵Béo­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝöÓcylãq=žÇ÷žÐybOâI=™'÷žÒSyjOãi=§÷ žÑ3yfÏâY=›g÷žÓsynÏãy=Ÿç÷^Ð ya/âE½˜w¸yàt¹{ /饼´—ñ²^ÎË{¯è•¼²Wñª^Í«{ ¯éµ¼¶×ñº^Ïë{oè¼±7ñ¦ÞÌ›{ oé­¼µ·ñ¶ÞÎÛ{ïè¼³wñ®ÞÍ»{ïé½¼·÷ñ¾ÞÏûûèƒ|°ñ¡>̇ûé£|´ñ±>ÎÇûŸè“|²Oñ©>ͧû Ÿé³|öÿÁ€°Ù¶mÛÞ®íͶmÛÖc¶mÛ¶mÛ6›i³l¶Í±¹6ÏæÛ[h‹l±-±¥¶Ì–Û -[i«lµ­±µ¶ÎÖÛÛh›l³m±­¶Í¶ÛÛi»l·í±½¶ÏöÛ;h‡ì°±£vÌŽÛ ;i§ì´±³vÎÎÛ»h—ì²]±«vÍ®Û »i·ì¶Ý±»vÏîÛ{hì±=±§öÌžÛ {i¯ìµ½±·öÎÞÛûhŸì³}±¯ö;Ûûi¿ì·ý±¿ö!¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥Pe`ÁQåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0#0£0c0D‚1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± ˱+± -«±k±ë±± ›±[± Û±;± »±{±ûqq‡qGq Çq'q -§qgqçqq —qWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿñ_ñ ßñ?ñ ¿ññ!’¡ša–áž‘‘™Q•Ñ1“±›q—ñŸ ˜‰˜˜I˜”ɘœ)˜’©˜ši˜–阞˜‘™˜™Y˜•Ù˜9˜“¹˜›y˜—ù˜ŸX…X˜EX”ÅXœ%X’¥XšehIÑY–åXžX‘•X™UX•ÕX5X“µX›uX—õXŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸ8ƒ8˜C8”Ã8œ#8’£8šc8– dƒ9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùO!R¡ZaVá^Q‘YQUÑ]1S±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZed‚(ÉUVåT^TQ•TYUTUÕT]5TSµT[uTWõT_ ÔPÔXMÔTÍÔ\-ÔR­ÔZmÔVíÔ^ÔQÔY]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4Pƒ4XC4TÃ4\#4R£4Zc4V -T‚5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏCxHå¡=Œ‡õpÞ#xDä‘=ŠGõhÝcxLå±=ŽÇõxßxBOä‰=‰'õdžÜSxJOå©=§õtžÞ3xFÏä™=‹gõlžÝsxNÏå¹=çõ|žß xA/ä…½ˆõb^ÜKxI/好Œ›Ãér÷²^ÎË{¯è•¼²Wñª^Í«{ ¯éµ¼¶×ñº^Ïë{oè¼±7ñ¦ÞÌ›{ oé­¼µ·ñ¶ÞÎÛ{ïè¼³wñ®ÞÍ»{ïé½¼·÷ñ¾ÞÏûûèƒ|°ñ¡>̇ûé£|´ñ±àäÁ>ÎÇûŸè“|²Oñ©>ͧû‚à@`¶mÛ¶ë«ÛÝ˶mÛþÿlÛ¶mÛ¶mÏÌ°™6ËfÛ›kól¾-°…¶ÈÛ[jËl¹­°•¶ÊVÛ[kël½m°¶É6ÛÛjÛl»í°¶ËvÛÛkûl¿°ƒvÈÛ;jÇ츰“vÊNÛ;kçì¼]°‹vÉ.Û»j×ìºÝ°›vËnÛ»k÷ì¾=°‡öÈÛ{jÏì¹½°—öÊ^Û{kïì½}°öÉ>Ûûjßì»ý°ŸöË~Ûûkÿ! -¡aá ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥Q(‹r(@Ž -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰Q1D‚1ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†,Ër,O#HŠÎ -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌ!ÊaÎÉQÍ1 dƒ9–ã8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿB!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UF*«r*/DI® -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯j¨Fj¬&jªfj®j©Vj­6j«vj¯ê¨Nê¬.êªnê®ê©^ê­>ê«~ꯨA¬!ªa®©Q­1 -T‚5Vã4^4Q“4YS4UÓ4]34S³4[s4Wó4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿ<„‡ôPÚÃxXçá=‚GôHÙ£xTæÑ=†ÇôXÛãx\çñ='ôDžØ“xROæÉ=…§ôTžÚÓxZOçé=ƒgôLžÙ³xVÏæÙ=‡çô\žÛóx^Ïçù½€ôB^Ø‹xQ/掄—ôR^ÚËx€—õr^ÞÍát¹{¯è•¼²Wñª^Í«{ ¯éµ¼¶×ñº^Ïë{oè¼±7ñ¦ÞÌ›{ oé­¼µ·ñ¶ÞÎÛ{ïè¼³wñ®ÞÍ»{ïé½¼·÷ñ¾ÞÏûûèƒ|°ñ¡>̇ûé£|´ñ@ò`ëã|¼Oð‰>É'ûŸêÓ|ú‚à@`6?Û¶m÷Ýî^¶mÛ¶ë«Ï¶mÛ¶m[36ÓfY°Í¶96×æÙ|[` m‘-¶%¶Ô–Ùr[a+m•­¶5¶ÖÖÙzÛ`m“m¶-¶Õ¶ÙvÛa;m—í¶=¶×öÙ~;`í¶#vÔŽÙq;a'픶3vÖÎÙy»`í’]¶+vÕ®Ùu»a7í–ݶ;v×îÙ}{`í‘=¶'öÔžÙs{a/핽¶7öÖÞÙ{û`í“}¶/öÕ¾Ùwûa?í—ý¶?ö×þ!B"B# Â"Â#"""# -¢"¢#b"±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP¨@ŽÊ¨‚ª¨†ê¨š¨…Ú¨ƒº¨‡úh€†h„Æh‚¦h†æh–h…Öhƒ¶h‡ö耎è„Îè‚®è†îèžè…Þ胾è‡þ€„Á‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é ÌÄ,c6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1C2C3 Ã2Ã3#2#3 -£2£3c2€±›q—ñŸ ˜‰˜˜I˜”ɘœ)˜’©˜ši˜–阞˜‘™˜™Y˜•Ù˜9˜“¹˜›y˜—ù˜ŸX…X˜EX”ÅXœ%X’¥XšeX–åXžX‘¬D#HŠÎʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆé â Îä,s6çp.çq>p!q1—p)—q9Wp%Wq5×p-×q=7p#7q3·p+·q;wp'wq7÷p/÷q?ð ñ0ð(ñ8Oð$Oñ4Ïð,Ïñð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ3¿ð+¿ñ;ð'ñ7ÿð/ÿ)„B*”B+ŒÂ*œÂ+‚"*’"+Š¢*š¢+†b*@±[qWñ_ ”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]9”S¹”[y”Wù”_TP…TXETTÅT\%TR¥TZeTVåT^TQª$DI®Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦é -Ò ÍÔ,k¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þyé¡<´‡ñ°ÎÃ{è‘<²Gñ¨Í£{ éËc{ëñ<¾'ð„žÈ{OêÉ<¹§ð”žÊS{Oëé<½gðŒžÉ3{ÏêÙ<»çðœžËs{Ïëù<¿ð‚^È {/êż¸—ð’^ÊK{/ëå¼¼WðŠè•ÜN—»Wö*^Õ«yu¯á5½–×ö:^×ëy}oà ½‘7ö&ÞÔ›ysoá-½•·ö6ÞÖÛy{ïནwö.ÞÕ»ywïá=½—÷ö>Þ×ûyà}ö!>Ô‡ùpá#}”ö1>ÖÇùxŸà}’Oö)>Õ§ùtòÿÁ`ÀÙ¶ÝÙ¶íOò³mÛ¶ÕnmÛ¶mÛ¶î‚l¦Í²`›msl®Í³ù¶ÀÚ"[lKl©-³å¶ÂVÚ*[mkl­­³õ¶Á6Ú&Ûl[l«m³í¶ÃvÚ.Ûm{l¯í³ývÀÚ!;lG쨳ãvÂNÚ);mg쬳óvÁ.Ú%»lWìª]³ëvÃnÚ-»mwì®Ý³ûöÀÚ#{lOì©=³çöÂ^Ú+{moì­½³÷öÁ>Ú'ûl_ì«}³ïöÃ~Ú/ûmì¯ýC„D(„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡: !8j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f A˜‰YÆlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üc†d(†f†e8†gFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f0-Ó1=30#313³0+³1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4Ë°,˱<+°"+±2«°*«±: ):k°&k±6ë°.ë±>°!±1›°)›±9[°%[±5Û°-Û±=;°#;±3»°+»±;{°'{±7û°/û±?p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:g0AœÉY ælÎá\Îã|.àB.âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þS…T(…V…U8…WET$EVEU4EW ÅT,ÅVÅU<ÅW%T"%V%U2%W -¥T*¥V(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºL%¹j¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸Fh¤Fi´Æh¬Æi¼&h¢&i²¦hª¦iºf(PAš©Y -ÖlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýóÒCyhãa=œ‡÷Ñ#ydâQ=šG÷Ócylãq=žÇ÷žÐybOâI=™'÷žÒSyjOãžÖÓyzÏà=“gö,žÕ³yvÏá9=—çö<ž×óy~/à½ö"^Ô‹yq/á%½”—ö2^ÖËyy¯à½’Wö*^Õ«yu7‡Óåî5¼¦×òÚ^Çëz=¯ï ¼¡7òÆÞÄ›z3oî-¼¥·òÖÞÆÛz;oï¼£wòÎÞÅ»z7ïî=¼§÷òÞÞÇûz?ïï| òÁ>ćú0î#|¤òÑ>ÆÇú8ï|¢OòÉ>ŧú4Ÿî3<ð?Ap îîîî.%D ¥ã½ÝýJ*(©¤Aˆ¢"ˆÒÝÝpppÝÝÝÝÝ]ÎØXgãm‚M´I6Ù¦ØT›fÓm†Í´Y6ÛæØ\›góm-´E¶Ø–X„-µeiËm…EÙJ‹¶U¶ÚÖØZ[gëmƒm´M¶Ù¶ØVÛfÛm‡í´]¶ÛöØ^Ûgû퀴CvØŽØQ;fÇí„´SvÚÎØY;gçí‚]´KvÙ®ØU»f×í†Ý´[vÛîØ]»g÷í=´GöØžØS{fÏí…½´WöÚÞØ[{gïíƒÇð˜Ëc{ëñ<¾'ð„žÈ{OêÉ<¹§ð”žÊS{Oëé<½gðŒžÉ3{ÏêÙ<»çðœžËs{Ïëù<¿ð‚^È {/êż¸—ð’^ÊK{/ëå¼¼Wð_êË<Ò—û -ò•í«|µ¯ñµ¾Î×ûßè›|³oñ­¾Í·ûßé»|·ïñ½¾Ï÷û?è‡ü°ñ£~Ìû ?é§ü´Ÿñ³~ÎÏû¿è—ü²_ñ«~ͯû ¿é·ü¶ßñ»~Ïïûèü±?ñ§þÌŸû é¯üµ¿ñ·þÎßûÄ@LÄBlÄA\ÄC|$@B$Bb$AR$Cr¤@J¤Bj¤AZ¤Czd@FdBfdAVdCvä@NäBnäA^äC~@ABaAQCq”@I”Bi”AY”CyT@ETÂGø•QUQ Ÿ :>Åg¨š¨…Úø_ ê¢ê£¢£ šÂà!àK|…fhŽh‰Vh¯ñ Ú -¾Åwh‡ö耎è„Îø?  º¢º£zâGü„Ÿñ z¡7ú /~E?ü†ßÑàOü…ø1ÿ`0þÅ‚¡†á‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚,Å2Db9V -+UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äø1+³ -«²?au~ÊÏXƒ5Y‹µù9¿`Öe=Ög6d#6f6¥Ñ ’bà—üŠÍØœ-Ø’­Øš_ó¶a[~ËïØŽíÙÙ‰ù=`ve7vgöäü‰?óöboöa_þÊ~ü¿³?ÿàŸü‹ø7rÿá`þËÿ8„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„\ÊeŒär®`W2š«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUIécUVUU5}¢êúTŸ©†jª–jës}¡:ª«zª¯j¨Fj¬&j*“ ¢¤ /õ•š©¹Z¨¥Z©µ¾Ö7j£¶úVß©Ú«ƒ:ª“:ë{ý .êªnê®ê©õ“~Ö/ê¥ÞꣾúUýô›~Wý¡?õ—èo Ô ý£ÁúWÿiˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰"´TË©åZ¡(­T´ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé|†…áaDF…ÑaLÆ…ñaB˜&…ÉaJ˜¦…éaF˜f…ÙaN˜æ…ùaAX…ÅaIˆKò–‡!*¬ ÑaUXÖ„µa]Xþ'€°(¶¸\[ËÖV-×rËÆrý‡Ì­-»¶l›Ë¶·l›[Z¶íÝm ÛÃŽ°3ì -»Ãž°7ì ûÃp0 -‡Ã‘p4 ÇÉp2œ -§Ã™p6œ çÃ?áßp!\ —Âåp%ü®†káz¸n†[áv¸î†{á~x†Gáqxž†gáyx^†WáuxÞ†wá}ø>†Oá3"à DD$DFDE4|‰èˆ˜ˆ…؈ƒ¸ˆ‡øø -_#¾AB$Bb$AR$Cr¤@J¤Bj¤AZ¤Czd@F|‹ï ™‘ß#+²!;r 'r!7ò /~@>äGD!FÅ(†â(’(…Ò(ƒ²(‡ò¨€Š¨„ʨ‚ªø ÕP5PµPuPõ‚Q ÐÐMÐÍÐ-Эð3~AküŠßÐmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ¿ãôFôE?ôÇ Ä Æ Å0 ÇŒÄ(ŒÆŒÅ8ŒÇLÄ$LÆLÅ4LÇ ü‰™˜…Ù˜ƒ¹˜‡ùX€…X„ÅX‚¥X†åX•X…ÕXƒµX‡õØ€ø c6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎãü‹ ¸ˆK¸Œ+øWq ×q7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿ_0"#12£0*£ñKFg Æd,ÆfÆe<ÆçWüš ø 23 “2“3S2S3 Ó2Ó33ò[~ÇLÌÌ,üžY™Ù™ƒ9™‹¹™‡yùó1? ° ±0‹°(d1g –d)–f–e9–gVd%VfVåO¬Æê¬Áš¬Åڬú¬Ç@ÍúlÀ†lÄÆl¦lÆælÁ–lÅŸù [óWþÆ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ü°7û°/û±?p q0‡p(‡q8Gp$Gq4Çp,Çq<'p"'q2§p*§q:gðOÎä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä_ü››¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžÿð_^àE^âe^á¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOü¬úBI‘EQM_*ºb(¦b)¶â(®â)¾¾Ò×J o”P‰”XI”TÉ”\)”R©”Zi”Vé”^”Qßê;eRfeÑ÷ʪlʮʩ\Ê­<Ê«”OùU@UH…UDEõ£Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ª~R5UW ÕT-ÕVÕU=A”dÕW5T#5V5U35W µT+ý¬_ÔZ¿ê7µQ[µS{uPGuRguQWuSwõPOõÒïúC½ÕG}ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5Cj¦fi¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£þÒßÚ¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óúGÿê‚.ê’.ëŠþÓU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}ÒgGðŽèHŽì(ŽêhþÒÑÃ1˱ÇqÏñý•¿vã„NäÄNâ¤NæäNá”NåÔNã´NçôÎàŒþÖß9“3;‹¿wVgsvçpNçrnçq^ÿà|Îï.èB.ì".ê]ÌÅ]Â%]Ê¥]Æe]Îå]Á]É•]ÅUý“«¹ºk¸¦k¹¶ë¸®ë9¦e»¾¸¡¹±›¸©›¹¹[¸¥[ùgÿâÖþÕ¿¹ÛºÛ»ƒ;º“;»‹»º›»»‡{º—÷îí>îë~îïèAì!êaîéQí1ëqï žèIžì)žêižîþÓ3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Áý—ÿö&oöoýŸ x - ˜íZ¶—½¼l·Z ÿ!{ËnÙ¶Ûò–VC[µlÛnÙv» [ÂÖ°-l;Âΰ+ì{ÂÞ°/ìÂÁp(GÂÑp,'ÂÉp*œgÂÙp.œÂÅp)\WÂÕp-\7ÂÍð_¸n‡;án¸î‡áax‡'áixž‡áex^‡7ámxÞ‡ácø>#"""# -¢"¢#b"b#â"â#"# ¾@R$Cr¤@J¤Bj¤AZ¤Czd@FdBfdAVdCv|‰ȉ\È<È‹|È(ˆB(Œ"ø -EQ ÅQ%Q -¥ñ5Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡>¾A4Ä·h„ïÐMÐÍ‚Ñ-ЭÐmÐíÐÐÐßãtAWtCwô@OôBoôA_ôC À@üˆAŒ!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆŸð3a1–`)–a9VàüŠ•X…ÕXƒµø ë°¿ãü‰¿°ãlÄ&lÆ¿Ø‚­Ø†íØØ…Ý؃½Ø‡ý8€ƒ8„Ã8‚£8†ã8“8…Ó8ƒ³8‡ó¸€‹¸„˸‚«¸†ë¸›ø·pwp÷pððOðÏð/ð¯ðoðïððŸð™‘‘™Q•Ñ1“±›q—ñŸ ˜‰˜˜Iø“2“3S2S3 Ó2Ó33233 ³2³óKæ`Næbnæa^æc~`AbaáW,Êb,Î,ÉR,ͯY†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõù °!¿e#~ÇÆl¦lÆ@ÍælÁ–lÅÖlölÇöìÀŽìÄÎüž?° »²»³{²{³û²ûsòGâ`áPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àBþÄŸ¹ˆ‹¹„K¹ŒË¹‚¿ðW®ä*®æ®åo\ÇõüðOþÅ ü›ÿp#7q3ÿånå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢/”TÉ”\)”R©”Zi”Vé”^”Q™”YY”UÙ”]_*‡r*—r+ò*Ÿò«€ -ª -«ˆ¾RQSq•PI•Ri}­2*«r*¯ -ª¨Jª¬*ªªjª®ª©Zª­:ª«zª¯oÔ@ õ­é;5V5U3A”d5W µT+µVµU;µWuT'uÖ÷úA]ÔUÝÔ]=ÔS½Ô[}ÔWýÔ_4P?jkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækê'ý¬EZ¬%ZªeZ®úE¿j¥ViµÖh­~Ó:­×ïúCê/mÐßúGµI›õ¯¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦þÓ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}vGt$GvGu4Gw Çt,ÇvÇu<Çw't"'vá¤NæäNá”NåÔNã´NçôÎàŒÎäÌÎâ¬ÎæìþÒ9œÓ¹œÛyœ×ùœß\Ð…\ØEü•‹º˜‹»„Kº”Kûk—qY—syWpEWreWqUWsu×pM×rm×q]×s}ãnèoÝÈß¹±›¸©›9¦e»¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³¿÷îâ®îæîîážîåÞîã¾îçþàþу<ØC<ÔÃ<Ü#<Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð?ùg/òb/ñR/ór¯ð/þÕ+½Ê«½Æký›×y½÷þÓyƒÿö?ÞèMÞìÿ ‚0¨ -€³Íf£±5³ÙV3þÃÔlÖlÛf«­Ù^C 5·ÕP³í­»=aoØö‡á`8‡_Ñp4 ÇÃoá÷p"œ §ÂéðGø3œ gùp>\Ã¥ðW¸®„¿Ã?áj¸®‡áßð_¸n…ÛáN¸î…ûáAx…ÇáIxž…çáEx^…×áMxÞ…÷áCø>…ψ€ˆˆ„Ȉ‚¨ˆ†èˆ˜ˆ…؈ƒ¸ˆ‡øH€„H„ÄH‚¤H†äø)©ié™YÙ_"r"r#òâ+äÃ×È(ˆB(Œ"(Šb(Ž(‰Rø¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ñ-¡1š )š¡9Z %Z¡5B0Ú -Ú¡=:à;tD'tFtE7tGôD/ôFôE?ôÇ Ä |0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°kð#Öâ'üŒuX_°± ›±[± Û±;± »±{±ûqq‡ñ+Žà(Žá8~Ãï8“8…Óøâ ÎâÎã.âþÂe\ÁßøWq ×qÿâ?ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|fFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&çLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìü’9˜“¹˜›y˜—_1¿f~`AbaaQcq–`I–â7,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈoولMÙŒÍÙ‚-ÙŠ­’¢Ù†mÙŽíÙß±#;±3»°+»±;{°'{±7û°/û±?p ñ{þÀÁ¡ÆáÁ‘ÅÑñÇñœÀ‰œÄɜ©œÆéœÁ™œÅٜùœÇù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\ù–?ñg®ãzþ ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì_y„GyŒÇùç žä)žæü“gx–çxžx‘—ø/ó -ÿæ?¼Êk¼Îü—ÿñ&oñ6ïð.ïñ>ð!ñ1Ÿð)Ÿñ9_ð%_ñ5ßð-ßñ=?ð#?ñ³"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹¾P -¥T*¥V¥U:¥WeT&eVeU6e×—Ê¡œÊ¥ÜÊ£¼úJùôµò«€ -ª -«ˆŠª˜Š«„Jª”¾Qi•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC}«Fj¬&jªfj®j©Vj­ ˆ’¬6j«vj¯úNÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hßë Ö Õ0 ×Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Öý¨µúI?kÖëmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaýª#:ªc:®ßô»Nè¤Né´þП:£³:§óº ‹º¤¿tYWô·þÑU]ÓuÝпúO7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸÁÉ‘ÅQÍÑÃ1˱ÇqÏñÀ ȉÄIÌÉý…S8¥S9µÓ8­Ó9½38£39³³8«³9»¿tçt.çvçõWÎç¯ß\Ð…\ØE\ÔÅ\Ü%\Ò¥üK»ŒËºœË»‚+º’+»Š«ºš«»†kº–k»Žëºžë»ú[7rc7qS7ss·pK·rkôl·q[·s{wðwîèNîì.îênîîîé^îí>îë~îïèAþÞ?x°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×øG¯õOþÙë¼Þ¿xƒ7z“7{‹·z›·{‡wz—wÿO<aP̶m-¯e-ÛZƪÿв½lÛæÚjYË-¬­Z^ma˶kwaOØö…ýá@8…Ãá×p$ ÇÂñð[8~„“áT8þ gÂÙp.œÂÅp)ü.‡+áïðO¸®…ëáFø7ün†[áv¸î†{á~x†Gáqxž†gáyx^†WáuxÞ†wá}ø>†Oá3" ""!2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;rà äD.äFäE>äÇ—(€¯P…PEPÅP%P¥P_£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢¾Ac4AS4Cs´@K´Bk´Á·h‹vh€ŒøÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒñ=†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-~À:üˆŸ°ð36b6c ¶b¶cvbvãìÁ^ìÃ~ÀAÂaüŠ#8Šc8Žßp¿ãœÄ)œÆŸ8ƒ³8‡ó¸€‹¸„¿pWð7þÁU\ÃuÜÀ¿ø7q ·qwq÷ñññOñ Ïñ/ñ -¯ñoñïññ Ÿ‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ_0's17ó0/ó1?¿d~Å‚,ÄÂ,¢,Æâ,Á’,ÅÒüšeX–åXžX‘•X™UX•ÕX5X“µX›uX—õXŸ Øø ³ ›²›³[²[³ ¿e[¶c{‚¤hvàwìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌï9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†kù×ñGþÄõÜÀŸ¹‘›¸™[¸•Û¸;¸“»¸›¿p÷r÷óòóWáQãqþÆüð$Oñ4ÿäžå9žç^ä%þÅ˼¿ù¯ò¯óÿå¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOü¬Š¨HŠ¬(ŠªhŠ®Š©XŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlÊ®úB9•K¹•Gy•Oùõ¥ -è+T!VU1W •T)•Ö×*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤oÔXMÔTÍÔ\-ÔR­ÔZmô­ÚªÚ+¢$«ƒ¾SGuRguQWuSwõPOõRoõQ_õS Ð@ Ò`}¯!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨EZ¬%ZªeZ®Z©UZ­5Z«´N?ê'­×ý¬Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝúE{´Wû´_tP‡tX¿êˆŽê˜Žë7ÐïúC'uJ§õ§Îè¬Îé¼.è¢.é/]Öý­tU×t]7ô¯þÓMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}ÒgGpDGrdGqTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvçðÎé\Îí<Îë|Îï/]À_¹  ¹°‹¸¨‹¹¸K¸¤K¹´¿v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#ãÆnâ¦nææná–nåÖnãoÝÖíÜÞÁ0-Ûü;º“;»‹»º›»»‡{º—{»ûºŸû{€zû{ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZÿàuþÑ?y½7øgoô&oöoõ6o÷ïô.ïöÿÁVÀl×2¶¼l×jÈÖr­Åÿ-/,ÛÖÒÒ²¶U˶m›»Û¶…íaGØv…¿Ã?áß°;ì {Ãa_Ø„ƒáP8Ž„£áX8N„“áT8΄³á\8.„‹áR¸®„«áZ¸n„›áV¸î„»á^¸„‡áQxž„§áYx^„—áUxÞ„·á]x>„áSøŒˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$øI‘ É‘)‘ -©‘i‘_â+¤GdD&dFdÅ×ȆìȜȅÜȃ¼È‡ü(€‚(„Â(‚¢(†â(’(…oPeð-¾Ã÷øeQåQQ •QUQ ÕQ5Q µQuñ#ê¡> !¡1š )šá'4ÇÏh–h…Öhƒ¶Áh‡ö耎è„Îè‚®è†îèžè…Þ胾ø¿¢úcbc~ÃP ÃpŒÀï‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠ?° ˱+± -b5Ö`-Öa=þÂlÄ&lÆlÅ6lÇìÄ.üð/vcöâ?ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|ÂgF`DFbdFaTFctÆ`LÆblÆa\Æc|&`B&bb&áLÊdLÎLÉTLÍ4LËtü’_1=30#313³0+¿f6fgæd.æfæe>ægd!fe1g –d)~ÃÒ,Ãoù¿ç,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬ËYõÙ€ ولMÙŒ?±9f ¶d+¶f¶e HŠf;¶gvd'vfve7vgöd/öföå/ü•ýØŸ8ƒ8˜Cø‡r‡sçHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎá\Îã|.àB.âb.áRþÁe\Î\ÉUü“«¹†k¹Žëù7p#7q3·p+·q;wp'wñoþù›{¸—ÿq÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?+‚"*’"+Š¢*š¢+†b*–b+Žâ*žâ+*‘+‰¾PR%Sr¥PJ¥Rj¥QZ¥Ó—úJé•A•I™•EYõµ²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤Jé•V}«ïô½~PY•SyUPEUReUQUUSuÕPMÕRmÕQ]ý¨zª¯j¨Fj¬&jªfúIÍõ³Z¨¥Z©µÚ¨­‚ J²Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯~ѯê§þ ¤Á¢ß4TÃ4\#ô»Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–ê-Ór­ÐJ­ÒŸZ­5Z«uZ¯¿´AµI›µE[µMÛµC;µKëý«ÝÚ£½úOû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôÙÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIü…“:™“;…S:•S;Ó:¿ôWNï ÎèLÎì,Îê¯ÍÙÃ9˹ÇyÏù]À]È…]ÄE]ÌÅ]Â%]Ê߸´Ëø[çïýƒËºœË»‚+º’+»Š«ºš«»†kº–k»ŽëúG×s}7pC7rc7qS7óOnîŸÝÂ-ÝÊ­ÝÆm Ó²ÝÎíÝÁÝÉÝÅ]ÝÍÝÝÃ=Ý˽ÝÇ}ý‹u?÷÷ô öÿæ¡æááß=Ò£<Úc<Öã<Þ<Ñ“<ÙS<ÕÓ<Ý3<Ó³<Ûs<×ó<ß ¼Ð‹¼ØK¼Ôx™—{…Wz•ÿôj¯ñZ¯ózÿå ÞèMÞì-ÿ@XW-Û6—íZ¶[mËvÿ!s˶ݖ·´µ­¶V˶mÛÆ9ü¶„­a[Øv„aWØö„½a_Ø„ƒáP8Ž„£áX8N„“áT8΄³á\8.„‹áR¸®„«áZ¸n„›áV¸î„»á^¸„‡áQxž„§áYx^„—áUxÞ„·á]x>„áSøŒ/ _"2¢ *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²á+dGäD.äFäE>äGD!FE1G ”D)”Æ×(ƒ²(‡ò¨€Š¨„ʨ‚ª¨†ê¨š¨…Ú¨ƒº¨‡úø Ðßâ;|FhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.芀ŒnèŽè‰^è>è‹~èˆð#a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!~ÂÏX„ÅX‚¥X†åX_ð+VbVc Öâ7üŽuøâ/¬Çü°ÿb6ã?lÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg~ÁŒÈHü’‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™_1;s0's17ó0/ó1? ° ±0‹°(‹±8K°$K±4¿f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Öç7lÀ†ü–ßñ{6bc6aS6cs¶`K¶bk¶a[¶c{v`GvbgvaW‚¤hvcwö`Oöboöa_öcà@þÀ9ˆƒ9„C9ŒÃ9‚#9Š£9†c9Žã99‰“9…S9Ó9ƒ39‹³9‡s9ó¹€ ùæ".æ.å2.ç -þÂ_¹’«¸šk¸–¿ñw®ãü“q=7ðoþÃü—›¸™ÿq ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ë EPDEÒ—Š¬(ŠªhŠ®Š©XŠ­8Š«xŠ¯J¨DJ¬$JªdJ®J©TJ­4J«tJ¯ ʨLʬ,ʪlúJÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥õµÊ¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¾Q5Ô·úNß«‘«‰šª™š«…Zª•Z«ÚªÚ«ƒ:ª“:«‹º*¢$«›º«‡zª—z«úªŸúk€êý¨A¬!ªa®©Q­1«q¯ š¨Iš¬)šªiš®š©Yš­9š«yš¯Z¨Ÿô³i±–h©–i¹Vèýª•Z¥ÕZ£µúM¿kþПúKëµAëmÔ¿Ú¤ÍúO[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôÙ_8‚#:’¿tdGqTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgóWÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í¯]Æe]Îå]Á]É•]ÅU]ÍÕ]Ã5]˵]Çu]Ïõý¸¡¿õwþÞÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÁ0-ÛÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ð?øGò`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðBÿ䟽ȋ½ÄK½Ì˽¿øW¯ô*¯ö¯õoþÝëü‡ÿô_^ï þÛÿx£ÿ'…°(€fÛ¶mÛ¶mó]ül{ŒC 5Æ¡–mÛ¶ívÎú°!l ›Âæ°%l ÛÂö°#ì »Âî°'ì ûÂþp  ‡Âáp$ ÇÂñp"œ §Âép&œ çÂùp!\ —Âåp%\ ×Âõp#Ü ·Âíp'Ü ÷Âýð < Âãð$< ÏÂóð"¼ ¯Âëð&¼ ïÂûð!| Ÿ ‘Q Ñ1 ±qñ‘ ‘‰‘I‘ É‘)‘ -©‘i‘é‘‘ ™‘Y‘ Ù‘9‘ ¹‘y‘ùQQ…QEQ ÅQ%Q -¥QeQåQQ •QUQ ÕQ5Q µQuQõÑ ÑÑMÑ ÍÑ-Ñ -­ÑmÑíÑÑ Ñ]Ñ ÝÑ=Ñ ½Ñ}Ñý11ƒ‚!ŠaŽ‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰³8‡ó¸€‹¸„˸‚«¸†ë¸›¸…Û¸ƒ»¸‡ûx€‡x„Çx‚§x†çx—x…×xƒ·x‡÷ø€øÄHŒÌ(ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌ@ÍáPãpŽàHŽâhŽáXŽãxNàDNâdNáTNãtÎàLÎâlÎágüœ_ðK~ů9—ó8Ÿ ¸‹ø ¿åwüž‹¹„?ðGþÄŸ¹”Ëø åoüðO.ç -®ä*®æþÅ¿ùÿåZ®ã\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á -‚(ÉŠÐ Õ0 ×Ô(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖ}¦Ïõ…¾ÔWúZs5Oóµ@ µHßè[}§ïµXKôƒ~ÔOúYKµL¿èWý¦ßõ‡þÔr­ÐJ­Òj­Ñ_ú[ÿè_­Õ:ý§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú úäHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì`˜–íñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñgþÜ_øKå¯=×ó<ß ¼Ð‹ü¿õwþÞ‹½Ä?øGÿ䟽ÔËü‹õoþÝøO/÷ -¯ô*¯öÿå¿ýÿõZ¯ó^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèO‘""GD‰ˆ-"zDŒˆ˜ÿl ÀnÛ¶mÛ¶m[ÅnÛ¶mÛ¶mÛv‚0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^Á 7ú /ú¡?` a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ2ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²AR4ìÍ>ìË~ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¢  -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê%ˆ’¬€z«úªŸúk€jkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ8¨ƒ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¦e;àÞîã¾îçþàäÁâ¡æáá‘åÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßþã¿þøO<@@˶mÛ¶mÛ¶ëðÙ¶mÛ¶mÛ¶k 0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~Á ?` a0†`(†a8F`$Fa4Æ`,Æa<&`"&a2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ2ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²AR4ìÏÈAÌ!ÊaÎÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¢  -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê'ˆ’¬€úk€jkˆ†j˜†k„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ8¨ƒ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¦e;àþàäÁâ¡æáá‘åÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßþã¿þõŸ x``vÛ¶mÛ¶mÛv±Û¶mÛ¶mÛ¶„F„E8„GDD$DFDE4DG ÄD,ÄFÄE<ÄG$D"$F$E2$G -¤D*¤F¤E:¤GdD&dFdE6dGäD.äFäE>äGD!FE1G ”D)”F”E9”GTD%TFTE5TG ÔD-ÔFÔE=ÔG4D#4F4E34G ´D+´F´E;´GtD'tFtE7tGôD/ôFôE?ôÇ Ä „`0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿ„AŒÁ‚!Š¡†aŽá‰‘…Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆ )šæå0çŽä(ŽæŽå8ŽçNä$NæNå4Nç Îä,ÎæÎå<Îç.ä".æ.å2.ç -®ä*®æ®å:®çnä&nænå6nçîä.îæîå>îçä!æå1ç žä)žæžå9žç^ä%^æ^å5^ç Þä-ÞæÞå=Þç>ä#>æ>å3>ç ¾ä+¾æ¾å;¾ç~ä'~æ~å7~çþä/þæþå?QPSp…PH…Rh…QX…SxEPDERdEQTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ DIV@ƒ5DC5LÃ5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH‹µDKµL˵B+µJ«µFkµNëµAµI›µE[µMÛµC;µK»µG{µOûu@uH‡uDGuLÇuB'uJ§uFguNçuAuI—uEWuM×uC7uK·uGwuO÷õ@õHõDOõLÏõB/õJ¯õFoõNïõAõIŸõE_õMßõC?õK¿õGõÏAÔÁÜ!Ò¡ÚaÖáÞÑ‘ÙQÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ Ó²ð`ñPópðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ïó|/ðB/òb/ñR/ór¯ðJ¯òj¯ñZ¯ózoðFoòfoñVoóvïðNïònïñ^ïó~ðAòañQóqŸðIŸòiŸñYŸóy_ðE_òe_ñU_óußðMßòmßñ]ßó}?ðC?òc?ñS?ós¿ðK¿òk¿ñ[¿ó{ðGògñWówÿðOÿòoÿñ_ÿ    „„ ü'؀ݶmÛ¶mÛ¶­b·mÛ¶mÛ¶í$B# Â"Â#"""# -¢"¢#b"b#â"â#"# ’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†bB0Ž‰Q1‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹   Æà Á ÅРð ÇðŒÀˆŒÄȌ¨ŒÆèŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡F͇sGrGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚(¨‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨† ¢$+ á¡‘¥Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç ê`îéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì!êa†iÙx¸Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ù·ÿø¯ÿ‚‚‚‚BBþ'  €eÛ¶mÛ¶mÛv>Û¶mÛ¶mÛµ!B# Â"Â#"""# -¢"¢#b"b#â"â#"# ’"’#R"R# Ò"Ò#2"2# ²"²#r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ ʢʣ*¢*£ -ª¢ª£j¢j£ê¢ê£¢£ š¢š£Z¢Z£ Ú¢Ú£:¢:£ º¢º£z¢z£ú¢úcbc†b†cFbB01‹q ˜ˆI˜Œ)˜Ši˜Ž˜‰Y˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹   Æà Á ÅРð ÇðŒÀˆŒÄȌ¨ŒÆèŒÁ˜ŒÅ،øŒÇøLÀ„LÄÄL¤LÆäLÁ”LÅÔLôLÇôÌÀŒÌÄÌ̬ÌÆìÌÁœÌÅÜÌüÌÇü,À‚,ÄÂ,¢,Æâ,Á’,ÅÒ,ò,Çò¬ÀŠ¬Äʬª¬Æê¬Áš¬Åڬú¬ÇúlÀ†lÄÆl¦lÆælÁ–lÅÖlölÇöìÀŽìÄÎì®ìÆîìÁžìÅÞìþìÇþÀÄÁ¡ÆáÁ‘EÍGs ÇrÇs'r's -§r§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚(¨‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸Fh¤F ¢$+ Ñ£±§ñš ‰š¤Éš¢©š¦éš¡™š¥Ùš£¹š§ùZ …Z¤ÅZ¢¥Z¦åZ¡•Z¥ÕZ£µZ§õÚ Ú¤ÍÚ¢­Ú¦íÚ¡Ú¥ÝÚ£½Ú§ý: ƒ:¤Ã:¢£:¦ã:¡“:¥Ó:£³:§óº ‹º¤Ëº¢«º¦ëº¡›º¥Ûº£»º§ûz ‡z¤Çz¢§z¦çz¡—z¥×z£·z§÷ú ú¤Ïú¢¯ú¦ïú¡Ÿú¥ßú£¿úç ê`îéPí0ëpïŽèHŽì(ŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì!êaîéQ†iÙx´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡y±—x©—y¹Wx¥Wyµ×x­×y½7x£7y³·x«·y»wx§wy·÷x¯÷y¿ø ù°ø¨ù¸Oø¤Où´Ïø¬Ïù¼/ø¢/ù²¯øª¯ùºoø¦où¶ïø®ïù¾ø¡ù±Ÿø©Ÿù¹_ø¥_ùµßø­ßù½?ø£?ù³¿ø«¿ù»ø§ù·ÿø¯ÿ‚‚‚‚Bþl ÀnÛ¶mÛ¶mÛ¶‹Ý¶mÛ¶mÛV¡aá‘QÑ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0#0£0c0ã‚ÀxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,Âb,ÁR,Ãr¬ÀJ¬Âj¬ÁZ¬ÃzlÀFlÂflÁVlÃvìÀNìÂnìÁ^ìÃ~ÀAÂaÁQÃqœÀIœÂiœÁYœÃy\ÀE\Âe\ÁU\ÃuÜÀMÜÂmÜÁ]ÜÃ}<ÀC<Âc<ÁS<Ãs¼ÀK¼Âk¼Á[¼Ã{|ÀG|Âg|ÁW|ÃwüÀOüÂoüÁ_üce0g†d(†f†e8†gFd$FfFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0çŽä(ŽæŽå8‚¤h8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸—û¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×x7x“·x›wx—÷xŸøø˜Oø”Ïøœ/ø’¯øšoø–ïøžø‘Ÿø™_ø•ßø?ø“¿ø›ø—ÿDALÁB!J¡FaNáAI‘EQMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ5DC5LÃ5B#5J£5Fc5N%Y×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2-× -­Ô*­Ö­Õ:­×mÔ&mÖmÕ6m×íÔ.íÖíÕ>í×Ô!ÖÕ1× Ô)ÖÕ9×]Ô%]Ö]Õ5]× ÝÔ-ÝÖÝÕ=Ý×=Ô#=Ö=Õ3=× ½Ô+½Ö½Õ;½×}Ô'}Ö}Õ7}×ýÔ/ýÖýÕ?qPsp‡pH‡rh‡qX‡sxGpDGrdGqTGstÇpLÇrlÇq\Çs|'pB'rb'qR'sr§pJ§rj§qZ§szgpFgrfgqVgsvçpNçrnçq^çs~pAraqQsq—pI—ri—qY—syWpEWreWqUWsu×pM×rm×q]×s}7pC7rc7qS7ss·pK·rk·q[·s{wpGwrgwqWwsw÷pO÷ro÷q_÷sð@ò`ñPópðHòhñX3LËvÀã=Á=É“=ÅS=ÍÓ=Ã3=˳=Çs=Ïó½À ½È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸýÅ_ýÍßýÃ?ýË¿ýÇý/$4,<â?AðÀÀì¶mÛ¶mÛ¶m[ÅnÛ¶mÛ¶m'‰P0‹pˆˆHˆŒ(ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ‰Q1‹q ˜ˆIÁ`2¦`*¦a:f`&fa6æ`.æa>`!a1–`)–a9V`%Va5Ö`-Öa=6`#6a3¶`+¶a;v`'va7ö`/öa?à á0Žà(Žá8Nà$Ná4Îà,Îá<.à".á2®à*®á:nà&ná6îà.îá>à!á1žà)žá9^à%^á5Þà-Þá=>à#>á3¾à+¾á;~à'~á7þà/þ1ƒ2ƒ3C2C3 Ã2Ã3#2#3 -£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrs‡r‡sGrGs ÇrÇs'rAR4œÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈE\Ì%\Êe\Î\ÉU\Í5\Ëu\Ï ÜÈMÜÌ-ÜÊmÜÎÜÉ]ÜÍ=ÜË}ÜÏ<ÈC<Ì#<Êc<Î<ÉS<Í3<Ës<Ï ¼ÈK¼Ì+¼Êk¼Î¼É[¼Í;¼Ë{¼Ï|ÈG|Ì'|Êg|Î|ÉW|Í7|Ëw|ÏüÈOüÌ/üÊoüÎüÉ_üÍ?üË -¢  -¦à -¡ -¥Ð -£° -§ðŠ ˆŠ¤ÈŠ¢¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á¡‘¥Ñ£±§ñš ‰š$ˆ’¬€&kŠ¦jš¦k†fj–fkŽæjžækj‘k‰–j™–k…Vj•VkÖjÖkƒ6j“6k‹¶j›¶k‡vj—vköjŸöë€ê눎꘎ë„Nê”NëŒÎêœÎë‚.ê’.늮ꚮë†nê–nëŽîêžîëê‘뉞Ꙟë…^ê•^ëÞêÞëƒ>ê“>닾꛾ë‡~ê—~ëþꟃ8¨ƒ9¸C8¤C9´Ã8¬Ã9¼#8¢#9²£8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°‡x¨‡y¸Gx¤Gy´Çx¬Çy¼'x¢'¦e;àÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^æå^á•^åÕ^ãµ^çõÞàÞäÍÞâ­ÞæíÞáÞåÝÞã½Þçý>àƒ>äÃ>â£>æã>á“>åÓ>ã³>çó¾à‹¾ä˾⫾æë¾á›¾å۾㻾çû~à‡~äÇ~â§~æç~á—~å×~ã·~ç÷þàþäÏþâ¯þæïþáŸþåßþã¿þøO<@Ì®eÛ¶mÛ¶m{ÙõX¶mÛ¶mÛ®»P0‹pˆˆHˆŒ(@TDCtÄ@LÄBlÄA\ÄC|$@B$Bb$AR$Cr¤@J¤Bj¤AZ¤Czd@FdBfdAVdCvä@NäBnäA^äC~@ABaAQCq”@I”Bi”AY”CyT@ETBeTAUTCuÔ@MÔBmÔA]ÔC}4@C4Bc4AS4Cs´@K´Bk´A[´C{t@GtBgtAWtCwô@OôBoôA_ôC À@ Â` ÁP ÃpbFbFc ÆbÆc&b&c -¦bB0‚030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{°û°p‡pGpÇp'p§pgpçpp—pWp×p7p·pwp÷pððOðÏð/ð¯ðoðïððŸð_ðßð?ð¿ððÿŒÁ‚!Š¡†aŽá‰‘…ŒÊhŒÎŒÉXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,ÌÊlÌÎÌÉ\ÌÍ<ÌË|ÌÏ,ÈB,Ì",Êb,Î,ÉR,Í2,Ër,Ï -¬ÈJ¬Ì*¬Êj¬Î¬ÉZ¬Í:¬Ëz¬ÏlÈFlÌ&lÊflÎlÉVlÍ6lËvlÏìÈNìÌ.ìÊnìÎìÉ^ìÍ>ìË~ìÏÈAÌ!ÊaÎ@ŽàHŽâhŽáXŽãxNàDNâdNáTN#HŠf§sgrgsçrçsrs —r—sWrWs ×r×s7r7s ·r·swrws÷r÷óòóòóOòOó ÏòÏó/ò/ó -¯ò¯óoòoóïòïóòó ŸòŸó_ò_ó ßòßó?ò?ó ¿ò¿óòóÿòŸ‚)¸B(¤B)´Â(¬Â)¼"(¢")²¢(@QMÑC1K±GqOñ•@ •H‰•DI•LÉ•B)•J©•Fi•Né•A•I™•EY•MÙ•C9•K¹•Gy•OùU@UH…UDEULÅUB%UJ¥UFeUNåUAUI•UEUUMÕUC5UKµUGuUOõÕ@ ÕHÕDMÕLÍÕB-ÕJ­ÕFmÕNíÕAÕIÕE]ÕMÝÕC=ÕK½ÕG}ÕOý5@5Hƒ5DC5Lè©Q­1«q¯ š¨Iš¬)šªi‚(É -ÒtÍÐLÍÒlÍÑ\ÍÓ|-ÐB-Òb-ÑR-Ór­ÐJ­Òj­ÑZ­ÓzmÐFmÒfmÑVmÓvíÐNíÒníÑ^íÓ~ÐAÒaÑQÓqÐIÒiÑYÓy]ÐE]Òe]ÑU]ÓuÝÐMÝÒmÝÑ]ÝÓ}=ÐC=Òc=ÑS=Ós½ÐK½Òk½Ñ[½Ó{}ÐG}Òg}ÑW}ÓwýÐOýÒoýÑ_ýs0w‡t(‡v‡u8‡wGt$Gv8ª£9ºc8¦c9¶ã8®ã9¾8¡9±“8©“9¹S8¥S9µÓ8­Ó9½38£39³³8«³9»s8§s9·ó8¯ó9¿ ¸  ¹°‹¸¨‹¹¸K¸¤K¹´Ë¸¬Ë¹¼+¸¢+¹²«¸ª«¹ºk¸¦k¹¶ë¸®ë¹¾¸¡¹±›¸©›¹¹[¸¥[¹µÛ¸­Û¹½;¸£;¹³»¸«»¹»{¸§{¹·û¸¯û¹¿x y°‡x¨‡y¸=Â#=Ê£=Æc=Îã=Á=É“=ÅS=Í0-ÛAžîžéYží9žëyžï^èE^ì%^êe^î^éU^í5^ëu^ï ÞèMÞì-ÞêmÞîÞé]Þí=Þë}Þï>èC>ì#>êc>î>éS>í3>ës>ï ¾èK¾ì+¾êk¾î¾é[¾í;¾ë{¾ï~èG~ì'~êg~î~éW~í7~ëw~ïþèOþì/þêoþîþé_þí?þëAÁ‚‚… -ùŸ x €˜]˶mÛ¶mÛö²ýX¶mÛ¶mÛºC(„F„E8„GDD$DF *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a81#1 -£1c1ã11 “1S1 Ó131 !A˜9˜‹y˜XˆEXŒ%XŠeXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹ Æà Á ÅРð ÇðŒÀˆŒÄÈŒÂFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0g Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&g$E3ˆ³9‡s9ó¹€ ¹ˆ‹¹„K¹ŒË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOÁ\!R¡ZaVá^Q‘YQ ¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á -ÔÔ(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,A”di¶æh®æi¾h¡i±–h©–i¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;ŠÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Üá‘åÑã±çñžà‰žäÉžâ©žæéžá™že˜–í ÏöÏõ<Ï÷/ô"/ö/õ2/÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿ `AÁƒBý'ƒ fײmÛ¶mÛ¶½lë±lÛ¶mÛ¶ïB"B# Â"Â#"""# -Ñ1±qñ ‰IÉ)©ié™YÙ9¹yùP…PEPÅP%P¥PePåPP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0‘…у±‡ñ˜€‰˜„ɘ‚©˜†é˜™˜…Ù˜ƒ¹˜€Œ ÌÇ,Ä",Æ,Å2,Ç -¬Ä*¬Æ¬Å:¬ÇlÄ&lÆlÅ6lÇìÄ.ìÆìÅ>ìÇÄ!ÆÅ1Ç œÄ)œÆœÅ9œÇ\Ä%\Æ\Å5\Ç ÜÄ-ÜÆÜÅ=ÜÇ<Ä#<Æ<Å3<Ç ¼Ä+¼Æ¼Å;¼Ç|Ä'|Æ|Å7|ÇüÄ/üÆüÅ?cp†`H†bh†aX†cxF`DFbdFa£2£3c2c3ã2ã323 “2“3S2S3 Ó2Ó33233 ³2³3s2s3ó2ó³ ² ³‹²‹³K²K³ ˲˳+²+³ -«²«³k²k³ë²ë³²³ ›²›³[²[³ Û²Û³;²;³ »²»³{²{³û²ûsrs‡r‡3#8’£8šc8–ã8ž8‘“8™S8•Ó838“³8›s8—ó’¢Äù\À…\ÄÅ\Â¥\Æå\Á•\ÅÕ\õ\ÇõÜÀÜÄÍÜ­ÜÆíÜÁÜÅÝÜýÜÇý<Àƒ<ÄÃ<£<Æã<Á“<ÅÓ<ó<Çó¼À‹¼Ä˼«¼Æë¼Á›¼Åۼû¼Çû|À‡|ÄÇ|§|Æç|Á—|Å×|÷|Ç÷üÀüÄÏü¯üÆïüÁŸüÅßüÿü§` -® -©P -­0 -«p -¯Š¨HŠ¬( -PTEStÅPLÅRlÅQ\ÅS|%PB%Rb%QR%Sr¥PJ¥Rj¥QZ¥SzePFeRfeQVeSvåPNåRnåQ^åS~PARaQQSq•PI•Ri•QY•SyUPEUReUQUUSuÕPMÕRmÕQ]ÕS}5PC5Rc5QS5SsµPKµRkµQ[µS{uPGuRguQWuSwõPOõRoõQ_õS Ð@ Ò` ÑP Ópj„Fj”FkŒÆjœÆk‚&j’&kŠ¦jš¦k†fj–fkŽæjž J²‚4_ ´P‹´XK´TË´\+´R«´Zk´Vë´^´Q›´Y[´UÛ´];´S»´[{´Wû´_tP‡tXGtTÇt\'tR§tZgtVçt^tQ—tYWtU×t]7tS·t[wtW÷t_ôPôXOôTÏô\/ôR¯ôZoôVïô^ôQŸôY_ôUßô]?ôS¿ô[ôWÿÌÁÂ!Ê¡ÆaÎáÁÉ‘ÅŽêhŽîŽéXŽí8ŽëxŽïNèDNì$NêdNîNéTNí4NëtNï ÎèLÎì,ÎêlÎîÎé\Îí<Îë|Îï.èB.ì".êb.î.éR.í2.ër.ï -®èJ®ì*®êj®î®éZ®í:®ëz®ïnèFnì&nêfnînéVní6nëvnïîèNîì.îênîîîé^îí>îë~îïèAì!êaî@ðHòhñXóxOðDOòdOñTOótÏðLÏòlÏñ\Ï3LËvç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷zŸ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ûŠ¯úš¯û†oú–oûŽïúžïûú‘û‰Ÿú™Ÿû…_ú•_ûßúßûƒ?ú“?û‹¿ú›¿û‡ú—ûÿú_P° àA!þ€A³kÙ¶mÛ¶mÛ^¶]eÛ¶mÛ¶ë! -¡aá ‘ˆŠhˆŽˆ‰Xˆ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ÈŠlÈŽȉ\È<È‹|È(ˆB(Œ"(Šb(Ž(‰R(2(‹r( -¨ˆJ¨Œ*¨Šj¨Ž¨‰Z¨:¨‹z¨hˆFhŒ&hŠfhŽh‰Vh6h‹vhèˆNèŒ.èŠnèŽè‰^è>è‹~èˆAŒ!ŠaŽ@ŒÀHŒÂhŒÁXŒÃxLÀDLÂdLÁTLÃtÌÀLÌÂlÌÁ\ÌÃ|,ÀB,@Fc –b–cVbVc ÖbÖc6b6c ¶b¶cvbvcöböãâãŽâŽãNâNã ÎâÎã.â.ã -®â®ãnânãîâîãâã žâžã^â^ã ÞâÞã>â>ã ¾â¾ã~â~ãþâƒ18C0$C14Ã0,Ã1<#0"#12£0€Qу1‹±‡qñ™€ ™ˆ‰™„I™ŒÉ™‚)™Š©™†i™Žé™™‰™™…Y™Ù™ƒ9™‹¹™‡y™ùY€Yˆ…Y„EYŒÅY‚%YŠ¥Y†eYŽåYY‰•Y…UYÕYƒ5Y‹µY‡uYõÙ€ ولMÙŒÍÙ‚-ÙŠ­Ù†mÙŽíÙىم]ÙÝÙƒ=Ù‹½Ù‡}Ùý9€9ˆƒ9„C9ŒÃÈÉQÍ1ËqÏ œÈIœÌ)œÊiœÎœÉYœÍ9œËyœÏ\ÈEIÑ âb.áR.ãr®àJ®âj®áZ®ãznàFnâfnáVnãvîàNîânîá^îã~àAâaáQãqžàIžâižáYžãy^àE^âe^áU^ãuÞàMÞâmÞá]Þã}>àC>âc>áS>ãs¾àK¾âk¾á[¾ã{~àG~âg~áW~ãwþàOþâoþá_þS0W…T(…V…U8…WET$EV(ª¢)ºb(¦b)¶â(®â)¾(¡)±’(©’)¹R(¥R)µÒ(­Ò)½2(£2)³²(«²)»r(§r)·ò(¯ò)¿ -¨  -©°Š¨¨Š©¸J¨¤J©´Ê¨¬Ê©¼*¨¢*©²ª¨ªª©ºj¨¦j©¶ê¨®ê©¾¨¡©±š¨©š©¹Z¨¥Z©µÚ¨­Ú©½:¨£:©³º¨«º©»z¨§z©·ú¨¯ú©¿h i°†h¨†i¸5B#5J£5Fc5Nã5A5I“5ES5MÓ5C35K³5Gs5Oóµ@ µH%YAZ¬%ZªeZ®Z©UZ­5Z«uZ¯ Ú¨MÚ¬-ÚªmÚ®Ú©]Ú­=Ú«}Ú¯:¨C:¬#:ªc:®:©S:­3:«s:¯ º¨Kº¬+ºªkº®º©[º­;º«{º¯z¨Gz¬'zªgz®z©Wz­7z«wz¯ú¨Oú¬/úªoú®ú©_ú­?ú«æàáåÐã°çðŽàˆŽäÈŽâGu4Gw Çt,ÇvÇu<Çw't"'v'u2'w -§t*§v§u:§wgt&gvgu6gwçt.çvçu>çwt!vu1w —t)—v—u9—wWt%WvWu5Ww ×t-×v×u=×w7t#7v7u37w ·t+·v·u;·wwt'wvwu7ww÷t/÷v÷u?÷÷ô öõ0w Gx¤Gy´Çx¬Çy¼'x¢'y²§xª§yºgx¦gy¶çx®çy¾x¡¦e;È‹½ÄK½Ì˽Â+½Ê«½Æk½Îë½Á½É›½Å[½ÍÛ½Ã;½Ë»½Ç{½Ïû}À}ȇ}ÄG}ÌÇ}Â'}ʧ}Æg}Îç}Á}É—}ÅW}Í×}Ã7}Ë·}Çw}Ï÷ýÀýÈýÄOýÌÏýÂ/ýʯýÆoýÎïýÁýÉŸýÅ_ýÍßýÃ?ýË¿ýÇý/(XPð ÿÁ`ÀìZ¶mÛ¶mÛ¶—mû±lÛ¶mÛÖ]„D(„F„E8„GDD$DF *¢!:b &b!6â .â!> !!1’ )’!9R %R!5Ò -Ò!=2 #2!3² +²!;r 'r!7ò /ò!? -  -¡0Š (Š¡8J $J¡4Ê ,Ê¡<* "*¡2ª *ª¡:j &j¡6ê .ê¡> !¡1š )š¡9Z %Z¡5Ú -Ú¡=: #:¡3º +º¡;z 'z¡7ú /ú¡?` a0†`(†a81#1 -£1c1ã11 “1S1 Ó131 ³1s1ó± ±‹±K± !AXŽX‰UX5X‹uX ؈MØŒ-ØŠmØŽ؉]Ø=Ø‹}Ø8ˆC8Œ#8Šc8Ž8‰S838‹s8 ¸ˆK¸Œ+¸Šk¸Ž¸‰[¸;¸‹{¸xˆGxŒ'xŠgxŽx‰Wx7x‹wxøˆOøŒ/øŠoøŽø‰_ø?ø‹ Æà Á ÅРð ÇðŒÀˆŒÄÈŒÂFe4Fg Æd,ÆfÆe<Æg&d"&f&e2&g -¦d*¦f¦e:¦gfd&fffe6fgæd.æfæe>ægd!fe1g –d)–f–e9–gVd%VfVe5Vg Öd-ÖfÖe=Ög6d#6f6e36g ¶d+¶f¶e;¶gvd'vfve7vgöd/öföe?öçä æå0g Gp$Gq4Çp,Çq<'p"'q2§p*§q:gp&gq6çp.çq>p!q1—p)—$E3ˆË¹‚+¹Š«¹†k¹Žë¹¹‰›¹…[¹Û¹ƒ;¹‹»¹‡{¹ûy€yˆ‡y„GyŒÇy‚'yŠ§y†gyŽçyy‰—y…Wy×yƒ7y‹·y‡wy÷ù€ùˆù„OùŒÏù‚/ùŠ¯ù†oùŽïùù‰Ÿù…_ùßùƒ?ù‹¿ù‡ùOÁ\!R¡ZaVá^Q‘YQ ¨Š¦èŠ¡˜Š¥ØŠ£¸Š§øJ „J¤ÄJ¢¤J¦äJ¡”J¥ÔJ£´J§ôÊ ŒÊ¤ÌÊ¢¬Ê¦ìÊ¡œÊ¥ÜÊ£¼Ê§ü* ‚*¤Â*¢¢*¦â*¡’*¥Ò*£²*§òª Šª¤Êª¢ªª¦êª¡šª¥Úª£ºª§új †j¤Æj¢¦j¦æj¡–j¥Öj£¶j§öê Žê¤Îꢮê¦îê¡žê¥Þꣾê§þ ¤Á¢¡¦á -ÔÔ(ÖÕ8×MÔ$MÖMÕ4M× ÍÔ,ÍÖÍÕ<Í×-Ô"-Ö-Õ2A”di¹Vh¥ViµÖh­Öi½6h£6i³¶h«¶i»vh§vi·öh¯öi¿è 鰎討é¸Nè¤Né´Îè¬Îé¼.è¢.鲮誮éºnè¦né¶îè®îé¾è¡鱞詞é¹^è¥^éµÞè­Þé½>è£>鳾諾é»~è§~é·þè¯þ9˜ƒ;„C:”C;ŒÃ:œÃ;‚#:’#;ŠÕÑÝ1Ó±Ûq×ñß œÐ‰œØIœÔÉœÜ)œÒ©œÚiœÖéœÞœÑ™œÙYœÕÙœÝ9œÓ¹œÛyœ×ùœß\Ð…\ØE\ÔÅ\Ü%\Ò¥\Úe\Öå\Þ\Ñ•\ÙU\ÕÕ\Ý5\Óµ\Ûu\×õ\ß ÜÐÜØMÜÔÍÜÜ-ÜÒ­ÜÚmÜÖíÜÞÜÑÜÙ]ÜÕÝÜÝ=ÜÓ½ÜÛ}Ü×ýÜß<Ѓ<ØC<ÔÃ<Üá‘åÑã±çñžà‰žäÉžâ©žæéžá™žåٞ㹞çù^à…^äÅ^â¥^f˜–í /÷ -¯ô*¯ö¯õ:¯÷oô&oöoõ6o÷ïô.ïöïõ>ï÷ô!öõ1÷ Ÿô)ŸöŸõ9Ÿ÷_ô%_ö_õ5_÷ ßô-ßößõ=ß÷?ô#?ö?õ3?÷ ¿ô+¿ö¿õ;¿÷ô'öõ7÷ÿô/ÿöÿõ¿ `AÁÿ“ŒB˜ €³íºÕͶn¶mÛ¶mÛvóž“m·Õ–¶jÍŠ[ 5ܶ»­ï‡|σ8ˆ‹xˆHˆDHŒ$HŠdHŽH‰TH4H‹tH ȈLÈŒ,ˆ@VdCvD"r"r#ò"ò£ -¢ -£Š¢Š£J¢J£ Ê¢¢PP•PUPÕP5PµPuPõP ÐÐMÐÍÐ-ЭÐmÐíÐÐÐ]ÐÝÐ=нÐ}ÐýÐ0ƒ0C0Ã0#0£0c0ã00“0S0Ó030³0s0ó0 °‹°K°Ë°+°«°k°ë°°›°[°Û°;°»°{° û°p‡pGpÇp'p§pgpçpp—pWp×pïá}ÜÀM|€q ·qwqácÜÇ<Ä'x„Oñ>Çø_ák|ƒoñ¾Çc<ÁS<Ãs¼Àø/ñ -?ágü‚_ñoð~ÇøÑx‹¿ð7bðþÅxÇXŒÍ8ŒËxŒÏLÈDLÌ$LÊdLÎLÉTLÍ4LËtLÏ ÌÈLÌÌ,Œ`VfcvF2s2s3ó2ó³ ² ³‹²‹³K²K³ ˲£XžX‘•X™UX•ÕX5X“µX›uX—õXŸ ØؘMØ”ÍØœ-Ø’­ØšmØ–í؞ؙؑ]Ø•ÝØ=Ø“½Ø›}Ø—ýØŸ8ƒ8˜C8”Ã8œ#8’£8šc8–ã8ž8‘“8™S8•Ó838“³8›s8—ó8Ÿ ¸‹¸˜K¸”˸œ+¸’«¸šk¸–븞¸‘›¸™[¸•Û¸;¸“»¸›{¸— (šû¸Ÿx‡x˜Gx”Çxœ'x’§xšgx–çxžx‘—x™Wx•×xïñ}ÞàM~Ày‹·y‡wyñcÞç>ä'|ÄOù?çü’_ñk~Ãoù¿çc>áS>ãs¾àü‘/ùŠ?ñgþÂ_ùšoøçü“Ñ|Ë¿ø7cøÿå|b…Ø!Nˆâ…ø!AH…Ä!IH’…ä!EHR…Ô!MHÒ…ô!CÈ2…Ì!KˆYC¶=D†!gÈr‡ÓçúB_ê+}­oô­¾Ó÷z¬'zªgz®úA?ê¥^é'ý¬_ô«^ë~ÓïúC*Zoõ—þVŒþÑ¿úOï˱ÇqÏñÀ ȉÄIÌÉÂ)Ê©ÆiÎéÁÉ™ÅÎêlÎîHçpNçrnçq^çs~pAraqQsq—pI—ri—qY—s”Ë»‚+º’+»Š«ºš«»†kº–k»Žëºžë»º‘»‰›º™›»…[º•[»ÛºÛ»ƒ;º“;»‹»º›»»‡{º—{»ûºŸû{€z{ˆ‡z˜‡{„Gz”G{ŒÇzœÇ{‚'z’'{Š§zš§{†gz–g{Žçzžç{z‘{‰—z™—{…Wz•W{×z×{ƒ7z“7{‹·z›·{‡wz—w{÷¦ƒe{Ÿ÷û€úûˆú˜û„Oú”OûŒÏúœÏû‚/ú’/ï;Ÿ#ÅÿŸáokDÇM߶k¯±m#JÖ½+ºô£»/NœÜétdtTÌÛô“¦L›5!bøÄ-×#£×'\/þ”ÕMkÄ¿Ò³ÃöŽ1¹ ÄÄ‹©õ¤ptÚÈÿ±[¯AQ\Y€-Ãtw&±¶RnS n3*5*DyøALŒOÂCE…@²5¨ È*¢ <f¦gf ÃcPf@P A¢ÙÕ(&¢Q*>R©uïlv+»§{ÏLÕÎݪÝÔþJ%E’:߯S÷GßsºûÜ{û§4)RKNßWsm{£f¸«#„ÿ¢ )þüeOøBWø@¿{Ñ ¼ú½ Ìpgö½)ÁŠš/,Ù¾{sÀ||#q7Z0Þ–+€!Òáy(âlmvm½¿#­;ð­zkåÖ²’<¡'ïPa®ÿp@!„B!„B!„B!„üÈäf¸Çƒ ºÐÆzDßG²¯w5+C….ˆ›(™ÌÆcì\—ʽ¹îëÌ*Kþ@ÀU˜³£¶DŸgÐ Ç ÿ^  6ñ+ç„Lxy‘©PU/øܹp¥¾Ä 5¹iËC²<“Ù÷|VY»Ó2O{úôº®pîïßlÓyÓzÀÖUJº*éM›plÀyÍq£Á›–ÖÄÉ×<ümáúüôÂ\¿âü}å;,8öþ\˜³–ÃÕv¡¦BÒW¹ì¦7bÄŒ˜¹u÷—%÷+îù5h%s¥y\€#tã-“°l³i7·cî]\¯àH¿Óï\ÚdwJ¦RËÆŽï¶!„ü8”§ÊR>Ç;t1U§*{*ÏÔk&mm°Q([xpii -‡Gï|àÑ›YG£UÒ(1ÐÆæãÜ4ü Æ£ºf‡¡w‡žv{{ÞcÑ8ýNj$ã˜h>i8UÝÃÁGî‡ÌÎýû·¿ÿŸkiŸcoÝnÎZ¤ßQµû‹ÉÜÖï/ßgkm½ž?òs§œwðNyMIbÂÔ«—¨Ü7™Ùí*Ïߌ¬«¾N§éSŠXË81§5©»Üß<Œº ª‡O@}wƇ³›—^]Ö–Arï']7:îØÕO ïD¬Y÷êéð³ø\ßÞáiò‹?]Ž£ÇJüÿM£œ‘_çÑ-Ì×5¬7­EuÞ%þª€!éèLÁ‚üÊí0Zx^Ÿ»#Ç‹òT÷Nãl°é4òzyl¨úmWÒ3B!„B!¿<²Ÿ2Ÿÿ¬ê¦ášyKê†e›×m±æÔ®1íNg_\d[Ñ¿¡ýzìÇ\—«»·³÷ƒR³^gLm†jmç¬õÅuå’{E˜œŽÉ©8=—«Çý|ú®ô]« 9˜ÄÚµF©¢6»Jèï<ÿÇöÎ1vPx+C…öHÌ̶·Þ}cÃú¬*ײ¯å§ìúݾöˆ©ê6k«åh-‡7Ô‘bçþÃûj÷pæ=U;µyÜ—’©õC@öâ‘3M'>à¸wóƒ=ƒ7ûî.­1T›B oOHšš–ÄÉrß²Ù•åÈœRV2³ôÁõGÏV_Z«Ó™¦v iaáøBÔo¹3X7¦!Bª0ªÍ~·Œ×çmd[íVFfÙãGƳҡ ÖúM7–÷B šaW‚þ|òÕ)Öø›©}‹¼À ÷—$ÃH9/?ãÝõØ¡,¤2 žíèdå¼hu°IðDÔ°«¤y¢Œ -¬a›ƒF~4Aîœ !„B!„B~2”Åòc>Ç-Ä—& z¿Z S8Eã+æ´&w—û/]…G!!P9îhVÚ¤‚5L'Æ~Šâc‚ј°D¿K€%ga `žü5| lU³åPke•IÀ¨ã8þ -2€Ÿ!»!’î² ùIá!U˜É@&Tó83a$+øz£o„Õ> ‚T±}VY»Óª«Ð@ßlõŒKBÖ:®ùV~)^ÌjMê)÷_æmióc¦a®lpŒ;$B”Æã&Ñ©r£ÔíÅF"‡¢÷áa ÒNf\€¯¾Õ°M«¤ ì8‚pLN‘ŽØë›CE íÀ¸¯BAEýM!„B!„B!„_¹åƒàÄAÖíAphPüxìÇège¯7rz#¸xÏZ«r?e]*Ï%{Än3h.ÈžY3ÕÊÚ`q¸‹!„B!„B!„B!„B!„B!„B!„á¡LUVó;³sWo{—Ã(潚ÖÖ–¶Æv?¸…!<Îú»äEÆñ34{fzX:2i™N‹Û]‚\Ji©+»m¥ZC$…BKÛ•b/Slj‹°Pz…½ÍÌn·-Ý–î…ì0›*Z5˜ø`åÒ„&¦‘M4j|àÅDδǨ³öÁ>ùê‹''ù¾ßùßÿä\è.bc÷?©'…z²^æe‰ÙÅû¼@͵6ºu§C {oßÿnˆ”ró´Ö:ïfÏA²2ˆú{ä6ŸÔKáè<â<ÚÕÙ{±§¯«Ÿëw¶´dUÂ7{]ƒ©eöqM."u›} N&n}t=ªËu'wˆƒ!H Eú|·j - §hš®-*÷Ÿ¢ÃáÑðG§Ik"{ÌÈy¸ ÛC1- (‹–•æ_þë‹þüû kƒ<‘H.Ûr¼ñø«'¸Ÿènž®ci3yTÃ9ú)OÖ“fºžµ/dð ³Q µ>‹¨D” FGƒÃÑP5!<ÇÖ®iª~C=+LŽ%¯½æèâÓèi®ØÈŸì¨{Dñúì-€ïßL&o&9r ½ ïýÙ7ɹp·êö¶ t8ÚêÎÔs-‘Ó‘L­ÿK ¢…°,iøc…¾;vÕ+-DÉnöõâjº¦¥’ûÁš°–fÖ:[ÛÎgw;/õŸËÚÒ£}áKJ'_ô¼u&ó7orêQæ|õ}›ýá½²úÆ 7¼¢ÈÒ*Î0«¥­ö½Ç^kïÕrVšE@šÒJrZî24µ KhH¡Å¨=µLÝlÔLËp›QË[V\`ÔÌK˜žÂb£fù§¸tƨm\B˜ÂÆÅÎŒ¥ù˜OÅŸùÅ£zúwûZ}XV+(åàE°5 4€&Ð -.€~à -¸ -ÆA ÜIð9¸ fÁCð=øü -†IgÖ0ë˜l&ÙÄä3;se¯¯hVp¼b ÙÐÛl :«÷7Ö¿=U,(¯o0™¸7=y‹£,VàX|‹ˆ‹E‹_ÀЄðÄ&„aPÉGø÷Š4;ßJ*³È#ˆù“µ>/BS<>/Dest(figure-33)/F 4/Rect[65.905512 355.756868 109.581293 342.157259]/Subtype/Link/Type/Annot>> -endobj -806 0 obj -<>/BS<>/Dest(name-example-of-an-address-in-to)/F 4/Rect[115.040033 355.756868 414.376459 342.157259]/Subtype/Link/Type/Annot>> -endobj -807 0 obj -<>/BS<>/Dest(section-2.6)/F 4/Rect[65.905512 327.657259 95.494623 312.057259]/Subtype/Link/Type/Annot>> -endobj -808 0 obj -<>/BS<>/Dest(name-resource-properties)/F 4/Rect[95.494623 327.657259 218.559809 312.057259]/Subtype/Link/Type/Annot>> -endobj -809 0 obj -<>/BS<>/Dest(section-2.6.1)/F 4/Rect[65.905512 267.35804 99.092035 254.35804]/Subtype/Link/Type/Annot>> -endobj -810 0 obj -<>/BS<>/Dest(name-cryptokeys)/F 4/Rect[99.092035 267.35804 155.527338 254.35804]/Subtype/Link/Type/Annot>> -endobj -811 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[274.557123 202.158821 318.073236 188.559212]/Subtype/Link/Type/Annot>> -endobj -812 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[324.13183 202.158821 383.146723 188.559212]/Subtype/Link/Type/Annot>> -endobj -2495 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2494 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2493 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2492 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2491 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2490 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2489 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2488 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1830 0 obj -<>stream -xœµW[S7>”éËö˜â$Ó@؆`2–¥Õ½éKîaHm.Ng2™NÉÐÒN›¼õ§÷“Ö6Ëb{íéáÕêH:ߧsŽ¤³©H9J#TN 朷F¥¿^'7 ³:vöë(¼Iв&5J2˹u6uV3¥¸W:ýô[ÒI~ODʧIóƒ`<ýøGæ[?˜"D–1-¼qqÎEÒBjáú#€r¡tzÕƒ¼ºÓÚM€1—æÿE¼ -’¹â;ݶÐ}±Y¦ãuÖï´ -í«¼- -í⼂ü¦{[˜á/-×EÈ­Ódà{g™³Š í¸K%Ü$lƵ\§§×IóxÿÍÁÎV*$‹j$¦§ÉÛ ²ô’öi–¨M¯PÚô†Ž¨E‡íÓ[Ú¦Ÿéò0æ(ŽxMçÔ¡³zÆ7ÐÛAÏ9ú:==¡7Ômh¼•nÓÊYFŸà½ç>êu»=g¨¿¦ÍÓwøÕÐâ˜z¥-ô¾¦]¨;¢¹ú»ÓÃKWB0É•s2¬ë[S€Ðmh=†ž9h¶u´ÑŽ³´HߢÌÓcZBy"w ÓÂÊ;‘w’“(Ýï­3Xl’Wó.Úã’z¾‰4wNïûÒ‡*óÖw½¨LÆ2™)¡J ã@»Ø-Àz ´8þ6”ŠØZqæ…ó²lÄ1ØÝ Zèôz|Ç^¥FX†½fµI3§°ö̉¬Ìü·07»IûLEš/:?~5œfÖ9„ßó  n{@µ»Q$”a‚;éEI/æ/Óli°ˆ3V ÜÝ(íš|'lGç¬Eq/ô¨äûá(ö†½¸wYŒ»»˜Ò8æ„•8FîaÎöpSéx¹oãÜSgáv±"-×ðØ$7D!ö‡¿=ï\‘ŽO¡Ĥ+›x8g'Ü‚ †-a\†…xfWXÏb¨µ~9;ØÚIEÆLüóNõBíGÇ -JƒRb(áyIh†>—B¨ _J†`âÖöÜ9ƒr‰“ËÑ‹êÉÊ1®¥U²09Wð„6C4>ULðhèü5Zc8„–k•+é åsÜZзÒÓv< -¨öû(0Ç3t¤ƒq?ÐxÎÐz?š5Le%ƒTã/üt ¶Ås’uZÍÉ -hiBø"v}…áÏ0\Uôœ1Äèc2@.£½†·&L´ÿ4ÇÅÙº -QôÝSHja}u¼ÌÅaK•$3®˜ãð£æÒOÎsr†3ô²&ÊjÎmNÈ«¼›Î³ÁO"xp–Ch6§ñ:6ñ«$#Cš4ÞâùNjŒåR‹FYƒt©¯¡‚²LšpÊh?…uÂîî -ÄV*¢ßàž‘Êh"&¼ñÑßãØ#Ûµrè1X}6|šØ)8/Áz!t6ãY‘óËypžy5D8×Ë(!hç¡m%ž?éÀBÁO°ÂH­Èspï—V;Ú8œùÂ:¿óŸ~ —0³G%2¸ÅµgÊîÃ^L³²ÞU¢ƒ£×cP?ByPN´ÆHãq'kD%P!±³Çä’Ó!£XÆ3«ª‘ÍÇ´'&ü5dÛ5z8XøP×S¦­Ôb(†‰Ÿ$ý$ý@Ý?ñhR»{ñOüÙ£ö”¶ÔÈ! >èä$àù7CølÙ‹¹|+íÒñ”¦Å®BØ]¹j õ‡½Ìöñýüœ¾¼. -endstream -endobj -1714 0 obj -<>/Font<>>> -endobj -800 0 obj -<>/BS<>/Dest(figure-32)/F 4/Rect[65.905512 581.289764 109.581293 567.690154]/Subtype/Link/Type/Annot>> -endobj -801 0 obj -<>/BS<>/Dest(name-example-of-an-address-in-tha)/F 4/Rect[115.040033 581.289764 276.613031 567.690154]/Subtype/Link/Type/Annot>> -endobj -802 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[346.674311 544.090545 405.689203 530.490936]/Subtype/Link/Type/Annot>> -endobj -2498 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2497 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2496 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1829 0 obj -<>stream -xœÍZ[oǔРTq#;N|p+±WsÙ¹¬¾¤¼IbEQR’™‡º¨òbHÚ§¢úÓ{æÌÌîÌr—릠iŠ»s;߹Ι³Ûc= -Ÿ×öÇä,3¦Ð*ïýåC÷çn¦%v†_lü¹ wZõT.2M©6ºg´Ìòœ¹ìýò×î¢ûS—õìç—»Gfíýø·®¯‹r -cœg’Êàœûî >°43aPù€¤dï½'ù>é·÷‹oXfzîLoH·pÒ­£îûoëp -ÉC?Šîß»{ÝÇó¢ö_núɘ°ÿzõߘì÷WÝRÿFgFç”ICMQ“qQpizWºGgã»ãÁ÷=&2\CÀ¨ÞÕ}÷íKrF&dFFä9éEäïOàî9'}ìëCûô,—dyOþpuÒ\y•$P-xƹP0~=ÐKr - fd `&dØøFÙ^;®O¦+h·EÊ€c’)þpjÀ94A°@s ¾½m#@=&søt€“ ô¥çmãC«_Á—põ’S=ÆU&4§š -Æ-" |‹<ßàÊ–Ž¥ñ¼¶‚È3™Se€! ‹ Ãa17ý X(Ï#°¡m®ç°ôzlû ®ÏÉ®¯±ÏZGzGž…ÉòÝ?±óñ -]d‚æBú  {k»ub,cò©Ï‰SqéÙ»Tø¢l·X‡0ÏŠaž¿Na•—h±|V| à÷m;¸²ÐLçžxÁuüsˆ2‚W:\¾ûJü:æ¼j €¦Ð| ß黚àß)Ì¢hÆÞgë1å4ªÈU°Šj} -“›Å©÷ícß¹«ÙÅÉŽÐ’&(]+ m¡O6AW°û ©JˆõÞcÔc$YUÿˆœÀ×^ï‘ò„<…ßà“Zåiì À.ÐaÆ~}£t+”@iìû:+þ -"jg|6Ûœ#â'•!.3ò²œrúÒÆêgÝ%b¾7N꣞GȽåÿøû)ÜA4µB9AF^@gŠëÛñOÉ— ©'p'É7~F;K…Ée\èÒý§åû5I4Œ|NÞ >>…ÏA…ÈYÙqÉÄ0Ù*fìÔüþ®pò:s¬È¤ÒˆҜúj)¹k—… |^ò¢t0gèg5× -­Õ²Ñ‡Æ¬Y^ª LÖè­±‰¦ü4°2¾Ã¸9Šä}ág]—óBä [^#tºÖZÀF€‘Kĵhë}Ó@N!3í–!.š)‚ƒŽiœ{®†ð½Œ`jûÜj .ÎðúããæY·²-v£Ÿ#ÖxܪDë pùµlAF` -ÃJÉY»<ñ~sd£mˆÃ(=ï5Ögný;·ß4.1#¸õQgìó‚…Òû~Ä´?FÜàݾßnpÇD¶‡>vlÚ›òÜÀÞ”û SB'K»ö¨æ™¡¯›d‘j nýyED­­ÉÎO±5žíd3G}M¢ýê5w0µ³¥¸©NR¹úŽ8¨bz•š}Ð÷‰L%b—ªÿäU bn{æˆñ|½°!K/”¨ÒÃÚ걬k]sCI‹,çE•ýYo¾öv³jµC&>ªwÆ]+ÁjS[4lí3¯ÉÓÃFí­+(8—”Ô”1ÃÎÖYÍôn0~OpcFœ!µ;Äè|Èy`ÈAÑß‚¿¸¥ú^©ý2£ æ&8nQŽk߇6%2/2ÊMœ€nH‡Þ` -äh‡ZŸÃõ^)ù=¢ÊüOpGá÷µµAºš‚äUÒl–/ßýãÌW6oôo ùD}%·ù¯'²``ÿ´Ê&-£xx(ÃeHÓû¨@{wŽí‹òDÚ<§ƒÈ˜&Q¹öúÂ#!4Bêa`†fþIóº­¬(F3Zˆ8w¬9çñ¡3Iµ^"¨…3æô<»ºX=)`·¸ÐÀo7ç­2Ú2mçŠÃèeúhχ}„2õñÛ*æ4DÎKD0Cħ=—¥WvâNV3ï< ”—õmÌÐ'ÚŽ§~·<Å“iØ;.}´{C®ÙTÇ{YÐ#D± -Ë,ÇsïÒ‚ZyÓ”fZjH#ü"«†æÎμó,võ¸½‡¦?õ»ÏJçše r™×ê‹Q}ÎÑ™aâ·*ˆ]¤ÚN›ku¯ÊÑ“(IN8pN~õqUÔÓ’‚÷¨<—‘ׇXd?EöÛbØìÎvĶã±?"Õë¨*ÈvÊÐQßk<-V˜œ¸0_‹ ZdÚ0žóUÎФÚ¡L–›¢Êô䬰_ Ö/¼4C‰tpµZÛ-ì/taË»qU<:+¤.`})j´ÖvU-×<<ÏàûY+‚ªºœ•!\‚$`;~0íÇŸ­U÷„ßÆr¶ä4cZ0U<¼œ=®Š1eLûœòá<ËBgÊ9äƒ)wÈ£íu«àp¯åz ›û…Uî–L*“g¢P†nñ´`yŸêÕ-Æz¯a~ÁÀDPÿänÛ§­Åþv<¿ùmÝÐ~-@Ií­ãwSRŒß@I‰}¥EÚ]””wwPRÞ@õ"ï`JK»()æî ¤öº €’úäJë™»(©Y̷ €’ß6€¶'+áHJ©’TÔŠ$G<ŸŸô,L )1þP¦!e„»ërÏŒdv¦´°±@‘ïàTnÈù棹fpúV4§õªÂÿ‹k%L¦•’E^;ƒ®ð?}ÁÉP•qÎ…` ÙÕ£Àž´Ç§ µé\XïÑ&¯-™ÔV&$~ôÝ\X¾L*¥ó”ŽÈ9¤T9cvÄUR5T)«b²çÚk”5[áâ£Î»²fž–q;þêMíQeZUv!6½iÕP—9.Ÿ[|F>Ǻ౯•Ý3XÄž{oýígØóÁŒËg˜ë„þFMô~U+NQ5–Íðœd†Ö~ƒ…KÿÍ¡ö,†’¯kÿÊ¿œq†"¸Àð5ûwß—ýú(.÷hj/}÷-3E´m¦«%DE°3E ¡e¢Æà(’,É×@ðKÊ3ò´î-ë Ày„¤´b ½E|[¸:ýv”l”ã”ë|3%JúÕÖ' Ï'UUçÁr+´Î¸ÔB²F -­ö•3Fõ-ÿŽÈÅòþß¾úy±¥,!¢1e´!Þå´åÖ9ÚKõälKÑj™qYüF®…õ¡!틺9κÿH¦ã -endstream -endobj -1712 0 obj -<>/Font<>>> -endobj -793 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[390.129877 771.389764 448.224115 757.790154]/Subtype/Link/Type/Annot>> -endobj -794 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[454.282709 771.389764 513.297602 757.790154]/Subtype/Link/Type/Annot>> -endobj -795 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[140.2185 276.202264 199.233393 262.602654]/Subtype/Link/Type/Annot>> -endobj -796 0 obj -<>/BS<>/Dest(section-2.5.1.3)/F 4/Rect[65.905512 247.602654 107.621088 234.602654]/Subtype/Link/Type/Annot>> -endobj -797 0 obj -<>/BS<>/Dest(name-additional-address-examples)/F 4/Rect[107.621088 247.602654 256.92309 234.602654]/Subtype/Link/Type/Annot>> -endobj -2503 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2502 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2501 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2500 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2499 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1828 0 obj -<>stream -xœÅY[sÅng£—å\X6TÙx’¨„lP«ï—ä!G–V²"yuÙ5 Š‚Tălª ©ªòŸž¯{.;×Y‰€ÆžÙ¹ô9ß¹ŸîNxÂpl‡‹Sœ:ç­QÉßߌߎ©Õñe~ߎqgMb”¤–1ël⬦J1¯tòý?Æóñwcž„ãûoÇ;_sÊ’o‡ñÖC8‚jî‹c®ÆS Í]þ¸¼‰¬tò:cùºò>ÜÏŸ‚uIú¯Ì¯dJ¸òÚ–^_=­ÃñZäï#¬Òýëôž—îËãJÏÿÏp«å2ü%õk™í³óqag©³Šqí˜K8sTH/´KÎߌwŽ'Ÿ<–pI# ‰¯’ó«ñ[dŸLÈÙ%¯È ™ƒ»3Ü]<l ×99%äáÍ¿ŽÈ”âîŽà}3#¨ã8ËÏ‹B°9Ë´n. •V°Bå@øYÔÍ«Hm./2.{‘Þ^Ä6‰œº #N† Á³*ýT¾Ý¨”ÚIÔOÙvwq¿ç³øí,ÊFY·dJ! ”s2 -¿üæ? wTøÀ烜®Ç‘ß>~…XÞ’jnU†="kæZûƒÂp‘h7@#¨‘Öx<…]ÿ†!{$n÷”öÌ؆¸ÊYqM“Îû&çÔ£RÍΣ·•µ²9Uíz„³Àý~ä7iÕY·äŽQk™f®áq)å àƒø, Z‹vºhàjúÖ¬Ýr)É)Ï !ïÖõ#‡¿hî¬wõ¤_ -Û<ɧb‡p˜4ܨGÑÕÂýI4©ó¥®š»hŒ ç’ëwê¹å ßg`³ÉS[#­ùp™­œÐ¸äÔpÇuè’„f2—Í¥ºÌàÿýNö‹¬Zæ-8£’)ƒ†e8ó†%ò°4–¬Â’ g¥B7‚ÛÍ2>ʬ’~UvÊÓž€Øœp…Uˆ=Í<Ï@Õ YKy¶ÕžW7°p‚zÖÜÖÜÀÀV4°4p.¥5úNÔšÁì›&æ†2g…ÍŽ¡©uÅÎÊýA·áoc^)EŒ•EÕùÕÌ[Eò‹›w0û†y«-¡–”I©E=†C• -Ç)”¼ ™/³ÁP'Y)9‰L¾(—yÛ‘ÒI /ƒ·•¼Ì¯AYÈ}²ÅPwÑE¤ÝË»¸êHbUî7á]K¤µœrc¤Ê“Ã:ydâünœT¤]îƇóZê4…³.ÚšÝØŠUµ1‹R]dùïEÔÛ4wýÕ }U^á»èm=s´{7(Ê:ê±Îçß?Y©ˆÛÚñ+£)Â]qUk0—ðšO†K¯ƒö…µÂGùÏêfÖÞ†¦Èi1œÑ23¯¯(¨q†zëB§8˜ÿåÕm'¥¨J˜ioê­òÎ__N_&¡ÖD^¬ˆI I9éï:€j;t(SGŸn‘®…E»%ѬHc¸2ùÒ×­¦Òp ª¥P٢ŋ¿ÌŽOÚµõ$®R¼ÊdH÷ɽZ}SNï$Ju•.Æ?jÌp±¥3–·||¹UËÐiÖÝ~R -“ J¹{Î3ó"V{Ø)¯=ºÉ¸ÈpoÛíášöàP±ÁŸÍíqÃa4,ƒZžÔ¯0ã¥ÌRl¶ÿ,»C€Tèu›À•%ºz:4t9C ˜qSO„®•F¦Ýüô³‹ƒgÏDÔÄ?ïTæŒ×(uql“„Pá|M¾&wÈõŽkA\8j “Ìd¶¾ƒã)Öß?X¡_RÆ[Yœøˆ< Á±ç@´ ªÈ¤,ÑJé ÐÛ¬”Ì~3’tCQ“¢&U8~"_ur)²[š-òI*T’J–Ëô¯nŠÞSã;dú1SôF ö8£unXàõl¶qÿU|ÊaÚƒÈÅw"„…2çu\y˹e,AœçðÜÆÿ¨ún$wúÀÉMÍ.×Ãà‡d ç÷ðd¿îc/øªÐ«ÙâcHþQäºj ’÷c°í¤þÑ ÅJ©Õ bú÷x˜1èÂñ€ü¦Ÿ½eÔˆÕ¬ñ3ûƒSÔñÕlb/h8„âã¥^‡¨ø3ν8ŸŒ­fˆÀŸ¥ `{©K ÈÑ À 4¹k1Å¿— 6(ÏÒ¶h¯î·…®®—QVaÖÙ¢ëHæw‘AÊiºCÊ"ÕÆZSÛ^26`ß÷@êqÌ|I¡ó¾dÄ -zUKtçãåÚðS¹ßœ–vðnÕB:É©õŽ÷nÅü!‡Ùq}ÓåçÝr†QÌHtï’Ñbé®mèel8÷‹µs`¿íFPµ÷ÆQÀM`O£*Ó†&ÒÊ䨹• Ól‹©AuØÌ2®Iû -µ¦YH*˜7¢sÑ4wÈ&fÞÙ;ù­÷öK€–7@Fè÷w++5m+>Õu™£HûQM…hƒ=CpÕ=º´˜´ ÙŒPæ`š²/|º¾6ÔµMSZ/®í¼`Y‰ä-ò—µ¸¤3DMkq)(Ý éÚÊ0˜a -n˜­…LIäîÕíþ-¼»‹ùÔMãZa¾Æyh©êyfÉ»-ͱH±‹Õ(‘ˆ Ã<&ôWÍéëPm6!çCâ‹…¨a $R·³ÆÞ˨ád«q2F!X…UýœÙÍwÃGq q}±˜;XoÞZ´›VjÞÊÃÄ•Ô³˜J'qÉóòŸ8íÓË«ÿf[‚§+êR3ÊÃöÂ<ÏáarÃ0_âÝ#Ç+ªÖ"ù9ô×ÇX‚üa¶Hòaݧãÿ•ÒOÿ -endstream -endobj -1710 0 obj -<>/Font<>>> -endobj -781 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[348.830561 744.190545 442.070795 730.590936]/Subtype/Link/Type/Annot>> -endobj -782 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[448.129389 744.190545 515.233881 730.590936]/Subtype/Link/Type/Annot>> -endobj -783 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[98.713617 681.792108 157.72851 668.192498]/Subtype/Link/Type/Annot>> -endobj -784 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[212.219233 646.592889 271.234125 632.993279]/Subtype/Link/Type/Annot>> -endobj -785 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[212.219233 611.39367 271.234125 597.794061]/Subtype/Link/Type/Annot>> -endobj -786 0 obj -<>/BS<>/Dest(address-examples)/F 4/Rect[292.1206 574.194451 359.225092 560.594842]/Subtype/Link/Type/Annot>> -endobj -787 0 obj -<>/BS<>/Dest(figure-31)/F 4/Rect[65.905512 306.919842 109.581293 293.320233]/Subtype/Link/Type/Annot>> -endobj -788 0 obj -<>/BS<>/Dest(name-example-of-an-address-in-th)/F 4/Rect[115.040033 306.919842 271.841303 293.320233]/Subtype/Link/Type/Annot>> -endobj -789 0 obj -<>/BS<>/Dest(section-2.5.1.2)/F 4/Rect[65.905512 278.320233 107.621088 265.320233]/Subtype/Link/Type/Annot>> -endobj -790 0 obj -<>/BS<>/Dest(name-addresscomponent-object)/F 4/Rect[107.621088 278.320233 242.407221 265.320233]/Subtype/Link/Type/Annot>> -endobj -2513 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2512 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2511 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2510 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2509 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2508 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2507 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2506 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2505 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2504 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1827 0 obj -<>stream -xœÅZ[oÇ^”ð T6§îźŽÚë¹_ -ÄRŠ¢dF)S”å¡-*¿Øâö±ýéýæìmöF‘bäš&©ÝåÌùæÌ9ß¹ìŽøˆáõ<|9ÅSç¼5jô÷߆©Õt±ø¦“? qdÍÈ(™ZƬ³#guªóJ>þc¸þsÈGáõñÝðÅ_yÊFïþ5 ã­/‡p.Dª¹7ŽÆ\ çxajîŠ_@Ê¥Gïs‘ïk×ÃñêkKÝ(ûË»d6qí²._}Ý„ãµ(®¬èø}vÌ£ãx\tþ–áÖ_)—áߨù‹ýîõ°ÜgSgãÚ17âÌ¥Bz¡Ýèõ‡á‹ãéÛÃýïF\¦4‡Ä¯F¯¯†?&ƒäνL=ìIíú·¸öY²HÎ’U2Ã÷ãO’Ë«äÞÓ_ ÷_“l‹\\Z:üdcÜ6yLƒüà:Äç*ÿÅ(ÚUry‰ÃðÓ³|@viŠ É>-–~RŒ|ŒÙ—¸¸‡¿Ï“‹d‚óAâ9-¶„ÏY®y3âÂ¤Ò -f™ä"¬HÏ€çsMõá]âóG |. Èã^õWNp~‚3…ÎÏ“{É VøÏb2BÁè-Óì:Õÿ!Såð[18\ÙØï5Qí†N¢÷ð—õˆ&PË))zžïifÆm~ÜúåË zçÕ&Rçõõú§ ÛîZËl\S ›w"þ=Ά1‡8ºÀñŠÆÝ¡ã2¶;·°*åS‡ò~ƒ=º /ƒõ„8è° O³Ö¥FXa7½ ­˜–UÉŸ³Ë(aìµÌPœç7¹‘ÿÐjJ÷Lm¢áŒ„(Ý6Fû²aøŸÈYCøfBòŒÅ×à?$W;¹‘–w‹ðF¥œi®$!üËéüøô¨ á}D‹x‘¿è…¤DyejL‰¡mþ€™ö“ïq4IVõ‰„BÆõq¢=QCf}!N§N:ð¹^Õˆ÷º0-*L8zBtÆÉ|B}[nNÈ–´Ea¦½2ux›‡Þ,ܯ(OiÖýfNóf¿íŠ={ùù6uì­Q„`2õ–3ás­õPæ­)3»"yh:}Cá’›ÔJ¡¸jKAêCË !£aΧžI#›ùA”‚=‡á?ÎÝxœïA™!4³±x«`‹å$oÈC.ÚЕ·)Zòô;Oë²Ö;¤«È–×2é\êR4ÒjõÚàñB¨ö€l™™Åœâû˜„ÉYoÒ(¼FY òJ Þ•ÛÆÚj]0ÑYf *›Z_ômA™¯¼É…õÙù´2Áx…›ñ>&#?h9 )·¶W¡pR›2g^ä:X–ç”ÊœSò>.sä™ÿœV;§+Cò°ÙÃi]>ÜPcÐ[{Ê µ¤-®*­½¥uÍK˜Ñ+ëÏ4º¤ù¾ÇŒ3‚tÕ¹¶ã8 |Ü¿zrÞ¸ÉdÍhΊFÆ •Ìè3ÛÍZG@qjÃ̹sų9ÍU×)M_v"5Ê(k;‘NZ±E;¾©…9Wµ¨1K[EM^PjÜoC -æɤÔ%e>«QZSuÖTnjÝHöÊyæÑŒõ,Þt}§"ƹÖ õ¯Kò”#Nù[*ž_Eø6s÷Ú~.Öúo¨~g9al°Î°–I®²yî9™Mè¯bŽ …Öåºu¢FÞs­j›?#Íg.¼‚i¾}q}ðV×~¹ß‡ô=-•À/¨%Ùμê;T¬—±ýŸ3Ãè_—AI ¹7&_× ©ã¸ÌrÆù´U¾×X}Dvt’oáÍ:íU|6S[ƒ×ûEøú—‰QÒ(ÜoV2á©ò T대ö{²æžÌ¼P‘'WºXQô‹½rSïŽsÌÎ.È7ƹn'äÉcÒUåÿݾ¿ åõ¯Ojx´´ÒÖȾ#­â D”7ºkP™VÕZ±Rº•Ð&ƒ&ý³”1…ÚªKfQ Žss÷¤û­N¿6´„ß­ -ÃùL¶±ð®tÞ¿0ËS%¼4EäŒ3ø†õK/ &µmt ¢ >ÓÁ,o2.rŸÞ>ÆÍ*KîÅn*[ᤈÿ¦æÔD[I=6=ÕZ{”¢õþT´æGØŒ3â³»(‘Íb+;qБÿK ÚKÖ1w–¢$FQÜè9Q9 -È:¿)ºDƒ”šŽ#e -OõÜ·§É¸gÙ»WmLtªL¨·ë=¥H9E99H~,Ë€Y…gQVÛe?W]ë"s´4¶•iRfPØñ6 ‚ŠÆ¨^˲ Ó¾–RVðC ž-)=Ê‹¥Šcg5~†íáa‹›ã ¦‹øÑ%­]] -Š‹«Pµ6zb‘¶›=°n]Þ¹ÈÓ†U¡É55â~Ü7ëWš©òܱEÄh ª"F”O“«D`V¦GÅjêÑä4¿ÖÖÆgEÓ¬Õ0óáKx8ÃÇwµV™XÃœô¼vM)ó$ùEÑ8ë_õëbÙÚ00.DªÍe_^å‘£H"2£,pÔŸ+YŽH ‹'cÌfWG*P ­:'DÊQÕü{U$ÝçyÔ;!§[Q6ßřҦÜ9‹ê¿ÞŽ¼¸¯–.ÒË mÞA‰âœ|eJ1{/¢¥`|{IÑØ«‡¥§ž=©9ù..ó[ŒõfÛl•8/–t•w„ÚY¤^¨ñòoÿɉ´kÞ)iyÞJŠäâ Uu÷A¯+šçT…tmNÞ1ﺺm;]€#,·fWoŠ–Ít‘{'CX6d2vW¡¼)çÌ߼ẋÐvËå&åÞk$Ü»ÜVÝ’ - nÍå7soÄ÷©-SHäæ‚š|ß(¹¿-ç{^dhË¿¼ÚÕ˜@Ù™Y³©·woÓˆE l.ŒsfhK¨Iþ„jÖ%/’¯vöeS#¹®Ý<¼ÍÅreBéŒmT­·Jjµ&<´¹PØ0OÄÏšN- -neô§ˆÒi$P!uÞø)ƒ—7H ìJ#9W›‹yÃÎÖy/ù„ñk¼înŸ("â™âQ|»3g‡5^oñÄ ´*m¸l,yc1:¹|š<ÿ6ùMòù¶¡F¸ÍQ l.pge†“Z2-šÏgÜn4—%3hßvÔ¡kš+Êúò>qò•èc¤ÐáÓt[­£¦µ,<ȸÁÍU ™@šæ·’U”òw±üo¶õPê ±¥Èí*Š9rc»Êæâ£ç3!ó Iþ ðÖpÖÔ‹ýjøÅ/›9úmaªÕ›*v‡Ñœ}‚B·Úc óÇD¸Éï@^’/›Û¿^@`dgA•üZA­G-¶“dŒJ2Du½$–Œ«S÷“ÏñþÕvÂÂCÕH……¶RóN† -î3ª(§¨íÉå¿ññ"Y\^ý7oÌ-¶Ô¥fH–P£ËM„gúì!ßsªª«{[Ç[ªÖêT8dI×®Zbú#¢Þ/“MsœÿQ„N¡ -endstream -endobj -1708 0 obj -<>/Font<>>> -endobj -770 0 obj -<>/BS<>/Dest(section-2.5.1.1)/F 4/Rect[65.905512 729.190545 107.621088 716.190545]/Subtype/Link/Type/Annot>> -endobj -771 0 obj -<>/BS<>/Dest(name-address-object)/F 4/Rect[107.621088 729.190545 184.061762 716.190545]/Subtype/Link/Type/Annot>> -endobj -772 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[312.149652 644.391717 370.474604 630.792108]/Subtype/Link/Type/Annot>> -endobj -773 0 obj -<>/BS<>/Dest(addresscomponent)/F 4/Rect[376.533197 644.391717 443.63769 630.792108]/Subtype/Link/Type/Annot>> -endobj -774 0 obj -<>/BS<>/Dest(ISO.3166-1)/F 4/Rect[350.743158 365.198358 400.619623 351.598748]/Subtype/Link/Type/Annot>> -endobj -775 0 obj -<>/BS<>/Dest(RFC5870)/F 4/Rect[280.580072 343.598748 321.537836 329.999139]/Subtype/Link/Type/Annot>> -endobj -776 0 obj -<>/BS<>/Dest(IANA-TZ)/F 4/Rect[244.53808 308.399529 341.02807 294.79992]/Subtype/Link/Type/Annot>> -endobj -777 0 obj -<>/BS<>/Dest(IANA-TZ)/F 4/Rect[347.227289 308.399529 387.774164 294.79992]/Subtype/Link/Type/Annot>> -endobj -778 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[361.206293 273.200311 420.221186 259.600701]/Subtype/Link/Type/Annot>> -endobj -2522 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2521 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2520 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2519 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2518 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2517 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2516 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2515 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2514 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1826 0 obj -<>stream -xœÅZIsÇnå rH©l-©hG´Újö¾\TŽÂ¤’àja*RR¡’\e;‡¨Ê‡\õòoóuÏ 0Ó3À HÅÑÌÒï}ýö÷¤Œg Ç£prŠSç¼5*ûûûáCju|Xžã͇¸²&3JR˘u6sVS¥˜W:ûéÃÓáCž…ã§7õל²ìÍÏðÞúéÎ… š{ãâšóáHsW¾.ï#+½+X¾«=ק«`F]–ÿ­òë™®=¶•Çç«)¯Eù<ª\¿Ë¯y庺®rÿ wv8KUŒkÇ\æUf¸¥@lµÉ—Ô{¯¬/•E¹ ²ô\Å÷äx85”qáµVhϳã÷õ§œìí?ÉÀ#Òx+;>¾|@Î’]²Cž‘“‡‚= #2 WÉ͇9Þ™QæÊPÎœ±:]¬¿EÉËLœ±¼åå³ä%Y'äˆìGVÛäœà|JžÆëM< OÆd ¿NÈ÷dí«F¸wJÎÎê,¥•:—Þ7Yæè6Ž»5À§*ðÆ+W*aù48ªåYz†Úú8õA?ÂÃÚVÕï\,‘ë6[ǶÌ>`¸ ¬¯jtœqª3N`;žÇvåE´ºñó“í'ÔÄ?Þ©ÂêÞ’Ûä&¹O²`wðó¡¸ùš|Fþ•˜S…”†Å¬-tûŽ’ÒçÝË•£LK«deyNâYÉä4Zн%OØ*6n!½”4Ãâ•)]š· -ê¯ÉG N¯p!ñ ¾òm|ò -stËÓ­¾ÉÛAbó1YC•HdõaÑ&à8†'Òy ÀüÀ¸MÖÈðï³`Š:ih&}·¤¿ƒ Ç’¢D-´@üö.ÙT›˜ïë°Ó‹ùVäcÛæçcƒqr›ÈïÃüו¥ÒgѾÜ͇2T‹£L—ÊÒ€©Ì „šè–{£Û­É`‚ñòÁ>ò™a%ß-'x2Á¾öÉw¸÷˜˜^k¾Çû¿‰!üïâ­èÏÎÉ•ê¦/½Y¥-ÓÌuìônL#1£„­\žà?1"§¨5fÛèY‚ R;€¬ò„xÓ%prÁiÉ‘–„°]&²•w -¹½Ä÷¤ø1üåGÈâö¯¤xm5Ré>V~­r;Bw4‰Ð8Úðwqs¿ -d#4ÕÆ8#:ðîƒÿÐí·ZGÎË”+ÏcÔÚŸÆ{;m¯’+ä:>ᜄRPÔ–«„Ü2§NRXEèÝ$™pW¯2ƒq©Hh‹‚´ àrNãá€lDØðÍy%»qaQÙ¦i ±Aåêávʹ2kŒ¢ýíæÑi\F6ðÛÄg—C«E4D±0·€AדÍú]ÚŸ˜¡Â(£xžeÔ{|Ð!5Ì*Tã½Ùé08¹G®‘›ä÷äwKÇ M·Ö¤•Á†ß§º¬7N -ÈKk„`¶6ÇT2øWæ“ÌÐm‹VaïKÍЯ‘/çÎÐët;fè—;gè=UqÖ¸tÏו -ÿX¢%ÓM8‹æëáFD›¢¼ƒÉ›<–Ι´/µöÿ6s7JÕPNÇïÞÔQ^lošÃ#1`ÿŠ;Á…ëœÃSr›Ü%¹ƒPz?Îþ|ŽË;q0Kqd=fóÆIÊ Zëúl~FÝv“@{%•U¾9Ÿ¯Owá7qyŸ¬‘UÜú&ÌqF&«øþÏÜÑîüá-j©¸…]ÔæóW ÇQÂÂáí¥Â>Ô뙪e>S™¸Üh™¶HQnTB TV-½z>Z@–‡±Oœ%2ÙìÉÓî ¥œD‹&«E³ô Tzϵê1„‰½fŒUÕ$[i'sƳÀx„ó$6±ûsf7¥vp}ˆï< ®ceÞæ+÷MŠNvïïÆ'y+[4Ò‹d€úÆ#+æ+£w2 -8 -´£¢kݪO›Ê•÷bo¿õ‰§”Ϊ½“Vô˜Æ.rá°Nî僦:’¥ùF8mesé ÍåX\9ok¡SõTyÃ~uÍüD½Ø „ÜÀq-•æbùÑ¡'2¼“QcXµ'cÂ`SXÕ͉U§ˆWÉ—ø\_ŽYøŸÖR=hÞÊÃDÓ<Š®4"{`töÏ<¬œÿ;êw«ˆô—¥fÈ)ÎjÙ‡ùút¼µ=ÓN½x“ì-)Z‹’Õy£;w-A~§(ø®§æ8þè c· -endstream -endobj -1706 0 obj -<>/Font<>>> -endobj -753 0 obj -<>/BS<>/Dest(figure-29)/F 4/Rect[65.905512 634.489764 109.581293 620.890154]/Subtype/Link/Type/Annot>> -endobj -754 0 obj -<>/BS<>/Dest(name-example-for-the-calendars-p)/F 4/Rect[115.040033 634.489764 280.081049 620.890154]/Subtype/Link/Type/Annot>> -endobj -755 0 obj -<>/BS<>/Dest(section-2.4.2)/F 4/Rect[65.905512 609.390154 99.092035 596.390154]/Subtype/Link/Type/Annot>> -endobj -756 0 obj -<>/BS<>/Dest(name-schedulingaddresses)/F 4/Rect[99.092035 609.390154 205.679193 596.390154]/Subtype/Link/Type/Annot>> -endobj -757 0 obj -<>/AP<>/BS<>/F 4/Rect[186.862787 475.392108 229.698481 461.792498]/Subtype/Link/Type/Annot>> -endobj -758 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[247.955561 475.392108 288.913324 461.792498]/Subtype/Link/Type/Annot>> -endobj -759 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[98.713617 440.192889 157.72851 426.593279]/Subtype/Link/Type/Annot>> -endobj -760 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[228.029291 404.99367 287.044184 391.394061]/Subtype/Link/Type/Annot>> -endobj -761 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[429.50268 383.394061 488.517572 369.794451]/Subtype/Link/Type/Annot>> -endobj -762 0 obj -<>/BS<>/Dest(figure-30)/F 4/Rect[65.905512 275.719451 109.581293 262.119842]/Subtype/Link/Type/Annot>> -endobj -763 0 obj -<>/BS<>/Dest(name-example-for-the-schedulinga)/F 4/Rect[115.040033 275.719451 331.083979 262.119842]/Subtype/Link/Type/Annot>> -endobj -764 0 obj -<>/BS<>/Dest(section-2.5)/F 4/Rect[65.905512 247.619842 95.494623 232.019842]/Subtype/Link/Type/Annot>> -endobj -765 0 obj -<>/BS<>/Dest(name-address-and-location-proper)/F 4/Rect[95.494623 247.619842 294.145014 232.019842]/Subtype/Link/Type/Annot>> -endobj -766 0 obj -<>/BS<>/Dest(section-2.5.1)/F 4/Rect[65.905512 187.320623 99.092035 174.320623]/Subtype/Link/Type/Annot>> -endobj -767 0 obj -<>/BS<>/Dest(name-addresses)/F 4/Rect[99.092035 187.320623 149.34643 174.320623]/Subtype/Link/Type/Annot>> -endobj -2537 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2536 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2535 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2534 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2533 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2532 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2531 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2530 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2529 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2528 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2527 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2526 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2525 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2524 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2523 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1825 0 obj -<>stream -xœ½YÙoÜDXñ²H” -z -(¥)d2÷ñ‚ l’Mrl’Ý´]„ -"<´E¢ð@%øÇøßøf|¬=ë½’B]{mÏÌï>¾q2ž1ëáÇ)NóÖ¨ì§çÝߺÔê8XþÆ—¿uñdMf”¤–1ël欦J1¯töâçî¨ûk—gáxñKwã §,ûå÷nXo}µ„s!¨æÞ¸¸æ¼{„¤¹+g€ËóÈJgÏ -–Ïãáyt̨Ëòÿu~ „Ì 7†mmøü^*Ž×¢bÕžŸåϼö\_W{ÿ‹;9œ¥Î*Ƶc.ó*3ÜRHlµÉ¤SÔJ¯¬/E¹ ÿ²ô·.ßý“n( âÊpøQhϳ“çÝß ÷îg\ÒHCbVvrÞ}|—Œ×ÈÙ%gätM°»¤O:äyíû“Ý e® åÌIkÒÅúH'™¬ÁÄË[&ï’ǤGÉ19ˆ¬vÈ€œâwDÄçãJŒœ§ÕÓ6ÙÀº£(h×>b¶,ÆXfÈxÜFIK ÓdZ˜\îÍ“vßPÝðŽôÁ¯Œ ¥xé ‹¬¡!-ÏÒ_8u™T¤>xOxDIûm=8œ«K§£tz"mJ·š.í9ñYKÎ`wÅŒŒrÇ4ó"ÆåÑÃÓû› &þóNqù”|AÖIF>ƹï>"ãäVØOÃÍ'xG1ï yü™Ä`§TTˬ-ÜþŽ§äsb/UŽj-­’µ¥åòDœÖSÜáõSòÃl¢FP˜Yq«ÜÙɽ°~d$®Khg õ"ÑnBO€Þ:¹SÙÀ=#ÙlbžSÎ[ô}9GÁ4• úh&ý”B¥sìl*ñå=沕’›ÈüâÚL(Dº Q¨}j¶9žýªÌs¬€c™jqÅÜ*àVh8퉋¸UxF•€¾Èm³‚g%S¨­ -5Ýêf“ ×'zÌå)õ¨`ÊUâY¿Ðlžåi®_Ò­mC¶•Ý*p«Šj»gƒao7*ùW:Om[ x9s‰b’ú4ÓçL‡9rœ 'E±âeÙ=Š#ôÐKA †ð Ê@l ßíî¢^ á¹JnàLᆰT -ÃŽ›°ä°BÀGÀ=àƒ½ˆ :Ilã×­ˆ;¶*ªQ Š¢Ø X# -ÝÑ:Îí4ËDº¦‚Õ¢µË\Áýþ£ÍVLf!Õ^D8CpߊR ]’öÇ?þ…ÛO‹ZUÃVõ¶£tpÿ0>âêG˜àØ”åc{^áñ/ŽãuX õ£57#‹SâÊy–PÀ!œkåkž:•«õ¨*Qó¥¢ -‘AE™ð ŒžÚe -ùO_MÒ×y3Z¾tMŸ7å¿\6Xlh}^²«l˜–»Ì‹w[rÕX+”Ò&¹6u“¥ÞðygÄôÒ„‹DïÆÆÅÁ™KÛ¡•JQi]ƒ°-Áœ<¬ìW”œ&Ç8Ñ)ìÂx’Wb&Å\ -¥cI p=Àu@öqwÞ!ïÿ>y›lâÍ0ç4Êò‹Ëp™rU3f¦ò¾ª*·A(Á`Mò]Q :.—-Ì:˜YFlŠ œÇÂæuZ€Nd:ÂÙÉ-è^i­AÙƒh›G¹;ç)ŠM¯RÂú²ôÀg;’œ¤U­êM‰+¹*Û• »æÂ&<§ZFÛ§ÙSûD_=ŒüΦM#ÃNH9çÌ4qÄX¤÷Æ”‡ÞˆÚ‹Q9jÉКÔØ °jZJ½͸Ý.rÞ&‹–Ö‹‘y¶Áa5°XÖWs´-«Œ±ÓlëfÈã)DujmQ%ŽîÅfFÇmöŒâ*i©NšÚ¥½ÖÞ4Šq=Šcƒ˜×½hŽaUN«ØN³tQ§+?=„Ùû8[±E©¥Ã~°”—*–ÉþY™êóuìU9QïЭ£,+¡¨ c•Óû¯'WªBÔlôÝnŒP˜©r±VjQ¦^Ý6W'GfB»öoõ~&5B‹iƒÆÑ,(sƒnZ®”bÉo Ø… ¢ßñå9¢“ÏäÒбÁHH`¼YA5“`¹w‹Æ}cE%5ÃFÓsëüò¼ÇçMæÄx¶î¨ðÜ{ÁA¢ø’¼*l™YygËóú[KضÂa«(ᛲ-±’(”gÄq€ý¬Ð(©—´Âi¦ÕÒYdò²œc¢Ÿ¡’ô‹/¨½0­œnžz·êKs¾`º9ʬvrÛÒí=œ7WN7À"#¤YÞ±óÒinÃæQ\8Ðæ´Þ­ow6w[Eú'J4Ï1ÿÈ>úÊä-Ó‡E–³ä°:Óž*o˜‡>Uÿ¯ÈuÈ-rÇõ4?ç3ÆCQc _Èhz§‚4ÔÕ8£¨`ªŜéM6A×È;8o¬Æ,üÍZ*4ðoåabý8Ž0´·Dã?pÙ ƒñùßäl“ÁŠ¶ÔŒr㬖Ë0ïU(o;",[¶-²¿¢i­¦Ây£j-‹¿EuÈõf¤äÇ¿º5QÏ -endstream -endobj -1704 0 obj -<>/Font<>>> -endobj -741 0 obj -<>/BS<>/Dest(figure-28)/F 4/Rect[65.905512 506.434764 109.581293 492.835154]/Subtype/Link/Type/Annot>> -endobj -742 0 obj -<>/BS<>/Dest(name-example-for-the-preferredla)/F 4/Rect[115.040033 506.434764 328.204096 492.835154]/Subtype/Link/Type/Annot>> -endobj -743 0 obj -<>/BS<>/Dest(section-2.4)/F 4/Rect[65.905512 478.335154 95.494623 462.735154]/Subtype/Link/Type/Annot>> -endobj -744 0 obj -<>/BS<>/Dest(name-calendaring-and-scheduling-)/F 4/Rect[95.494623 478.335154 333.433588 462.735154]/Subtype/Link/Type/Annot>> -endobj -745 0 obj -<>/BS<>/Dest(section-2.4.1)/F 4/Rect[65.905512 418.035936 99.092035 405.035936]/Subtype/Link/Type/Annot>> -endobj -746 0 obj -<>/BS<>/Dest(name-calendars)/F 4/Rect[99.092035 418.035936 148.837397 405.035936]/Subtype/Link/Type/Annot>> -endobj -747 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[267.979242 352.836717 311.495356 339.237108]/Subtype/Link/Type/Annot>> -endobj -748 0 obj -<>/BS<>/Dest(resource)/F 4/Rect[317.553949 352.836717 376.568842 339.237108]/Subtype/Link/Type/Annot>> -endobj -749 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[256.904047 299.537889 314.998285 285.938279]/Subtype/Link/Type/Annot>> -endobj -750 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[321.056879 299.537889 380.071772 285.938279]/Subtype/Link/Type/Annot>> -endobj -2547 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2546 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2545 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2544 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2543 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2542 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2541 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2540 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2539 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2538 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1824 0 obj -<>stream -xœÍZÙoÜÆw‘—-Àhœ qÁ Žk;ÑhîŒÔYY«£ºµ’í ;ˆü »€“<$EÚÿ¼ß É]rÈÕ’–"Dô.5äÌï¾åŒg ×J¸9Å©sÞ•ýðzøfH­Ž/Ë{|øfˆ•5™Q’ZƬ³™³š*żÒÙO?O†ÿò,\?½®>ç”e/†óÖÏŽp.ÕÜÏœ ÷q4wå`yQéìUòUí}XŸ<2ê²ü_ß"sÀµ×¶òúìAJŽ×¢|ɪ¬_åk^YWÏUžÿÁäÖ/ÊeøÉÒ{í££áLÿÎRgãÚ1—q'¨‘Öx½®îŒŸn¬=ʸ¤†Ä®ìèløìyLÈ>9!cò ßr› ˆÁoÇdÏ7ÉCòv]ìáÉ7xÿW¬±g;žáÝôŒÜ¼ÿÝÑæpí¨°„KÒ/„§ÚxQ]Lÿ!(“H·5Pµ‰û˜¬“¯"g×C¯5T3!¬_Bï.ð¯ºÝ†¤»ÐÙ—F.ÕŠ'2ÎÒ í–PXÚÂ!ÙŠtŒ#¥'XmCº<9%{‘‡c¬ògØV#|Öñæ ž?Æ}þæ«ÀÝn|úïÄ>Á®æ2ÈwOâþ1`lEˆÛÓÿÁâǃxÆØp“ ¢dZy…õX†… -¼‚§ àxv!¬qü'ñýoöÆRÔˆÜr­|úÇ6#’~bœŸ+…²ErŸ5H‘e®,øN¼DØ(çAÃÛ‘» ­¨±­Hâ¾O#ÿ9Áã„\ 'w ŠIÜ9‰d J3m˜¨7áá°Òªq’%·FvW&Eá"‰Xá&ŒÑ æ -þßÍáóþB*çŽT÷C÷PmóªŽ#6hî¬wid«è¦Œdãxß/üçOÚµPêî8F“Ñ,n”<(N'ç&Uý-¡²°'ijҎßZÍ\rj¸ã:ÚUÍ ¶Ôß=õ'8£’)ƒlÜySÊP#œPiœÇæ;Ñ«‚·©ïa5ðs‡.õ÷$FõSü~E>¤œ¦NK‡MSÐ"áÞê)\mbÔ“ÚvÇ}sÎdžwsh<[AvòÜ{7)KÕkÈvy÷ºª¥¤?AµDÕ‡ 7ÃzéºPflf¸¥(¬-\] -üêúdÙS\ª¾2LQå5ó¯¡B®•QE?!Ói’Å5ò „ÆmÙL oÚt ¨hè@„¬ês!ç:xËc4ô”–géªëÒVÂWû¯Up®F ž¨ç² -½9B·Õ5ý3^º‹äžzæµÍ’ý'ÇÖàÕÔÄïTa€çäKò9y 1#Ëçäù5ͳs¸ðHæP²Pó \çd‡ÿH½ô¸BT€Å@Š³ŠóFq“¿çt`ߨ1èŠMÉeVïK²‚¤ÅɧdlÏɃDj0:a0\¿‘ïòŒ:¶´f))çä3 $0 î"cÅ4eb!WRºYuåHÁïÉ‘’’*!¤vé¹ó $¢Ém±RQÁsò;jÄ—äëx¥÷¯É‹B»ÿ›=9¿ˆTAÚµÈ"×náæèíb†£Nø¿w ×5às%ZÌÜ/× ì«Vª{Û¸F`•²E}9<x+änG[@UOµÎ9ÞPëE"ÑR d¶2ÔÅBCÕ&ÂÊ9.F¨B'“*mñvè˜!®8mg*û­ZìW&V—Ëì0Dm­µ1Kj£Z‹tG<«q(ò}Þ-‡4úì¯ðîaã­ÌÏß_qþÞuM²ÐÔ†ÜÖöŸÇz –éhèŠ)ò•º™e³µÝD|m«½¸g=öŸ¡öW.B§4Uhß–vÒa¦ó‚¢Kb}LüróÌËy¤DŠ0·¹}|»·¿³·ÙFë­Ð‘ãóaÛDLP”‚–«\7/NúoËB02a„žKð*”ŸÂHÇ`}BKÛ&'nÐðƒê¨®4¹QÑRç~ëÿ…³„س•³Œ1Ž ¶óÆ“8xŒG£hÎëµ™iÙ]Ü“Óõ¦ôëî."¿Ô¢:²XãØhü«˜„ñì(²[¢ÜˆÞ³‹ï§3fƒÈæ-M>½0ïBõ,LãaEò+pÕ»5iæ1„U© £Û°¤†á- RKÞBA>Zw' ‹„ñy/Ý6ŠÍIˤÈù´dZ$Q¶§…•,űp…†ñ¢½Aßq6±”¼ŒZ ¢d7 ‹“úé‹ßóà²ÐXÃ/XOi>qꘪTpÍ$on,™U׃û•ÌªÛ¤yój4ç\[­T÷ŒÔm^팤g½þÌ«ë0ß~^ÝH^=GÖM#ì>¶n ¼€¾PŽž3ª¨.kIÄ$NiÚ¬êŠl#N`ûØT'â†Üµº4qÀÞwcÛ¿ÄQ)ž3c|Zã–ƒ(±Ð¯ÄÉ—½4RëàƒÂ˜4Àþ‘H92¨`šY†4‰pÈøá[ü­‘‘1þ\Ñã]XÎÇ(Ä>î0œ¤¶;ÂoÚú@!.’ øÑÚ2ÌK[ÿŸ¨³1 Ÿ‚•æNÐ „:k¬áK5êŒ~˜a ªå˜EŒEÝ-ò7|>ì‡,üÇk©ÐVjÞŠÃÄXvå˜ìÑô—XßLÏþ[Ô=e©* ؠ삼lÿB!:‰eK>ä¢Ýé)ÚP¯;oôR®å,™|0ÿ³Õþìú?^› -endstream -endobj -1702 0 obj -<>/Font<>>> -endobj -727 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[487.298822 715.590936 521.945307 701.991326]/Subtype/Link/Type/Annot>> -endobj -728 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 701.991326 102.674555 688.391717]/Subtype/Link/Type/Annot>> -endobj -729 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[98.713617 666.792108 157.72851 653.192498]/Subtype/Link/Type/Annot>> -endobj -730 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[364.390375 645.192498 423.405268 631.592889]/Subtype/Link/Type/Annot>> -endobj -731 0 obj -<>/BS<>/Dest(figure-27)/F 4/Rect[65.905512 399.197889 109.581293 385.598279]/Subtype/Link/Type/Annot>> -endobj -732 0 obj -<>/BS<>/Dest(name-example-for-the-phones-prop)/F 4/Rect[115.040033 399.197889 267.621088 385.598279]/Subtype/Link/Type/Annot>> -endobj -733 0 obj -<>/BS<>/Dest(section-2.3.4)/F 4/Rect[65.905512 374.098279 99.092035 361.098279]/Subtype/Link/Type/Annot>> -endobj -734 0 obj -<>/BS<>/Dest(name-preferredlanguages)/F 4/Rect[99.092035 374.098279 202.562006 361.098279]/Subtype/Link/Type/Annot>> -endobj -735 0 obj -<>/BS<>/Dest(RFC5646)/F 4/Rect[96.753656 240.100233 137.71142 226.500623]/Subtype/Link/Type/Annot>> -endobj -736 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[492.118158 218.500623 526.764643 204.901014]/Subtype/Link/Type/Annot>> -endobj -737 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 204.901014 102.674555 191.301404]/Subtype/Link/Type/Annot>> -endobj -738 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[212.011225 169.701795 271.026117 156.102186]/Subtype/Link/Type/Annot>> -endobj -2559 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2558 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2557 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2556 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2555 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2554 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2553 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2552 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2551 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2550 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2549 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2548 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1823 0 obj -<>stream -xœÍZ[sÇng‹—u• -Âv’©21 ›Vß//”CVh…I» •°•JH*ò*œ<„ª<äÕ?Áÿ6_÷ôìÎuwG Ãj¶g¦û|çÒç6›ñŒá¸NNqꜷFe5|=¤VÇ›Å9^|=ÄÈšÌ(I-cÖÙÌYM•b^éì‡ O†ÿò,?|?ÜzÎ)˾ÿ×0Ì·~>…s!¨æÞ¸8ç|8Á¥¹+ž•W‘”Î^&’/+÷ÃødĨËòÿez+@æ WnÛÒíóÍ:¯Eq?Â*_æc^—ç•®¿c¸Õƒrþeõs™ìçùþ¥Î*Ƶc.ãÌQ!½Ð.{új¸u0þvwûaÆ%kH<•==~w—œ’c²On‘1ä$~ŸÇ}L¦ä ®ìãíë &/šq‰DC'\KlûãÑäàèqF‘C|4ѧەt+Bn%-Q /¼á½Âj]à}X†ª‰YÁ[Âí²…[xÐ߬¤G¤PÞ{Ñ‹¢&g÷|o’ß_“Ï{r©´¢Ò0©T/šß\ÖžPoRdJRûZ@m“!_ƒÚ"wêD+ɺLîuÀn¸¥(ª-’:Áò;¯‚´ó~Â¥*ÍUÆz¦V$ˆPI(YPÒÆ}ÜÐFRÎbOÁÃ!—ž×ÖÅü[Wƒˆ3–·<|vYCHäžÄŠ®éË)˜©E›‘ d9ª¥? aÒcE“øܵ¼n׉iè„$²0so<œ{RËÅgÒÐe²<«Ÿ¡Ðu:E¥ýØþµlÎU0ªF½Àh«/Â×ùæÚ±6¨I™”X[‘—דgÇ»·±‘¨‰ÿ¼SÉ8_Í` w qÊ‹2rŸp ‹o÷Ÿ“Èê9Ü‚lQ!]QN|„ãìÈ®ž -éÀÇ10½˜šOgÀp;-ƒU…ã9üÚí'|$ÆñÖ þŠË›aø¢›"R^Îp”L0½QlOÄIFcCŠêŸ÷ugÑfDZM›75“Nb¿ãJ«\ )[+ ^‰¯Tž4'+&(³J ÌhL¾…õ=š7mKb(CíìÁÖ»£ŽZ­„P5g[ÒK®Ò°껶îzsÓ«¶ »5‹(²àc;5ÚZõ‚]£L×=yvg^mÕÛË'st9QФ¶M®Fo•ÛÚ r—{­ƒTJXç[{Ç Ó¸ô|;–Qm—CP7£pBð:‚¹WçNåðÔ’sÝ6i±MC<›´„¥ftÎ ÇtÛBœ•]Èb_Ô=Z|U“DÇQc ¿èÛE¡ïGÜJÆ’+¬j"ùµ¢¤Îe½˜Y6®–๠¯v“ÖÌÍÅ:M5ø2â3Œžà˜F¯=‹öŸo©Bù¥·Xr)ƒ-nø¢_x«~8/^rÏ4®ÇI#B0|BB³ ‰Cb ¬{âgéýä´'–żÂ?”{õ)]Ä#$x/S—:ÚÆ(N»ÖHC—[In£Ôüïv;…|SWwõ©j$Ý<ù½}ÐÍ0vÄÏÂÚFÉkçò ¢…¿çYîÜs,Ó$ܽåÉÒ(RÝB NêZå­ uîÖöcŠ¾Ÿtšž§VÕ´0ÝqÉd/ÓT„esÎBÙ¬}.Ó¤^õB®Å+!ÃOk*AsIözþ0‚$ ¡Ùõ¡SêÞ»;,¬§R‡dl}‚—n K‰Xd”ÐÖØ»¨T¡7¦˜¾ˆ<7 Ͼï,‘ÞPaUxgùþäÚÌÂgl-º¾ã÷6[©6ºÝÌŽ“/§–ô(O–úŠY‹ðV×i±>e­ APwÐjÛ^þ*¼ ìûæFzØÓ,ß&ë’?;¯ª6_g÷ÃK6î}p/Yú}fÿ—„ÙV7ž_|Rwûï -P%ÿúUÒ°P%ûU³²õ>‹Å5»!ˆjO•7̇À]¦ ª¾~€ØùŽ›u§¸œ€DÅ謱†¯$Ôè¨ô£„FC`YM‰•ëÝ òK|>íG,ü@Ù"Œi+5o¥a¢ÓŽ&Î töoüÙ"Ó³óÿÅr©_?Yj~Fbµ\‡xÑ=¶Y,:‹hò(åÌë‹AL8oôJ®eªÈ nÔÍq2ü?é’d… -endstream -endobj -1700 0 obj -<>/Font<>>> -endobj -711 0 obj -<>/AP<>/BS<>/F 4/Rect[238.719721 757.790154 281.555414 744.190545]/Subtype/Link/Type/Annot>> -endobj -712 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[299.812494 757.790154 340.770258 744.190545]/Subtype/Link/Type/Annot>> -endobj -713 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[482.678705 700.991326 517.32519 687.391717]/Subtype/Link/Type/Annot>> -endobj -714 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 687.391717 102.674555 673.792108]/Subtype/Link/Type/Annot>> -endobj -715 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[80.905512 652.192498 139.920404 638.592889]/Subtype/Link/Type/Annot>> -endobj -716 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[364.390375 630.592889 423.405268 616.993279]/Subtype/Link/Type/Annot>> -endobj -717 0 obj -<>/BS<>/Dest(figure-26)/F 4/Rect[65.905512 469.718279 109.581293 456.11867]/Subtype/Link/Type/Annot>> -endobj -718 0 obj -<>/BS<>/Dest(name-example-for-the-onlineservi)/F 4/Rect[115.040033 469.718279 301.197504 456.11867]/Subtype/Link/Type/Annot>> -endobj -719 0 obj -<>/BS<>/Dest(section-2.3.3)/F 4/Rect[65.905512 444.61867 99.092035 431.61867]/Subtype/Link/Type/Annot>> -endobj -720 0 obj -<>/BS<>/Dest(name-phones)/F 4/Rect[99.092035 444.61867 135.598871 431.61867]/Subtype/Link/Type/Annot>> -endobj -721 0 obj -<>/BS<>/Dest(RFC3966)/F 4/Rect[168.556635 310.620623 209.514399 297.021014]/Subtype/Link/Type/Annot>> -endobj -722 0 obj -<>/BS<>/Dest(RFC3261)/F 4/Rect[256.998041 310.620623 297.955805 297.021014]/Subtype/Link/Type/Annot>> -endobj -723 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[206.28515 261.821795 264.379389 248.222186]/Subtype/Link/Type/Annot>> -endobj -724 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[270.437983 261.821795 329.452875 248.222186]/Subtype/Link/Type/Annot>> -endobj -2573 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2572 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2571 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2570 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2569 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2568 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2567 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2566 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2565 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2564 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2563 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2562 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2561 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2560 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1822 0 obj -<>stream -xœÍZ[sEnJåñ`R`ÈCÂ…ac'i÷½{ª¨›•c96–e[²qD»µæ! UHü þí~ÝsÑLF—ØÉn&Òܺû|çÒç&'WÉ>>ë–úw–:«׎¹„;E5SÎÉäìew稹¿û8á’†5$F%gWÝg÷ÈçäœL&ä”ôÉ]Ò!·#rH†ä)¹µõÝÙÓîîY®Ûk"ž8SÒˆˆzdÇ€Æ8bPò>9Ƙ!Æôðüo€ruÓp £B£Õ¸Oa }ò ßMÀÈqBáaX8ÄÏ1ÂÏíáÝã—ÌRnœ7°ùøOƒ¨÷n4c zŠs~8{7xµ¢œq!í¼ÐߺÁLÓX„sUŒœå .,"Ú-@hÉðuðñ†zȨýw' îKŒ>„àÚ›s§´¨®ÎÃÓb½aà-lØNXì4_²Ÿ›àžïn v/RÌükðòéa´ø ™Â=iłɃ‘Ípr¯äc3,]夬»äÜeX0r\¡¼,€ïËRKôIð8£À_énw)M™42ödñ>„ò¿lˆ*÷e×~G%¤P.òm°’ ]G Rì¡%Ÿ  °CÖæËf¬-{^EçMù '¨±)iä—2£‚‘C/ò¾eT‹ÔÀ( ð½7Š¦i.¨Ô,… Dþúàã£Á\ýPxÑ?‰–´‚:¡5—ˇ€š^r‹Ú#ýÉ¿þÈS¾y"a‚gÉ¥2¦DÔ––Û”’—Â;W9ûŠìcçÞ¾i/‚Š3ƒ úX ·M<‡™~^a~ðR •ú“HmêT‹oÖQiReÌÉš|d²C>˜Ûø|ÔJ~ê k´¡Ú0-ÓåiÏ°~Ž¥¹³©‹#VE E„ê‡óø›û»]Ø…ÊF!fô*¼gŠ;É×UW‰¼ÑTÐRh˜0·Yhd+ý›Ó®7a¸ef„31Ý7PðÇ+*Xrl ìˆT-O»©`e(ð Ç÷\üöòÛÆëáwÓÈžÅQE¿SpCâUNS§¥Ã ¥S6Ùn¬([mP“Ú.OûÖ”É7Í·””sfà£òàŸÇã㧠91†LЄxf¯MTjÔ‰*… Gîÿ:Dkj]”¸ÕƒÁ -úýRÿäšÎqYÚ…C{ôž[É’ôvYršL¶=Ý+Û¯0^§ˆ—jy‚_Ç:­gÿ–S‰p P$sKQœ[ Å)¤eÑ—¸V‰¡SCSÜ©tAFÑøè‚Œ‚9zÿ³AnG1® Ly´.æßý × âŒå3#…|çvŒ07(SæÑÌÐ惙ÌAMèÉ$Êl@ >Wð´I¬ô!¯fëÀ5tÀ‘k› 9ÓÁN£¾/eyŸ¡ºezKóŸ}Y5çjÅ žÔ€+stµ½´3`Ü;{ãD"ý Q'«É‡ßŽöïÂRþ¥Nåøœ$Þ.î ÐýPÜþHÞ#¿ÇII¹®âœÀdE†ÿ¿†]<±Ý98,W™šMÿ”lû°ƒu$¾—€¡ÅEÎ^e­l=õÂçdËìàš‘¤}1FT užüñš|ß>É8ªÔLnî¿áxfhÉÊsòy@îÇ]ÈyÿVœãé;^ ÷ñ*Áƒ ¨¦¸¯åDÄþ\´ØŽÏP›[(j 3¶£w¼2r…—Û8ÿÕÎáÈæÂÝ ?Ç*žæg9EÛ¾„L©´ׯۇÛiSáôu5 +}ÓkÅc,µV¢d^Ç|f0%E?ä #¤¦‡¡$ÉZP <‚­·zGí?TT>.k„§ÿ“þ¯5¶eÈ‹Ô¢Jq\Ù»èóÕA‘!jjSKT›87|aå €féÃ%’m!,WÑróm(ªŸ]!Ã&ÆT†òiÔw> F“ËÛ²-›cS ÊÁáˆV-S”AseCiÚe˜ßƒµ¾\bP]‘±e=ØvrS Øõ²©ö¶2­g?]ŒkÍè‹°;y®z‘ 4^Ûë*r;眯,\»Ýò¸1™5KÛ[Âuçö¿h 7L[ÂíªZ¦l5þgAÙô—>‡¡`˜ÅRûF.T•)è<غ7*ëåºuTn(oÌBxoÝ -NißœvÏýæ< ›½À~—ïqÉ\/ÿaX{[ejòsr‰ËÝðË•wÙö<ű^áú#Á?”á8w^£|ׯ^.‚ݲh´Ö«¼$'L ÷ÎyÛ­t=œ½¼i¹ê¸3,9—Êڂ?Ëd›îI`¼O>83˜ñvÆ} %_ÊBO(.Ç'½†|ÎϺxϬoá½ÿœäOæ;2çÊԨZr×-÷ò¦ÝžçsK1ÿôúSuGXsoµC5m‹EYÓ[$j˜¤ÜZf͌ĨIwsË‚êWצj¾ëÐ)ªoËeY-³°b«R”7,…0kIˆ¨÷Ÿ:¨@nû.TÌÙ|S1Öð…„!a5JˆS¥ŠU‹)a_Ló“ ò!>Ÿ¬FÌÿŠ…1hd|& ÜÕiØ´}lcìÿßðµƒìäêÏÜÓœ¬(KÍüÏ.ØoË/þðÂç\ã9²v”íÑŠ¢µš -—½kR·~èÈ~›ã°û_é{ƒ& -endstream -endobj -1698 0 obj -<>/Font<>>> -endobj -700 0 obj -<>/AP<>/BS<>/F 4/Rect[80.905512 678.991326 139.920404 665.391717]/Subtype/Link/Type/Annot>> -endobj -701 0 obj -<>/BS<>/Dest(RFC5322)/F 4/Rect[158.177484 678.991326 199.135248 665.391717]/Subtype/Link/Type/Annot>> -endobj -702 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 643.792108 139.920404 630.192498]/Subtype/Link/Type/Annot>> -endobj -703 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[173.685053 608.592889 232.699945 594.993279]/Subtype/Link/Type/Annot>> -endobj -704 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[364.390375 586.993279 423.405268 573.39367]/Subtype/Link/Type/Annot>> -endobj -705 0 obj -<>/BS<>/Dest(figure-25)/F 4/Rect[65.905512 404.83867 109.581293 391.239061]/Subtype/Link/Type/Annot>> -endobj -706 0 obj -<>/BS<>/Dest(name-example-for-the-emails-prop)/F 4/Rect[115.040033 404.83867 264.961664 391.239061]/Subtype/Link/Type/Annot>> -endobj -707 0 obj -<>/BS<>/Dest(section-2.3.2)/F 4/Rect[65.905512 379.739061 99.092035 366.739061]/Subtype/Link/Type/Annot>> -endobj -708 0 obj -<>/BS<>/Dest(name-onlineservices)/F 4/Rect[99.092035 379.739061 173.543451 366.739061]/Subtype/Link/Type/Annot>> -endobj -2582 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2581 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2580 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2579 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2578 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2577 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2576 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2575 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2574 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1821 0 obj -<>stream -xœµY[oÜDž²ôe‘@- TŠ¥´™ÌýòÂ¥$d“,i²M²KYÄM„‡^¤¨Ä?oÆöÆÛë qïŒ}îç|sf6ãõnNqꜷFe¿>¾R«ãÃò'_ 1²&3JR˘u6sVS¥˜W:{ùÛp:|>äY¸^þ>Üü™S–ýþÇ0Ð[¿ á\ª¹7.Òœ p5wåò,ŠÒÙÓBäÓÚó0ž®CuYþ[•×£dθöØVŸ­§êx-ÊçQ­Êøi>æ•q•®2ÿ?«[¿(—á'KïU±Ž‡‹ø;KUŒkÇ\Æ¦Ú -íyvül¸y0z¼»ý ã’FoeÇgÃïï‘)ãï!‘SòÏÈùœØÅì—˜{ƒLÈ£øæ„‘-ÌÏÏÈÚýŽ÷†ÛÇEä/©/4¥Þr&|¾CùꌢºÃ(vDö®Z#‡°Lããr‚G[Ô ~;ij#xt ó<æWî:É-ÕÆ{dÕrE¢b;­Š¦¾Ùµ‹Ñ ãi¤º^I—ëWo‰2>Ô÷ºÇ’àʽèÚ1ù!:7×ü³Âºp_%m/Wb# |ÈäëãƒÃ½6mo’µø÷þQü‚!—‚I-W »ze&DÆP%”²¼I”ðe%¬3òˆ`É>dÈ·pÛ6îU„D×3¸ô›šspöùû»‘GÎs„Ùœ*aV#DÖù£QŒÜö}Áîå¯DÊÄ~V„ÁdÜDÕŠ©Âþ»På<ž®×6×”[®•/Èî@Ò9æ ¢åßâS°p ¶¢-¥»xþׄ<^”P0caé$Zñ4ÑÛ㘠Á¨Ã]Åé¨Ì»ÑySÍÅ//õfU˵hA>ÿ]ŒÇ,|®k ¼EºiÉ[4€×#ñõŠ#®“·03ŽBC„¦M¿ -Ô¬`B“ fŨiͳ'1ð“b\¢çe -î) %àÅ*+E‚™U»%Oð\ù<Åg§%¾¦¦œ›¿‘w îLi)5RZX_¦K¥‘[…À\ð‘ã>‹ -Fã>-²tGûE¨§ÈÞQtfš%%o¬5©2›û_<ìk#fFRô=ZÙ”Y7 Šz[Œ6´)üQWÁG½N8äþê&ÄÔš´"p%\Zµá¢Ç¨Ü¤ÃhTž#Œ‚¹ ­¼=ÈmvíÁ–Ã"ÙOcÚÍPéû –¸sŽUyDZêÑ‚z­[{§)t´:)Ù¤p˜¤^aípM‚*Úäæ¥È'H'2Å µÆúbWÀ¡›H:*$P¾¬‰~$`ä@µW2é%*>Ž}M—ù/G¼nâj{Þ•>Œ÷ÆE,¦ñói‚rùLàö°‚D—è“”A£À™1>m•Ë¾Cyƈ#&f”íêÃMxë;årT ç\ráLš.K’=8xó¯LîØ¥BK¬¯ -{LË$Ó«KFÛ×)¥fnM`)§¤½€$SÔ\™7ç÷C›wQ+½oåµ\]öü¬ÛœÏ6P'ž{/8V¶bÃÑTë,Ön}^{3ÍðÿK¡\D¡ÃúVì –9™ô^ «M …á€:_„\j‡`A’c)U=KÍü~ÄûYQ-An’w8T†rè‹þ½Îô4°«’tÆò–—ç÷È÷±ézT€ÕnÑ×4û•br±–Íí|ž,Jb?âP¨Ma‹(¼h‹]#ZQ)cèÓT†ÿNIÃqvJé\åH«‚í«‰€þ·ª£;×QŸë(ê:þ»ÎÖWÅÎxY:y‡•_y“ñ軓ÝÛX6¨‰?Þ©"ŸMì‡6ɧ$#£ŸÉ5òWÚAœ³ÅTx…½Ò²ú5\O"ýýôŠSÛ…­ç îB TƇª^OÈݵ†M¥¡5Žàv+ä¶`ùv42Ãô¹M>ÆÜ Üï`ïyÿŸtËB¾;˜€äç¼"îÕ2ýФ0•X¬uýÎò€?ÑjZÃYd½×UèZ©âP_é¦û›ÎZ‹L?ÁÌmx噿Œžûÿ7–ˆÖäu~݇‚Ó×Ãpþ¼bÍzðN7Å(J¸î—Wݯ£ ¼…Ùh0Ê>vYÄP”›ŠúËÔî/ãÎ*Ѷ0±x-·@©U"öüuòcˆÕóðø6ùi‰±\P+’0u»êYÅŽWÕ%÷JNƒçµB…ÅŲÒîšÊáÚ;-k€%) 7ªÉ#ÕXdóô&ÙYX`»ÓV¶ó[vØ„Ý!ÕN;ÐôžnÛÅnâ4é.±i Û•£bUÞ‡OíÇN¦'HWv¨’vU—±g­Š½§£¸·Ç“óo*îåô¨ö®Ü¤Ó¿¼¸\†G"¯™žSà¨7–ž×ÙÕ­Nˆ,zsmC¯Ú ´"‹”]Façƒ}¥ò†ù° ª†¢ÜYê€ wáÒ[ä=\朗°\€ K%6†÷ -j‚^L’1*Ià{%1²užë7Ñ ”m÷ÊÂÂW‡- AóV&ÖÕ£xž0"4ÿÿ6Éd~öOLÕ2¹ /5Âä,:®„—_A…ú=ÇÄå¦ürpA×ZM…óF÷Z-‹3¨àÖ[i: ÿµž‚Ö -endstream -endobj -1696 0 obj -<>/Font<>>> -endobj -688 0 obj -<>/BS<>/Dest(section-2.2.5)/F 4/Rect[65.905512 756.389764 99.092035 743.389764]/Subtype/Link/Type/Annot>> -endobj -689 0 obj -<>/BS<>/Dest(name-titles)/F 4/Rect[99.092035 756.389764 124.818354 743.389764]/Subtype/Link/Type/Annot>> -endobj -690 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[101.33349 563.592889 159.427729 549.993279]/Subtype/Link/Type/Annot>> -endobj -691 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[165.486322 563.592889 224.501215 549.993279]/Subtype/Link/Type/Annot>> -endobj -692 0 obj -<>/BS<>/Dest(figure-24)/F 4/Rect[65.905512 275.579451 109.581293 261.979842]/Subtype/Link/Type/Annot>> -endobj -693 0 obj -<>/BS<>/Dest(name-example-for-the-titles-prop)/F 4/Rect[115.040033 275.579451 257.571527 261.979842]/Subtype/Link/Type/Annot>> -endobj -694 0 obj -<>/BS<>/Dest(section-2.3)/F 4/Rect[65.905512 247.479842 95.494623 231.879842]/Subtype/Link/Type/Annot>> -endobj -695 0 obj -<>/BS<>/Dest(name-contact-properties)/F 4/Rect[95.494623 247.479842 209.164301 231.879842]/Subtype/Link/Type/Annot>> -endobj -696 0 obj -<>/BS<>/Dest(section-2.3.1)/F 4/Rect[65.905512 200.780233 99.092035 187.780233]/Subtype/Link/Type/Annot>> -endobj -697 0 obj -<>/BS<>/Dest(name-emails)/F 4/Rect[99.092035 200.780233 132.568109 187.780233]/Subtype/Link/Type/Annot>> -endobj -2592 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2591 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2590 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2589 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2588 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2587 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2586 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2585 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2584 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2583 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1820 0 obj -<>stream -xœÍZÙoÇŸ„ð ´p§Ab·ÛFu%¥ÍìÜ@‘¶.%Q¶ªƒIÅaP¤E•Ùœö¡~ëkþëþæÛYrž²Xkrwv÷»ï¡3™ {ñäµäÞguö—ÝW]î =,ÏtóU+g3«wB8ï2ï ×Zm²ïþÙwÿÕ•Y<¾û¶»ÿä"ûößÝïÂDÊ<çFë æ¦{¨¥/ß•—DÊd/ɵçq=Þ1î³â_•Þ -& ĵǮòøf·ÉN0yùœØª¬_kYYWá*÷`vë—*þeÍs•ì“«îÔþÞqï´Æ ŸIáy®Bn|võ²»Ú~|ð$“Š…·²«›îWÛì)îäb›õØ9Ž³vˆóÛe}vÁŽð=dX‡Y<âé`:ì'lÀ.éíîÄ÷'7ìþÎ×WO»WÉÞPåa¢¬Ó+d¸_‘‹»Æ÷ˆ¸ý=8ÿ‚©Æ“?ý8œkg¹A²‚óÏÀÇdvú-¿]ŽŒ0Üg‚¼ƒ.›–~=#zËO Á[W¡q‚;›Û`V0|H쎡Á¯ðÝfø ö[¼1€™ûÄöäV:(\Äúj…÷Ù1ñíIå'àú÷ŽàÄQ²uøÝ”W¥sTpN®Ÿ*{®:KRF|6KriDpÑ\Ç7¯ñ¬7•h„û…Ku°!‰7eXŠ¤]›ÉÜrårá„*lië$‘O\c½ä>îOvv4@ÄjtŸ|IŽò3b¾w—„)|¾ƒ§=r«kœŸÒó#Áâ~\EÈ(Ô1…øX¢µÅrjÍÐÞ«©Uå.WçˆD}FŠë{Š>ÖÃd¤â:†Í=r°c\Îr>8ØÌ&‹‡ üœÈ‚èÙ ATrršº9ò£!•I›s«\ŠsÙa_&‘úÉ/b|%›mK%o6Kë< Ö‰t(„cõ%Éêõ8JºP.-B+×S/ˆœðÂ,¢lÈQoc`{¼ºúh6[ª¨¦öW +8~–N)Ñ1ÕÞ²¥- M\’ K«5#ÜÃÝgªÙMUº‡´ô¸¡°i?Õ4_•ËJbªd›Fèà¸Ìɤ-Ù ø^K÷¨vœé¨g"ÖÈ~ÈX>H¶l‰¯DŽ·ØŬœTØNîNÎëv¨U*¶Tð¶kEnTDÚBÿ1¹â^ -JGžl“ýÎR‰+âôØ8Jê(JßE§Ú0«!…%ÀýSO,¯NðrÔÝZ†1HÜB[o]›ÅÒ0rï"¥Q–Ìñü’`môBct@àLS^Óa'“;´ «ò€²&µsÂ4ØŠi› kÉÖs\H~ÖÖh{‹",Œ -ëÓn”—¨«Fz|³ónÄT?Õ•>yn;K´staœ!¥Ì^EâÂDÓnuìÂè²ÊpŸ;B-;ÝùOyKÖŽ½—µ> ±ÖY¸ƒµ?ÚÐÚÊŽ¶r}Ú÷gB.ÌjÂÎwªmu­ã\B9úÈ5™¢ìjÆÓ>b‡Ì`V«Ý]BMõ"9(®%Ê”YŸÐ<Û~í»¡œ¹‹Í‚³:¬O{rS7mLf{˜HQCŽ.÷-7pŽ‹ùyÿ§M_ûªïCµ¡æ]`¨6*½ ÕƯw€¡ÖH· O›SÖˆi)…µ¡¹»ù—ó‹Óó§Y\QP 晥„éÞ˜(Æ)UŽQªÞéÍ!ºµã@òo·VÔ[Á%™,6ÚŤ{¾®nÅl\-wZÇ@\›öKE¬¿yÜõ[›P³TÐ é¡­6ÚµÉN3Ê«ùÖ0mkHÉ1ꆠ°¥AîÉc³ádÖ<ÔëüXY ù—U—ˆ£I…G=ãÑLy¡Îã]äºÙ];Q ý§J`a¥\ŠÁéâËáñ“¤F´ùñ/xÜò–qö9ËØCöþ¸ËÞÇú–}ÃÞcÿmŽ)3ä±¥ÌeüM¹°û{8nÙoØÐLÈû²}xÔ/qþ›üøáþ¿Âi/!¿72¤èýtóo ©9¤^+¼V²Fís€íF,»À‚Ój¶]͆R' Qì1Â?®F€ù5®.÷ É"Žn!ägS³ïÓÕd{¹ÄFpi×édì× »_ŒÆê8Yµå}½Œ¶C“¥çÈ•PÆW* IÁåK™Ÿ¯$¡¾Ç÷Ö -ðÂò çˆ5O;n1x–mA_/ýsßmÉë:pí*Œ¾®–«òˆ‰Rô¢zãLf€)X”«Oe«c¢*#?Ä þñl_€²iÉ:Œà«µ¶W7£dá’¹@­_MI°Þlgóû9>¿ØŒXüÎq|eä\–¦÷KÚì£vØä?øÚgƒÉÍÿhçˆ 6Ôe»sýÄËß̇øÑ>g¹­pÈN7T­‹Î¬Y)µšþLù€}ÚvÉÿÎŒ{ -endstream -endobj -1694 0 obj -<>/Font<>>> -endobj -678 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[80.905512 730.590936 138.99975 716.991326]/Subtype/Link/Type/Annot>> -endobj -679 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[145.058344 730.590936 204.073236 716.991326]/Subtype/Link/Type/Annot>> -endobj -680 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[80.905512 446.096795 140.8081 432.497186]/Subtype/Link/Type/Annot>> -endobj -681 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[146.866693 446.096795 205.881586 432.497186]/Subtype/Link/Type/Annot>> -endobj -682 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 410.897576 139.920404 397.297967]/Subtype/Link/Type/Annot>> -endobj -683 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[207.501703 375.698358 266.516596 362.098748]/Subtype/Link/Type/Annot>> -endobj -684 0 obj -<>/BS<>/Dest(figure-23)/F 4/Rect[65.905512 182.903748 109.581293 169.304139]/Subtype/Link/Type/Annot>> -endobj -685 0 obj -<>/BS<>/Dest(name-example-for-the-speaktoas-p)/F 4/Rect[115.040033 182.903748 284.63891 169.304139]/Subtype/Link/Type/Annot>> -endobj -2600 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2599 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2598 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2597 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2596 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2595 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2594 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2593 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1819 0 obj -<>stream -xœÅZío·g¢õ‹ -ÌÖ¬Å‡Ö bc9ó< (ºL¶å—Ù–mÉq¢¢ëŠºœH;¬-°ûÓ÷#”x§;I¶œÌÊI:òÈç÷¼?|”Œe¯gîÃJ–[[-³ïÞtßvs£üdüôƒo»¸3:ÓRä†RcMfÊ¥¤…TÙOßw/º?vYæ^?ýÐÝú–å4ûáç®[oŠÉÆ8Ï+´õk®º¼°5³ñ PyãI©ìu ùº2ïî/6A,·Yù/¥·d¹qeÚ$ÓW›u8…âqÞÃJî_—÷,¹O×%ãïnõ•3áþ²úgJöùyw¢krk$eÊR›1js. -®lvþ¦»uÔ¹·ý²P¿¤\Ø\èBj½éŽÇpAúäÕDº)Ú/ÉŸñÄ)0ötð¾$-Í ˜ [„ÿsà§?ýŽ™Â9+ÔDN"' pœÜN¼ wñ~á-Èï\t.%‹BùŽô¦(¹.ra„Ðjy·_’c`IHöü»sþžwþ¯½(§;I X ÏîBC\»¸ïa¼ãGF0ý¾WFäx{ƒÓ§N%r€A,ò=,Þ!aÒ `£Aò:c\ƒ;N ̇ ÿ› „†sH¼’¼lJYž3(?1𤜢›Ä ÿó?^Ö£„ÉK`;Ð<ñ‚HƒFM¢­ìqZäJ*Œ’½*ØÒüJØö&8ðÞ#@iÅØž?õÑè7†µqdtöÑ*Ü*T%`=”*cg¡–çÍ(Èu/8oÊÄ¡7‘Á¬a -îò“ÆPUKÓ‰iÖÓr´¢—ÁB,sDv0’ÚUôó…¶Ù®¥á™œ›"Àr>pæ]ÚÙƒSÏxcCÒ§q‡²çYwäÄïD~â5ćùlÂCÏów€µ‡~5’âÔ0 ÁÇ"Q3]zæ¥{éÙ˜•Ã¶ŽE#ïÏNCQ¹ÈZ3«p¼ŸHZi®J…ad®QlA®Ò µ“èá#€ù×G­ä§ ³BÛBúš*Q,O{Æ̪µ Õ9£Œ‹hÃë`µŠv²ß&Lt|zH}ÏWÇx9ñ÷ªO•Öñx6àThQ/êkÙ=™„þWCY—:}¿†²%|UÈÂäŒ+ÁDgþ &Œ¼&)p6àœá”;ß­Ö† cÓèSça™f^R«Vyï;©Uq¶¤¸Öð"Q*iÁå$¤–8—Iqõ¯.ØÑDàŽëKh¥¤˜ns‹Ç˜wÛYDmc´âEŒ  ™ˆÕaÚ˜Nú’Ô)ìv6uW¥¢jÈ€U¼µ†©8];ך綰ŒÕ+­ù¹÷Žªõ®ZF´óiq¼´à²VôÞ®Úà…Î "$·S³›ß®àXá8É”Dd£ÌÚZ¾õ·“ÁÑÉ~æôëÓEÀÔÞxͪDÄ«µ.¬¬•\ D×7 H~±*Ig®ŒQ­÷Þ!Ÿ\ÛÜRÄkš^žÏêq¿ÀQ…*–ifòBq£P´0éÒƒt•MÙ*]©§  •+œ¡h‰ô௣£ãÆ:d¼C܇©–Í™íCò°æHÒU#V ¨©î‹õg΋ -D¬6¬ááñÓJÝ9õ‹$dzm‡%æ+®_­Ö!]«epÁÄÕÞ6+ÆÌ(†¡j`þPõÛ¨›Û¯Ì]å@ýZ]¦žÀÍ_Së°¶‚±˜bTSŒ¦Šñ6|]m.])S–+Iµå™â0xa9/Õàr¸÷|¾äbJ+¥…^“MÔ›Ÿ‘GÎV׉—-|nºÛ³ß’{ä×z䟒ÁM£r±1¯ßÃËmi/UHŽŒ)¥“¥år~ä¬9 ›\“û°Îß‘oð}ü£›þ”ü£ß´o®uŽ€دlNKF·&Üý»}$fkÜÅׯ-P×¼@·È縻_N=½OK ßC)½N®ž=ø1ÍsœûäìŽ5Eˆ(îZI¥Sª‘ªq‡z“ -ð(£HÒË[C¬õËD|Rkw¦ ça8LŒ|§Áõb ßÃü®Ÿ…&þ”½ò™ÐØo-ÏE.Ð8ŸÇãøÐwÈû¡68M*„²|Kô)Æò\0ôôK?t™j‡Æ¸Ó_…ï.èÄX—+¹µ’M:1íÞr7ý˜µÉy§Ú>/Font<>>> -endobj -671 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 646.592889 139.920404 632.993279]/Subtype/Link/Type/Annot>> -endobj -672 0 obj -<>/BS<>/Dest(figure-22)/F 4/Rect[65.905512 330.921404 109.581293 317.321795]/Subtype/Link/Type/Annot>> -endobj -673 0 obj -<>/BS<>/Dest(name-example-for-the-organizatio)/F 4/Rect[115.040033 330.921404 299.148188 317.321795]/Subtype/Link/Type/Annot>> -endobj -674 0 obj -<>/BS<>/Dest(section-2.2.4)/F 4/Rect[65.905512 305.821795 99.092035 292.821795]/Subtype/Link/Type/Annot>> -endobj -675 0 obj -<>/BS<>/Dest(name-speaktoas)/F 4/Rect[99.092035 305.821795 153.247309 292.821795]/Subtype/Link/Type/Annot>> -endobj -2605 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2604 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2603 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2602 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2601 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1818 0 obj -<>stream -xœÍZYoLJÐË0#IJÀ2ˆ¢HŠÔìûxqeI-\»¤L?AèIää!~ËOÏ×ÇÌÎôÌpwEZ —˹º«¾ª®®þª‡%+)>/üÁJF¬uFËòoïFïGĨð°:†›ïG¸2ºÔRC©±¦´F)©“ªüñï£ùè#VúÏ?Œ¶¾g„–?üsäûWwaŒs¢˜Ó6ô¹Mñhf«Ðò.¨RåÛ¤òm빿ž?ƒ2bËøÛÔ·dÜzl¯ŸåpœâÕó«qý6^³Æu³_ãþÏ ·ý!LøŸ2?6Õ¾<Õão ±FR¦,µ%—–(ʹqåÙ»ÑÖáäõîöË’ d´*Ï®Gß>)N‹ý⤘“b^;ÅÃb£Ð8?ÇÕ´ØÃÕ/ñü4<õíÆÅQqu]ÜúÝÙÞhû,ŒûºH™DIª-/µ„ Ç•]‚s„§Ð~þ”Ó'8Îæ< ã»®ŽÃýy¼¿ÏF±¬}¿´Üç'8ú§¯pïßW¸öÖãÜŸyÛ5(qÇc<‰žœâþ,¹¨×h®‰0œ*÷vÃ>ƒqðš.ƒ‡/Âù)d{ß{Dóâê*@Ü €cã®Ú`üNáM™5Z_AÛöú 9h³vèžœp -‰“ðdNC9®çìicSZͬ¥¦‹-FÀ,iMÁ=lš¥Äª¨MÝw’Fï­‹€à2`]'ò¿®AøáÃ]›µÕÞ m4Ò9´ÑBwÑäÆŒ’Gø†Íu–8*o̼¾Iô:<Þ|ªmÝ1;,¢®}òC¿Wq4 ¶Âõ"‹™*Ú§vOô ÚÊ™!Thäâ$ÎÃãYŠë‰ÑælŠÝ Á~pÜóÖ¶urÃñ9S2[vi-ê™B¬Ÿ|àÎ'Å"év'JÕ:‚ë± >ˆ^ÛÌüCÓ*©K®5fŽ¢Ž%¬ó:Kƒ»BðÎÂyÄ04ýýíâ¯aÒÌ;˜BÞ ÷Û‹­®dœ)Çu"ì4Ä×ç>Ÿ 7sÿkâ˜qšum -!4ì+‰ÑÆQ™šGŸy7? -ã}’ü8I:±àw{çÜaȱ޷–y \Ê8¬îJdºnXéurcŸÏ—ø~1ˆ`A7šê¹O’R*.W×}ag$´Q+_€¦8SÈ[bÒöüâÓÐúj¥Ä9jÍ‹­¿O÷JŸo‚õ´°)$MnÏo @Jd9…‚Áe ¾@@†²ÅVñû[[Í8áš‚bwSëÇ2\ 3‘MÌ›äJo] -¥ˆÒFDZvCðOCª9¬3ð,ÐëçX'¾OÚÏþ´RapkìÄòHé²òà·1÷û”›W0wŒHS $Ö9³Ô›ÑS}Õq ¯jäwï:ëÜç´^42¾y úó4èMÀß¿C‹“´N?ÖÐ+"IËå•aäö»· lÑ3ÿÈÒž'þu÷5l{ŠjY!E;»t¡>ÀS}7râÆ R¤a²-­o^fô‹*"”fH&yÏL°­¥Ù6jõ¼`jf–燜E–vPñ°óÀÍÏCÓIŠ1O:·+Ú³èùØSx<ìø¥ígë)­P¼¢—BºnÃÊÉXUVªvC,áïëzJö¶‡Ùa>!™k‘g¥†‡^`⊠TU»-ýv[%VÖÓøêIkËs±:4K| Zs#"K9Ö2.yWeïûFuLg$ …6~«¥‹îHü#ÃÊüˆA\å­OcBöŸ6ƒÁÚD±€¨jˆº ñ¬º~¶r -¦¬ªÉ–WGÁŽâÔ™^žï¾ÜÆÔeò?ÎÊŽo|@>*¾ÆR“¯|Ä”Áíï‹OŠçY¯–¯! -õÕNí'ø¼Wüiziw¿¬®¼Ñ=ŠX ˆBÞ€ï>CI„ûø•Å›a¡’©+›“П†›#¯iÕ0á§f¹³ŠÕhD ìMÛùÓO̽P”ßµ6Ì•+hó‘Ê‹åY8á_ôýŸT°AÂœ|ÙfØMìÏZN,bŒ;ÍW­§>¿±žj‹»)l2fÅ•_Ð%RXGDN~ 8)09W^S´_âÏ¢.:©ßŠõÝh->q/a#ì­ûÚk6H¼Œß‘ujñ~ÅWFžuU[ò±>ë¾ýX­<³Ì"›0d‰šÔy¬C3ð® -µÍšÈ6«ˆU÷ðdw‰Û¦‚g+'e]àôËCÒaí=EÁÝéÞ~Õ3\z¶ÓÉÿ¢ôì X”žýT"ªW)C$ÍÌrT« ]ùm‹úcìØ5S°ÝY.d6lë°ë[PúlYQi¥˜‰Cj jTêNS'L;aUò•çáâ¯P}¹¨ŠVS ´Ã¬ÑF³¥Š:¼ž&­¥ßÄ0r¹&ZŒ™öAñk|¿XO™ÿ‡!cƒU¬W‡Ù4du¡èê_ø³Uœ\]ÿ'½~=YÓ— -“B[£Ä*Ê«fŸ¶gaŽ/þëâpM×…ÚÅiµÔjñ{©@ûMŽÓÑ¥«Ïq -endstream -endobj -1690 0 obj -<>/Font<>>> -endobj -660 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[140.2185 638.993279 199.233393 625.39367]/Subtype/Link/Type/Annot>> -endobj -661 0 obj -<>/BS<>/Dest(section-2.2.2)/F 4/Rect[65.905512 613.89367 99.092035 600.89367]/Subtype/Link/Type/Annot>> -endobj -662 0 obj -<>/BS<>/Dest(name-nicknames)/F 4/Rect[99.092035 613.89367 154.017084 600.89367]/Subtype/Link/Type/Annot>> -endobj -663 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 471.895623 139.920404 458.296014]/Subtype/Link/Type/Annot>> -endobj -664 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[121.740961 436.696404 180.755854 423.096795]/Subtype/Link/Type/Annot>> -endobj -665 0 obj -<>/BS<>/Dest(figure-21)/F 4/Rect[65.905512 329.021795 109.581293 315.422186]/Subtype/Link/Type/Annot>> -endobj -666 0 obj -<>/BS<>/Dest(name-example-for-the-nicknames-p)/F 4/Rect[115.040033 329.021795 284.460932 315.422186]/Subtype/Link/Type/Annot>> -endobj -667 0 obj -<>/BS<>/Dest(section-2.2.3)/F 4/Rect[65.905512 303.922186 99.092035 290.922186]/Subtype/Link/Type/Annot>> -endobj -668 0 obj -<>/BS<>/Dest(name-organizations)/F 4/Rect[99.092035 303.922186 168.755609 290.922186]/Subtype/Link/Type/Annot>> -endobj -2614 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2613 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2612 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2611 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2610 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2609 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2608 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2607 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2606 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1817 0 obj -<>stream -xœÍZ[oÇž”Õ $0·F!; [¶%¥ÍìÜ‹ @]](šEI$}a$AåÛâmRô¡¯úúØ_U ¿¦ßÌÞ—»$%9…¼ö23ç|ç:çŒñˆáÚñ7+9µÖ-£oÞv¿íR£Â`v¿íâÍèHKA cÆšÈE¥dNªèݺÓî»<ò×»WÝݯ8eÑ«?uýzãò%œÇ1UÜiÖ\tG¸@šÛl¸¼ ¬Tô&eù¦2îߧÛ`Fm”ü/ó[2!\6¥á‹í:§âl<À*½¿IÞyé½¼®ôýG†[\ÖPk$ãÊ29in(¥#a5•†;Æ3cQ.ü¿¨~/ã{rÞÍ¥B\jAc©ÑùÛîîÓßNŽ‡O".h !0+:¿è¾Ü$³-2 }òŒŒ·b¶Iz¤Cn“Ÿm}qÞ/(s©)gV8^£‹õwI§6Y‰Õ†7Lžm’—dœ32 ¬ŽÈ)ã>%OÃûî§d„ç)`àËÞqâûÞ†øþî~ÜÏœ`L¤àO±¾z~¬G&U\Ò*ªt,]<+aÿ|3!µ‰egfºätêãØð¨~‡UW‰Eê¼ùbg\ÔüXökËÀà¨\åÀ„+[Yxô·,{#gœ*É´!xY&!”ïÝqô||ôd?â1Õ៳2uÇïjÎT¢"…[1cR£}€ë5ùÙ%’|F"<¾ü”¬“ò)ž¾l'&-eJ)*Äc)â>ax¸_¢©ÈòŠÌþœŒï.¦­cxÄ5ÒV¨c庌ìY ’A\“5!rl{ŸùÛH84¥ø—vŠŽSŽü']¢¿¾ ”‘ OíÓ\h -5ìTP¾s|xŒ±\=ënð¼¿ßk0êçÿM&´[ý5ù`k“|¿@©1ƒër­c¾:þûøÀ]úÿùÏ{3¬â‰+·W†BÞxi®Õÿü¿ÿùh²"üvðÒQåb+âø¿¶/Áæ`Œ“®) „=ßéš‚|.ÙF°z‘7>Ö¥IÌÒ¥á4I¹j@ý©Ž­?ÓØèk2DŠþ‰äA–J<Â{äð xŽüŒÌ ãÅyOÀËUÜâ(K™ÞCªÙÀÀnÎsö.h-‰Þv®BRÃt5ϵ%uþ@t¤" zÑ1`ãÀŽbÝJ*oÅaáP Šû˜EAk}HðdfW2H+$»V¿^ ñ›ëYÈ-‚ñ0øÉ瘸‘*¥ ¶A©¬ÔžB$v-kZ\0ÅD-¤ý>«-Gé•5תï•6¨ ™¡ÄØ=î½8Úo¬ï žÍBaŒR®>E<@áÜ'·ÊÈ®È!ç@Ü,Aô` Œ,˜Qù L(že%`;¥/…j?cC0= †…˜–÷¨Çxœ–•Ý I“ O¨Ä{–ßú$~’’Œõ,DíÄ—Ë%> vè¥L†­bXD3\Ý(ÆbX¡©DMž§™ƒñ0ÍTƒ€1ÓCÓØr9üN™­„3;­ís@ §¸>T½¨e£6¤'ˆ6ûúoHEkÕdÔ.ŸÂ£aJÈT¾54·PbYkæ5v¾4IÁO(ê<;Q?¨¢—8‚Y«y¼Œ;&Çé)û8—zN!ó9w'ͨ…¢~®þ5*c‰-£òЮÞTd%gœVi Ý øÍR¦ÍÒe¾Šiªö•ÉÊõ¸×í³àã…~ádš¦••”+¥_3¢½•KEÖ -#lɱ†ëÕé´€ÌÜÆWõ¿ÄÏK -© -õ˜Å1Bauªer<Ú±4vܹ˜[“ýÆñ²ŽÖZ«´ãùÉGuÿþ‘Uë‘›¨RpÜ@•Mþ&ªìå7Puc½ €êû×꘲¼ÎÙ6^F!ÅQé4sh\*²=Cù¹GÈcë䮟×7ŽÅ „v莴Ñ|)£¹Nýrœ´–ÙÒÈåœÙ˪äð»rüüârÌüß%øCQ…(ç>/Font<>>> -endobj -652 0 obj -<>/BS<>/Dest(figure-20)/F 4/Rect[65.905512 505.135447 109.581293 491.535838]/Subtype/Link/Type/Annot>> -endobj -653 0 obj -<>/BS<>/Dest(name-example-for-the-phonetic-an)/F 4/Rect[115.040033 505.135447 364.171869 491.535838]/Subtype/Link/Type/Annot>> -endobj -654 0 obj -<>/BS<>/Dest(section-2.2.1.2)/F 4/Rect[65.905512 476.535838 107.621088 463.535838]/Subtype/Link/Type/Annot>> -endobj -655 0 obj -<>/BS<>/Dest(name-namecomponent)/F 4/Rect[107.621088 476.535838 195.404047 463.535838]/Subtype/Link/Type/Annot>> -endobj -656 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[380.022455 370.1374 438.116693 356.537791]/Subtype/Link/Type/Annot>> -endobj -657 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[444.175287 370.1374 503.19018 356.537791]/Subtype/Link/Type/Annot>> -endobj -2620 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2619 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2618 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2617 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2616 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2615 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1816 0 obj -<>stream -xœ½Y[oÇWÍ ûàqë<ØÍ" \K…Ws¿<Ö¡$ZR%RÒVTiQåAv§Aš}èOÏ7g/œ]îR¤äDµ;³;ç|ç~f”‰Œãó"^¼¹÷ÁYýóÝàý w†VWš|?ÀÈÙÌj•;Îw™w&ךm²ïþ5˜ þ=Yü|÷í`ç‘óìÛÿ âzê%BH™¬§5׃ > -|õ¸¼#V&{[²|Ûxdzm0Ë}Vü¦ünYnx±>ò-ÉŸ³«+6ÅĈï]èBé\Y/ŒÍ÷¹TA ð ¶ |€QLfã |÷1»Ï^'ˆ§xçˆ7I–â¾z¶[ ¼ÉCˆ3ÃݧD´x)Š9®Ù!~¡³ ½=‹ËÏ0|ˆA¤¾…¯J‚£„ÿlJjš ÎK£Apiså$w•»‘q.H×#ZM#®ˆç”8OÉnëù#ÂvB†+Ð kC}Œ7"©=vtõÿáµáb´È· Û„+-í†]™¦@×PF¿øZç†kïUIdQÑÝÈ:5²ÙÏI%8Áe(ù\=‡Žö€mƒ“+Œ*²“Ä‚c¼tÖVƒt:·!H!ÉV:âû†‚äˆsEOª½.‰LɧGÑp“ÒÅ_•®VA<&Èûý’ ®Páú½ë´á¶¢Äú¬é)äûyÓŒRBÔû¨”úO/))`âjkKC«ÖÑêº~XÏĘniÞ:”«½ê+rùŠ¼bÖ« )$²ŒµF—‹Š°?!€ÓRÀÉšJ˜§ÃÒb•D‰Y›¢®ìä§+„DÎW6hDe!Tåkun^ÈË!^dp!¦æFFNÈZ´DÊØ[KÉÕ¤; Äe{Äžôò׃S‹Š.=RÉêL£FO(P¢Ù.È«†TºR¼&ÿlû÷ò¤·@*Í‘fIƒ”¢jh“ÿ°vŽ%¦s½†×²òÇ1¥‹}òÈ4iÄ ?)¬HIýÚ¥xH’E+T˦4ëük,ݯsS¡•8¾$'‰NªÊWéj!aØdÓŸteðˆQ!•+Å«T:’)qÞKìóQCüVÓmYµ»”vJ’•ÑU7éÑÈ>åè¿X}A-EFUÂ"‹h®«¤ßßu Ê¼)5<+ù¥õÑžú-z›XĨǙg¥åe¤]°¾b_­|Ø/ucÖÛªž¯/ô¬ Ç" ŸQÙÛ#Õ—"%ElJ™2š#"=M,te}Bü‘TR•‰K²^цµý¸"Ø/uÜÍ„`]‚Gä²#j&ÍRÜò{…VYg¸YÜB$®?M¶i(6 Dš`V/έ¦¾WfÍe΃·Jõ´u´Ey¿C!AyÖÊšnKrº-KêQ¹áS|¯YO¤S9’WauÞóàÓµÊìÅì8é§cöŠžp¥h4»ZSã¸2°Vuý=ûdMm »Î9¥p'm IâÔÃz±ÙnËbBäÞI%[ÐÄïÛÎ Év³?>ˆÃësÅC]gY‡opû•~UÞ¿ºÃ¯ -ìƒ:üúÚètøûžÑ¤Û±æAÇ—ãÉñø ‹áB@“T±Ü}YTs'Š­R{¯¾À•3_ž9Š¸„ræènU­ò2÷ejv† ï[{Äu˜6Õ,ú=ã<Záò`¤3hnµÄ;Ò UýÞëäΑ®\Ñ+ïþuz|rK|”[éù–kîoÚBp¯‚hÑÅú§íì- ˜xëDÇËè_Ó@Xl1›½¡*A5Rk³TDf؆ûfu‚yßm·`\n\¡äÂw\–Ç£'²ö¦[åø>ɀݷ© xßèæÍ I®-ÑõöÊ[o.r£¹õ¨Ü°òRÍÁäÍÅ«—»–ÜÒOðºtÀ›è‚O¢kd¸ÿ†=`?¶ oMÔp›[©½¯¶Jð¹Aÿ¾×ÿ%^¶@vX^Rû¡ŸšDs!„16¡??ÕgðBPú¬¤sÃ>Ç„(Èß°¯iJùŸùYýÒ'ñã€pƒ™ŸØ×ýTC¨t´¿Â&føíÌQÌ„oér ó4_4lÕÇÿû”Àqÿ[Ü=‰k>/àôƒ±ˆc×2Å—¡wðPÓR]¹MšÿMmþ%΄„át‡ºdM5û OÂ~¸–#U‡«µ¼ªÃ‡úiÂ}…h©`™ÅmÜ‘ó…èùâ~ ^ŸǬ6ùF0k?9í±ÕMdú)-{Õ'¦^N«ûê–30(YîÓΪ*­&jç*Â4´Ÿ²?´ëërÊd<문•Ñ 4ÑÏêã’½òìweNÖê\réôíœ8Î'Еâûx=fñ¥ˆ´ʈN–vCgÔ„ŽØq<@úvØéÕõÿËr®©K§³Þµ -ó¢Ó/ŽÀ¦tZ­î±ã5U‹ŽOú`Í­R+?(›ýÇ‹.ù3€pL -endstream -endobj -1686 0 obj -<>/Font<>>> -endobj -643 0 obj -<>/BS<>/Dest(example-name-sortas)/F 4/Rect[80.905512 656.192498 125.571527 642.592889]/Subtype/Link/Type/Annot>> -endobj -644 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[145.827387 550.995233 204.842279 537.395623]/Subtype/Link/Type/Annot>> -endobj -645 0 obj -<>/BS<>/Dest(example-name-phonetic)/F 4/Rect[333.336908 550.995233 378.002924 537.395623]/Subtype/Link/Type/Annot>> -endobj -646 0 obj -<>/BS<>/Dest(prop-phonetic)/F 4/Rect[145.827387 515.796014 204.842279 502.196404]/Subtype/Link/Type/Annot>> -endobj -647 0 obj -<>/BS<>/Dest(example-name-phonetic)/F 4/Rect[333.336908 515.796014 378.002924 502.196404]/Subtype/Link/Type/Annot>> -endobj -648 0 obj -<>/BS<>/Dest(figure-19)/F 4/Rect[65.905512 333.641404 109.581293 320.041795]/Subtype/Link/Type/Annot>> -endobj -649 0 obj -<>/BS<>/Dest(name-example-for-the-sortas-prop)/F 4/Rect[115.040033 333.641404 264.990961 320.041795]/Subtype/Link/Type/Annot>> -endobj -2627 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2626 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2625 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2624 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2623 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2622 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2621 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1815 0 obj -<>stream -xœÅZ[oǃph ¨R;IÓØÙ&ªm©Õhî—>­+ÉÔ%ºKtiRTy]ÀiÑ&@úÓûÍì.9{ã’² -kMîÎîì9ßœsæ;g†ÎxÆpl„“Sœ:ç­QÙ__ß ©ÕñayŽ7ß Ñ²&3JR˘u6sVS¥˜W:ûáoÃñðïCž…ã‡ï‡›ßrʲïÿ1 ï[?}…s!¨æÞ¸øÎÕðDsWö€–×Q•Î^*_Už‡öxʨËò©¾¹àÊc›<¾Z¯ÃñZ”Ï#¬¤ý*o󤾗Üÿ?í”Ëð—ÕÏ©Úgçéÿ¥Î*Ƶc.ÓÂPf™Æåùëáæáèåîö³ŒKeHôÊί†_?%ä’rAž“¾G8?$òkrŠãí-r‚ö=´ÎȽOÑÞ“G¸ÞÙEëÚãøÞÝØ>‚Ì®'WdeíÏç{Ãíó">ÞvTVRÆ„õ¾gTUd­3´.Ö{Šó£¸ˆx ®/0ª²×:Ê[±*€Õ¢o»ûÑ»Aé‚ž;ƒþóQ^FKŽÉ*®êH_iýa!ä Ô>œ„·¾8gr“!0¨Áì’¶öd ö`áñrŸ|R‚˜c¶ŠRƒé+œerq¥è }[“X¡=ÀÕ Úä8"z‰¾c²_ܳi'Úìylܳ¾¡½Sô-%™ï'qvï'’Wp½5?Çqú"Z Õª—œkC‘¯£¸³H¹Ê‹Ê>ĽŒ”q¿+–F×N;WšZ2GZò’9¦¾O>]Ò¡R€šµ³n -ƒhâç7”VÔ;®¤[\݇ËÊxÔÖ¸%´¬Tã@zA…gRÛZJAW o -O‡`Ú™Rk¸·‹ïqÑc¬!ŒCä„ á3Žñ“ÇJì݆Z)* :Ît ]Ú¢EjšL’=­dº•ÂuIê$—VÖRM2ÚjjÉ'g3¹ â9Ùed@¶q5ÆüE´síÒmÏánm¸(€}™ôE1_F˜'…È“Â)£¨j<Í![‘‰æ;fP“œ(ç£\ÎQ|3eùÈ/1ÿŸ¦õ:Ö0O…qJ¨b@°ðä»ÿDö*ù)x. ¨Ã"èZ=ƒ -’vÿÜųݩ§¢Ðn€dϸÈOáÈ/#'ãˆÛC£½êhC\Õ¬¸FäI‡ÈkhÎC(·ì¸1Íøԛͪn¾¥ºÇ®4ÕR±)ùÄX¨ÖyƒÖI¿ðäÌEžàöx:´ÆÔ„ (™yU«¡’©YÖLi\_D/äÙ'G±ÕU<É’M™}~3ÚRi…tõ*¯î·ncƒl•1Rñ©±oÏ 5¦c’*ç5-Õb/1g:òÉsÿAD²7 ì3ôÏÙ?*"(붓}ðÈQÅPÑi'=Õš+¥§S0|‘ˆnÒßq>‹ °ñù û¢)ÏjÁp%ŒÂ£ZÚÂù8šb0£¯~ês™À|ºL©7ÀT%é¦òØ%j»°öqôOº¢È[5XjÊÒ›eÿÄ=ãÃ"Øqˬ5Ò,?ÄU`ÎgíN‘½w ß%Ž¨×e²Ú­ÅjDï ¾J†îѨ£¼V›Œ[ÌéU¨îò]“e×\i‘­\ ¹Çúlÿ—‡G=K—Âaùò‹šŒ¡œaÎðš\¼ÿ°‘èPèHg,oéÇ ž‹¿&ßÄ[ÈŸ6…~M>ÊßzT¸ÆÝŸÈ7Ý –@¨€¸Un1ú6*FëÂî ß2ù¦ùœ|‘£éÆb U¢fÞÏï5¼fÁk¦ägÀø°làSbßD ø:Å ¦¨c°…f²¬m~J³…5e¨g¥S(bÓ0và(a¸2·ÀžÊIL8k¼¾ {~ÒÉžU¹=ìÙè<—=Ó -—Öê4%<óÚȦün– &×M“+FÀÔ¶­T¹èKïˆ/%73x3Þ”.·ähnÄœ¨Î‘¬œËÉà–hSj…^¨poƒ6þöÉo‘6ï¢S†®ë½„)¨Ö–ºMºüytOzQ¯›šI—@áæààÎŽÕÒ'ëÑ+󘙖r]óÉ<æVÈóRÖ¬xsæVˆ|-s´Òö öß•Ñ K« ¸º“3g“±\h?nÝõZ|ƒS‡õ…“\/®|@î-¿a«ùZ„ÓŠL±ET.p`Q>÷ÃyÉ‘ä¥0§ùâú'Woû£ÔŒÂ¶ÞÔ·¢6ÿt|rx¼—…MȨ‹a¾˜˜SmÜHùõÛ0H R[‹’G×;›aÎÎÂzÆK”½i^@1â¸WŽ9õˆµp‘ÓN”ëÞeK’_v–$ Ñ=UI[ÿFaRÛ M6½d+ÝaªW(’h(IÛtu)–3Êž@vÕ¢µ>Y ÿ;*M`ç²ii¶¬D­*éà -+A‚Vš¼ Ÿ[ü -“ä Ž2½¤ñ\ÝCû"_ˆ|o¬ ãCt\E ’à{È:¿Å“ë…’Fï¤V4àkþæQcb@“{“>/Font<>>> -endobj -630 0 obj -<>/BS<>/Dest(figure-16)/F 4/Rect[80.905512 666.409764 124.581293 652.810154]/Subtype/Link/Type/Annot>> -endobj -631 0 obj -<>/BS<>/Dest(name-example-of-a-surname-with-t)/F 4/Rect[130.040033 666.409764 313.750483 652.810154]/Subtype/Link/Type/Annot>> -endobj -632 0 obj -<>/BS<>/Dest(example-name-surname2)/F 4/Rect[80.905512 642.810154 125.571527 629.210545]/Subtype/Link/Type/Annot>> -endobj -633 0 obj -<>/BS<>/Dest(example-name-sortas)/F 4/Rect[231.639399 629.210545 242.819086 615.610936]/Subtype/Link/Type/Annot>> -endobj -634 0 obj -<>/BS<>/Dest(example-localizations-replace)/F 4/Rect[266.236078 629.210545 277.415766 615.610936]/Subtype/Link/Type/Annot>> -endobj -635 0 obj -<>/BS<>/Dest(figure-17)/F 4/Rect[80.905512 489.615936 124.581293 476.016326]/Subtype/Link/Type/Annot>> -endobj -636 0 obj -<>/BS<>/Dest(name-example-of-a-second-surname)/F 4/Rect[130.040033 489.615936 269.857172 476.016326]/Subtype/Link/Type/Annot>> -endobj -637 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[348.830561 395.617889 431.923822 382.018279]/Subtype/Link/Type/Annot>> -endobj -638 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[437.982416 395.617889 505.086908 382.018279]/Subtype/Link/Type/Annot>> -endobj -639 0 obj -<>/BS<>/Dest(figure-18)/F 4/Rect[80.905512 268.104842 124.581293 254.505233]/Subtype/Link/Type/Annot>> -endobj -640 0 obj -<>/BS<>/Dest(name-example-for-the-full-proper)/F 4/Rect[130.040033 268.104842 264.812983 254.505233]/Subtype/Link/Type/Annot>> -endobj -2638 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2637 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2636 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2635 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2634 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2633 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2632 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2631 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2630 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2629 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2628 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1814 0 obj -<>stream -xœµZIÇ®€Ð…>B<‰ƒX ²$Û­Ú— …â,¢g†‘Ç'Èè )€œsÈOÏW¯«÷æ–™%6{©zÛ÷¾z¯Z#1âø|^‹Ìûà¬ýýãðÓ0s†nGºøiˆ3gGV«Ìqî¼yg2­yÐfôÓ?†«á?‡b??½¾øQd|ôî_Ã8Þ…rˆRfFëiÌÍp†¦¾xR>’(3úD~hÜç«ç–ùQþ·.o‹’ùÄÛ®vûæy[`dqŸÔªÈÏEí¼>®výžÕm~2¡âŸQûXûòÍ°Œ¿w™wš ã¹ î3©‚4~ôæãðÅéÑÕñ«—#¡2šCá©Ñ››á÷OÙ%»`‡lÌVìÇÇlÀ€‚ >ÀV+\4:cGÞf^‚-RñV0ðžÂè@.}ý—åéY¯K¯ŸÁ+'@Âbýò9û¢åm3ÄHÑšã'{«‡ „xëDÏÃ×OÙ÷pñ9 tF¢Žá¼E-$MP˜JjEðáÉ»¾nŠSVeÜ%Û6C\‰O}qÐïÄ©évÈŽ"«Í¢R8½èªš274 e!7»ÈæHÃñɘµ8]àÂ}/Ó­<É_QŠÓ#]j.\gY¦IÎ -†ØdpàYn¸OΚ¯‰Á²&$xFú!àì2+®uK\'à×OMÙ«dþkܹ"ÅçI¹crPqå.]ÕkƒÁ -yï$ˆÂYe“ÍK™³ÓÄì1¦9Ý^‘ +;KëÞŒV1¾š û”%XÀ/eØÇE± ©éî˦veêgéÐÕ®`ƒÏ{AÉ ¤î„nMWÕ9Ó­dw@kni8¼‡jIîîÈ¢VªÒrlÞ%"cŽTì1! (3(£êq¸(tX[]i®3kŒ-K«Bõ‡¤î#@óýžRbæ’ÈËÄ@GIë­Ò½:#Åä>!üt3&Ž‹É»$”õTr·NÐQ¤Êm‰Þï*§ÅL°8]PùzÒMÎÛi¤\+Za·h4SΉOf ËF’>éÜÿûóý§®Öå¦uÔî©Û—¾¨ËuЕJsÊÆ‚.§ïòe²•¡2dX£½Ýá›–im5XC¸­­Ïï|8¯ô Eh\®ÅEU}†O\šrÌô¯Þ[.ð°£ nã´Æ&ߊO(’±£ÊÅ7Ó»¦G]Ë‚,âõ·ƒËø»Uì`Ñ(sDE*?(Ýð ‘Áqª]VݨªØŒ£vV¦ôʤæãQ–ÇjËu uÌNK—Æf%7vÚ®Új¬fŒÉ¼QF†«Õ=Ò—\í˜E*mY‡‚Pƒ5¥ìJ)Ü•;¦pS…KBHŸŒÄç9…ü†Â™_¬–‰˜‰ŒÛ+G#–ëåT¼UZôêµÙ‘¯£ Žeáú–1Þ¦Uh•HœO“&/V¿Enp> ë˜J½éõÍÉÖB•<î‡ëã°þSû™éñl ø©pž¢—´øŽS³;¦ÚqëÖJ³ReÆ#Ü¡ÃQ½Xj±PŽ¡.¸îDE€æ´Æç8¤€]bê×’¿½×2¥ê²²2¯­4ßw˜qJ*åeý2¹º¾´E<×ÛŒÕ!êe} šÒ„¢w,x¦µ;$ÛÒö êþœQæ ßÅvÅyš¢Ñ;´èCp¿ŽtÞѶÊÅB£¨‚¬»y½é& ½y;ƒkNÀŠ®½$ªÜ¥ 2%wµÆᛆçf›±U†¸ ™‡å Í͸Ø")Z+¿ø½¬TôhýµteŽCìuð^%[úu¾"$¼®i–¼_zݹUç³wDOÅÞjJ[[3BÚ õØWe.MèW1Ç„ -ðņuÍW¦væêL –¹æy*¯ ä(E¡Ïõ -z ØËHÓ±BÚ„á9InÿÕª‘wÕÈ!±Þ.>V˜ªq?#wœ6ø¹ßå[ö7Gägg)„4ëÑZÇ›Åmî’ -\o¨U™×¾Ñ°OKZ3B,G; Š„RÿPß±9ØÓPãÚB‡îfwù×7·…“ÙºÕß -N[„Ö{ÐF3ÜjÙ×X†={Á¾ºµ¥q·›«X¥mz‡–Ò&›Wñ=t³m½OKâL9.xhµt÷SmÑ [o]«ª¸O¡Z „t6þה݅ÒÊ!ïF—¯œoWÿ…œf_'eZkðÊ5_•²L\ùŸ@Ì—ì |~Ѷr³eѹ;ë¬Ø*¨³·ºŸ¤XWI.Þ.‰×—Ýösüûå~ÂâœÅ‚딽2,UTo¡>°ëãë›Çµ¼ ˜ïéKÃ3aQj«]„çÕë8• -qŸ±êñN÷t­3™ôÁš­V«ô5ºõ  ÇÙð?ïÚ| -endstream -endobj -1682 0 obj -<>/Font<>>> -endobj -617 0 obj -<>/BS<>/Dest(figure-15)/F 4/Rect[65.905512 692.675545 109.581293 679.075936]/Subtype/Link/Type/Annot>> -endobj -618 0 obj -<>/BS<>/Dest(name-example-for-the-updated-pro)/F 4/Rect[115.040033 692.675545 272.301996 679.075936]/Subtype/Link/Type/Annot>> -endobj -619 0 obj -<>/BS<>/Dest(section-2.2)/F 4/Rect[65.905512 664.575936 95.494623 648.975936]/Subtype/Link/Type/Annot>> -endobj -620 0 obj -<>/BS<>/Dest(name-name-and-organization-prope)/F 4/Rect[95.494623 664.575936 306.937494 648.975936]/Subtype/Link/Type/Annot>> -endobj -621 0 obj -<>/BS<>/Dest(section-2.2.1)/F 4/Rect[65.905512 590.677108 99.092035 577.677108]/Subtype/Link/Type/Annot>> -endobj -622 0 obj -<>/BS<>/Dest(name-name)/F 4/Rect[99.092035 590.677108 127.319574 577.677108]/Subtype/Link/Type/Annot>> -endobj -623 0 obj -<>/BS<>/Dest(section-2.2.1.1)/F 4/Rect[65.905512 520.477889 107.621088 507.477889]/Subtype/Link/Type/Annot>> -endobj -624 0 obj -<>/BS<>/Dest(name-name-object)/F 4/Rect[107.621088 520.477889 172.494623 507.477889]/Subtype/Link/Type/Annot>> -endobj -625 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[302.00268 449.27867 360.327631 435.679061]/Subtype/Link/Type/Annot>> -endobj -626 0 obj -<>/BS<>/Dest(namecomponent)/F 4/Rect[366.386225 449.27867 433.490717 435.679061]/Subtype/Link/Type/Annot>> -endobj -627 0 obj -<>/BS<>/Dest(example-name-twoword)/F 4/Rect[80.905512 191.68492 125.571527 178.085311]/Subtype/Link/Type/Annot>> -endobj -2649 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2648 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2647 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2646 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2645 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2644 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2643 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2642 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2641 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2640 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2639 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1813 0 obj -<>stream -xœÍZYoTÉ®Ik^:Rˆ5ñ\$ÄŒÉP®}IÈLBðŽ7Üm–ŽÅ<‘˜ä!HyÈßÈ¿ÍWçÞ¾¾[w»1fÚ×î»ÕYêœ:K}îLfǽt -Fò¢w&ûÛÛþ»>÷–^ŽÏôð]wÞeÎhî…ðÁgÁ[nŒˆÆf?þ½ÒÿG_féøñUý¥ä"{õÏ~¢÷±$‘R)nethNû‡8ÀZ†ñHyK¢lö¦ù¦ö>ÝŸÜ…0²ü·*o†’9ãÚk_y}z·©N´jüžÔªÜ¿Éïeå¾JWy~Éêž\êô“5ÏU‘Žû¥ï¥6Üá‚ʤ\é¨lÈŽßö×÷¶Ÿïl<ÀN´6;>í¿ø–m²#¶c›=dØSœ{k:~ÔÍTEhŽ“˜ć줛øœBóI/­‰%ᲆìñ4"¯¸ÓÞE[mAÎÉt£áRhD@A²Íð7À̶¡è&¦P+i¹u1Â19õ(w‰rk™ö\hßd{ :œF`·B)?¶ÆÁÔIaG„e*çYÞåFë…–ª¤Iæž&F#”#–¥tÉ!†ïÂrÙÜ<˜Fj ×Î7–öžá¦êé,X‹"dCÈÛÀZLæ{40x®bÄz* Ÿ@ÅY34ˆ ï,(K²ç HÆ|LëPª»q\¤²œÌî!œ¢ŒQI¬Ž"‡~‚ðüÙ/>•BµÐ^…j)cª¥£EP¨–ì@¡zþ\…j™yªeþEP¨V[@¡VíZj•qªÕÛEP¨VÉA¡Z‡° -Õ{yz×Ç\‚7`_£,/´rÒsl`¼uH½†› K±w›Wך§4WÎø"O=þýpo¿s÷0Z£ñ)¬)‘Úí»Ê®5:0ãP§‚Ž²Áô7[íš…à¼ì<ú–½@—v€foŸDíä}iÑ¿õJ%ö‹ÂókOŽðNo@½MÞhT­½ä.¢fضèÒ'ïº<â`û¦G¤‹Ë'FM;åÃ)yÚÏ{™5Ïpçyöä<&¿©ˆ u_V—E5ý™ŽöLG_×ñCæ…ýî”UZ $T…q aÇŽVÌÆ<Õ>ì<Ø@ûÊýÄ`Š¥ùšÝcû†­°uœ¿fËì.ž½dŸ±7–\…¹s\Û×~ÿ Çk&À -+ý%.» ^/Ù-ö=ó¸ú5®VÀÿû-î2¶Š+Oo®Vðô>û ®Žü­²ð6ÃÓ› ¼?[£ pi£–r­Î¦wSƒ~3y¡aôzlº -¯œß-p¼ žàôuÁkË&r´ÈjH’u{¥ãýd„– ½gžL S*ohýæ_ÅÜW¡ê-˜2ßãêÎ7aðØÿ0H¿‚™2ö ¾›ng™É&¬ÇwLj²É§Í¥Ñ¹æ|'GCle¶ï«Õ`\>ª'x,áÌlxè)òûVJÓX»'‡ÐÖœýiø!#)Õ¦4<±Ñ)[ªª{1-bQKòýÖ÷u©¸Ì–Pt–à–¥öæÉí¶4 vã™5‹Oê«„Mée(‡* UAZ7‡-o'Tˆì™##»£¿þ‡jQ^Á’!{øâ8b›˜W±a¥Â± öG\m–cÏÞ ©6nÓ󄯧ÄíŽNÿK‚HnsíFw™G•Ñ‹ P>Jˆ~’8_!î[8¤YâŸÐ¡#¶W¾%´Œ=#äì9žÂ+ˆÍ\Çgx¿ß…2+¸Vb»ß¥F’’ϬdzL6é±d¸t¨}¶“þ -qxJV£®a²´à(‰!ŒÑ¼„q¢uBðÔ.T'%b~»dÿæêˆ(Á)žC›ßZ-\Lëˆ<¡QÂÛ$=²Úú˜º¾kÙ1IvA[ÕÅ&o—vÈyÛì—äÖd”3ÇLphw&Ínœ:ƒjÇk²ÓW 'èÍ£iŽ'HjÉæsèg¢ÏqwX,ô!ye³c19ÁSàÞ”ÐJVKÌâ-éRg‹mRêÛ(¢1©û´¨l´6Z[œÏ( -Ì™póanU2Ó!žß>$@žÖWþâ¸pÁw(>Ô1¤\p¤—Ô‚W‰.Ðkˆì±ëdÜaÓh&¹ÕB¹­—š’yóºŽÉ¬0Šjg™ØU‘%굂úë웋ʵ԰J‰JÞ–;9O?–Û’Wë—k’Ò—´†ædSq‡}…úu](¶»)¶Þòn¡ ue½)bwQÃ*•vÇ1ÖÈ2תJk›:ßLf³Mzƒ]c_²/æ4©Bâ…Êœ_à…‰.ƒ{…=QKh34°ùXóØÃÞ¿¨HÿiK[òËôŸÿÐÌI¤Óyýw íÜWìÆœþ3ÉØøš9Öå…ý'æˆEB£~\fjÓÑqg½’Í¢õ‘=˜àX›ÄyÅ\AüÝ`Ëóz}·p^·*÷ezÐ8Ÿàƒ_^ª1½oăþDÆ´ÊsáÕ¿OfL×^ŠÐì$Zá`Ónü""Á*¸”hXpjÅFm[èƒæA)¬ÿ*¶Gš1€ç VsƒÝHñ¿¬9ÐëÐ:ßhkðL4o’Ï…vê„ÊN1ÓÐN°GnÙßHŽG7ÊyŠŸ ÝÄ–óL·ÝÄV,×mžy|š¤àB¨ ÜL43GsÀér!É.ÄébÁ„ð4H{±ÞÖL†r®²/ºÀœ˜ê,¨ÁÀœ'å׃š N„‹}Jƒm²^×TQNš -“ÜD'b*RÕdªê9»GYûËâß!•|6]€v¦sIßY‚îÁ{wª_ÁšO’s†+¡¼™-I°‡”OhSº ï,9îÜÂÒ—ë¼çÊzme§ GÞ{BÒ6Ûƒ Ñ¿ð±ÎŽ|5 ÿçÍiK›P!lîõy„ñÌ>‡„‚äI4™voNÓbo¦P‹ìÌYkúÞÝ6™õjs9öÿâó -endstream -endobj -1680 0 obj -<>/Font<>>> -endobj -602 0 obj -<>/BS<>/Dest(figure-13)/F 4/Rect[65.905512 385.120623 109.581293 371.521014]/Subtype/Link/Type/Annot>> -endobj -603 0 obj -<>/BS<>/Dest(name-example-for-the-relatedto-p)/F 4/Rect[115.040033 385.120623 278.769281 371.521014]/Subtype/Link/Type/Annot>> -endobj -604 0 obj -<>/BS<>/Dest(section-2.1.9)/F 4/Rect[65.905512 360.021014 99.092035 347.021014]/Subtype/Link/Type/Annot>> -endobj -605 0 obj -<>/BS<>/Dest(name-uid)/F 4/Rect[99.092035 360.021014 115.770014 347.021014]/Subtype/Link/Type/Annot>> -endobj -606 0 obj -<>/BS<>/Dest(RFC8141)/F 4/Rect[390.563227 318.421404 431.52099 304.821795]/Subtype/Link/Type/Annot>> -endobj -607 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[174.822504 304.821795 215.780268 291.222186]/Subtype/Link/Type/Annot>> -endobj -608 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[324.868647 304.821795 365.82641 291.222186]/Subtype/Link/Type/Annot>> -endobj -609 0 obj -<>/BS<>/Dest(RFC9562)/F 4/Rect[301.092768 291.222186 342.050531 277.622576]/Subtype/Link/Type/Annot>> -endobj -610 0 obj -<>/BS<>/Dest(RFC9562)/F 4/Rect[354.349359 291.222186 395.307123 277.622576]/Subtype/Link/Type/Annot>> -endobj -611 0 obj -<>/BS<>/Dest(figure-14)/F 4/Rect[65.905512 212.507967 109.581293 198.908358]/Subtype/Link/Type/Annot>> -endobj -612 0 obj -<>/BS<>/Dest(name-example-for-the-uid-propert)/F 4/Rect[115.040033 212.507967 249.383783 198.908358]/Subtype/Link/Type/Annot>> -endobj -613 0 obj -<>/BS<>/Dest(section-2.1.10)/F 4/Rect[65.905512 187.408358 104.681879 174.408358]/Subtype/Link/Type/Annot>> -endobj -614 0 obj -<>/BS<>/Dest(name-updated)/F 4/Rect[104.681879 187.408358 146.52807 174.408358]/Subtype/Link/Type/Annot>> -endobj -2662 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2661 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2660 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2659 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2658 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2657 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2656 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2655 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2654 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2653 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2652 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2651 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2650 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1812 0 obj -<>stream -xœÍZÙSÇoŒ•‡u•Ê–£$€G±, Éjú>‚G´  —`áM%J*ð ÉUvòWå!z~Ý3³;=»³B1ì=Ýß÷ûŽþŽ…Œg ǃpqŠSç¼5*ûûÛÖ-ju|Y^ãà-¿W‡ãµ(ßGX•ç7ù3¯à|@¶p>!]<ËÖV„±é÷SvÒx(ß2ða—#Û:žAûZSÆsõæÚŸs: ÛÓò¬~…±fÙbÔbÂ[Ÿ¿­ݹ*0ø×C`²lf ਼­êdœqª3N@Oc -òx½ìðåÉÎÓ­Œ jâwªð²×ä¹|íKܾ" 8ÿŽ< ÷#÷qÿ—š U˜HIáLÌÚ¦¯•åàIYAêßÍ‹•£LK«d±x!r¾®ßà(‘Ü _ع<áz+§SyÝLÝ*ä·Êôž$ ¼S‰DC…0(²½ÂMþâp¬ßO,1¸_&[¹À˜Ú'¸{ŒQƒ™Hîžà%8âx4YÞQÃ+Jz+·övLtªžSÔ1hB3éU‘Éå2ÎÐY ¿À¨-¤ ’=Æxi× g‰ž`¾Ãó2YÅìðîVj æ4Ë'ô½«è½Ù -(?Šú -×Gà´¿ tÙ*F îžD«¸ÛÀóVÌ6ê|#^d͸àÙÜVôþs­‹£Ì²Çà™'‚½öÙÎÖØDðáõˆ<#ß⃠ÙzéCd‡EòI Á=<adá»N–ªˆß %C,ÑP (ÿxp¸w°;å ²„ü´D~ƒO=ñHA‹,W5r©pµEÖ!;!øè¢}¡áHÚK&fWª-òZ¼ÛPØÿÛb*M~%ÈS²±||3ÞmãM;Þ·ñ~¸âÆN0]@´œ»ï‘ë•9/£µNÃ}=« ”•Î ¬”FG-pSŠsðbÁ~?2ïÆû`þv„ÀåÙy3Î…Ú3vS߸ŒsV8ˆ©Áx‡(”ÌLbëLS's‚Z¥9K2¡3¨»¼Âo®¤ôR(A¥´™ù¥×ÆÒ+¥;¥ô™<µôz1(µò0Sñ¥…ØRûQ†“Š/é$RgÝhs´h¨¿fXñ+Á¤SClƒRLúÛt4Aï³3’1QÏ¡¤ u„àËsR/Z²ÔoQeq|~ ìüóœõl¤:@]+•1ÐËhï8¤w°6iQQy›–:Vº_V¶œÃ:¹½fB{¾Ÿ ?IQè… õŒ¢BøX©W8ª,fÜ’…f{¼·É1nFÃôbÛÓÍVH„Ò[²¢;$v‹î{Â"ÃàÇF«ÒzÛÑo÷Ç(¼²áX1lz¶¡–ÜjÝJÏßLÀ3‰ÒݹÁ&Ì œÅ^nî“a/uÙfZ:F™C×akjžfz^¦è°¨4Žëz|'¦ã²*_Á+ÎQð¦{rB uwH¹[bú)ÑÌØ” @g'š™s¹uÆqIdMì‰$«à}vMZËPT~vsN!¥õmõvvÞýó+°+ü‡"Ž(éfglÉC"¶®ðÛ¨4žMàýx~»òе[dh¦Sfæ4LƒØ=§Q¹sˆIÆ;;×ï®À¦Z°ø7;iç·îÉ¿†ÇÏœBkï©°Béz’š¸]ódy ã´Ô†ktò³³ÓáË–;î r“|6§|Æ:*„ÖÖ]Ú¨9-ž=%Ͻ]uñ/s,ß ç£Oë¹ï}Jj†PR|€’Zç”ÖN³*£‹4›!…/W¼a16U9ˆto.’eìÍ›ä‹z8œÌ üコÆ>•ÑÈ·óq2FQÁP+LçÄÈf,bIƒ|†Ï¯æcþçÆZ*´•šåabiõ"òm²Fýá´NŽúçÿ-zœ£9u©åÆYò˜ç_¿åN76¸Ã?cíÍ©Z«iøjUO•Z]HTkÝ[ÿ‰,É6 -endstream -endobj -1678 0 obj -<>/Font<>>> -endobj -586 0 obj -<>/BS<>/Dest(figure-11)/F 4/Rect[65.905512 645.129764 109.581293 631.530154]/Subtype/Link/Type/Annot>> -endobj -587 0 obj -<>/BS<>/Dest(name-example-for-the-members-pro)/F 4/Rect[115.040033 645.129764 277.280268 631.530154]/Subtype/Link/Type/Annot>> -endobj -588 0 obj -<>/BS<>/Dest(section-2.1.7)/F 4/Rect[65.905512 620.030154 99.092035 607.030154]/Subtype/Link/Type/Annot>> -endobj -589 0 obj -<>/BS<>/Dest(name-prodid)/F 4/Rect[99.092035 620.030154 133.888666 607.030154]/Subtype/Link/Type/Annot>> -endobj -590 0 obj -<>/BS<>/Dest(figure-12)/F 4/Rect[65.905512 513.315936 109.581293 499.716326]/Subtype/Link/Type/Annot>> -endobj -591 0 obj -<>/BS<>/Dest(name-example-for-the-prodid-prop)/F 4/Rect[115.040033 513.315936 265.80102 499.716326]/Subtype/Link/Type/Annot>> -endobj -592 0 obj -<>/BS<>/Dest(section-2.1.8)/F 4/Rect[65.905512 488.216326 99.092035 475.216326]/Subtype/Link/Type/Annot>> -endobj -593 0 obj -<>/BS<>/Dest(name-relatedto)/F 4/Rect[99.092035 488.216326 148.146723 475.216326]/Subtype/Link/Type/Annot>> -endobj -594 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[161.213373 276.220233 219.307611 262.620623]/Subtype/Link/Type/Annot>> -endobj -595 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[225.366205 276.220233 284.381098 262.620623]/Subtype/Link/Type/Annot>> -endobj -596 0 obj -<>/BS<>/Dest(IANA-vCard)/F 4/Rect[497.986078 276.220233 522.634272 262.620623]/Subtype/Link/Type/Annot>> -endobj -597 0 obj -<>/BS<>/Dest(IANA-vCard)/F 4/Rect[84.505365 262.620623 141.41015 249.021014]/Subtype/Link/Type/Annot>> -endobj -598 0 obj -<>/AP<>/BS<>/F 4/Rect[390.439447 262.620623 449.45434 249.021014]/Subtype/Link/Type/Annot>> -endobj -599 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[467.71142 262.620623 508.669184 249.021014]/Subtype/Link/Type/Annot>> -endobj -2676 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2675 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2674 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2673 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2672 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2671 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2670 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2669 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2668 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2667 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2666 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2665 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2664 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2663 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1811 0 obj -<>stream -xœÍZÙoÇž†Ð D0b7vËÀu¬ Ï}E8ºL’HI¤ì0iù!v§yÌCÿô~3;{ryl¡½ä^ó»ï·ëŒg Ÿ'áÇ)Nó֨짷ÃwCju¼XüÆ“ï†8²&3JR˘u6sVS¥˜W:ûõçá|øï!ÏÂç××ç?rʲ×ÿ†õÖ—K8‚jî‹k®‡|@š»âpyYéìMbù¦q=Ï¿3ê²ü_ß!sÂ˶vùú«¶8^‹âz«vü&?æµãúºÚù·úP.Ã_Öþ­³|v1,}Ï™¥Î*Æ vÒ í²‹·Ã§'ǯž<˸¤‘‚d\g×ÃïK^c2ØûábT’LR¯lXÝ$„ò’ì“Sr…e3í“KìÝoàRQ­˜q»êâ@%c2!Gø~‰íd±û‘ÐÃÕÎ@&rŽïKœ›âÜ`5Ã)·\+ŸŒ°h -Âç%ÙêÌ¿Ïé)¾sFS\`oBæ lQ·Õ, FZãubŒ»I"8Šûcò~ÉõZ¦(gÉ›HžbÁami¡Ëßgïûí{Öšjã=‚.'Á‡Áy‰tý\ðÅö^Äk³R³}-˜mûiõ!D8õ+ˆü¶[6ûç_Å3'ÑØÁôgÉèkW–2iùIðJ€.ëÌ¢£<.+îÏ\¤ŠÕ‘k>üoýêt“šrÎ%Îôȸ ñUÔürO°ÇQ(¸³hMÒ×™ ŽÊk™dz{ÎòñJ. uŒ£F9%mNVÆ&·É-ò7lwûjé=h+¯åö¼×MßæÄxöë=÷^p$Ajƒ½+쪺¶Zž>iÛM Ô¨ƒ‚@*ùÔ¬±‚@ªü!Ô¨¶}z7t |hÇ\&Œ¢ÂH&xf¸¥ÀYV›Ìê¸W¸Á›dö•¶Á7R§µá"ÊûâÛÙÉiwQØC-¡îæ574†ÏÛ=ÇQ£µ@)oRÅêûK JéP1µë¸yñ˜|{t.ž§68Ï¡Ú_D&q¦ êÌÉbÑBb9¤”j™QéwÝö·KöÇd Eaøþ+h*,ÏÚ¿pÕ6ƒA­ÇtïÖ]î\C6]ɦ ÙP€sÙúè½eï጗iápºT2/“——ÏŸdèÀ&þy§R˜ýB‘‡!Ø`÷Gò|§Ã‡„c{@ùœ|I~©'Ϥûß+ЋB3¿¡¾!.÷#Ìà{” Aô]&ø  c²hà¢/®É­ºÔï—·ÆPdÁófþÝÙäälÔ%逆îb[‰‚"Ì,W-rË -¶"N9Ghv,lñVR!Œ3Öþlmß4T-Ù9Ô€°·[‚j@îÅ¿~è8„ñ2ˆ×ES+ë­4²%Xí¦ÂPä€ÄÁež°ü ,¸ô j±µlQŒ -)‹Üõå ¶,ýÈä‚V5íÕn^ˆ^Ö¸G¥! Iˆ¥EZpÉ£2ìö±”F°âöüÎœáYÂ/M(ôS ¾f»¹~…y‚tˆ.$è4êS7hcÖmņÓ.G‘Y&{¢ÐNãXóqa¨–¯­£Ê)º‹êydkÍ£{ÜÚ8ËlHMLú¡É8 Ç­Cüëþ“„ŠO;”AÞmÍF‡êùé|Fîõœ4*Ö#u¿y_c - åCÇn:°¬r"±bäáž…ÿþù'Ì¢ -q§#‹Ði3^×êñYåÖ¬§¥ª;g^šv.üÙÓ(FA -¨«|%ÛÃè4ŒÞîNhµ¤Ç0Ú]J;Ê•5¨¹7 “A–†ƒ4‰õ‚ɷɧmìkàk'‘JMº@Yƒ Ú'ï¸y#P^n@[fã©áF0¹Ìp`ž0KžX˜·XñÌJûJ¶ €yƒ0£—Pt1ÆÕFÀü%1ÂŒ¿ Y œ`ÿ5ùéz3hY{GµôÆnx€ÕņF·±ò×äïÇi á®ßÜð؉`ù-+w¨˜_È-³[*X·Új#TÏH– ·0³æÐ ¹Cè†ïì)V/´³.0†´PE×(br_$Lã;ª|LȜıaPÚ'XçኸWXu§š«8¿Ô¢ÃX-„،­v€w˜zŽÁÔçêŒaÊv_¬kˆâ <\½Ò[Ũé’JŸÝhØ«ðó%K„¼¼ˆÁ™fž ßf»NÓD·S¦•*Y†î)-SNÊÂùf:L “GEnïYÌÑãRÔâ5×A¤‹W4‡Q¨Jôb`ÍË4ðA‰1@ºŒY”«“h¦Wd²Z™ðÆ=Ò¯¼Ž#FÇ–sX˜c¸°—ì )!^ÑNTÚŠc@œG½ædg©ý‘N^b #Œs­ÊÒ1å8b¢íû2Õà$´·ÜfªoË´`Ì"ÅUl¬FâÊ 4¶ùîB4ÇÒ Ë]|þÚÖl=ƒ€Q5ÖðŒžk<*뢰'Ã3”Çً͜u‡|Ší³~ÌÂÿŸÀˆTjÞÉÃÄ™Çâq| ¼ø _OÉtqýߔӞ¶ÔŒr㬖Û0Ï{i…&l-ÁOzšÖj*0 éZËr|¹^:ÔÂq2ü!WyÜ -endstream -endobj -1676 0 obj -<>/Font<>>> -endobj -571 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[101.33349 771.389764 159.427729 757.790154]/Subtype/Link/Type/Annot>> -endobj -572 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[165.486322 771.389764 224.501215 757.790154]/Subtype/Link/Type/Annot>> -endobj -573 0 obj -<>/BS<>/Dest(figure-9)/F 4/Rect[65.905512 602.177498 103.991449 588.577889]/Subtype/Link/Type/Annot>> -endobj -574 0 obj -<>/BS<>/Dest(name-example-for-the-kind-proper)/F 4/Rect[109.45019 602.177498 249.483393 588.577889]/Subtype/Link/Type/Annot>> -endobj -575 0 obj -<>/BS<>/Dest(section-2.1.5)/F 4/Rect[65.905512 577.077889 99.092035 564.077889]/Subtype/Link/Type/Annot>> -endobj -576 0 obj -<>/BS<>/Dest(name-language)/F 4/Rect[99.092035 577.077889 144.837641 564.077889]/Subtype/Link/Type/Annot>> -endobj -577 0 obj -<>/BS<>/Dest(RFC5646)/F 4/Rect[358.08349 549.077889 399.041254 535.478279]/Subtype/Link/Type/Annot>> -endobj -578 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[305.429438 521.87867 365.332025 508.279061]/Subtype/Link/Type/Annot>> -endobj -579 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[371.390619 521.87867 430.405512 508.279061]/Subtype/Link/Type/Annot>> -endobj -580 0 obj -<>/BS<>/Dest(figure-10)/F 4/Rect[65.905512 456.764061 109.581293 443.164451]/Subtype/Link/Type/Annot>> -endobj -581 0 obj -<>/BS<>/Dest(name-example-for-the-language-pr)/F 4/Rect[115.040033 456.764061 277.212152 443.164451]/Subtype/Link/Type/Annot>> -endobj -582 0 obj -<>/BS<>/Dest(section-2.1.6)/F 4/Rect[65.905512 431.664451 99.092035 418.664451]/Subtype/Link/Type/Annot>> -endobj -583 0 obj -<>/BS<>/Dest(name-members)/F 4/Rect[99.092035 431.664451 146.826899 418.664451]/Subtype/Link/Type/Annot>> -endobj -2689 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2688 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2687 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2686 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2685 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2684 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2683 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2682 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2681 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2680 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2679 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2678 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2677 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1810 0 obj -<>stream -xœÅY[“En*¬V…¡QYpJY”Þ¾_µÄ²înö’, Ñr÷A°ÊKy©òÁ¿á¿õëž™d.ÉL"K±C’™žîs¾sï>$Â*ür°¹u'áa0üaV²wØ}rŒVÈY'dE°k¤G:何oöÖ't¹tÔh-Œ©PÅꋤS™¬4õRj7eòèyBÖÈ6Ù%[‘Ñy€ï5|>Â÷@îáþ*îS0÷Ë´…mn½áuÚ)Œ»{s(šsŽ÷°3¹®_ACr¸:øœ$Ÿ‘%ò&9"_€¸ñ#r÷·ñ9"Ÿãþv3äFnáéMò¾;¹çF(ÖP%jzº - i‚%{¼¡D­}ÜLØ3jxMg ²57Àl -¦¨cP’fÒh¤t._ƒ%£ê“ðµ -S¤DŸMÚ»Š¸ùõçtÑ?ŒR'©‰Ÿf–ⳂËé”䯽8&·½´  `u£¤ºY0–#I1ÌF ,•&˜öU5üÑ„Ü„Û)º ÞAÉéF!"’1ôU<Þl’¨vVV”Ñ€ÜyêáBºIWü•'æ~v…ôür¥ÍÂB¡å\ýj»¿¹½Ž˜ÍrÎ9r†œÅ§Z˜´ -aU&€% ÕhˆªsŸa¬G’ì£:íb|#øTk‘¤‚ÁJ¶N®Â¹ Þ{ªáá2¿Ù{üàîÔºlÉCðËÜïE;¤çû¤7úîoÜöâëÝ:ÔXTïbô#|rRX5ˆ"öA²\‚cÙñÀðoÆñtÕ0þ`ÕÙÃo/ŽFÀ3À ìßÊ'7(I.ŵÊsÆ=,ìEÅO O½H. ˜âÝãŒ|'®ØÊf ¢„;Q– i2‘fP Q|¿]3yÐÍÌÙÇ» š3E÷Í·q/å¾ -Õ\K΄oñ€Ë1EË^Œµblå:žNE”ý @©£Ã2ޗéµØ‰¤‘<³:Î<à¦ûËU…\I¼Ê„r3º¾¦B^„Èsç£ùµj£ tø œd':ðZŒ¯ÎDßy\ ³É“ØØA\}$Ä“{„[id”1®(“,ìT˃8 /,uXp¹Eͨ­§Ø#kWÔ’QdÊ`a··ÚöØý‡(ŸiæZ,ò(†ä ¸×áêZ „yT9=§«Ÿktõ2¹ª„•eNbëÊ”ª¢˜âírc…š_·MÞ^Ö{ÑåÓb‘ûä|nÎ$E4BVÀÜ|'Ö¬RlU·™U |i#%Ç *?ã}šmoOÇü¿a£½›Ó„ô+&žj‹‚N„b¦9ëUµ”ëëh´âA0èä -ˆ bá º7‰Ûš/–Nu¥HuØݧ'ÚšÀ V5•ApÉåà–3L?Õ£)¾§b)Ê8ª,TRóåRT9†½¢Æ3Û‘úuÜ+LðæXú*Æ(*œ°Þ/ÞWyf_¥Lµ¥¯R›\ë«´¹´Ì@•ÜºÄNjŽ=-Ǥή©Õ¢=<ªf…Ä&f´ZæXñÚZ-Ú› ¶qËEú Û"rü¯V‹ ˜á®¥ÏÒÖë˜v{éo¥¦Ì¡äµm¹&;ü§/Æž‰xÇãtÜÂ9·£³žŠn™'·©µÖs Â)uÞmí;µ¾L®*l½ÖK§”õe’sjR±™_ÍyÎO“ƒÏp¬ÜÇqNêÖöqvÜ+›kJ²/{T2ð+Í»›#ϸÕnñ¼{afÞ-SmÉ»µÉ­y÷ÞD®Íys¯ÐØLé:˦Ü,áj–hʽs¬xm¹×j9ÁÖ’{[äø_¹×ZìPœ×i7­1÷^Š=µe²Zè¬ýûÀ¡Cú¾¡ìñ{Azï=¹…o‹‘ ¯(9;/`.ZûL›ñœu깫šˆ/¥Ý'øùl ï.ÆÓkJaûŒÐ:ˆs—Ž7m;­(\+´ïæKÛçÓv™ÜD •~%½æ¼¾ š°£J3ÍåüªÏvn‚j×!뮥m‰i;äéÝø=È&Ê*Ï݉E˜³Dƒ=¸ò†yiu t¾ ×!¯^Ëeò.®wª%¡™4¦46sZÕÎp‹qŠ›U&¬jçÄÈZLÄQ·çÈÛøœ_ŒYøïe›„F‰æSy˜˜öwc!îÁÎ2ú _«dgtøOvnÝYP—šagŽâ çaž÷MòV¨ÍªOPí悪µçÊÙÆX‚üztÕ³Yí-¸c¿ûbí  -endstream -endobj -1674 0 obj -<>/Font<>>> -endobj -552 0 obj -<>/BS<>/Dest(figure-6)/F 4/Rect[65.905512 602.569764 103.991449 588.970154]/Subtype/Link/Type/Annot>> -endobj -553 0 obj -<>/BS<>/Dest(name-example-of-a-basic-card)/F 4/Rect[109.45019 602.569764 221.938471 588.970154]/Subtype/Link/Type/Annot>> -endobj -554 0 obj -<>/BS<>/Dest(section-2.1)/F 4/Rect[65.905512 574.470154 95.494623 558.870154]/Subtype/Link/Type/Annot>> -endobj -555 0 obj -<>/BS<>/Dest(name-metadata-properties)/F 4/Rect[95.494623 574.470154 219.904535 558.870154]/Subtype/Link/Type/Annot>> -endobj -556 0 obj -<>/BS<>/Dest(section-2.1.1)/F 4/Rect[65.905512 514.170936 99.092035 501.170936]/Subtype/Link/Type/Annot>> -endobj -557 0 obj -<>/BS<>/Dest(name-type)/F 4/Rect[99.092035 514.170936 130.299799 501.170936]/Subtype/Link/Type/Annot>> -endobj -558 0 obj -<>/BS<>/Dest(section-2.1.2)/F 4/Rect[65.905512 461.071326 99.092035 448.071326]/Subtype/Link/Type/Annot>> -endobj -559 0 obj -<>/BS<>/Dest(name-version)/F 4/Rect[99.092035 461.071326 137.287836 448.071326]/Subtype/Link/Type/Annot>> -endobj -560 0 obj -<>/BS<>/Dest(current-version)/F 4/Rect[439.813471 419.471717 498.828363 405.872108]/Subtype/Link/Type/Annot>> -endobj -561 0 obj -<>/BS<>/Dest(figure-7)/F 4/Rect[65.905512 354.357108 103.991449 340.757498]/Subtype/Link/Type/Annot>> -endobj -562 0 obj -<>/BS<>/Dest(name-example-for-the-version-pro)/F 4/Rect[109.45019 354.357108 263.370844 340.757498]/Subtype/Link/Type/Annot>> -endobj -563 0 obj -<>/BS<>/Dest(section-2.1.3)/F 4/Rect[65.905512 329.257498 99.092035 316.257498]/Subtype/Link/Type/Annot>> -endobj -564 0 obj -<>/BS<>/Dest(name-created)/F 4/Rect[99.092035 329.257498 137.538324 316.257498]/Subtype/Link/Type/Annot>> -endobj -565 0 obj -<>/BS<>/Dest(figure-8)/F 4/Rect[65.905512 236.142889 103.991449 222.543279]/Subtype/Link/Type/Annot>> -endobj -566 0 obj -<>/BS<>/Dest(name-example-for-the-created-pro)/F 4/Rect[109.45019 236.142889 263.441156 222.543279]/Subtype/Link/Type/Annot>> -endobj -567 0 obj -<>/BS<>/Dest(section-2.1.4)/F 4/Rect[65.905512 211.043279 99.092035 198.043279]/Subtype/Link/Type/Annot>> -endobj -568 0 obj -<>/BS<>/Dest(name-kind)/F 4/Rect[99.092035 211.043279 122.129633 198.043279]/Subtype/Link/Type/Annot>> -endobj -2706 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2705 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2704 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2703 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2702 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2701 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2700 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2699 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2698 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2697 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2696 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2695 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2694 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2693 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2692 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2691 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2690 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1809 0 obj -<>stream -xœµZÛnÇž‚È Ôb'i‘ª$–¯wÎ;—u%Š–Y¤¥•âÐ@›¢ÊEíN{Ù‹ö%ú¼ý柙=kIÚŽiî‘óŸÏ£Ÿåø<ö§Bñ¬(œ5jö·7Ó·ÓÌjz™ÎôðíwÖÌŒ’™Ís[ØYau¦Týò÷éõôç)ŸùÏ/?MŸü•gùì§Nýzëª%œ ‘iîLAkn§K|šéÀò†PéÙëˆòu뽿¿~dY1 ÿ›ø6·^ÛÆëÛG]rœé=‘Õ¸îyã¾¹®ñüW&·þd\ú³î¹‰òéå´Ò}a³Âªœë"/f\ªÌäEŽËË7Ó'¾Xž_œÌ¸™]ÞNxÈî³=ö¾“ƒW—'5.l&…á0ž6,q&È슕쌭ØÇ%;i\e‚ƒ ÑÐÁÕ&×€!é„äž/^>;z -±,ñ«Høú!ûžˆX¯Ù„((Ù5;ÄyŽÇÐõ ÇC|3þ&:ýû9Ž$´£µÓFvÐ{Z ô1Žs,¾èÏ^²Szr: >R–Äãa\ÓºoÙ>ãøþnLÖeÜŠÜJ é*®ïPJ¢ÀßÚ \­pôO®ñ6ÐvHôzÙsvS=½"±᪌ë=mÐ<³àc1Hu9Àÿ1AYáú4¾Ðõ¢gC«-4WnÆÌ)WE!+±¶‰'%¾$9¶aB¶žöãg#8µ„'iç´Æ PÖ{È.°83Ù -QŒàpbiÓàæ/HBgdxÄ–çÐ yÊxÞ4;”ºÀ¯f¦«€Z4]… Mã ¿ŒÒ%$c J™i›ëÊQψ¯§cÒ¼2› ³#`^µÁ,öÆ@ ¿2F'‹ÞßÒsæt.£˜Ê–c_àø]$'ÙÆžµa’çL¦sa‹ä}ÃÎÖ·ÿ¡õÜ:غT¶}­¯°uMöáá¸F³ˆ‘+OI¶‘€Ìk‡aN"© ‘¹gÄÅQ·G&y3mšÝ!’ïx˜(,mÁ¹íöa}{¼-Ú̳(¸¯?f‹õÿ¦,Ò@Z)tmøjH"c\K‘YS(‘,®ïXpp™†’ôc°œ³s¸NA%¼öŒô´"‘1àIÔË’ ŒÂz&¤Òºà¹³·»,y³½âþ¸#К[/«ÑüuL¿ "¸‰OV8.I“~`c·™4VVqx7©Î‰l/ÏlHWV¿>¨®×1ý^ïÊ(„ò¼F^Ûž—Ä v%:d¬”_GøTyŽ’ó*=¤tliIôx€/üØ?™Gd![ÔtB›äº,‡crÞ'fB¸‡gQ,gã^ëÕ·(Š ê±*W4õ”ôpÖcˆmeeÞ!Œß%ÿ5­K¹o,¥E¾ŠQ;ý¢)Õ1&¥A ñ—µ§Žãº&7yEw«Ž.c?4PÉ;κ;‹yá‹SW¡·¯cÉ”°ôML2G½¦z•í1MØÇwbiñÖB@…·¤±=.©Î+°»ògóÌ)ëmßeÜ~"A¢Ó“>eöŠûÜ-KÛHÆN=a«4!á”ëÐIFŠ\!öl¨§[x¿oMwÕ1‚Ÿ—o¡Ôö¸?ˆŽÑ½gÜWì€xPÁ[2ª´É -ãðr{|ïä¬ -ÕJòšwÕæ§^›;2¨Q¿Êš^÷ø~šÜà&B#o©ŒëT·ÕàDD\9+˜¡^Ò¾/R%ÀJ! ;y{ )ÄÊ™ø0´“žqˆÎBÛ"¡/í4:º?0>‚ò8 pÕ78>š°õÁÂú-©ëÝ*[ªò½3Á¡’:çÒôñM›”óë¸3fƒeíá“ØÚ]Å£®üRµª„E,»Çª—{±[ò…튚v¸¢©fM ×0†'øL*;ôGÁdU5§YÇÁçµ­o·'¬Ïë-9ž<‰MKÿmslÕ†™Ê~¼ð£Ž“ªA =ÎrŒQ™gÊYíx§¦àÞ 6ÇjÏ#ª{S ·Šô—D&z\ßêÎcá_Ñ;T– -kŒ3å+ò\åêŽJµi¯a´÷¢7ÛPgS牱}ö¢,ðËnèi“dtVh+œ@ d3§QÌšYÌÅÂœI[ ï±¥3¥\ʧ*ÏŸç‡RÃMt ÏÝçÝÀ!j-ÚP±úË^”SÚçM] ü8ÍT+IÕ3¡žg((†gU[Ú‰x€!ïãž$¥¼R‰ÉdO%ŠgZ$]ì¾"ó»L–Ϻgho›¢Fñ1|Ù´ô¸MÚlM›N´IiÛ…ÛG[ט9Ö¨Üb¦QíæÒÚ<ÔËﯞ==BºÎ ýóÕ`°¼¯X3˜A÷Lâ‘7ˆß°ÿâkÙÿØGlý3[ÿèðèì/øö_5]íƒdzc -èˆÂm™éŒfú68jCoh䱈ѮgäÉ¢BíãPçÙ>¨±$n ÇM.܆$n)[”Ž_P‰Z…ãºVíNåË;°Ùfà -sÆqcª¾j@º‚ŸÇ òaœEk™!¡ø„Þæqgñ9Õ;Ìg;•‘Žª .·Ç½7Tlåñ®Lf5ÊAô–&wÒêü”¾´÷¯ÁÊìs|>í&ÏqÒO6¬±†oD4¼Qº5&ãÇ)¹°j3¦œÖ-ã|¶2ÿçVÖfB[©ù C¥%œÏýìã_49Xù=ӰżÚQ–ˆ.ÜVËm‡YTÚ­ô;õdå|GÑZÁ ÐcnB,>l¦Ýgèšãrú¹ óØ -endstream -endobj -1672 0 obj -<>/Font<>>> -endobj -530 0 obj -<>/BS<>/Dest(section-1.9)/F 4/Rect[65.905512 753.389764 95.494623 737.789764]/Subtype/Link/Type/Annot>> -endobj -531 0 obj -<>/BS<>/Dest(name-versioning)/F 4/Rect[95.494623 753.389764 160.664057 737.789764]/Subtype/Link/Type/Annot>> -endobj -532 0 obj -<>/BS<>/Dest(card)/F 4/Rect[206.698969 731.789764 229.316156 718.190154]/Subtype/Link/Type/Annot>> -endobj -533 0 obj -<>/BS<>/Dest(card)/F 4/Rect[235.37475 731.789764 278.210443 718.190154]/Subtype/Link/Type/Annot>> -endobj -534 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[459.527338 718.190154 495.303949 704.590545]/Subtype/Link/Type/Annot>> -endobj -535 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[69.36474 704.590545 128.379633 690.990936]/Subtype/Link/Type/Annot>> -endobj -536 0 obj -<>/BS<>/Dest(iana-media-type)/F 4/Rect[306.875238 704.590545 342.65185 690.990936]/Subtype/Link/Type/Annot>> -endobj -537 0 obj -<>/BS<>/Dest(iana-media-type)/F 4/Rect[348.710443 704.590545 399.635736 690.990936]/Subtype/Link/Type/Annot>> -endobj -538 0 obj -<>/BS<>/Dest(section-1.9.1)/F 4/Rect[65.905512 499.895233 99.092035 486.895233]/Subtype/Link/Type/Annot>> -endobj -539 0 obj -<>/BS<>/Dest(name-version-format-and-requirem)/F 4/Rect[99.092035 499.895233 273.172602 486.895233]/Subtype/Link/Type/Annot>> -endobj -540 0 obj -<>/BS<>/Dest(figure-5)/F 4/Rect[65.905512 375.981795 103.991449 362.382186]/Subtype/Link/Type/Annot>> -endobj -541 0 obj -<>/BS<>/Dest(name-the-abnf-for-jscontact-vers)/F 4/Rect[109.45019 375.981795 290.940668 362.382186]/Subtype/Link/Type/Annot>> -endobj -542 0 obj -<>/BS<>/Dest(section-1.9.2)/F 4/Rect[65.905512 350.882186 99.092035 337.882186]/Subtype/Link/Type/Annot>> -endobj -543 0 obj -<>/BS<>/Dest(name-current-version)/F 4/Rect[99.092035 350.882186 180.442865 337.882186]/Subtype/Link/Type/Annot>> -endobj -544 0 obj -<>/BS<>/Dest(tab-iana-version-registry)/F 4/Rect[338.004633 332.882186 372.240961 319.282576]/Subtype/Link/Type/Annot>> -endobj -545 0 obj -<>/BS<>/Dest(section-2)/F 4/Rect[65.905512 301.182576 89.131635 282.462576]/Subtype/Link/Type/Annot>> -endobj -546 0 obj -<>/BS<>/Dest(name-card)/F 4/Rect[89.131635 301.182576 124.251264 282.462576]/Subtype/Link/Type/Annot>> -endobj -547 0 obj -<>/BS<>/Dest(iana-media-type)/F 4/Rect[197.038324 238.063358 247.963617 224.463748]/Subtype/Link/Type/Annot>> -endobj -548 0 obj -<>/BS<>/Dest(example-card)/F 4/Rect[65.905512 214.463748 104.981684 200.864139]/Subtype/Link/Type/Annot>> -endobj -549 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[414.771967 200.864139 473.786859 187.264529]/Subtype/Link/Type/Annot>> -endobj -2726 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2725 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2724 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2723 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2722 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2721 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2720 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2719 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2718 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2717 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2716 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2715 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2714 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2713 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2712 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2711 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2710 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2709 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2708 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2707 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1808 0 obj -<>stream -xœÅZYo[LJQ -0²ËNQ[¹ASÛ²ãñlw4-ZW²(G•DÉ"½0Hã¢Òƒlv úÐ>ô¡@Ÿû{ûÍܹ+y/IÉED“w™å|çÌ™³ž0|îû‹UœZëŒVÉŸ^÷ßö©ICc~ /ßöñdt¢•¤†1cMbMJ•bN¥É»?÷Çý7}žøÏ»Óþƒï8eÉé_ú~¼qÅÎ… )wÚ†1'ý!>˜šÛ¼¨¼¤ÒäU$ùªÖîŸÇwAŒÚ$ûW¥7d6q­ÙTšOî6á¸TäíVåùUöÌ+ÏÕq•÷ÿg¸å‡réÿ’æµJòá“~±öÖPkã©e6áÌR!HmòäuÿÁÞàùÎÖÄKæè•<9鿸C܆fwÈ€ É69$Çä2‘#6Éjèu¡EÎw9ß²ƒß1ùOAd{˜äs“¥@þïƒÜ ,eÎaöv<­0ð^£Ð^Á¾èäByâi쇅ߩÐ^JÚqöQËZP-vidù8Çõ³l°r›ÐÃø -GzPÛMò¸¸;BÏ+]$¢œIXæHÒÄ©¿ ¿$œL6p{ ûáå -h]ÆÝ Ý:¾¡@kí;AAÒûÇÛdàå1ŒºV®ÂyÄ7Äèƒ0“W#ŽæqÀåå±YªE¿‚ ì8­S5cÇÄÝç¼Òõ\xE¼õ@ÿ0ªH©g£Ã0XƒaÀuðæv ãû›¸Ž·ñÎË)[O^ðÕ#cüm¼‘ÉÉ”é°Þ©ÙT™iFÖ»¸–ŒJí”Ö±s¦@žÈÎj‹ Øí6mè•1=*zVöàn´ -uXaû9:{T™ÊÏ¢ëEõ¸‹Iea0„0®Æ¤_¹§a%K3Ÿmã\¯G5 ò{¦`cŒ®½ åbU”°M -ÓŽÅI O¥l쭪ʠœËnç¢ßŠ¶ â´ªÛ̯ª€BUé®fB{ÆOnŠŸÜ[¼Ýhäó•º.~á8ÈÂ\Ãîœ)Ï0<‚,ê[Èoi]ç<·#Œ­6\Í\Û¿`oÖDPõÜ«ÅTU›º¤¼Á¨XŸˆ¸‹¸+'¯Øî’Ò(ˆy÷~.™lÝruÚ.¼Õ9”aµâêöƒÂF'0®:ÀÃÖ“éÎù‹pØ>ˆâªÁ[šJ* K"Ш3Ú½ÁwìB¥žFky­•p;V©j–†ðFËÅIÞÌi c¼ºlœŠHŒ*éÂÞF”úûƒáÞÁãÄGZ#_lH÷«‹’L}Ò¢…¶Sñ4IKtXRsQ¢Zrê,WrFÙE7ø*ñž0 ‰‘̦V7œYÇÿfyíÕB"±ÒñÅɤ^yo‘ä:¾7–U\¤NHÐŒ‹ümS˜uϦSj„ãÚ@h†"54)„† ÍoÚ‰C=¯Hê>/ñ¥T‚ë'ä'˜äùŠ8ò+˜‰oq-ëÀThˆÃú¸VŠ;šÚ -ƒ5•‰œ™ ÝO1÷•Bœ/¢ûûÿ@=,Èœâ7©¼s@tJ~M>kg½CM”Äþ73˜¿áá)ܬ“_àá>¾ëac܇\.…m²Žß{a]>„à±*4ˆf…ü”\ˆ5òQÕeß+x5¼ ³{Äká;4}Tuc3]´™reàkB8Ä Ny[ô\™6Š -çpYÞ•]kueõY縲©ÎБÁén,K-ÎåÄv§}—„,+í¦‰wù.¿"zjE¬¢Ì2Æ`ºy‹÷Z|àæ¿R-Kˆ…ÿ²¢ñ\ˇ¥Àæc 'çø°³°5ƒ]¹#šÀ,­{u¾êsÜÜ ^Ë›–›a[Ÿ‘o[ƒf^ Škð—WæÏo#…¿¶Ï˵_4+LÅ蔀Jx)9kŸD2jm.Lò·YäB¶À0C3Ëk¹Í´-ðûçø®ùBDÓÀh a¸jL7óŒB7ö¬KQèhžN¤Ô«¾nB-¶m _ÈàŒö·œÍK‹u¨_ Z*|_Âr|/‡Dýq(›Œcup»µøTGëUþfQô°(tt–5|ñG„É"Åh µÎꢲ6¨×¼ôK: ;É•JXô©i¦KJEåé9æÚU+ÏÇÓ Ñj…%«¾dÅžQï0”?c±»*—­XåôïFu5(Efî+ÆÙUiOf+Ï!ç±ÎbÒt®,Í-<°!áÔ¸BÂMô¥2”ÊpªÐ%«)ת<%k?€¨Ky3Ö-‹ˆ Á IÃ|{Oç¾Tj¨½ÂÄ\]²¢£@Yj4s‹Ó.ÏÙz3vǹD |Xa5éâ0EÀëKrî«ÊÒǦtl¯æ6Á[‡› -瘢J¹òè±iäG¤<(ÅãA_>UnßñQ8É(ä2åËëßq3aûÆcÁ¬>ü|Žéè:b½îõ»Ãœ¶¬(ÏÇa¡†1:}OÔKCUìßì07;Y)­Ðaq°äùôq8ÁÉÏJºÊ…³ã¹Z,e¥/§I-lZï…X!{Aå·ÉÊ’ê' 'ËåâÔzäãsXxs¦¤“M߶„uñ‹·0Ëî1É5’)ͧ=9¹pÙ[Á ˹i8‰eÊÞ5m¶ 8÷õÐj䮩åN¡ƒ{?uRk Vi–O.¯·&—õYç$—SÉežZn.–^ÖâÓF°„lHY¡ùNíJ*ýZØ©µPüEK6¹Àˆ-´ð¶"”.b[†s%ŽV€”ái–Àu&Ž·²BÛgE -ÖžéU“³JÆ•ï-€´m “&©£Ê!&‘¦žˆú!Jd>ÅçZsóv¦Èh£ù\BSIÍr”´FX×ϧÄÈfyƾF>Á÷úrÄüÿä3†ŠÔȔϤ¡ƒË< -1Àž«çˤ=ò€NNþ“²Ã%e™2„NÖ¤râÕàc¢È<ŠyDö–­I1ƒÎåZÆ ÉÉ?›VÉÿ¹d× -endstream -endobj -1670 0 obj -<>/Font<>>> -endobj -514 0 obj -<>/BS<>/Dest(RFC9499)/F 4/Rect[467.331293 693.391717 508.289057 679.792108]/Subtype/Link/Type/Annot>> -endobj -515 0 obj -<>/BS<>/Dest(figure-2)/F 4/Rect[65.905512 494.677889 103.991449 481.078279]/Subtype/Link/Type/Annot>> -endobj -516 0 obj -<>/BS<>/Dest(name-abnf-rules-for-vendor-speci)/F 4/Rect[109.45019 494.677889 332.334955 481.078279]/Subtype/Link/Type/Annot>> -endobj -517 0 obj -<>/BS<>/Dest(vendor-property-example)/F 4/Rect[414.952875 443.879061 454.029047 430.279451]/Subtype/Link/Type/Annot>> -endobj -518 0 obj -<>/BS<>/Dest(figure-3)/F 4/Rect[65.905512 346.844451 103.991449 333.244842]/Subtype/Link/Type/Annot>> -endobj -519 0 obj -<>/BS<>/Dest(name-examples-of-vendor-specific)/F 4/Rect[109.45019 346.844451 290.297602 333.244842]/Subtype/Link/Type/Annot>> -endobj -520 0 obj -<>/BS<>/Dest(section-1.8.2)/F 4/Rect[65.905512 321.744842 99.092035 308.744842]/Subtype/Link/Type/Annot>> -endobj -521 0 obj -<>/BS<>/Dest(name-vendor-specific-values)/F 4/Rect[99.092035 321.744842 213.809076 308.744842]/Subtype/Link/Type/Annot>> -endobj -522 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[137.42724 290.145233 167.224359 276.545623]/Subtype/Link/Type/Annot>> -endobj -523 0 obj -<>/BS<>/Dest(kind)/F 4/Rect[173.282953 290.145233 232.297846 276.545623]/Subtype/Link/Type/Annot>> -endobj -524 0 obj -<>/BS<>/Dest(vendor-specific-properties)/F 4/Rect[215.528315 262.946014 274.543207 249.346404]/Subtype/Link/Type/Annot>> -endobj -525 0 obj -<>/BS<>/Dest(vendor-value-example)/F 4/Rect[355.714594 262.946014 394.790766 249.346404]/Subtype/Link/Type/Annot>> -endobj -526 0 obj -<>/BS<>/Dest(figure-4)/F 4/Rect[65.905512 197.831404 103.991449 184.231795]/Subtype/Link/Type/Annot>> -endobj -527 0 obj -<>/BS<>/Dest(name-example-of-a-vendor-specifi)/F 4/Rect[109.45019 197.831404 271.861811 184.231795]/Subtype/Link/Type/Annot>> -endobj -2740 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2739 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2738 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2737 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2736 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2735 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2734 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2733 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2732 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2731 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2730 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2729 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2728 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2727 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1807 0 obj -<>stream -xœ½Z[oÇ^€ð Ô_b·ÒÔâõÜ//E‘R¥°’HK¢d³MPåÅ.´}èOï™33»;³Ë%×’kZäÞfÎeÎå;gvB'>¯Ý´4Æj%&?}ÿ2.µÄ›ñ/þ2†3­&JðR¢ž-K!ˆròë?Æëñ?Çtâ>¿þ<~ówZ’ÉÏÿ»ñÚVC(e¬”Ô*ƒcnÇKøÀÔÔÄ'€ÊG$%'ÉÉ}w¾þˆ•fâÿ7éí`ÒOœÜÖÛ·ßæìXÉâ}d«qþÁŸÓÆys\ãúgf7ý””»“ü·Iöû‹qµþF—F B¥!fB…-¥fÒÒÉÅÇñ›Óù»ãÃï'”—8‡§&·ã÷/‹yñ¾X—¯yYL‹ß£bY¬àÊÎÞÂç¬X38>„£yqðêo'ãà \î»1HE)‰¢`?ŽÁ¿œ/OÏOºü²8(žÃßøsÇ#d¡š”‚N…ÚˆlÊ\¶l˜¶¥¡„ÑŽaÆeI‰U–ï¯U]üÔGÅ%|_ÁßeqßGpå-¯àÛ][› \z€ ¦Ì -ø~P=~‹p„Sàè—e¿sX¬5Ü¿Ä;ïàÞ»¥kÊä'a1Ô„* V)Aþ%Œ?GöÝlS4†R˜…Ù¦p¾Äû+4˜9Šw Ç+xfV\ãñÇtñ‚.ñæÆK¯ U|Ï-‘ é®Àðþ -ãܬ}ñ]KzÇßG]mÑÈÒpÃàЋxCN@¸5ªmŠEqÎÑòG IJ8Eox‡¼®P¨${„g@À·ÈÜbóãà'—tÖÌO<ÅáS¸³¨ª¹jîÛë9®ÀC8>FÖ[%c„—Vƒ!Û Y=Éb‹¹Ô -kñ½+8ø£ãº$\ ¾¯“?íppÎJH6<5†™l‰x[û™/k -´¥"“etSAd®©;¿×>½qÕï˜Á­k|Ð;P—á$S4–ð¹ùvǪ½×@nÆÞƒg÷‰ R*k!YyýôYR0Ó0ñ.B,ƒ~1xÇHÑŠÖý€¬ ÍØ@--!›r!2j=¥Bðv#Å—[ÉתI›)[ZFÒûÓöpÜÐïþæ"üæë‡ÕÀåŽ@ܲ¤te8ÄxeUŒw–“ÛLwꙆ,°l0æåZ§™&¬:™R^uHßH¡ÛœxªMŒç9¯r|ÔÝÎôÞ§hš © ¯ìsW¨­ýjVék^åñk{T]뺙:”u%h'W#œåÌÛ†SËzp¼êÈ[©2 ÌH¥á'Ðüddrrf½€nÉNzpLTé4¯íÙe¾ÃæÑ_z¤„_W,Q++«÷ ê >Ž\^¡4×~Šš5Äš%ÙgQeÜ d¨Ö $[…œVç_Gù ->1{ßT®}\4ë&ÇaLUÁú¥PŠ@ØÃm‰¶™.c´‰¶åÉt°¯(bðª9¸+¾cJc&¥ÎSg…îXˆžà™B½ê»Uˆ•s¼{ˆ‚hÁî‡åº$Ü€¨i üœR  ÓÂ?ÖŽ4Ÿ“nj’• ¶ bOÿ¬§ÓÁ°C\×hÓM'tÎk_)¯ÂŒ>b7G¹¸î[%ú”aYQ«b]œ’ŽA~;ªœ70RŒþ׋² -‚^bL½ÂÙŽC¾šbëÍRX-(¿F'^Ùžº_’\)7Û &\R—BÁ"$!$(«Cj7jw²ˆ%†òöDŸ„[Pg™d„—Šj@‹4RûÊ”Þ'·p9’Ô=ªN4³3ð%•Iw ²”0`=[˜žHñ 3ûV­È°±×Tèe¬Ìö/g¤u|J¡ð9*~3¼fSD–®QûÊk6׺}>P@À·%1Üj½?ÝÍíÑ !%ÑŠ*‘Yïòín³ƒÜU - FmNw»´}x¨5QÀÚJIÛûž­I:¬+Ä 9»:/àïñ`—1%e‚íOû1cKP3˳j@¨ð‰é’3o”É0ć–¦!¨<¥B jÕ).T©„”€¯Á¾[4úàp)EA|ޡɜюfhärKEÜ(ëºÓˆ›ÁXtÖ›þ)§® -¿oâáM3r_%_²Ò§.JƬƒ£±&¯²é5æÓcl§åðÇ£·³ª¢«‹ÕQõ\W‘{€ø/b•®J¯†o˜cÄ#ÒÈÅöB8Ðé“p7šâFŽ«-Z½¥]d"°ò›\‹0f]¦P>o®‚ú²vzœþ$à¿æ&fmJ9°ñÛYïúÄÖÄí8Öñ.[õØz[vo§÷Øo””–(3¦‡äîQV(SÁ¬¢ûÓ<ø$á´€TBµ±Ÿ.\¬Y§ ˆ„N(6YÔØL«wJ0ôY1¥bºÞPðQë&ĹÚë£gïÂîó¤j¸‡ÎP®f.à -FÔmƒ[¶öë¶A:Ý~yoçf Ôc9á€õ[ó÷å<-\ÎãîÝa9ogW6ÙPh•oœ™ÒXêPZÊZ×f¬ËÂoi7ßØ£1Œ†ù>XOÚ8¬StsWÊG´¾”¨•K‰JK“ÄÉ#ÌZ­¹£7<vµZõBÄ×ÅÀ¬7¯Üh´aàô•&/=L¤w›¯5¬05ÄÞDtšóbûNOŸ ò ´R¨È²]Ä&WÖ![x÷ -ç€Î:iyMøåq³ŸWïgÔ"_#e/lÄ;—¸Öi£º…ôÈnˆ ¬Þ‹è†+é.ç<À¬­ºŽMŸ¸©¼¥y°›ˆh|_ÍIqS5‡êiÿ˜è‚VºPÑê|@ÏÝ…ÍmC7ª`ðàwð(ßɳ˜øì -"ÀYÈy‚Õf×ß5Ð…%pXû™Óô¬Ê¢‚ A§¡é朡Äžì»j÷7bÓ£êžóÖ×(Ådµj€äL«’¨Òj#·ðU¯xíd.u÷ÍËAGÊ¥, ~Æí>H©…§ÚÑï³n:qÈè€ÌÂ@OÆÿÓ'4ظ)©¶jéÌýM_OŠ§C[k–•Ú¸go‚¾Wt˜ÆÊûÕ'çöÆ0ûÞ„…>¨P*tÉ\-Âö'xg…Rˆ‚J\Å$Ôþ¿öD…3Rø^H+*Ýï’ -ЯT†K6ˆRXÓ¯ŠßÁª}_H(>4ÖÎCh&Ë5KpÒmz¿—¼PA8Õéü,•d’<ƒÏ“|éú pe]ÔÖn¯`¡ÖFÆ0JÊA~´ØM‰4{1ƒ?F̽´ï6s¥æ’vÒP˜Nß"|˜§@hóoøzS¬6·ÿ …ðj .%$#«ù>Ä=nqH푇nà’ÓªÕbŒUr§Ô<4¾\{ãYnŽËñÿ̪} -endstream -endobj -1668 0 obj -<>/Font<>>> -endobj -492 0 obj -<>/BS<>/Dest(section-1.7.3.1)/F 4/Rect[65.905512 766.389764 107.621088 753.389764]/Subtype/Link/Type/Annot>> -endobj -493 0 obj -<>/BS<>/Dest(name-extra)/F 4/Rect[107.621088 766.389764 134.85766 753.389764]/Subtype/Link/Type/Annot>> -endobj -494 0 obj -<>/BS<>/Dest(section-1.7.4)/F 4/Rect[65.905512 674.491326 99.092035 661.491326]/Subtype/Link/Type/Annot>> -endobj -495 0 obj -<>/BS<>/Dest(name-unknown-properties)/F 4/Rect[99.092035 674.491326 203.501703 661.491326]/Subtype/Link/Type/Annot>> -endobj -496 0 obj -<>/BS<>/Dest(case-sensitivity)/F 4/Rect[143.426508 615.692498 202.4414 602.092889]/Subtype/Link/Type/Annot>> -endobj -497 0 obj -<>/BS<>/Dest(section-1.7.5)/F 4/Rect[65.905512 512.594842 99.092035 499.594842]/Subtype/Link/Type/Annot>> -endobj -498 0 obj -<>/BS<>/Dest(name-enumerated-values)/F 4/Rect[99.092035 512.594842 197.540522 499.594842]/Subtype/Link/Type/Annot>> -endobj -499 0 obj -<>/BS<>/Dest(iana-enum-registry)/F 4/Rect[290.326899 467.395623 447.829096 453.796014]/Subtype/Link/Type/Annot>> -endobj -500 0 obj -<>/BS<>/Dest(iana-enum-registry)/F 4/Rect[453.88769 467.395623 504.812983 453.796014]/Subtype/Link/Type/Annot>> -endobj -501 0 obj -<>/BS<>/Dest(vendor-specific-values)/F 4/Rect[310.852289 453.796014 383.824945 440.196404]/Subtype/Link/Type/Annot>> -endobj -502 0 obj -<>/BS<>/Dest(vendor-specific-values)/F 4/Rect[389.883539 453.796014 448.898432 440.196404]/Subtype/Link/Type/Annot>> -endobj -503 0 obj -<>/BS<>/Dest(section-1.8)/F 4/Rect[65.905512 412.096795 95.494623 396.496795]/Subtype/Link/Type/Annot>> -endobj -504 0 obj -<>/BS<>/Dest(name-vendor-specific-extensions)/F 4/Rect[95.494623 412.096795 259.984125 396.496795]/Subtype/Link/Type/Annot>> -endobj -505 0 obj -<>/BS<>/Dest(iana-considerations)/F 4/Rect[308.196527 349.697967 351.032221 336.098358]/Subtype/Link/Type/Annot>> -endobj -506 0 obj -<>/BS<>/Dest(iana-registered-properties)/F 4/Rect[356.131342 349.697967 415.146234 336.098358]/Subtype/Link/Type/Annot>> -endobj -507 0 obj -<>/BS<>/Dest(section-1.8.1)/F 4/Rect[65.905512 310.998748 99.092035 297.998748]/Subtype/Link/Type/Annot>> -endobj -508 0 obj -<>/BS<>/Dest(name-vendor-specific-properties)/F 4/Rect[99.092035 310.998748 233.947748 297.998748]/Subtype/Link/Type/Annot>> -endobj -509 0 obj -<>/BS<>/Dest(RFC1034)/F 4/Rect[478.63476 252.19992 519.592524 238.600311]/Subtype/Link/Type/Annot>> -endobj -510 0 obj -<>/BS<>/Dest(RFC1035)/F 4/Rect[69.505365 238.600311 110.463129 225.000701]/Subtype/Link/Type/Annot>> -endobj -511 0 obj -<>/BS<>/Dest(RFC6901)/F 4/Rect[335.676264 211.401092 376.634027 197.801483]/Subtype/Link/Type/Annot>> -endobj -2760 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2759 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2758 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2757 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2756 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2755 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2754 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2753 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2752 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2751 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2750 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2749 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2748 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2747 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2746 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2745 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2744 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2743 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2742 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2741 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1806 0 obj -<>stream -xœ½[ÍoÛÈ' ìE ÔÔI»- ƒëÆiv2ß—¢ØJ²â¸‘¿;î¡-ê½$vÛcýÓûæÍ É!)Š²ã¬V¢E‘ó¾ßû½7Ì„M(¼~ð+±Ö-'ÿø4þyLŒÂÓOþ<†oFO´ÄPj¬™X£ˆ”ÔI5ùåŸãÕø_c6ñ¯_~¿þ#tòÓ¿Çþ~ãÊ[ãœ(æ´Å{îÆ§ð‚¥™MW•OHJM>F’³ßý÷ÕK Fì$ü_§·É°pö³©ý|÷²ÉŽS<ýŽlÕ¾ ßYí{ý¾ÚùGf·z&ü“æ±NòÇ‹qi{kˆ5’2e©0!‰¦–ŸŸÆ¯ÿ|rúîähÂôäânüáE±[<)¾ƒ÷èà¯GÕŒ"¸fà<ùp‹;ÐôE1-–ÅqqÇO‹£bTüPèb¿8ƒo+8?/Vù¢ÜqÂ8eÔµmÐÏEÐ ¤p\Þ-nÞÌ~„%ªAÀUQS¼^®€“«â¼XÇ·ÿ/“ž±°ì/IL¿ÇooábÛ Ž«â>xí -~¹Äo£âÞqˆ×oàó~;CB—¸^XÃ_/‘RPÌuC]ž“ßÂùWÅ^ÁàýMŸôÆf85B€5‚¶ Ç¿®ågŠ\@ÒS᮸AÙº®Þó7¨Ä9|ŽPŠêláy —ÊIÚöºN‚íÔˆ^£"áüe¿üJkE”°aÀ‡³‹Ägí`rþÀq>žêa$¤&Šs©Dƒ½Ô™&F^ßÃ{w-ù*–ë´%W„SÈÞf8mbp¥Ž(D‡‰¼¢Õ¼Z*ÇôßßËpˆïÛÛÒÏᦫãqÙMíT4Þ:G ÖÉé>é[,਀J®Ü»Ô|úl•ý*úÅ}Ôs1‚Ïiô’œ;”3¬yÝÖǨwب‚KüPNÊêÙL¥Wç—¥xó¢…œ{‰Fš"þ8lEpJõóR-W µ,p]I–xO_}Òe€qa¢ŽÅ`s‰uß/¸ ¢]ap&ŽÎÊäƒù=•žÎǘO;‚ñ -SÓ+ó™K%fZ»¢™R#ÌY.d›ÙÆ´×ß2拼Oέ¤2e“io-ï´éN¿gì”Uoˆ¹G(Æ2•ŒãÛ»ÿá¢W¥º“ø"扞Ä{új‡d>M@\ðfÒ ô«rXC+]Z½ŽÌ¤<[GÀUrŸFX´Þä©ZGÿ>ØÆüÑŸËœ~Ö＇;§MCI5i?’mÆrS ’k9/—ă7È*-NÖ¢ûàie±Ðøi× ³%žöéùù–x:×·t€W¹´fõ†ߢç$¿É£zHwõàò-&ÌBÐ4ó :š¬“®°P¿•œ·\æ¯Ûv?Öƒ~ßXÆÕp’£âëí½RJF¤¡¾y¹·W>€áé–r*N S†³-"âöî³#i9‘ÎZ'£§½À(_n+'…êœYˆvœä‹ f‰––ÑŽÅû°’¢šXgµØÔ6‡Ž¨âsÈl¥Ö4f¨ãªª¼¼µzVŽ—ºIùŒ?ÇúV ò>$2Û'=÷0IÙÝ’#guê—éÔûX¿F‘Ù38³ÂJ÷Ði -pÀ -Ý`n‹8{¶e| pCý`u8ÍÐ$wÁçTì7ÃÖŒwúì%=Þ‘qÄ løUç±êNPáÖ¼Ø×áX øêÿaÀ}§Ý×ùæª,}³e$Ñ”/ËL° æÌå(À…öBÍqj-"†o²d0]ÚJ~£I)€Ñ‚ªêS÷Ó‚³4]h‚„<ªûàç½J› œÃ(À…œ•/¸„…Ê£Œ¦n8íÛ»ÚP¨=6“š®¸ÒÒlð×ú„3ï‡zý£Ç„šQ¨"šr×™G#®+Â0pmèîÎ"/û®0M\á”rQóµúgiF{’Õ'&w„r[ Zg˜ö+ê æccïª&Içdks9ë -Àž œf'´6÷Ŧ–.«¯eÕHDše³·ôNéÖ5€f¸1εðÑ`ÜQf¼ --´ÚvС ‚†ƒ†öPë¯àUýv‰†¡ NËR1y ůŠ_ÇW²d:·[Ü0W_±ÓÐÆ@fÐ,5÷éöïàvŸv²þ–¯áÍ2âÏ€ýxa¤Ë%\Âcãã·)÷ðÓ€”a -7ª‚d‹=…׆ܣ¬ ŽqFy›ûl²VË=úà IFıއ°·zÌXµqÖÕg˜ -gVY¤RËèPÀ4•0Áï­—ð6 à·v÷¬üŠj…ß2ЪQ®ëã®Ü Þ~^·/ -…lï£Ï¿öLEÛÔmñÞ`‹u’>¹T_2ìªCÖ!IÿþdèÞ\5Š Û$´ -°Är6¡æ‘eQÅ<à”jp¯>ÇJ:Òç†pÀ×Я6êûãŽ" ¡ÔÓäùø‘FL»4ÙLï^`P(¨Q¹á„>ׂ+Eœæ~‹y0í‡Ï!¸³DXiT³\õ¹HÉÊÿ@”´wßàÏ“ú#û°Ò–P©­6Ôß;¥8Ç”vŠ(ê¨áw÷x¬@Câ]*†SFÐùYgNy¦í!ýÇíÃÈy!/AVVà )<ö‹o!‚žmÝê0ÐÙðáÿôP…jéÇbiDÚ û¥vU•„s%UžùןõóåÐ,áqKLáƒÆ…Üçkj¨uíåúÆ…ð† ¤˜Û4ºß¤a{¶Y9[ÉåºOwo±Lù¡ü`æ[5o“­‡óŽPÃéFt½ÕêqÊPHP9ÌI^}}{j–CBWµ »íâ1æuÙ–N;mSußëçEõqœ_7íOÖŸN«F„kmâi›sY,û¤•>™Sø“Ѥ£&KÇå&‹nRëâw×WE¾YÞ9-<U>TíŠzwŸ¡¡¿B÷¹ÏaäqÖ'¯ït¹ˆÃ}¶zÖŸV¨ÏKkÛà¡UWÐõ¤gÒ†Š²·iǹù¨]{Ž;íÖÿjãF±µ¾ãÐÕTפ÷Ü Õ3FÇq¶_ã´1J€š¦7Ü´‰¦,6qëgZUþþtôÓÕ\¹!O÷å2^Ŧ{'OS Ç9öγÈÝ ›/hÈÌçxžJBrö \ø… ¬*a©i:ÇP S\q£ ËÃ¾Ë “'{žC¨Qñ€QßVUeeÛ ]ìFBÝ™¦¤5  -}ëfJ´˜V¡þEÏ·#æÿ)ï딊uÒП瘳Å; tûøx]œùiBPm©KE¡…³ÚšÄÓó«—ñÑvS›¹¼ÛRµFvZm”ZÀòG½»¹JÃëÿ¨¬% -endstream -endobj -1666 0 obj -<>/Font<>>> -endobj -471 0 obj -<>/BS<>/Dest(section-1.7)/F 4/Rect[65.905512 753.389764 95.494623 737.789764]/Subtype/Link/Type/Annot>> -endobj -472 0 obj -<>/BS<>/Dest(name-validating-jscontact)/F 4/Rect[95.494623 753.389764 219.090082 737.789764]/Subtype/Link/Type/Annot>> -endobj -473 0 obj -<>/BS<>/Dest(vendor-specific-properties)/F 4/Rect[259.89184 704.590545 318.906733 690.990936]/Subtype/Link/Type/Annot>> -endobj -474 0 obj -<>/BS<>/Dest(section-1.7.1)/F 4/Rect[65.905512 601.492889 99.092035 588.492889]/Subtype/Link/Type/Annot>> -endobj -475 0 obj -<>/BS<>/Dest(name-case-sensitivity)/F 4/Rect[99.092035 601.492889 179.073236 588.492889]/Subtype/Link/Type/Annot>> -endobj -476 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[289.267816 529.094451 325.044428 515.494842]/Subtype/Link/Type/Annot>> -endobj -477 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[331.103022 529.094451 390.117914 515.494842]/Subtype/Link/Type/Annot>> -endobj -478 0 obj -<>/BS<>/Dest(unknown-properties)/F 4/Rect[442.360102 529.094451 501.374994 515.494842]/Subtype/Link/Type/Annot>> -endobj -479 0 obj -<>/BS<>/Dest(section-1.7.2)/F 4/Rect[65.905512 490.395233 99.092035 477.395233]/Subtype/Link/Type/Annot>> -endobj -480 0 obj -<>/BS<>/Dest(name-iana-registered-properties)/F 4/Rect[99.092035 490.395233 238.986078 477.395233]/Subtype/Link/Type/Annot>> -endobj -481 0 obj -<>/BS<>/Dest(iana-considerations)/F 4/Rect[244.192377 458.795623 287.02807 445.196014]/Subtype/Link/Type/Annot>> -endobj -482 0 obj -<>/BS<>/Dest(unknown-properties)/F 4/Rect[226.778315 407.996795 285.793207 394.397186]/Subtype/Link/Type/Annot>> -endobj -483 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[91.122065 367.197967 126.898676 353.598358]/Subtype/Link/Type/Annot>> -endobj -484 0 obj -<>/BS<>/Dest(prop-version)/F 4/Rect[132.95727 367.197967 191.972162 353.598358]/Subtype/Link/Type/Annot>> -endobj -485 0 obj -<>/AP<>/BS<>/F 4/Rect[426.03515 316.399139 489.509027 302.799529]/Subtype/Link/Type/Annot>> -endobj -486 0 obj -<>/BS<>/Dest(RFC5234)/F 4/Rect[69.505365 302.799529 110.463129 289.19992]/Subtype/Link/Type/Annot>> -endobj -487 0 obj -<>/BS<>/Dest(section-1.7.3)/F 4/Rect[65.905512 264.100311 99.092035 251.100311]/Subtype/Link/Type/Annot>> -endobj -488 0 obj -<>/BS<>/Dest(name-reserved-properties)/F 4/Rect[99.092035 264.100311 201.830316 251.100311]/Subtype/Link/Type/Annot>> -endobj -489 0 obj -<>/BS<>/Dest(iana-registry-policy)/F 4/Rect[278.861566 246.100311 329.786859 232.500701]/Subtype/Link/Type/Annot>> -endobj -2779 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2778 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2777 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2776 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2775 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2774 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2773 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2772 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2771 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2770 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2769 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2768 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2767 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2766 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2765 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2764 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2763 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2762 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2761 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1805 0 obj -<>stream -xœµZ[oǃõ ý`•¦u¢QËŽGsÙ¹EѺII¬$R"%9 ‚´¨ó »€Ó¢m€>ô5@ŸúÖßÙ?Ð3gfÈÙ]rIZ‰irÅÙs¿|g—Þaðzá¶àÔZgtÑùãÛö»65 -O¦#.¾kÃ7£;ºÔ0f¬éX£hQ0W¨Î7j_´ÿÜæÿúæëöîWœ²Î×iûýÆͶp.UÜi‹{^·‡ðÒܦ+€Ë[d¥:o"Ë7¥óþûÅ3`Fm'üÏù­2.6Ùé×Ϫâ8%Òy+ûþ&|çÙ÷|_¶þ‹;Q.ý¿Nõ˜³|yÞžùÞjMÁ¸²Ìv8³TH'”휿mï÷_ì¿ìpI‘†„«:ç¯ÛŸ?%†‘>i‘2"'ð‘Wd@†äÖúäs²GNɬûkxÅ%™ 2Þì)œ½€38wéœÁqûû°2 ]\ÃʬŒam:ÌÆpÜ#­/Îç:h¦¨ÕZ0YÑ$ý9^ºÃlœ?gÜRÆR­¸Tn} ÑýĽÁ-9'Å ZX o,ë3k‘;K•Ô+ñòy¨„ðZ›‘tÑGÞ[-ò€ÜÇ÷Ö†zjÆ©PÒº ,:}]ue9v¤Ö¼€dâ†B–¥;G:«OêF "!§µ4®p(ìÑo'Ç'‹…ÝBÔ‡ˆ÷1¾UZ.}P)¡u…ªÚj„óByG*»àâéÓJ S0K¤•Œ-I­”·Øã®æqî,eÎ ÈŸèñ÷ÜF};4¼S=B ¬ÓÒ²Ä[ügpÖ–ÔsÕ\@ ¸±FÐ(ÖÌM¹© -¦- Tc¸¯Æ/÷ÕøÏÙ"†ûµøG>;ð÷WäùG%€3¢ª5Ø@Èèã[ðº&É3¿ÿ¹?ìøØ%4Rû[= áÊZ—Ñ 4ŸmOç£Håšüx ~M¾\NÒT°¤w‰$5?!l¦ç5¹¼Š¢€*縅¨Q|»£Î» ÞãáïÚ¬"Ö¬þ£ÿ„ –»å£U‚À»‡ƒ«Ãýþ" -ÿ[Eá¿«dž#×Ë #¤RÇrï}K¾l !! V+S÷OÍåœõ¢ž ^òÍ,ôRÝï[žÞ6øìãfšîZU\åyzút•éÍ -Óßúw³å£VAƒT%Ëÿ½IÈ &g¢”º5=¶HìúD{:Sj®{Ô ô@NÐíÛ¼ß/…oµoçý+l*ïþîtx|z)†ê ™á]m¾ÂP)4‡á¨L¶| - î;éamF{Љä‹ùJ™ p‚U“hÖð‹_øâÎû«Pé´ê'(ÉÈà›oÕhßtàs[²‡å¡U'0XªQ (å4'Huˆ»÷à³{<¬Ÿ õ¼Žá¯RÙóf…$áßû@m:Ýq€î¢@~fðB^!£KO¦ÉZ¡ÔŽ¥H™À–.€ŒH"øn0£¼·Ž#P; ˆ(É+|…Æ€ÊO9=Ü’&?óÌA×I\¹„ãaE€.¬žÝË(„7ˆŸ£ͺª‚rí ³Pœfê–QxéuîÝ:itc)03Ç \}r/®œ.óÌÌ̯Ð\'³ïè ²Ý -¯¡ÆÝ8 -ÑÒ*Lr–W^)¯Â`ú‡¢žÃà¡àä¦r¿ ‚‘Pjë¤+ez=URÎo-È{)( ;Ë -¹ÐÕ’µ¦;‡“ÒfGbÙ*YQËÜ -W'×”õJ8 -EQ›U’,̃èª#pÎÕl8ßÀÉe‘@\ @‘¬„ãç¼0Ä1ù©tÃÎ'Ýs䆄”8!t<™^]”;%Y7†rS¢¨ÂG^¸”%E ؛ŨÏb_£V¸'s'œTHÊñÞÅ,®ëy‰b÷à=.åd(—~;€µ{XMî!§C ~‘U…ùZº*îjRUûúWH–²%yðîÒÔÜosîß R¤T=òÉ’Ý¥ð÷uåbFâÉb'΄ªÖ­816in}54œ'àW¿!#ª’{œÁ\)ýˆY#áýþél|>eg^!'1lsÍÖ2gY@WƒJÕEh¡éŽg· -&±I„Ñy}ÓG5G3A@i‘òrÁ=´yX‡`j§Zñ*Œ÷ÙÈ>ŽùTMÆ™Ìòv>Ú—£å— Ú†ÏC ˜Àí´±’kÁh!…)ø¬54úªâx]À”îo—Ö …0ô¶>­ØzYÛKwVzä÷èÀ¾z³2Y3¡‹p¶;C=¤4nÒYZª`üT)Á½)'¨õ^ª«Õ¢¼¹!Úµv^Üg¾|ƒönæÅÅÚ¶`ÿaÐ0ÃVóø w˜†¥²¶×¤Ò¦©ußÆ+ŸÎ5oE=JKC„– ÖŽq_Œákë!fñ®6†œõ ®0F¬ 4‚‡29Ø1Leƒú -ཨoh‚ÀŠI¡¸XãÞ-bÙXO–n9éSx ÐèyP•ËI>VìaIðZfµÞ¹›Ø>+ÒÌ0ÛÂ(ëäkt“¤/{~j¯!e0IpY'ÔT–G$ Oe+¶â1‡{™ƒ°À Ëæ¥' ,š›4W¾¢1.MØ wÇ‹~z•¾î!KºbŒÑËœµwÕã[É" |†¨*r”Ü@¨B”OUÃ8W5á™PÅünpó´4© ØÜÎA–äƒûVÇæ<&±Î´b[óUê4Vš|¢ -Ÿ™ÎM:Z_ •Ñby©ŸKycâ26©P´?#ÏÉöŽfþ©Üg¸åYܱ Ç],ÝÉù5 òŽÑ\w0Âþ5ofde~‚ÑÞ…u¸ªAKË -j…U&¥Ö²8»"UQÝàžŸÁû¡û<Cj¡„:Wç…{BŽ^Åù}‚Mí¿íÍF‘J™s0¾¬fÞ#z””Ô:W€q×f£üž'PwAýùpÓ‡ùޛ̵H»qeÞ,ã™…ÐêßHH+¨¶B3Wüšàá{ü’ fÊJÿ 4[›ušnÞ#Ž -SPÿ è/k³+ÅÑO7#È%5U¤õƒÆ‘.¢¬¯å†úý&¥€¾ âo̬Íf๚ö†–•4çZ¹b}î%Ë&ë2¤¸Ì–‘•£T8„Ë9}QÈOàõ°ê¾f£5Ò~%£ÆÝŒ“ÖþÉ8vˆUœX`ÃûƒÍ˜ù×C!×dxöQã¡!†ëãã¦é_ôŽ¦¯ÿgÿц¶„ãÚ%×ažƒiM†i74-¤‚°N«•ZËøt©E¶Ê‘^ÿ%R7 -endstream -endobj -1664 0 obj -<>/Font<>>> -endobj -454 0 obj -<>/BS<>/Dest(name-prop)/F 4/Rect[358.98852 771.389764 385.866938 757.790154]/Subtype/Link/Type/Annot>> -endobj -455 0 obj -<>/BS<>/Dest(name-prop)/F 4/Rect[391.925531 771.389764 450.940424 757.790154]/Subtype/Link/Type/Annot>> -endobj -456 0 obj -<>/BS<>/Dest(figure-1)/F 4/Rect[65.905512 588.840745 103.991449 575.241136]/Subtype/Link/Type/Annot>> -endobj -457 0 obj -<>/BS<>/Dest(name-example-of-a-phonetic-prope)/F 4/Rect[109.45019 588.840745 502.506586 575.241136]/Subtype/Link/Type/Annot>> -endobj -458 0 obj -<>/BS<>/Dest(section-1.6)/F 4/Rect[65.905512 560.741136 95.494623 545.141136]/Subtype/Link/Type/Annot>> -endobj -459 0 obj -<>/BS<>/Dest(name-internationalization)/F 4/Rect[95.494623 560.741136 219.546381 545.141136]/Subtype/Link/Type/Annot>> -endobj -460 0 obj -<>/BS<>/Dest(section-1.6.1)/F 4/Rect[65.905512 473.242698 99.092035 460.242698]/Subtype/Link/Type/Annot>> -endobj -461 0 obj -<>/BS<>/Dest(name-free-form-text)/F 4/Rect[99.092035 473.242698 177.122797 460.242698]/Subtype/Link/Type/Annot>> -endobj -462 0 obj -<>/BS<>/Dest(UBiDi)/F 4/Rect[126.998285 414.44387 154.375483 400.844261]/Subtype/Link/Type/Annot>> -endobj -463 0 obj -<>/BS<>/Dest(section-1.6.2)/F 4/Rect[65.905512 334.945823 99.092035 321.945823]/Subtype/Link/Type/Annot>> -endobj -464 0 obj -<>/BS<>/Dest(name-uris)/F 4/Rect[99.092035 334.945823 122.519281 321.945823]/Subtype/Link/Type/Annot>> -endobj -465 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[400.424555 316.945823 441.382318 303.346214]/Subtype/Link/Type/Annot>> -endobj -466 0 obj -<>/AP<>/BS<>/F 4/Rect[287.011957 289.746605 337.93725 276.146995]/Subtype/Link/Type/Annot>> -endobj -467 0 obj -<>/BS<>/Dest(RFC3987)/F 4/Rect[356.19433 289.746605 397.152094 276.146995]/Subtype/Link/Type/Annot>> -endobj -468 0 obj -<>/BS<>/Dest(WHATWG-URL)/F 4/Rect[206.819086 248.947776 278.262445 235.348167]/Subtype/Link/Type/Annot>> -endobj -2794 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2793 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2792 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2791 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2790 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2789 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2788 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2787 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2786 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2785 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2784 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2783 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2782 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2781 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2780 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1804 0 obj -<>stream -xœ½[[oÇ^”È Ô1"ÇN|0 +Çs¿¼AJI´ÄX¤d.eGyH‹:/v¤}ìCzÏœ]îÌ^¸«KÂP˽̜û9ß™YÏØŒÂç¥?XɈµÎh9ûǧé¯SbÞ,xñ×)œ=ÓRC©±ff"RR'Õì·N·ÓMÙÌ~ûeúêgFèì—Oýxãª!ŒqNsÚâ˜Ó5|`jfË'€Ê'$¥fÉÑ}¾ýˆ;+þ¯ÓÛÃd1qtÛÔnø&eÇ)^ÞG¶jç‹sV;¯«]¿gvãaÂÿ7Ku²ß¿Vö·†X#)S–ÚÓŠ(Õc³·Ÿ¦¯Þ,Þ¿>ú~ÆÁ9<5{ûaúã‹ì<›gGÙŽO³I¦³m¶É–Ù:;ÍþôötzôM{;f8œ ФEfþ¶Z¿Y¶1s=ÌžÀ÷|'H¾š NÀç “Étu’! £¬Tº9$Ý2 ãLלÉ΀椦ÁÎæð7Ï.²cÐâ´¹ÈNàê{8ÛÂóüëGÃ3k8›Ã¯-œŸàÓs/8Xá -®ž5æ^eóCN_d××pr„Óäð× Ómàx ÃüÄ‹D>ìòYï„JRT±j+œnÓ=€Ižp|ŽòœÀg×r$V<1‡Q^®‹ ']êl¸˜ãì9ÚûÇôZ´Ñ-(sÄF¹ ‚!±Ø+6ðë2°Ö¢Ô Êë9Y3uËØ&ÙÎ#r¸âm·€ó¼ -ãEî$µqG‰¦vO€^"#¯1±Ydg B­ÑÄߢw—⸄ -#…˜â¾ìMqñt;YÒš€ÉµjHæ†0 TZ¦Ýpý= žãu¸ÀãÍ=A¯: ÞTúX2ÞMŠ{+tó%Þ÷!p}x(Á¯Ša‹ìG¸½Bw\„Ü2 ®š¯Œòžšw=á ¨%Ž -Á©`<(c Á±7±íœ¸.µÔ‹*ßÆR¦É3/_Wif¼¬•WI‰ÐNê2G•5åÆÚ•ÿؤSÒZÆ­n_²Yd©²Ö”qì«úŽ½ƒJ´ƒì øxÓ¼‚ó÷Aìy|Ôu‰‚žTãçh\e-ð¶|‡ù ©u+@8|ÞÅ~ùÛƒHÇAȤxç¸Ù®>vƒ¶ñ"}‹Â®‘Ñvo^¢€E%Ý•¥º‡ùvÎ’3É™0šh¡h);¹´`­t©9²TÓktÞ-h§†%8 £Œ H· RÎ>ýx Ï‹„пþûC&-mƒæ®i#8Ç@ÝE1ã­á“BÁ%ˆEŸŒ\± K/Ú“aúÅÝ%·¼æx…»§‹³*ôc4µC2K|v’¿Ö¨Ž¾èRBxk«Ë<¶@-žEÀëaZ`ÇÖ1fQB2Ó|RU1 -…2ª1—˜[­å€(8ƽ5”И¦Ž^(QZx‹H¨·Wº5[†r04"r$[Á×®oï›EéwÂ÷¯#Y,+yŽYhum§ô=6=´í|Ü‹Éâ隢%#¼9sͱ ™ˆo…‹ {Z‰|:=džè}U/êß³WTñZæž ÷ï«<] XcW¦Ây EXq ÅOkI®hÊRyŽ ñ¤k„&Þ›À”og´²uü–Š:–M/3[üUŸÅ󔬅$XÓJöaŸ‘„%ÔY ÎjÎ ¨3‹Pg¼ÈäU…-ëõ-¯ÊOÓD»Ö7˜ª´è~s½Ä^mŽæÍC5*ÊhU­ú$R¾Š2)ËÂXá°eöSÅ eo"¶4Äs¼¾ “ß•Êuè`eQËeƒ³1:ZôKf|•\•ÑWÀ«zØäÙÓh+¢à”T‰ZÜ¥¹­A—A¼E€=)ĉƒÊ û,[ïú›¼–ÃÛÜÚ/UÎÝ]‰$ªŠ-²6Ô×Xñh¡$±ZA -l]¢ØSôÄM…^ c¯¦”AоÖÔaÊ.$ß •´RDBAÒ»–ï,×–ÔÑøçAë;°ÝÖÓ5ÙÖ‘Õ’µ¸®Ò×åÞ˜w ë›æÌÈ*RK콨ÄNÝͤ–DRÍ%oN/06ê"Œ!ŽQ ÏÇh¥±'ïœ öÙz}‰u\—êdœ«˜RøNN‰„ ¨Z磤â-kËY¥ qìÍÓ’Z SUJ Pc›T›ŠUÐ0…2Ä¥I`VoêÉcÏêRwªÔnõUw·Š5€IÔÆÌ' † -â¤ñɹ1 ]„(òþÓ¢I¢À-Ÿg‰uÜUkÛK¬‡O 3…|´‹±/¦Y#´5FÊæl-è°" Àåv=èÞWˆwPo-šqÙ­×ÄÄŸAÁ4.Cyþ¬ŸG¿?ÈéìV—»ÒÓǧF§/ËþI+ Á÷_üc%Ý+¸$êŒøŸ¾}o&*ë`)%ÁÑ\Š8B/ö+[ñÂÎÞý`O®¯o†ì ˜2½/ƒjúÆç}"ú.‚KVåÖ‡gKŸsŽã\—Þ¬+ –¥J»cšºŠòE’É´&Ô*'Œj²V)¢ÙAqg,”£ŽÊtµåÊ 0ÍÈô¶®“b—©\m,n/Êb”wúúYç@Ú kÀž]Ó,+YéiW£Å©|±•Ž":ÉþØI(’5¢¥Ñþ¬¥Åé¡¥+¥Náwd±M)*ë ß>³Qä¯?Üu¥w“ðÄ8ÑÏq7°€õ<–] G$sŽÉû·²’P9¥ÂÝÚÊö–)ªæš0¿Ñ.~+×qqÔ Ü_øê*|S¼Yìš*vº³ÀUUà¦=Àž{Öïx¼ P9¡zkÑœ;"SN&mÐ}Õ~ïV çwbÓßÛÝ0Z7áSVI;2Ò«ü÷Ë‘^%9®Š20ê`Úe_ò×ñ$¥ˆ;·“SÙõ!àò'ÙWÙã쫱9Ÿú ˆ9œàww‘´˜Œ‰b[8î£zH/ÂvÕ¢Ú"ÞVKi#RãD*¼#¥|£|ÈA¥ZZ)ÌJ©ë„7:!:ÈB:%†ÓNb1›½´¾qqŽ3kfá½ÌÑ;h]mo7?øSóuœ8–€_;1œrxßÆ÷Aë¤*^(¾é\¿ÄE0lÜÆ&)àU\çïféE1(š)6FâPA¨=+T&j„µ#„úîwñ¾xåcŒ÷ÝCÑ2ǽ‡ƒû@1fKzâË°bcd¬hA –ùVz0¥%Zi8¡”:í†ê‚7è'”¢!Ê`úwÒL(gˆ VA” &ü Kgm[kló$Áý¥ó ÌýZU+]Bú›Yõ®W\âõ .… ú›ø’õ[[Ýøpz±/•âRœ²K2À$ -~§).Õ ðZN²¯Aš';ð<Œ€ÐÐôÐl/¡—`·çõ÷®ÆQÒZNÄî§Dë¯f>ʾ€ïãqÄü¿½0Ðê)#k¥¡9”Ûo€Ðõ2|WñúÃÿ¦ãÅH]*J˜¶ÀÜâõ•ïW\K¸|œ½©Z£·ÐÖî•ZT;¾Ù£Ô×ÓÿŸ¼.€ -endstream -endobj -1662 0 obj -<>/Font<>>> -endobj -429 0 obj -<>/BS<>/Dest(section-1.5.2)/F 4/Rect[65.905512 756.389764 99.092035 743.389764]/Subtype/Link/Type/Annot>> -endobj -430 0 obj -<>/BS<>/Dest(name-label)/F 4/Rect[99.092035 756.389764 124.318842 743.389764]/Subtype/Link/Type/Annot>> -endobj -431 0 obj -<>/BS<>/Dest(section-1.5.3)/F 4/Rect[65.905512 662.491326 99.092035 649.491326]/Subtype/Link/Type/Annot>> -endobj -432 0 obj -<>/BS<>/Dest(name-pref)/F 4/Rect[99.092035 662.491326 120.549799 649.491326]/Subtype/Link/Type/Annot>> -endobj -433 0 obj -<>/BS<>/Dest(section-1.5.4)/F 4/Rect[65.905512 494.194451 99.092035 481.194451]/Subtype/Link/Type/Annot>> -endobj -434 0 obj -<>/BS<>/Dest(name-phonetic)/F 4/Rect[99.092035 494.194451 143.5581 481.194451]/Subtype/Link/Type/Annot>> -endobj -435 0 obj -<>/BS<>/Dest(language)/F 4/Rect[65.905512 462.594842 109.171869 448.995233]/Subtype/Link/Type/Annot>> -endobj -436 0 obj -<>/BS<>/Dest(language)/F 4/Rect[115.230463 462.594842 174.245356 448.995233]/Subtype/Link/Type/Annot>> -endobj -437 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[344.662348 462.594842 404.564936 448.995233]/Subtype/Link/Type/Annot>> -endobj -438 0 obj -<>/BS<>/Dest(localizations)/F 4/Rect[410.623529 462.594842 469.638422 448.995233]/Subtype/Link/Type/Annot>> -endobj -439 0 obj -<>/BS<>/Dest(language)/F 4/Rect[80.905512 374.596795 124.171869 360.997186]/Subtype/Link/Type/Annot>> -endobj -440 0 obj -<>/BS<>/Dest(language)/F 4/Rect[130.230463 374.596795 189.245356 360.997186]/Subtype/Link/Type/Annot>> -endobj -441 0 obj -<>/AP<>/BS<>/F 4/Rect[257.042719 312.198358 316.057611 298.598748]/Subtype/Link/Type/Annot>> -endobj -442 0 obj -<>/BS<>/Dest(RFC5646)/F 4/Rect[334.314691 312.198358 375.272455 298.598748]/Subtype/Link/Type/Annot>> -endobj -443 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[101.33349 276.999139 159.427729 263.399529]/Subtype/Link/Type/Annot>> -endobj -444 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[165.486322 276.999139 224.501215 263.399529]/Subtype/Link/Type/Annot>> -endobj -445 0 obj -<>/BS<>/Dest(IPA)/F 4/Rect[178.835199 253.399529 332.347895 239.79992]/Subtype/Link/Type/Annot>> -endobj -446 0 obj -<>/BS<>/Dest(IPA)/F 4/Rect[338.547113 253.399529 354.805414 239.79992]/Subtype/Link/Type/Annot>> -endobj -447 0 obj -<>/BS<>/Dest(name)/F 4/Rect[319.883783 184.001092 347.942133 170.401483]/Subtype/Link/Type/Annot>> -endobj -448 0 obj -<>/BS<>/Dest(name)/F 4/Rect[354.000727 184.001092 421.105219 170.401483]/Subtype/Link/Type/Annot>> -endobj -449 0 obj -<>/BS<>/Dest(address)/F 4/Rect[447.98144 184.001092 486.186762 170.401483]/Subtype/Link/Type/Annot>> -endobj -450 0 obj -<>/BS<>/Dest(address)/F 4/Rect[492.245356 184.001092 526.89184 170.401483]/Subtype/Link/Type/Annot>> -endobj -451 0 obj -<>/BS<>/Dest(address)/F 4/Rect[65.905512 170.401483 95.764154 156.801873]/Subtype/Link/Type/Annot>> -endobj -2817 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2816 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2815 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2814 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2813 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2812 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2811 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2810 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2809 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2808 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2807 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2806 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2805 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2804 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2803 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2802 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2801 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2800 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2799 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2798 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2797 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2796 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2795 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1803 0 obj -<>stream -xœÅZKsÇÞ -J¸*K’å$R -G1]ÖhÞƒ]Ž‚„H.H >$©Ð)UvrÌ!?==½;û˜Ýv ‰1L¬°é¯{zº¿îÙ ›Pø¼ð+±Ö-'ÿ0þyLŒÂ‹áˆ'Ã/£'Z -b(5ÖL¬QDJꤚüòñzüÏ1›øÏ/?_þ•:ùé_cÿ¼qÅ#ŒqNsÚâ37ã%|`hfà åŠR“÷¹È÷µëþ÷úkFì$û¿*oÈlàÚeS¹|óu Ç)®#¬Êï÷ÙoVù]}®rþíþ¿I|¬Šýáb\Ì¿5ÄI™²ÔNµ„ Ç•\|¿<™¿}uôÄ ‚c¸krq3~÷Ur’,’erœKVÉ9œYÀq™L“Óds“þxñz|t‘Ï÷¾( ¢Rh¾åâjÃxÈ<þ)œ_Á•ÍæãÃ䜂1µVr̳dPÆx çðóÿbW® aÚzïÚx†Ö€ó|§ ´ß%€;V€qŽvþþnð & £Œ ³ÿ9 '¯·4) z G? ß fwƒWÃB(îvà=ùG€îôV~1#—’HŽ êú‡“¼ˆ£"4ŒÐ+ø^çç½ÉS8çå þ}çÂ3ö)\{‹S0J®ñÌ>á¯^â]ÇÉ|ó·ÿäó4B1åð~NW¸v.áÜfƒ(tb47¼ž0®‰0œ*À^Œ¼(,™5€‡µ@ñf»ÎMì³èçÛlÕ¦uP‡ú9@J ò€¿‡O¿Å©™9L ¼.÷Ñ ®°;4lì‡åØÛôã¿œ©5©¼u3—õe÷ïk‹Çc»Ì9Ö(¯žVXü‡h—@ŠKnoz*==5Bèþ±ý™Þ·„Ð`Éú‹)h“ÿ<Êö)%PÊJÇû Ü;ÓƒW®¨Ó. -¥{qý]3NhÞ}‡B™qÄ)ã u(¼mrÁ½YÂ?%-aŒ -GÜ»PšƒC1—µÇ -ºBçÚ¨7DpÍ´Œxç)“¯ÐÏòX,jݶ…ØqÿÆyp@§›Cm£tÊZ°àLïXÓκÑí9o"Kª}ÿEÞY]açá,Ï3e¶MñÙYÖœœy­™¬^9|ž7§y]A€ÿKR£Vþ•ÏZ[T×Ô÷Í4-Ú#íªtìlLq3$‹Ü%•¬÷À΋Šú:ï“uÂ5ƒÌ™F¥:bܦ*W„r …d®ê¬æ]aïà -tòƒžç&Ïò}­5VÈP‡eJ -¦òŽ ¼–1Ž9J ðpU®YTwt2[¦Û“‚0X@E?¼Õ~1Ïæ„3îw]×ÓQî Èœ :4íå‹‹Ê"©±KÏ{ΑÌй¬°02“K“ê¾›oÕn7‡f„;Yvé«=½@Û}pÿìgs– YuH"Ú;(Ž©Ÿb{|¯ýÚú,9OŒ)Ô¦=º¸#°µ P®©[ô $ -#……Ú¿ñ`\`iI È’j€]÷ÛÊ©>9-VÒ²Væ—Ac[=ѹW`%œërÛ%Í÷|³uçW¢Ñà Ê. ·c\>뼞\c¤~S<³ÄÔvêúbÙ½ÅãI%fž£‡]ç…T›Âµ}å„ÐHݺiK„rJYFC?çCà£ÏqCਲ޷ºTö÷£þ‹ÓÄ9á·RÚpµ¼ €;ÕÝÊ9G,W†…Øf:Óa%!…â°Lv±Åqs#o1WÒR¶­ÞœŸÚ¼µ%Àm/=´P·ŠŽ– ֶܱÉܨ#·¿üÐöêCf¦vƒ—ä#š?«‰TŠfÍ¡²­fíVjê˜(ˆHÛ[$ÏâP‡[7Úò‰Õ†(eÊU}9=F"#Æ›Y²œÓéÎܨKôz)Z„×=Bx¸3Ü+ܺM1 tùxŸ]¯ÝPR9¢8v«ë[_!Ò¤ƒK~E€sp* %Ÿ ïg(’§àv¬xƒí±ß$¾ÅF± ã ñ››1¯4ƒ,¢°Eð{+ôQù†×²øü}0Ī -endstream -endobj -1660 0 obj -<>/Font<>>> -endobj -409 0 obj -<>/AP<>/BS<>/F 4/Rect[443.105951 722.590936 485.941645 708.991326]/Subtype/Link/Type/Annot>> -endobj -410 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[84.505365 708.991326 125.463129 695.391717]/Subtype/Link/Type/Annot>> -endobj -411 0 obj -<>/BS<>/Dest(RFC2046)/F 4/Rect[294.33935 687.391717 335.297113 673.792108]/Subtype/Link/Type/Annot>> -endobj -412 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[492.876947 652.192498 527.523432 638.592889]/Subtype/Link/Type/Annot>> -endobj -413 0 obj -<>/BS<>/Dest(prop-contexts)/F 4/Rect[80.905512 638.592889 102.674555 624.993279]/Subtype/Link/Type/Annot>> -endobj -414 0 obj -<>/BS<>/Dest(prop-pref)/F 4/Rect[98.713617 603.39367 157.72851 589.794061]/Subtype/Link/Type/Annot>> -endobj -415 0 obj -<>/BS<>/Dest(prop-label)/F 4/Rect[364.390375 581.794061 423.405268 568.194451]/Subtype/Link/Type/Annot>> -endobj -416 0 obj -<>/BS<>/Dest(section-1.4.5)/F 4/Rect[65.905512 556.694451 99.092035 543.694451]/Subtype/Link/Type/Annot>> -endobj -417 0 obj -<>/BS<>/Dest(name-utcdatetime)/F 4/Rect[99.092035 556.694451 168.604731 543.694451]/Subtype/Link/Type/Annot>> -endobj -418 0 obj -<>/BS<>/Dest(RFC3339)/F 4/Rect[334.182856 538.694451 375.140619 525.094842]/Subtype/Link/Type/Annot>> -endobj -419 0 obj -<>/BS<>/Dest(section-1.5)/F 4/Rect[65.905512 432.596795 95.494623 416.996795]/Subtype/Link/Type/Annot>> -endobj -420 0 obj -<>/BS<>/Dest(name-common-properties)/F 4/Rect[95.494623 432.596795 216.952143 416.996795]/Subtype/Link/Type/Annot>> -endobj -421 0 obj -<>/BS<>/Dest(section-1.5.1)/F 4/Rect[65.905512 331.498748 99.092035 318.498748]/Subtype/Link/Type/Annot>> -endobj -422 0 obj -<>/BS<>/Dest(name-contexts)/F 4/Rect[99.092035 331.498748 142.307856 318.498748]/Subtype/Link/Type/Annot>> -endobj -423 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[344.645502 276.299529 379.212152 262.69992]/Subtype/Link/Type/Annot>> -endobj -424 0 obj -<>/BS<>/Dest(phones)/F 4/Rect[385.270746 276.299529 444.285639 262.69992]/Subtype/Link/Type/Annot>> -endobj -425 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[313.21435 239.100311 371.308588 225.500701]/Subtype/Link/Type/Annot>> -endobj -426 0 obj -<>/BS<>/Dest(enumerated-values)/F 4/Rect[377.367182 239.100311 436.382074 225.500701]/Subtype/Link/Type/Annot>> -endobj -2835 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2834 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2833 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2832 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2831 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2830 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2829 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2828 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2827 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2826 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2825 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2824 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2823 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2822 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2821 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2820 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2819 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2818 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1802 0 obj -<>stream -xœÅ[[oÇ”ð T¾ÅNФ Pð‚d=÷ PAJ‰”ÅZ$e’ŠÍ>´E•»@Ü>ö¡?½gn»;³’–å†!©åî̹̹|çÌxDF^ßÛ/ÍI¡µQ’þþ~øë°PÂÝŒßîÇ_‡p¥äHrV(Œ•V#­DÁ96\Œ>üc¸þsHFöõá—á‹¿’~ù×ÐŽW¦B¥… Fj7æz¸€LMt|¨¼w¤Äè] ù.¹o¯7ß±Büÿuz;˜ô'·Uíöõ·9;FÐxß±U»~ç¯Iíº>®öû-³[½ -Âì£ü»Nò§×Ãríµ*´â˜õˆP¸bÀ¸½~?|ñ§ùâÕü到ÂÍÁà©ÑëëáÛç躞Àû1¼Çyý²š0ZÀ+³é`Cc´A§èQt‚þŒ¦ð÷&Nš"‚[Kɇg”RÖaU(3TxÖ_MßœüÔÆúS4hç~Ÿ¡5|.Ñ|nÐv‹.áÖÝA.Wp{^¢Ðöú~À, 4ï×ð^ÀÃëpw€®às ÷&pÇ>aŸ·OmJJ—%7Ó@áFÐ÷@˜"â~«ø¼ß§… ¦(V˜Ô¶}“ÙéèÕ1ÅÏa-J;.98o•Äs<+yZƒD'™Ç{_wfaü -®ÏœæŽN¶Œb5BÒÊ=RaþȧåûþþMût¡u!0ך…©ü‚Ì€Ktߧð¶B\ÀäcÓ¯¯]ïð>rÂ.ásÚ§?§­íßþƒÞU½q³ž—ó @]Ó €©S⥣sD‚;ô×##ŲLI#‚ŒSPÊf¿rªš•Æt„–Ά-±y¯Q¦ ‚$…0éÓÄJ++«ØåQ /ð p7 Fux»¨)ÁjÊþ²td¼‚NÝGÖË´N5ùM„/ÇRÓ•¦Ò(^˜Ê˜ÍÂŦ ÕœÀ{ÉYðç07 ²v‚MKßÃ+g2c÷¹Ýø:r6qTw  ²v¿·‘ØÇÑ¥SnÚå)Ý{Ñ­Xu…©2¦tœß@Å -õÖñí©¥t+ȶ7ÍõÉÀÉ!s*šT½ƒ `Ò+·ð©Ç÷,ÄŒBKŒ!A´Lzå‚”õÂ{!XïÒÃŽeìÙ¡*,.ªÛ>"ÎBؽŒö©»ðü}¸ºïT Ó,û\XŒÁÓ‰À¬Ég´>KgADzwá"´w¨L8ßÛ*»õCY¸S3K+§FT6GÄ sáBê´fFÞÅ7µü™jÒ*|æœ#…9ü6w¶³‚ßÕ dédœ¸³t®°rO.m¾hŒ; -ñÉ[àÔñu· -8 L(‹Á`ãÈõ å³M\ŒV“ªÜf{Ý‚¨jä%ƒX¤X™Òž†à¹Ÿ]ºàuâožÔãýšcÃ_ge ÷mþ[¸GlÎô“[a2Q$æ1+ÖÅg‚UÈÅN/åšw+D ŒI™ÿ¼—Wì®qr™$(kÑ ê@lâ ê»Eç -XÇÝÒxfqDÄuSxpó:!g7@FZ9ŒÞ˜²oºlêaÒ`ú ›S ÐðO²ôª™I(†‰Æ]ƒb&ÙtX¢&²N™ïÂ,o*ÒÉÕǦ7¼º«gKDèìš™‚3(…eLú¨U¼ ¹Å¹Æë½õNˆ{¿¯Ýç(Ö¨ «Y/[Ú¿Ó¿LÚhRfÕÎÊÓ(€”F1 WÝœ8.e/6'¶‰í2¤=gªuwŽ5ÊÝL§nšU¹ÞµJÏi¦[ze -Ì°)³ÙÒÑ«ù Äuª ª-:Æ0ê¢tŸu(-OkÐçQ™¼¦8ƒ›ê¼ì!$Øé£pãÉBr! FÈþ´·×7w¼À¬† -p²´Š»Õ|ƒq•$€ðÒësMj™E87>âchAƉQmßAßGõ0Iau#nØf´©t9zÒ{ä(ŸÐÕHS׋¼þOó#Äð‚qƉjÚ×°Qà=LÀršŠŒýь״»R8iA×:9±I·jŒÜÕ_½™Xÿ‡Ú¿ëtÏIÕ ˆ#Ÿ¹Òz’÷S($Ñ2¶‚ýéGÒÊÐ˜Ü -£Aß5j~Å -¥ÀÎƤ¶ûô"H¹Jz¡¾ý7qz¸*[ ± i;a*4R×é¹’jW+i÷õiÊGI¹,¤ÍÅNvê½ÏwíeIw8f¡A•ñ}½t9Àiù4럖„ÖÉIŠ^Ž2£Û%®&@…âe›4åqV›f:V«rëeîºëU+5žÿ©oÒÌëlï³Ë^•­×xòÃÏؼO0jƒ4¦å1’¤¯š7ƒÛì*ÊÞ¶’]«ÔÇ _(‹yÙå|Úº”iú<³°¶Um\çÛ&†Š0ϵ fO¬= '7ÆÍý´|ã2ÝiÙ9Ê6°¨ÝÀÒ–£ÁAl÷Þi¨ãú=Š'b ëLD”-G†²‚j­Ê“\¾ŒÑ6¨Úö¢Y#™×T1Fñ¤ËihÊVû€¾y×Yó´Ñû£K@°PØc{´2åôti; _ÚYd`¡úºµ’.c‹iNi–H>m»ÖžR6'¨ÚŸLèÕ>F_£ß¬Q*uˆU¨<ëîߨ=\™’‹BhŠÁçÒˆ{MQ.Ê,eîñŸ¯%(¡ ‘ZªÜt÷,"aìfì"£ÄH×}w» õ…¤©½ À^¾„×ã\²~¶‚ÕJBí±“P#†FIJ^€(¾›®ïÔ~ÂûÉaÄì¿·€’™ -Åi¥!]L½t›€S´ý·CËíõà üåºF¥VP¯îAÜï>zô¼vY.¢ÐSôê@Õ*h¤Ø)µÝ|éÒÅ#ô07ÇÅð.Ýæ -endstream -endobj -1658 0 obj -<>/Font<>>> -endobj -398 0 obj -<>/BS<>/Dest(section-1.4.3)/F 4/Rect[65.905512 756.389764 99.092035 743.389764]/Subtype/Link/Type/Annot>> -endobj -399 0 obj -<>/BS<>/Dest(name-patchobject)/F 4/Rect[99.092035 756.389764 160.286615 743.389764]/Subtype/Link/Type/Annot>> -endobj -400 0 obj -<>/BS<>/Dest(RFC6901)/F 4/Rect[400.414301 724.790154 441.372065 711.190545]/Subtype/Link/Type/Annot>> -endobj -401 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[247.443598 379.198358 277.310297 365.598748]/Subtype/Link/Type/Annot>> -endobj -402 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[283.368891 379.198358 342.383783 365.598748]/Subtype/Link/Type/Annot>> -endobj -403 0 obj -<>/BS<>/Dest(section-1.4.4)/F 4/Rect[65.905512 303.29992 99.092035 290.29992]/Subtype/Link/Type/Annot>> -endobj -404 0 obj -<>/BS<>/Dest(name-resource)/F 4/Rect[99.092035 303.29992 145.757563 290.29992]/Subtype/Link/Type/Annot>> -endobj -405 0 obj -<>/BS<>/Dest(RFC3986)/F 4/Rect[160.49267 271.700311 201.450434 258.100701]/Subtype/Link/Type/Annot>> -endobj -406 0 obj -<>/BS<>/Dest(resource-properties)/F 4/Rect[352.628168 160.102654 403.553461 146.503045]/Subtype/Link/Type/Annot>> -endobj -2844 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2843 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2842 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2841 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2840 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2839 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2838 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2837 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2836 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1801 0 obj -<>stream -xœÍZëÛÆ'*ø‹ äΰ¸¨ƒ¨ãæ›Þ]î³h‹ÂÕIòj‰÷t— ‚¤èå‹] i?¶@ÿôÎÎî’ˇ(©öµµ|).çµóøÍP)M ¼^ÚÍi¦µQ’§~?üq˜)Ã'~ùãΔL%Ï3EˆÒ*ÕJdœÃEúÓ_†«á_‡4µ¯Ÿ~¾úŽf$ýáoC{¿2å-”2– j¤Æ{n‡¼€4Õapy¬Dúγ|W»nÏW_³L§îÌo‹Žpí²Š.ß~ÕÇ®£XÑù;wN£óø¾èû;·ze4·ÿÒægÌòõÅ°Ü{­2­8¡BR¢3–&tzñ~øêíôúÍñë”æÒÈaUzq;üúËäER$ƒd‘Œ’∑/“›8Ãé2™Âßœ­’S8$¿‚#¸|Ž'çÉer†Ç—îëArwÍ“5^žÁ½ö}Kæð9M&p~\±¸F¢—~ñ -—Ÿ%ÇÉŸà›1œÛ³1¼Ö°Æ‘²r¾Ldò®°bä×MàÈž=8úæâd“9˜Ìrň"9eÖ" ù3 »ú ¤}â!ÍcàaÏ°j`mƒâÇNæ.Iêò—ÆZ&Ÿ×E£”g‚©YJˆ™kFe)UÑA)ÈåÌj·f…²,£í‰Íÿ(\âŠÎºF“ŸÆBZª3°BœÖ^Ë{G6ì¾ßKu5„!‘Š(%sÙÖd€R_!¶ m¶Q”0ãétÈï ðŽ^€ª»{¨3_›¨T^D®¸Ý—W@Å:ÊÔ;IäÛAœ¦›u6<£$‡Üíuž$Ó›ïÿYyfèfšæîgTdBIåÿØ‹’o1‚î[í€ö®Ïa• -7Ž–¼¹m{å¨g^Ynó'SÆìäfÝ’Õgè=³È(#ðlŒDÎpå3ïs«V(°<Z‹œD7o7Ô# Y¦²}õø¢ŒƒhÕÖMjÃF pwW î mEê -—/à}ÙQ}ªzÉUI3ŒL»rÞ——r°¦*×¹W7䃥zThÌËH™Â×ÉKL‰£!²šæ,b³}Îe›ÙÙa/<&uühúP‘¡Æ0 -©Òƒá}qÖÆê½eý쓦@û³’Ù%\4Kí«?.Š·‹“Ôú$B:[Éû_±A½öÜ­ b¶µ4»« ögɵÎ8¥n–ž–:‘èëêƒõTZ#Ylw¦wµÛÍx·ΌΌÒèFz¸Kë×:‡œ›Œ»^c+=ÛGk>ë¨Le9“ºð:¸Åv ÌÛ6OþºÌËey]6JtÜD2nX›Ö §çÉHë<HommíŸDx3 ÜyŽ˜`jŸl(.QÓsàkÄȬ:ǯÎÌÄ dª–k\3\$]ŸÀxFʼY/K±¶5uYMZÅg†²>ø¨®x7#9S\Õ\¯½Á u8bU†ò9Ü÷IfKXL”¤íÅ}žÆí|$g|[ H~5ý÷, õ=J:Ï++€Ñá%Ô] d-ÊÅÒcR×ÍO³+ç¸Òá¤GÑ&: 3J¾ÆöÎÎÂ}“'ðrSˆ‚ -?…賃´) -.„§m†¾ñ"–³v÷`Û?b¨Ò¦Mb€î8s™à›Þ!y˜åuã’7è‹(~ïA‚É«H’›# 3G“Жւ#¸uŠÛrì‡@?ß²ÜÜèsdzìšç>kÀ$nZbe·«µÆÀãÔ&Ïv‚iÚ4¬%§°]cDГÚèÆAÂ’í¶Œ¿÷’þ‹>Àœ{êÝ/ö¥@Ìj;3^[Y{4ÄfZbÊNcó¾„\X<ÃŒó^±q tÅ):ó¸wŸï—Íõaò;¸vþöÞŸ:­¹Nþ>/;0k…ÃjEpˆ5~:ÒcÄú}©Õö¼Fæ*)ÂR}ímÛwŸ‡Â^âüΤ­#lZû¦¡ÆT¥È’9/“Ê=ØêσñÃÚ·ÈvjÇ{tægKe¿ñÂçŒÂ€"*}ú˜ð.Ì9}«þ/ææœ-®·!(# œHqIª{ñØ4›×x=sËäß—èU1sû~†EÝYh’T­q›ã²7êDPUíµ§D!¬&Èjâ¯P »¥'åö¸´=Åm>Å£•Bß8 -D•»î— œï:]ÏQÿ*Qtìy+Tq¿ìÑT Õ â^S¶6 .zÊ#å V¨T½NuÃŒƒÒs]Y<÷#È1fà¹/-kпIËEÏ…w¹&À;îr @ÀH -¸Å«x‰3!ç(nª4©Õ›3/Æe‡ Áfµ9Ð6Ô6gsÈ6†qšgLå<·[šâ‡ÑO —;úò»\DLnÔ„J6F}—¾t¸ùج¹W>‰6ñåÎ÷ £¤xÁ £L½0•ù¯KŸ[bö´…7ìW<Úy ;FMFxeãËÄüËÞê‰å(/L]£îõ¤ÞNzU:¯\·G]H3¡Ê§)õÐ%nÒn3ȼt©¸ú¤vstÄI˜ÛYà4ò1‚!Púº  -–x@óÚ£Ó øŸ¢YÖÞáÚJÛÒ¹@«œB»¯EùìÇš¡ô!ŸO}]»òq|Š{r†ä;›2øž!…îôS ùÜ·¶U®4÷Åëy¹€‰¨ö©(ˆÅúUC:Å ›ád:î.O18¦½j¹¬‚Ü*·F¿­òÎ3¸mx†…U´·–^ŽÂç¶Eiî@qä;ð“>%¥ÎãTðÚ>6çƒÛe*LF4·´Ñ8}ÐxÈØf”é™Ï±Lå„ÛF¹Ö¡ôô¾²fÉAò$ÈÑ£tmÆnp®h³+êáòßï7òªéZc'xFaG Û°-åshmËø‹=õ•)£@ÅÝþჇêÜdLh¥i)ܱA×=RL5Rl²>;íiVNì“Éܨ=8AAÝßa8à/%lwF͘x¼¯rg쯄ÙçÍíGÒiB3@%ÚY¥wœÓ=îÓµ(úy•ÉØ=i·€¯7ÆÆRf"Ï5—ûæyÐÓdL*ηýx¨9ϳB~ĉ^x„mÇ'ÜÕkw@”…o½ UnU!Úþà -BY3Þ¥Xˆñ'ɧ»yžIƈÌw·É'8`üe’&õ'½î›†x’óLR~»ƒxƒ¶€RÒŒrÅÅ‚€}¼æ:ã„0©EY¿¯5¹V|V›‘-ýÄ°½¡Å¨ï ûåÉÊ÷ÇåÐ:ÄÍ÷ÿ„¯~±D±yŸyן ðªšÞö@#L‚§yHܧª‹¢BwHqðæžg÷5a†°LØŸ=…ÙW=:Ãó÷pJ™\í®62Òs'Ôú1;¼­©ß#ûlÍH¦2ƒo‡äµóÞÃQ{K}êéŸ ×MÉ^‰@&7’;O貂‡=ƒä)>3ø´Y_úä\µ’ö¡Ë6F­±Á~œ ¡ƒ\ÈßΉT¿Ú°BÂßgû1³?§U -À•Êíä!qÛÎÑG§É[Û¬þÞ^%g7·ÿòÙálO[BsE¥Vw`?Í\b7UMØßîiZ «‘RËmŒórÌù´éŒÅðßÙ‚ -endstream -endobj -1656 0 obj -<>/Font<>>> -endobj -386 0 obj -<>/BS<>/Dest(section-1.4)/F 4/Rect[65.905512 592.294061 95.494623 576.694061]/Subtype/Link/Type/Annot>> -endobj -387 0 obj -<>/BS<>/Dest(name-common-data-types)/F 4/Rect[95.494623 592.294061 219.796869 576.694061]/Subtype/Link/Type/Annot>> -endobj -388 0 obj -<>/BS<>/Dest(section-1.4.1)/F 4/Rect[65.905512 531.994842 99.092035 518.994842]/Subtype/Link/Type/Annot>> -endobj -389 0 obj -<>/BS<>/Dest(name-id)/F 4/Rect[99.092035 531.994842 109.59057 518.994842]/Subtype/Link/Type/Annot>> -endobj -390 0 obj -<>/AP<>/BS<>/F 4/Rect[129.547846 486.795623 172.383539 473.196014]/Subtype/Link/Type/Annot>> -endobj -391 0 obj -<>/BS<>/Dest(RFC4648)/F 4/Rect[190.640619 486.795623 231.598383 473.196014]/Subtype/Link/Type/Annot>> -endobj -392 0 obj -<>/BS<>/Dest(card)/F 4/Rect[280.070795 317.19992 302.687983 303.600311]/Subtype/Link/Type/Annot>> -endobj -393 0 obj -<>/BS<>/Dest(card)/F 4/Rect[308.746576 317.19992 351.58227 303.600311]/Subtype/Link/Type/Annot>> -endobj -394 0 obj -<>/BS<>/Dest(section-1.4.2)/F 4/Rect[65.905512 251.301483 99.092035 238.301483]/Subtype/Link/Type/Annot>> -endobj -395 0 obj -<>/BS<>/Dest(name-int-and-unsignedint)/F 4/Rect[99.092035 251.301483 199.900385 238.301483]/Subtype/Link/Type/Annot>> -endobj -2854 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2853 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2852 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2851 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2850 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2849 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2848 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2847 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2846 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2845 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1800 0 obj -<>stream -xœÅZIÇ.„ð…¢‰¥±"#*Õ¾\‚À.3bF$g†Ic¶áñE -`%ÇòÓóêu5»ªº¹ÅŒ#J\ºØo_¾÷¨ŠW ÏËSœ:ç­QÕwï‡?©ÕxؼâŇðÉšÊ(I-cÖÙÊYM•b^éêÃ÷ÃõðïC^…LJ†/¾á”U?ücî·~s çBPͽqxÏÃp Í]ó àòYéê]dù.;Ÿ×_3êªúoÊo5áìØ&Ç_”âx-šs+ùü®þÌ“Ïé}Éõÿ±¸íƒrþTåkÊòË›áÆ÷œ+ª3NTœ9*¤ÚU7ï‡/®¦o.F_V\R¤ ×ÕÍÃðíçÄ’—dJäšÜ’%‡‹K<‘¿¡^µ ò5~kÇ#|_Óš…— -¥*Kt‚›(^ã™ sJ~&‹œ&(øq Wfè¤RÔ0þªß·)Qâ)ºj}ºF÷­Ð&ÁÃA˜;$ò‰ ¢ë¨oYm×Òhê-gÂG-£ÏàæUføÕÆ\£›XXjŠ¼z¾÷Ü{Á!‰bEû’å¿*:ž­á†:áèJ¶/®æ—UOÌLF1gbÍþ ¼Rë7°mœÏ’pjî-ƒmË­Ÿõh eÜ9+‹êÚÑ P½EÏñ±bÍ"gß#qáÕ€N ûòºš8$ÅÙu -L1E|Ùk™eÿQŸæœSN¡¢Õ5!¡PKp‡†ù:EürŽSCRÝÁ§ÉêƒÏZ»m?Š^ 4—8Õx|Žê®#ŸÜÈóÔ Ýé†Å*`*s¤ðžë&.Ç1Á×71+k£T—EÉxÑŽ³”ß?¤¨¼Óx|xÞúÐ{¶¶ À× ï{Ódª` zº•yÛõ2„«5µ¦ls8ßAêÿU4еõ¨{žºx…NF£¥&›2Øô™ÚøuèÞ¡sÒë³hÿK Š´›ÔÌp:9ê6"ä„´Òî1HψZìc %x#÷8Ç6‚òÄb@“³F¿oóóp‡i}Z!¬”mlè ±Á6§Ã†:¬%·Ìˆ ŸìĆ99¸MvÏ:K¦#@ Z°èÒÛ…µ10msµw¼YÏw'³¾ÊÂp…ûž°ÏzA½Gi«iw{¶ÊëLÓë—±p¼‰°-Óë]èuß]vp -Z±jg­ÐëÍÆ© ç)ÕŸW h55\!‹¢²sÅXxÖ[*™w®,LÍv/±i‹É±z®°$‡ú›ïìf¯ä‹ºÃ¶sP”¬3Jó¢>íÞ›ŽQŽGÈáù-p7ÁwK¸òèÿ¥£L«°|Ë ]Ôgg’UÜpNú§ &ë­n -•B Õ0v”Í­æ­n=&¡ú3$;ë¬[ d™¢ÎkhôQ­e°ºqPÀP“WÝc-Ò¤NÈÈyâ±ÆRå<¸eqü8"Üéí&ÐP…µ¾Ù°Á¾Åào㺾¦i„•±Øè<)1o=ÝŽñg„éÆKÒ•óRJåϾÉBu”¬¡1]BŸƒ—¯'@]Nj„v M¬ò)d«ÏÇ'ëñÖ…”QâàÿtgÏÉ%…2sqÙø»-ÞIfï’ë$°§žI#0kº (#‘1Oàî„rõOá¦\"e`³ÊJQH„]lŽµq¼­­—åcÝÝý$©îƒ"Θç§zM6ýanMÊÕH~Çl3lëKpÈ£ÝBÖ`Ð…¸\‰U©ñ¾Š°ka×Jã5^ÃkØê4´óbß6!Í -ì¢&”Úbývié•PiãêDúBé>q›¥ŠË“\Å Û©T~†z‰YŬ#VŠê¹2ý¶_²)Áh§g¶ð0f+ÏÛeO/F -Ò×½¾qdû dòcñ8Q·Œ’£z[{ëyDeu²uæêcë©‚ò' ,‹Ðmåx¦œz%¥.½|(Ó†1CŠÛØX]iî4ÌK›N }MîÏÀ ò ù<ž”šíf ‡Ø1Öð½Œ:Þ>Ž“1Š -µy?'–Îw“ßÀ¿§Ç1 ÿ™$lå´•š÷ò0˜~×XL§ä -Ýÿž^åýÿ± LÈòH[ÀçÆY-aÞ¬tnáy…ȽYŽÉÕ‘¦í}Xðîc,ü%¦ãïË`\ ÿ*R+ -endstream -endobj -1654 0 obj -<>/Font<>>> -endobj -377 0 obj -<>/BS<>/Dest(section-1.3.2)/F 4/Rect[65.905512 702.991326 99.092035 689.991326]/Subtype/Link/Type/Annot>> -endobj -378 0 obj -<>/BS<>/Dest(name-type-signatures)/F 4/Rect[99.092035 702.991326 180.343988 689.991326]/Subtype/Link/Type/Annot>> -endobj -379 0 obj -<>/BS<>/Dest(common-data-types)/F 4/Rect[65.905512 470.995233 116.830805 457.395623]/Subtype/Link/Type/Annot>> -endobj -380 0 obj -<>/BS<>/Dest(section-1.3.3)/F 4/Rect[65.905512 445.895623 99.092035 432.895623]/Subtype/Link/Type/Annot>> -endobj -381 0 obj -<>/BS<>/Dest(name-property-attributes)/F 4/Rect[99.092035 445.895623 198.831781 432.895623]/Subtype/Link/Type/Annot>> -endobj -382 0 obj -<>/BS<>/Dest(section-1.3.4)/F 4/Rect[65.905512 263.598748 99.092035 250.598748]/Subtype/Link/Type/Annot>> -endobj -383 0 obj -<>/BS<>/Dest(name-the-type-property)/F 4/Rect[99.092035 263.598748 199.373041 250.598748]/Subtype/Link/Type/Annot>> -endobj -2861 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2860 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2859 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2858 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2857 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2856 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2855 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1799 0 obj -<>stream -xœ½ZÝoÇ?”Ð Tâ؉ã’¶qàœo÷ö³E‘R-±–HŠ”ì(mQåÅ.´}èŸÞ™Ùݻݻãñ(;6-’÷µó=ó›YNؤ€×·øa˱Z‰É?ÞŽçZÒÅðI'ÑV%Ê\…6zb´Ì…(¬“Ÿÿ9¾ÿkÌ&øúùÇñó¿±¼˜üøï1>¯mõcœç’Yeè™»ñ^°43á ò–HÉÉOòMr¯¿b¹™¸ÿ1½Lº…“Ë:º|÷M“+y¸NlEÇoÜ1‹Žãç¢ó¿0»õ+g%þ›4?c’ß]+Û- -&Ma&¬¹*L_¯ÞŽŸÿårñòòlÂÔäênüý×Ùƒì({£§?\ÕK0®ó’+Γ.ü!›f×ð7Êtv{›­²|eÙ’N^gsø¶È6ézÜ2XDn2ë5H§Ü+¯´\:î_Î^¿8þ–ÈI%ÜååÐÙ9PÞ'àç¤âcŸ 8ZÃÑivWft×5Ü|/š|ù)|žÒ=3xî’VXfðw†`$ânYÂûi6»ýûá®õ\õl<£ìÛLe¿'Bx ²yÔ'½…°*¤(„W•ö\߇ÈÝÒÀµÏàô XFÂQÍ‘W^á`ºCRÛ’Î_Ó•-BLž»ñx˜Ã*aY‰†‹²Wtß =sDn\÷ˆÉY‘«ÒptJ3(I<åÅ×@â8û«7ìAd¢ø¶ÎÖtÏ”Þ[w>ü¹€W8VGÕÜrVð>'£¼¢«‰ÈÁrr §å å,q |!¯õÙcXeF<Òù>Ñ9äÍ -n½èµ`¸<ò~ÝÞ‘kÏœSÿ¬rm¤¿¢«×Þ+§Þ†(Á q~쯦üHˆG©lÉ;¸Aë}å5ØåF•›ô‰(Tn‹Ê‘_Ôñîœdîù=zëiåËNÎ`°œ×ÁÖ^v”óÌnÑ-Ÿ0{ Ám³‚òxä‚Tµ!_v$×à;s -ó#P‡>.úäUR–R2í%<ü›Ò™4'¸À‰½t¥2ÀLÊð‰Ò6çVì¶æ—5xýL«"À°»° çG&/l‰ k??ÇP“ VX„–U_zt3%¤·F®ç&L¾›¬-•Á‘Dœ¯Û,†øAG\òœ¹™h,ñ-X­¤VsErb$ÏZ­0àQˬ<ÚZ´G— -2‚‹:ïê&êiïBÇxÒêIoòÓ†êó -yMaáS¡BŸP§¨74„ó¦^Ra5fkÆKí5³Ïÿœpï…k‡ëvaNySKê©ðéaþ1{A+:´8£ó—ñÉßFjApŒb¸g]/0ò¦ÞÅ)Áô ¬wŠ>1-ö -Ðô¹¡¶´^àš†³ª)©{|G<ÜYµÙ¾eÙ%VÝ/àjgÄè"5‚Ì~”Â{j{ăJEœG}Bß’¡˜nm‹\?áç]ýÍi^ûœ÷E#žë &„ÈDM5…ú*sc•yvE=U±EQigÞ¯ftT+,ðñ c¸`J]•*‡ž@2Ö¦ÞN=«JA²µ¬j(¹Ÿ49¯¼¤ÏYKOq›÷k ->¶õ,ñتå\Òå4i6[#!G|CgN²9æ|æh»@Fä¼d¶jU•GšLÇ]íù°Ž¬ÚYÎöiQ2WÖ0ÆZL—¢ôÔ´¾Œý nC§=íxì£.[øÐŒ»áçrI*ÜÒ -–í²ñ27eayðØŽÈ#Ñ?Ï(ügÕå¢êÏ]ÔuhâN8ÆÝdD ijÏcoý]Ź¢¹Î ©Êçã©ÏÁ7tjÞÑ›ï…S9ä®XCô}°µ/ûöÅز…ZŠÁ´[~™dI)%€;]HÊôÖ”Öpoâ؃ûIßçô@çxzw -ŽÂûˆ0dƒÜþö‚ž$W€aÑ^Ma{Ô†&z¼ï˜À4gv/RU⻇3r‰Öh¹·pŸïÝ߀-öÏû çRÊ¢Ï u™ ”Þ§ )É! ç&˜˜¯h`Ý€¡ÒôdÖMï¾´ì¹±ªžCëªN…å -KƒÏcgÕ·åæ9…ÌM2.¾öi,DÆtP(ÌÛÅi¥³Üè1Ÿ -ÚªX6¶(\tÊYŸàQ -nêõ’†Ó¤º ÕSÒvs^'¶@+Ы,̯]iu0Ï¥—74‚oÛ8 ÜíU\I‰?BP‘šºÜÖšãÊzÃqÈýR%x}ÚGnÒeبà¦e¶Y+Ã"Q=ol˜€‘4tpPZ„zØð†Cò¥U¡låœáHš5zëH*çF#2Ë+BôMQÒ¾m˜0ZçJ0iE›pfí£ÎE¬›}r=àr¹Ò2 Û3JS—4Â?ŽœµÞ€©¯?€;ú+§–À¼å¶µ?:¥m¸WßÝ/Sܧ«ÐÆâT¼îçžuußÃrOB<íÊ3]ýÐkŠ¿®h:l-Ü*mmОÕ]ÝúÀ·ÁṌöüƒ¡tÝQ/p¢pî­Mh‚iÖÔÎÏÞ/¸„h^¹´ªÁö—@6„†Ä:œ íOA¥ákÓ$;ÐOá‚VÜF6ZXŽ¨Ó -O7ŽGÙ“ìSx=lJÖO Tš¥q쵃P÷¬w0%¥ \‹Ý”Šúw’#ÈoÃߣýˆákäR—’uÒPÔD­β—ˆÙþoϳåíÝÿü¦ÉrO]Ê"gÊhY!pèÚI]uw'ÙË=UkXn-nbí"\Rƒ‰@ëqÓãÿÌÙ/ô -endstream -endobj -1652 0 obj -<>/Font<>>> -endobj -359 0 obj -<>/BS<>/Dest(section-1.3)/F 4/Rect[65.905512 753.389764 95.494623 737.789764]/Subtype/Link/Type/Annot>> -endobj -360 0 obj -<>/BS<>/Dest(name-data-type-notations)/F 4/Rect[95.494623 753.389764 218.704828 737.789764]/Subtype/Link/Type/Annot>> -endobj -361 0 obj -<>/AP<>/BS<>/F 4/Rect[295.276606 680.990936 338.112299 667.391326]/Subtype/Link/Type/Annot>> -endobj -362 0 obj -<>/BS<>/Dest(RFC8259)/F 4/Rect[356.369379 680.990936 397.327143 667.391326]/Subtype/Link/Type/Annot>> -endobj -363 0 obj -<>/BS<>/Dest(RFC7493)/F 4/Rect[282.468744 667.391326 313.296381 653.791717]/Subtype/Link/Type/Annot>> -endobj -364 0 obj -<>/BS<>/Dest(RFC7493)/F 4/Rect[319.4956 667.391326 360.453363 653.791717]/Subtype/Link/Type/Annot>> -endobj -365 0 obj -<>/AP<>/BS<>/F 4/Rect[443.5935 640.192108 486.429193 626.592498]/Subtype/Link/Type/Annot>> -endobj -366 0 obj -<>/BS<>/Dest(RFC8259)/F 4/Rect[69.505365 626.592498 110.463129 612.992889]/Subtype/Link/Type/Annot>> -endobj -367 0 obj -<>/BS<>/Dest(section-1.3.1)/F 4/Rect[65.905512 601.492889 99.092035 588.492889]/Subtype/Link/Type/Annot>> -endobj -368 0 obj -<>/BS<>/Dest(name-objects-and-properties)/F 4/Rect[99.092035 601.492889 214.439691 588.492889]/Subtype/Link/Type/Annot>> -endobj -369 0 obj -<>/BS<>/Dest(iana-type-registry)/F 4/Rect[293.602045 519.094451 416.717768 505.494842]/Subtype/Link/Type/Annot>> -endobj -370 0 obj -<>/BS<>/Dest(iana-type-registry)/F 4/Rect[422.776361 519.094451 473.701654 505.494842]/Subtype/Link/Type/Annot>> -endobj -371 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[462.606195 459.696014 521.621088 446.096404]/Subtype/Link/Type/Annot>> -endobj -372 0 obj -<>/BS<>/Dest(validating-jscontact)/F 4/Rect[429.500971 436.096404 443.180414 422.496795]/Subtype/Link/Type/Annot>> -endobj -373 0 obj -<>/BS<>/Dest(vendor-specific-extensions)/F 4/Rect[466.597406 436.096404 480.27685 422.496795]/Subtype/Link/Type/Annot>> -endobj -374 0 obj -<>/BS<>/Dest(prop-type)/F 4/Rect[335.064447 231.000701 394.07934 217.401092]/Subtype/Link/Type/Annot>> -endobj -2877 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2876 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2875 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2874 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2873 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2872 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2871 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2870 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2869 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2868 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2867 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2866 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2865 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2864 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2863 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2862 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1798 0 obj -<>stream -xœ½[[oÇTÈ T6â[àƒbG¹¬æ~i‹¢H)‘–K¤-R”•‡¤¨ó’HÚ§"ýé=sff¹7.wC:¦%r¹;s.s.ß93²!…×—þÍJ–Y댖Ãþ8øy…7Ó;~ùó®Œj)2C©±fhʤ¤Nªá/ÿ,? Øп~ù~pò-Ëèðûüxãò!Œqž)æ´Å1o3xÁÔ̦'€ÊHJ ˆ$(Ý÷×ËÏ€Xf‡á‘Þ&ÃÄ¥Û¦pûígUvœâé>²U¸þ!\³Âuq\áûwÌîú•1áÿ «ïE’_½äkϘ̔¤Úò!£6ãÂqe‡¯œ¼œÜ¾8ýjÈD†3ÊÔðõÛÁ›O‰!dBȘŒÈ~È™ÃÕ„\ÂçÜ“ø<†«YÁÕ4~¾Ä'Fðü)|wOMa†)Œ\à÷3|î ->½<æôS¤âŸð´¦wßý—œáÄþ‹%L[}ô -^ K黽!×pgFοy}Þ,;×™0œ*÷⃘S˜ïP›ÀûF/QÜ)Бûä`ó\ÒdVXÎtœèîSòFú9qü‚¢ªn@¢ Ýs:ƒgnáýð;‡ßx¯«ç îyÎæø¼ç g+ó£˜É¸1Î{\•Ÿj„“5ú5¼†ï^ãŠøOþÞ  kì•;'/6‹¬Uæ £ÜEKjµ?ÇUK:¬iÎwF‚uYj‡Ìu ÃŒŒ%[ó<½Âß‹Úb o(Ëšh“e¦{“»ï~EÝñËYêÉ|S{½ûûÞξ$špÂàÓáî½üúî-|õf¿F#\VÅÒ·Tm« uØ¢ÎT¦´ó ¾E©‚™L£! ™_ã÷ËhH§¨™eI“’k­Ls1ý¼Þ°ÎñÙy”§Î)QgÖ”X´m?Q‘d`Ø/‚gø’ÜÝyþÛÄ>Òqã’%Á¢£/`櫸ègèX΀ñc˜ð´n1Øx3 æ2Š¦¼ˆ¢<§ÏЈ¼b‚2'èSTÏÚAÆè‘KôÛä‰IÅ>È`Ä%ü>ÅwÏ ÊZóš²´#¬P:9ÁóÇ’yßËåÀ‹ÊÝ (È%>ã—%xq²ž[TÞ%2ïãÚ'¦1 -à‹ê!ðp·‰¤]É]r™‡Ñdk1¤Åå¬(Ê[Š7cÏä}œÿôuÄ~ ùÉ1ç8Ë‹ äwÈwøSô…wÎP)P÷a¨?Y (F+JU5?œüãjöòê|èM³=×Ö¸f–‰>ïÊ€æ&ÓFe,*‡Èìñ·D·FÏù7îŒó$K”6£•RÝÉ(rw áCò˜<%6Ò\ËX"A­vTw'ø÷TÛÌù¼Ÿ÷«Li >;¸aº“‰Êüˆ<$OÈÓžÊTÜf’Q&]w‚;+³Ñu™¥B0É©-¹ˆŽô@|Ѐ ÁÄ× ªªÚèXs ׫”I¹Eåñ6Ý ™hšôqyŒ™èëÒUû&}[IáPEª´Òü´á2!4ÄJ©”eTu,Öœ¡G ÄàÎeÌp+eÂÖiŽƒ;B˜x0ó:Ç—!â)¦[ø=‰+0†W€š‹6(™ m„‘ÁS 2'/yÆVž$@¿ŠÐäºçWHvŒŒ.J}Ÿ=;+|ö°„lËâ]ÄÂá<áÉk¬¿Î1^Å‚iB›8êrJ™Kú^`º>ó…ׯ%$SœÕÇL^Ä·xïAÄ,| ê4_‹î×à§u)¼Õ K˜Àg€— WÌÚ„v4Ó`¼¹ èWáY”)TE_ù9}˜/jÂjÅ%-/ÿ¢€?«¶;â¸jŸ› -˜%.ø2÷„ëX$¤Š~Ð"­Ä‰>®½ê6Ÿ3 YTÚBÈ+퓈ƒkÁ¦Èô”|“ë¼Èجd£›‚×ýXl%w›æÏvôoBXT· e½uV¸´¼Á"S•}X‰ŒUv—ªsóÒKË).Ñ u¸xVŠ„Ú=òÜT£”R, -ƒ ¦¸›D¹.2B!ÊѸh]Ézwz”<¡MD£3éŒr,Š8•"$ÅIn5ªhhíJUÔ@U"ŒH%ëQÁäâUêr Å_G‹\Ûws;#Yëª/IjE­KâXÂ-±,XG1IÞ¢&ÏÖ1|ÝìBnÛ„k§N+érµ.cß©©Uüà?Ï£SU;R wš 5AW5dÔCLC!•…x–m†‚¤ŽW²±yä ¥<Ü&œ”çNèT*_`ñ#QÐÓ3â[hE½Ncsm]'€†I´²qÑh1ö­°6^Ö®˜sƒ‡¹ -Z2DHϳc ×w?áèÓ3ÚÕüŸ¯»EÅ6ܸ€iF8n¢„ n1‰eû}ÒÜÞ(Á›h‹a1Bhô‹uÓô{ Aâb‚+ôЊ}ËU3î,‹g)ø¾\7ڛ؄ˆ~¸Jñ?5f|O9¬y$,z°—%ùÝi4Á>AD3A„±<› ;'õ¼¥**Íǵ®[+e'm^½„“}\ƒJÎBù)œ1uŽ›—®MfA!¦¿Ýf(:Öo[ºB(À8ã Jç:ÙãÉуW\ENšUW¬A®±‡ùh_Zˆ:Ú¨„k8¦m°q™vÜÑj3ûÍZ‡• -ˆï º>x­Ø¯7 Ê7Oc¦iøF<_3ÌMé¸ äÅI›B\qeòˆæ1xè_ @>)H½Fee=ŒŒ%ñ»y$öð“ÜÝ´½Dh9%ëž4"€dN)W”KËmù×0•9eU¾ r“gC¤’bQüòL¡³œ¡1_c@ñÏ—2J£"Vð¿Ï£‹Ù,d¥Q,ÊV[ÝöHÉ|‚U•ý”6‰…7eB& WÛíÙµÂÓÜB‘ݧñ:[\8(Ž¸¶ýº±¹õyDž÷{6·¸“€R*\/šÛû[%)7ô óXQ.¨[è®bOiªocTq€6\rƺÓ<ø-k© }((ü„îN(.äCò~>è+™U*¶ÚGy—]J¿%‡¾¨+‰~¿Ž¡„Í|›‹[ÆUwJQŸOÁ-žÇ}õéDÆ­d†w'¸³>á^æC)Køc¿ú OÃ`vÓƒNI›OzjS€6g°€Ý î¬M¦ ÈB@© Fö«M¦îâI®”èN©¶ô Ûè­tšòîwÖ'· -'j}§úô)‰ÃÜšõVæ‡ä}o } ¶ó[=Vo¿<Æ€ßsÍCs¨qwçaëîNyÂ?®Áq@aÏò"eÝ© +Á¬ß‹µÊÕ'mÛŸ±”fB¹uk,• éBÉÛ8=l|¯Z‘BQZŠ* ˜ë=„¤•‚êLk¨âx×Þ®)õÛ(ÝH0­µ³²ã%L¦¤¶Út ©ÀhM±›øM|¡­÷M +(åù–Æ\pÀ Š²Õ]ÇïJñÎ $fð´rrÓ€T[ÕX”[åå¯,ÍMÑuq…G›Õ0p–9%“R'›ËR]ÞgØ¡=%ÅC\Ÿ€‡ ò8ìãzkg’[¼u¢•G¥¦£`d²áÑ|/¤ÜÌÌwºŠ·KµÚ+¬NGظkß’²JfF)— IÇ&Ïpš)–˼º´¡2þHh"·5&¬õëË©ô¹Ò›852Ï =i©Êß¾úi—%•—³J8LÛ7ÕƇH °$iâð~™»kÜÙL]¬yêWVÎöµhÒ ¸¶´ùþmƒn<=8‰›žØ÷®F7À[`vPÓÕèù#…Õ†û²¾ ©ßû òì |uÌxìü™h"֗ω$6Ïñ§NÛÎ:¨Å ªé|Õá¸gäs ­p¾# 'ðºhíÏÉä3ø1áä¼Afi`jˬSÙ¹!À ]( ¬«&½–ƒK;c/É3*°éN”ìñ´”ðiX`A»…åÞÛÁáãóA2¤Æ¢W¶“Öh+'äd÷³LÖX¶us’ûT¶R7¹Ô5ÓHžƒ®OvW³öÉšþžDËY¡”êkd÷¦^Ø;ÛF øKáuçYx¾“æÒeŸ,å®B“ƒwÆpÆÃtÿç@w C”`è¯;û˜¡™¡Ì—/[HrH‰o¾íîÜ‚ÛÜÐKøjß]‘Q`Êt'“·À«ïAEÎäÕ ÅÎwoY9•Y'¯‚Õ=Ÿú„ˆ¤„¥ë­Ì@•öîÿIÁ‚BÍfÔï¨M©!Kl±Ôè¾Ñ,”ØeéC)êô ˜è£þ=UÀZa£¥ÍÝmÔwË4À'YÀ{vx¿wªñ pg2;éS°E<ÆíÎ4÷Ð@×úu,Ãë=7­M¸¯3™6Àlm­Ô®;Á’2“B)θI}Q”ï¤êÐ/ÎÏËbÄvû£êŠµÐ…ÑF³­„jÇúQÒZfœBµ%#2ØŽxHÞ÷û\ýˆù?u5&ãÊÅihìÔ¼ÂJq‚ç ïþ¿NÈüîíÿâ_Î{êRÑŒù, º/ž}ôÅ´ÉÏŸœ‘—=UkYæœÖVo#,È(žø jŒ³Áÿû÷Íà -endstream -endobj -1650 0 obj -<>/Font<>>> -endobj -339 0 obj -<>/BS<>/Dest(RFC7493)/F 4/Rect[474.357416 704.491326 515.31518 690.891717]/Subtype/Link/Type/Annot>> -endobj -340 0 obj -<>/BS<>/Dest(RFC8259)/F 4/Rect[355.349848 690.891717 396.307611 677.292108]/Subtype/Link/Type/Annot>> -endobj -341 0 obj -<>/BS<>/Dest(section-1.1)/F 4/Rect[65.905512 621.993279 95.494623 606.393279]/Subtype/Link/Type/Annot>> -endobj -342 0 obj -<>/BS<>/Dest(name-motivation-and-relation-to-)/F 4/Rect[95.494623 621.993279 407.479242 606.393279]/Subtype/Link/Type/Annot>> -endobj -343 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[179.822016 600.393279 220.779779 586.79367]/Subtype/Link/Type/Annot>> -endobj -344 0 obj -<>/BS<>/Dest(RFC2426)/F 4/Rect[347.777338 573.194061 391.743158 559.594451]/Subtype/Link/Type/Annot>> -endobj -345 0 obj -<>/BS<>/Dest(RFC2426)/F 4/Rect[397.942377 573.194061 438.900141 559.594451]/Subtype/Link/Type/Annot>> -endobj -346 0 obj -<>/BS<>/Dest(RFC9554)/F 4/Rect[404.005365 393.598358 444.963129 379.998748]/Subtype/Link/Type/Annot>> -endobj -347 0 obj -<>/BS<>/Dest(RFC9555)/F 4/Rect[254.033197 379.998748 294.990961 366.399139]/Subtype/Link/Type/Annot>> -endobj -348 0 obj -<>/BS<>/Dest(RFC6351)/F 4/Rect[120.929438 342.799529 161.887201 329.19992]/Subtype/Link/Type/Annot>> -endobj -349 0 obj -<>/BS<>/Dest(RFC7095)/F 4/Rect[220.719721 342.799529 261.677484 329.19992]/Subtype/Link/Type/Annot>> -endobj -350 0 obj -<>/BS<>/Dest(section-1.2)/F 4/Rect[65.905512 273.901092 95.494623 258.301092]/Subtype/Link/Type/Annot>> -endobj -351 0 obj -<>/BS<>/Dest(name-notational-conventions)/F 4/Rect[95.494623 273.901092 239.129145 258.301092]/Subtype/Link/Type/Annot>> -endobj -352 0 obj -<>/BS<>/Dest(RFC2119)/F 4/Rect[249.76391 225.101873 290.721674 211.502264]/Subtype/Link/Type/Annot>> -endobj -353 0 obj -<>/BS<>/Dest(RFC8174)/F 4/Rect[300.520746 225.101873 341.47851 211.502264]/Subtype/Link/Type/Annot>> -endobj -354 0 obj -<>/BS<>/Dest(RFC5234)/F 4/Rect[352.532221 187.902654 393.489984 174.303045]/Subtype/Link/Type/Annot>> -endobj -355 0 obj -<>/BS<>/Dest(RFC5234)/F 4/Rect[240.495111 174.303045 281.452875 160.703436]/Subtype/Link/Type/Annot>> -endobj -356 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[216.058588 160.703436 257.016352 147.103826]/Subtype/Link/Type/Annot>> -endobj -2895 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2894 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2893 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2892 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2891 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2890 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2889 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2888 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2887 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2886 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2885 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2884 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2883 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2882 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2881 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2880 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2879 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2878 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1797 0 obj -<>stream -xœ½[IoG.„72cÄ‹¤d€> +ˆËµ/—A¡(J!l‘IIQãÁ8;@–ãòÓóêõÂ.6)V“M›6ÛÝ]ý¾ª¯ÞÞRÆ3ŸWáà§ÎykTößý_ûÔj¼Yñâ¯}8³&3JR˘u6sVS¥˜W:ûíýEÿ—>ÏÂç·Ÿû¯ÿÃ)Ë~þ½ž·¾z„s!¨æÞ8|æ}Í]9P>"”Î>¢ûá|ñ €Q—åëx[&™ ŽnÛÚí÷߬NÇkQÞÇiÕÎ?äç¼v^®výÀÓ]~œ¥Î*Ƶc.ó*3ÜR˜±Õ&ÓœS‰ÊÍj9|×½¥<S}8o}$ìû›~¥’œÉ|bþ s”À¦Ën>ö_¿Ý_œ}ŸqYLæžÝ¼ïÿø’<'OÈÑéO7—ý³›&fqÀ&̹V¥ãÍv²Ÿ«ˆe–êT¨.¨ŽµäÙ¬ mçç{ðl>YhK†êÂ%ïáD¢êRzëö‹–\{MÁ;sÅšÒÀ6x í¹u>ÊC f†œ£’ædÎáÂyð §ù+}ø|cDS|%¢½ØÅß.#Z,ï -*(› ½æH ,MÈåfNÔJz±‹c¬q¢ƒjœ¤B9°¨o›–öˆY)kbMiÛ‰Ì*–vP³J† ->æ#jp[Ã&5Ñá¿uÙ©s±Ô‘XÞAu$Šƒï˜?ÎýÈ:îVÉG¼S3¢Æ‘<°+®q” -ßÅ.R°=­|±¾'aÁ%zo/+V[Ìà ¦Ñ£œŒs\à˜\â†÷Qj;½¨©Í: ïáX>v{Jîáü«f«RÌ8‘ÙðSF:ÅWæ¼ d¹_‹ªËF.°;t†5D®¼s¬%ná¹ójß‚¬ÐR+Ô0¬>´5óŸÁå0èÛL?Ô¶°>…š‰œ—ôl^že¹1º´à•BB](µgjÐ%/#òcÑ…œ/·0¤œ§œ)®ýAñP­ …úÐÃJ ß:ÚE•ÖV$ õPä‚Z3¹u(øRj!Ü*™9pfVxeLi øb+'tŽ/†d6§næ«Š»šnàýFåÉuþ®Ö_Ôß Ý#j©ðÁ»ä¯'fØBžlÔ ±Ô!liÓ¡ï°(ÜÉÛbóÎ/öíÚRèß82Ó°œQ±À -¹‰‹%”þ=÷¶Ínôßð‰ŠÃº«Gìj&›—AË{Í<¯\rc½“¬xŸbuG;…ã}Éi-wfZÌh†Ö:Ç;ctÃk7£êßá3ójg(÷É›”ëܼ6ã(‡cªZÛ:Ó÷cRlïª`Áêuìò°3*\ÚnÞÃPÃòy Z°&ÙXÎ lZ{Ū0QZÅ&å®oéº}…zQmC4†…¤RÏr/;.Þ ­Dš¿GÖstV ¤ùnßbÀÝÆ»g,߀Õë+÷ÛÂXŠ·ñÂÂ’ç\Ù7½åm’PòÝU>‡òGò³µïä;5V: - Ó4y8³8&ÏÉѲ`H~Ag©€°mE:àw1¡¹,ž½‚ÄÕsïw6+~&¶-ÕSŠÍÓùìóýwXhpÊ3·óºÝ_aõÊ9gÒaöÚ]É-ÕPK@^ øݾd*H œWÜ»ƒ’©„§œe#ùH!óE½ÎL$S9E%SP>!™à´ñaý%Ó[*·®ÅÚ"2Û¾¬ÖšSï—-Lao2µaT(mYp·dj£)ƒÚèÈòËð{©0™Ê/Úÿþ€•Š'}:à§I/â\;=½(w˜¡ÌM@VgÚSå óÒÆ fóÚ#_A`?jv=g I© ®lP£Ll‡dŒ¢‚ «¶#12À“øg .Ï–q!™7yŸÐVj¾Ã`ùsÕ[‹À×k2}xÿgQL[r©å`öZ¦€ç=š¼Ì˜cç¢l· ¡njG­ƒ þòÁ-Àá'€.±Â9ZUÆIÿ/q51 -endstream -endobj -1648 0 obj -<>/Font<>>> -endobj -277 0 obj -<>/BS<>/Dest(section-3.5)/F 4/Rect[77.905512 771.389764 91.584955 758.389764]/Subtype/Link/Type/Annot>> -endobj -278 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-p)/F 4/Rect[99.283441 771.389764 310.847162 758.389764]/Subtype/Link/Type/Annot>> -endobj -279 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-p)/F 4/Rect[518.190391 771.389764 529.370079 758.389764]/Subtype/Link/Type/Annot>> -endobj -280 0 obj -<>/BS<>/Dest(section-3.5.1)/F 4/Rect[89.905512 750.889764 111.674555 737.889764]/Subtype/Link/Type/Annot>> -endobj -281 0 obj -<>/BS<>/Dest(name-jscontact-properties-regist)/F 4/Rect[119.373041 750.889764 304.461908 737.889764]/Subtype/Link/Type/Annot>> -endobj -282 0 obj -<>/BS<>/Dest(name-jscontact-properties-regist)/F 4/Rect[518.190391 750.889764 529.370079 737.889764]/Subtype/Link/Type/Annot>> -endobj -283 0 obj -<>/BS<>/Dest(section-3.5.2)/F 4/Rect[89.905512 730.389764 111.674555 717.389764]/Subtype/Link/Type/Annot>> -endobj -284 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsco)/F 4/Rect[119.373041 730.389764 363.242426 717.389764]/Subtype/Link/Type/Annot>> -endobj -285 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsco)/F 4/Rect[518.190391 730.389764 529.370079 717.389764]/Subtype/Link/Type/Annot>> -endobj -286 0 obj -<>/BS<>/Dest(section-3.6)/F 4/Rect[77.905512 707.389764 91.584955 694.389764]/Subtype/Link/Type/Annot>> -endobj -287 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-t)/F 4/Rect[99.283441 707.389764 289.330072 694.389764]/Subtype/Link/Type/Annot>> -endobj -288 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-t)/F 4/Rect[518.190391 707.389764 529.370079 694.389764]/Subtype/Link/Type/Annot>> -endobj -289 0 obj -<>/BS<>/Dest(section-3.6.1)/F 4/Rect[89.905512 686.889764 111.674555 673.889764]/Subtype/Link/Type/Annot>> -endobj -290 0 obj -<>/BS<>/Dest(name-jscontact-types-registry-te)/F 4/Rect[119.373041 686.889764 282.944818 673.889764]/Subtype/Link/Type/Annot>> -endobj -291 0 obj -<>/BS<>/Dest(name-jscontact-types-registry-te)/F 4/Rect[518.190391 686.889764 529.370079 673.889764]/Subtype/Link/Type/Annot>> -endobj -292 0 obj -<>/BS<>/Dest(section-3.6.2)/F 4/Rect[89.905512 666.389764 111.674555 653.389764]/Subtype/Link/Type/Annot>> -endobj -293 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscon)/F 4/Rect[119.373041 666.389764 341.725336 653.389764]/Subtype/Link/Type/Annot>> -endobj -294 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscon)/F 4/Rect[518.190391 666.389764 529.370079 653.389764]/Subtype/Link/Type/Annot>> -endobj -295 0 obj -<>/BS<>/Dest(section-3.7)/F 4/Rect[77.905512 643.389764 91.584955 630.389764]/Subtype/Link/Type/Annot>> -endobj -296 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-e)/F 4/Rect[99.283441 643.389764 323.716547 630.389764]/Subtype/Link/Type/Annot>> -endobj -297 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-e)/F 4/Rect[518.190391 643.389764 529.370079 630.389764]/Subtype/Link/Type/Annot>> -endobj -298 0 obj -<>/BS<>/Dest(section-3.7.1)/F 4/Rect[89.905512 622.889764 111.674555 609.889764]/Subtype/Link/Type/Annot>> -endobj -299 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regis)/F 4/Rect[119.373041 622.889764 361.815668 609.889764]/Subtype/Link/Type/Annot>> -endobj -300 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regis)/F 4/Rect[518.190391 622.889764 529.370079 609.889764]/Subtype/Link/Type/Annot>> -endobj -301 0 obj -<>/BS<>/Dest(section-3.7.2)/F 4/Rect[89.905512 602.389764 111.674555 589.389764]/Subtype/Link/Type/Annot>> -endobj -302 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regist)/F 4/Rect[119.373041 602.389764 346.507318 589.389764]/Subtype/Link/Type/Annot>> -endobj -303 0 obj -<>/BS<>/Dest(name-jscontact-enum-values-regist)/F 4/Rect[518.190391 602.389764 529.370079 589.389764]/Subtype/Link/Type/Annot>> -endobj -304 0 obj -<>/BS<>/Dest(section-3.7.3)/F 4/Rect[89.905512 581.889764 111.674555 568.889764]/Subtype/Link/Type/Annot>> -endobj -305 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscont)/F 4/Rect[119.373041 581.889764 376.111811 568.889764]/Subtype/Link/Type/Annot>> -endobj -306 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jscont)/F 4/Rect[518.190391 581.889764 529.370079 568.889764]/Subtype/Link/Type/Annot>> -endobj -307 0 obj -<>/BS<>/Dest(section-4)/F 4/Rect[65.905512 558.889764 71.495356 545.889764]/Subtype/Link/Type/Annot>> -endobj -308 0 obj -<>/BS<>/Dest(name-security-considerations)/F 4/Rect[79.193842 558.889764 192.069574 545.889764]/Subtype/Link/Type/Annot>> -endobj -309 0 obj -<>/BS<>/Dest(name-security-considerations)/F 4/Rect[518.190391 558.889764 529.370079 545.889764]/Subtype/Link/Type/Annot>> -endobj -310 0 obj -<>/BS<>/Dest(section-4.1)/F 4/Rect[77.905512 538.389764 91.584955 525.389764]/Subtype/Link/Type/Annot>> -endobj -311 0 obj -<>/BS<>/Dest(name-json-parsing)/F 4/Rect[99.283441 538.389764 161.857904 525.389764]/Subtype/Link/Type/Annot>> -endobj -312 0 obj -<>/BS<>/Dest(name-json-parsing)/F 4/Rect[518.190391 538.389764 529.370079 525.389764]/Subtype/Link/Type/Annot>> -endobj -313 0 obj -<>/BS<>/Dest(section-4.2)/F 4/Rect[77.905512 517.889764 91.584955 504.889764]/Subtype/Link/Type/Annot>> -endobj -314 0 obj -<>/BS<>/Dest(name-uri-values)/F 4/Rect[99.283441 517.889764 150.36767 504.889764]/Subtype/Link/Type/Annot>> -endobj -315 0 obj -<>/BS<>/Dest(name-uri-values)/F 4/Rect[518.190391 517.889764 529.370079 504.889764]/Subtype/Link/Type/Annot>> -endobj -316 0 obj -<>/BS<>/Dest(section-5)/F 4/Rect[65.905512 494.889764 71.495356 481.889764]/Subtype/Link/Type/Annot>> -endobj -317 0 obj -<>/BS<>/Dest(name-references)/F 4/Rect[79.193842 494.889764 131.429438 481.889764]/Subtype/Link/Type/Annot>> -endobj -318 0 obj -<>/BS<>/Dest(name-references)/F 4/Rect[518.190391 494.889764 529.370079 481.889764]/Subtype/Link/Type/Annot>> -endobj -319 0 obj -<>/BS<>/Dest(section-5.1)/F 4/Rect[77.905512 474.389764 91.584955 461.389764]/Subtype/Link/Type/Annot>> -endobj -320 0 obj -<>/BS<>/Dest(name-normative-references)/F 4/Rect[99.283441 474.389764 205.163813 461.389764]/Subtype/Link/Type/Annot>> -endobj -321 0 obj -<>/BS<>/Dest(name-normative-references)/F 4/Rect[518.190391 474.389764 529.370079 461.389764]/Subtype/Link/Type/Annot>> -endobj -322 0 obj -<>/BS<>/Dest(section-5.2)/F 4/Rect[77.905512 453.889764 91.584955 440.889764]/Subtype/Link/Type/Annot>> -endobj -323 0 obj -<>/BS<>/Dest(name-informative-references)/F 4/Rect[99.283441 453.889764 211.342524 440.889764]/Subtype/Link/Type/Annot>> -endobj -324 0 obj -<>/BS<>/Dest(name-informative-references)/F 4/Rect[518.190391 453.889764 529.370079 440.889764]/Subtype/Link/Type/Annot>> -endobj -325 0 obj -<>/BS<>/Dest(appendix-A)/F 4/Rect[65.905512 430.889764 65.905512 417.889764]/Subtype/Link/Type/Annot>> -endobj -326 0 obj -<>/BS<>/Dest(name-authors-addresses)/F 4/Rect[65.905512 430.889764 156.823969 417.889764]/Subtype/Link/Type/Annot>> -endobj -327 0 obj -<>/BS<>/Dest(name-authors-addresses)/F 4/Rect[518.190391 430.889764 529.370079 417.889764]/Subtype/Link/Type/Annot>> -endobj -328 0 obj -<>/BS<>/Dest(section-1)/F 4/Rect[65.905512 369.789764 89.131635 351.069764]/Subtype/Link/Type/Annot>> -endobj -329 0 obj -<>/BS<>/Dest(name-introduction)/F 4/Rect[89.131635 369.789764 182.568891 351.069764]/Subtype/Link/Type/Annot>> -endobj -330 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[69.505365 316.670545 110.463129 303.070936]/Subtype/Link/Type/Annot>> -endobj -331 0 obj -<>/BS<>/Dest(RFC6350)/F 4/Rect[197.211664 255.871717 238.169428 242.272108]/Subtype/Link/Type/Annot>> -endobj -332 0 obj -<>/BS<>/Dest(RFC6473)/F 4/Rect[322.270502 255.871717 363.228266 242.272108]/Subtype/Link/Type/Annot>> -endobj -333 0 obj -<>/BS<>/Dest(RFC6474)/F 4/Rect[373.027338 255.871717 413.985102 242.272108]/Subtype/Link/Type/Annot>> -endobj -334 0 obj -<>/BS<>/Dest(RFC6715)/F 4/Rect[423.784174 255.871717 464.741938 242.272108]/Subtype/Link/Type/Annot>> -endobj -335 0 obj -<>/BS<>/Dest(RFC6869)/F 4/Rect[474.54101 255.871717 515.498774 242.272108]/Subtype/Link/Type/Annot>> -endobj -336 0 obj -<>/BS<>/Dest(RFC8605)/F 4/Rect[89.505365 242.272108 130.463129 228.672498]/Subtype/Link/Type/Annot>> -endobj -2955 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2954 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2953 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2952 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2951 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2950 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2949 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2948 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2947 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2946 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2945 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2944 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2943 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2942 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2941 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2940 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2939 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2938 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2937 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2936 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2935 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2934 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2933 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2932 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2931 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2930 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2929 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2928 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2927 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2926 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2925 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2924 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2923 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2922 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2921 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2920 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2919 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2918 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2917 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2916 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2915 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2914 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2913 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2912 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2911 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2910 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2909 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2908 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2907 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2906 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2905 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2904 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2903 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2902 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2901 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2900 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2899 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2898 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2897 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2896 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1796 0 obj -<>stream -xœ½›ÏsÓ8Ç5“›o KÒR>0Ý–W²-ɺ2!IK§4ý•å°0[.eg`÷Ø?}Ÿd;¶l'}‰¥Åc'y_÷ã÷CzrCRØÞè]–²(Ë”iøíGð3ˆ$7o–{sògGR„"M"I©Ìd˜I¥)U)ý,‚¿êí×÷àèÑðûßþ¾T˯0ÇgJdæ;÷Á60Ͳò òÃHñð¡|°Þ×Ç‹W eaþ·®÷ÈE憭·eííûWÍËQ<.ß7—U;~ÈYí¸þ½ÚyÏ—[m™Œ2™RÆ3š…* “\±ä"Ì’¤q³6üø¶÷6b‰þ.÷Jïb%•eìíU°tIÆT~a"d®1šYxõ#8:›}:~÷6dIdŒ%píáÕ}ðù€<#OÈ^£Ã/W'Á»«¶n±QK+Í¢L©”n õ„|%_WêX?Ÿ%ÅUÄDJ9ÇK]’k2#Çðº6ÿ›’#2&srBnagnÌ…T"4Y²K²ˆSÁà~€HÁhc>pSKb™6ìyà“ÄQ"¥Šc¼Ô>Pøæ@f „N ›a4…½ òÞp»…Ï•ï&ðÉ `«©.àl›bͯݪ’"¼~ëái–M¿ž†•š4H®!1Ïdœñ¸AäY"–M¿D°R7¾óò0¦pfj¢ñ¶uÇIÛwv¶@Ûž×DKµ‰TÑwQ¦ýJÇØœÛ,òb¨¡-?Ûéy¶M¯~†–ãý)cmÚíáO–=¿þ„•â†ÃÄÜ5øÎlCŸI¨jûÌn?Ÿ±mzõ´ÔXÜÝ” ‰LÎô‰5dÑ ìöËÚ¶M¿d°RSðKƒæú1ZSö "ß>ËÚö¼fY´5cMË‘Í­ÿm–mÓ´#Û>ï—mm›^}-õ¡ÇhV_jã™Õ•:•ªíC{=|Ȳçׇ°RÕÈïtIdsâ0nùÐ^?²mzõ!´”ÏÅGC妘­®%“¤íŠ½×¯bÛ6ý’ÁJU×O¦dO×AÉy¯_Á¶mú…‚•š‰Åz÷È:’ï^¿‚mÛôK+uYL™^^Ãþ˜\Ø\¬V¦`仩o(AÖe)m[óÀ„òˆ+&3…—zM^¯ÙÏ ¤’©ædB S DÚH»ÃmRnU l{^ ZŠ–C=à$óé’žOêæ œ¾L `«qÉF.n“‡k¸¤ç<\Ã…•Ú7ó¦z·æmÇï ·7DOéùUƒ¥F< ¯Lñ¿%—+aJÚÈáÃmòwÓ¶ç&ZªLXôr’–M²}À›·ô«fǤh;^¯­2VíÞ*Ž« -`ÛôZÐR‰á Ñ›Éʸ$ª½ñ¶[3²Zä'5ùfhõi59.Úá¼UH×Èñÿ­‚–€æ¡V뜙¯˜É ¬%«YeIG´öqÙ6ý²ÂJýn¸œBÎMœ™è¼; Ÿ—3œseŒu‡e™mÓ+0´Ô¦‰«*扃¦KõX™´íy-h©mª©:f&tm1ÿV³¬v;ÑQ z.TÚ6ýºVj[pzxÈÍÇÎ!¢?äA¾§ê(=W9m›~qb¥^µó´èÝ”hgæß·~ ?ͼxfeýOÕù\ˆP4R1åúìÃê~9RÆ>š0¬ -¤#eìR¾{eì’ù°Êân”ÑËÐ˷K¥Cò­2zùѽ2vyoDž:VÆ.¡ªBêH»då\½L4r=ÑK.Ë#×ñŒ^"p¯ŒmÁª§’)cûÜ£êùGÊؾ²set÷vT­:RÆvDÝ+c›‹#×݉s¯Œí[í¸®Uè¾{elŹ2ºá^;Õßq]ŸÑsa÷ÊØicC¹T§Ææ*!ÉC˜¡¦JP•H[!^öÍïa~9 /@b§=‘Y/=R°G…ZóØÍ”„H£˜Æ2}\‰’±Ye2-ˆgä)¼ZuþQnJÊ(æ2á¬SC˜û¥éÇÍÈ™n\þ“?€{wÿoñ›²ä4b"“<Áˆ—ŽOMÓ@.—Ö&älC´0ÿQJˆL<&œ¿1°æÛa‹D» -endstream -endobj -1646 0 obj -<>/Font<>>> -endobj -188 0 obj -<>/BS<>/Dest(section-2.3.4)/F 4/Rect[89.905512 771.389764 111.674555 758.389764]/Subtype/Link/Type/Annot>> -endobj -189 0 obj -<>/BS<>/Dest(name-preferredlanguages)/F 4/Rect[119.373041 771.389764 216.423334 758.389764]/Subtype/Link/Type/Annot>> -endobj -190 0 obj -<>/BS<>/Dest(name-preferredlanguages)/F 4/Rect[518.190391 771.389764 529.370079 758.389764]/Subtype/Link/Type/Annot>> -endobj -191 0 obj -<>/BS<>/Dest(section-2.4)/F 4/Rect[77.905512 748.389764 91.584955 735.389764]/Subtype/Link/Type/Annot>> -endobj -192 0 obj -<>/BS<>/Dest(name-calendaring-and-scheduling-)/F 4/Rect[99.283441 748.389764 285.443109 735.389764]/Subtype/Link/Type/Annot>> -endobj -193 0 obj -<>/BS<>/Dest(name-calendaring-and-scheduling-)/F 4/Rect[518.190391 748.389764 529.370079 735.389764]/Subtype/Link/Type/Annot>> -endobj -194 0 obj -<>/BS<>/Dest(section-2.4.1)/F 4/Rect[89.905512 727.889764 111.674555 714.889764]/Subtype/Link/Type/Annot>> -endobj -195 0 obj -<>/BS<>/Dest(name-calendars)/F 4/Rect[119.373041 727.889764 165.808588 714.889764]/Subtype/Link/Type/Annot>> -endobj -196 0 obj -<>/BS<>/Dest(name-calendars)/F 4/Rect[518.190391 727.889764 529.370079 714.889764]/Subtype/Link/Type/Annot>> -endobj -197 0 obj -<>/BS<>/Dest(section-2.4.2)/F 4/Rect[89.905512 707.389764 111.674555 694.389764]/Subtype/Link/Type/Annot>> -endobj -198 0 obj -<>/BS<>/Dest(name-schedulingaddresses)/F 4/Rect[119.373041 707.389764 219.182367 694.389764]/Subtype/Link/Type/Annot>> -endobj -199 0 obj -<>/BS<>/Dest(name-schedulingaddresses)/F 4/Rect[518.190391 707.389764 529.370079 694.389764]/Subtype/Link/Type/Annot>> -endobj -200 0 obj -<>/BS<>/Dest(section-2.5)/F 4/Rect[77.905512 684.389764 91.584955 671.389764]/Subtype/Link/Type/Annot>> -endobj -201 0 obj -<>/BS<>/Dest(name-address-and-location-proper)/F 4/Rect[99.283441 684.389764 254.284418 671.389764]/Subtype/Link/Type/Annot>> -endobj -202 0 obj -<>/BS<>/Dest(name-address-and-location-proper)/F 4/Rect[518.190391 684.389764 529.370079 671.389764]/Subtype/Link/Type/Annot>> -endobj -203 0 obj -<>/BS<>/Dest(section-2.5.1)/F 4/Rect[89.905512 663.889764 111.674555 650.889764]/Subtype/Link/Type/Annot>> -endobj -204 0 obj -<>/BS<>/Dest(name-addresses)/F 4/Rect[119.373041 663.889764 166.218012 650.889764]/Subtype/Link/Type/Annot>> -endobj -205 0 obj -<>/BS<>/Dest(name-addresses)/F 4/Rect[518.190391 663.889764 529.370079 650.889764]/Subtype/Link/Type/Annot>> -endobj -206 0 obj -<>/BS<>/Dest(section-2.6)/F 4/Rect[77.905512 640.889764 91.584955 627.889764]/Subtype/Link/Type/Annot>> -endobj -207 0 obj -<>/BS<>/Dest(name-resource-properties)/F 4/Rect[99.283441 640.889764 194.693109 627.889764]/Subtype/Link/Type/Annot>> -endobj -208 0 obj -<>/BS<>/Dest(name-resource-properties)/F 4/Rect[518.190391 640.889764 529.370079 627.889764]/Subtype/Link/Type/Annot>> -endobj -209 0 obj -<>/BS<>/Dest(section-2.6.1)/F 4/Rect[89.905512 620.389764 111.674555 607.389764]/Subtype/Link/Type/Annot>> -endobj -210 0 obj -<>/BS<>/Dest(name-cryptokeys)/F 4/Rect[119.373041 620.389764 172.386469 607.389764]/Subtype/Link/Type/Annot>> -endobj -211 0 obj -<>/BS<>/Dest(name-cryptokeys)/F 4/Rect[518.190391 620.389764 529.370079 607.389764]/Subtype/Link/Type/Annot>> -endobj -212 0 obj -<>/BS<>/Dest(section-2.6.2)/F 4/Rect[89.905512 599.889764 111.674555 586.889764]/Subtype/Link/Type/Annot>> -endobj -213 0 obj -<>/BS<>/Dest(name-directories)/F 4/Rect[119.373041 599.889764 170.746576 586.889764]/Subtype/Link/Type/Annot>> -endobj -214 0 obj -<>/BS<>/Dest(name-directories)/F 4/Rect[518.190391 599.889764 529.370079 586.889764]/Subtype/Link/Type/Annot>> -endobj -215 0 obj -<>/BS<>/Dest(section-2.6.3)/F 4/Rect[89.905512 579.389764 111.674555 566.389764]/Subtype/Link/Type/Annot>> -endobj -216 0 obj -<>/BS<>/Dest(name-links)/F 4/Rect[119.373041 579.389764 142.480951 566.389764]/Subtype/Link/Type/Annot>> -endobj -217 0 obj -<>/BS<>/Dest(name-links)/F 4/Rect[518.190391 579.389764 529.370079 566.389764]/Subtype/Link/Type/Annot>> -endobj -218 0 obj -<>/BS<>/Dest(section-2.6.4)/F 4/Rect[89.905512 558.889764 111.674555 545.889764]/Subtype/Link/Type/Annot>> -endobj -219 0 obj -<>/BS<>/Dest(name-media)/F 4/Rect[119.373041 558.889764 149.140131 545.889764]/Subtype/Link/Type/Annot>> -endobj -220 0 obj -<>/BS<>/Dest(name-media)/F 4/Rect[518.190391 558.889764 529.370079 545.889764]/Subtype/Link/Type/Annot>> -endobj -221 0 obj -<>/BS<>/Dest(section-2.7)/F 4/Rect[77.905512 535.889764 91.584955 522.889764]/Subtype/Link/Type/Annot>> -endobj -222 0 obj -<>/BS<>/Dest(name-multilingual-properties)/F 4/Rect[99.283441 535.889764 209.930414 522.889764]/Subtype/Link/Type/Annot>> -endobj -223 0 obj -<>/BS<>/Dest(name-multilingual-properties)/F 4/Rect[518.190391 535.889764 529.370079 522.889764]/Subtype/Link/Type/Annot>> -endobj -224 0 obj -<>/BS<>/Dest(section-2.7.1)/F 4/Rect[89.905512 515.389764 111.674555 502.389764]/Subtype/Link/Type/Annot>> -endobj -225 0 obj -<>/BS<>/Dest(name-localizations)/F 4/Rect[119.373041 515.389764 179.275629 502.389764]/Subtype/Link/Type/Annot>> -endobj -226 0 obj -<>/BS<>/Dest(name-localizations)/F 4/Rect[518.190391 515.389764 529.370079 502.389764]/Subtype/Link/Type/Annot>> -endobj -227 0 obj -<>/BS<>/Dest(section-2.8)/F 4/Rect[77.905512 492.389764 91.584955 479.389764]/Subtype/Link/Type/Annot>> -endobj -228 0 obj -<>/BS<>/Dest(name-additional-properties)/F 4/Rect[99.283441 492.389764 201.169916 479.389764]/Subtype/Link/Type/Annot>> -endobj -229 0 obj -<>/BS<>/Dest(name-additional-properties)/F 4/Rect[518.190391 492.389764 529.370079 479.389764]/Subtype/Link/Type/Annot>> -endobj -230 0 obj -<>/BS<>/Dest(section-2.8.1)/F 4/Rect[89.905512 471.889764 111.674555 458.889764]/Subtype/Link/Type/Annot>> -endobj -231 0 obj -<>/BS<>/Dest(name-anniversaries)/F 4/Rect[119.373041 471.889764 184.856684 458.889764]/Subtype/Link/Type/Annot>> -endobj -232 0 obj -<>/BS<>/Dest(name-anniversaries)/F 4/Rect[518.190391 471.889764 529.370079 458.889764]/Subtype/Link/Type/Annot>> -endobj -233 0 obj -<>/BS<>/Dest(section-2.8.2)/F 4/Rect[89.905512 451.389764 111.674555 438.389764]/Subtype/Link/Type/Annot>> -endobj -234 0 obj -<>/BS<>/Dest(name-keywords)/F 4/Rect[119.373041 451.389764 165.767572 438.389764]/Subtype/Link/Type/Annot>> -endobj -235 0 obj -<>/BS<>/Dest(name-keywords)/F 4/Rect[518.190391 451.389764 529.370079 438.389764]/Subtype/Link/Type/Annot>> -endobj -236 0 obj -<>/BS<>/Dest(section-2.8.3)/F 4/Rect[89.905512 430.889764 111.674555 417.889764]/Subtype/Link/Type/Annot>> -endobj -237 0 obj -<>/BS<>/Dest(name-notes)/F 4/Rect[119.373041 430.889764 144.970453 417.889764]/Subtype/Link/Type/Annot>> -endobj -238 0 obj -<>/BS<>/Dest(name-notes)/F 4/Rect[518.190391 430.889764 529.370079 417.889764]/Subtype/Link/Type/Annot>> -endobj -239 0 obj -<>/BS<>/Dest(section-2.8.4)/F 4/Rect[89.905512 410.389764 111.674555 397.389764]/Subtype/Link/Type/Annot>> -endobj -240 0 obj -<>/BS<>/Dest(name-personalinfo)/F 4/Rect[119.373041 410.389764 180.60644 397.389764]/Subtype/Link/Type/Annot>> -endobj -241 0 obj -<>/BS<>/Dest(name-personalinfo)/F 4/Rect[518.190391 410.389764 529.370079 397.389764]/Subtype/Link/Type/Annot>> -endobj -242 0 obj -<>/BS<>/Dest(section-3)/F 4/Rect[65.905512 387.389764 71.495356 374.389764]/Subtype/Link/Type/Annot>> -endobj -243 0 obj -<>/BS<>/Dest(name-iana-considerations)/F 4/Rect[79.193842 387.389764 178.33227 374.389764]/Subtype/Link/Type/Annot>> -endobj -244 0 obj -<>/BS<>/Dest(name-iana-considerations)/F 4/Rect[518.190391 387.389764 529.370079 374.389764]/Subtype/Link/Type/Annot>> -endobj -245 0 obj -<>/BS<>/Dest(section-3.1)/F 4/Rect[77.905512 366.889764 91.584955 353.889764]/Subtype/Link/Type/Annot>> -endobj -246 0 obj -<>/BS<>/Dest(name-media-type-registration)/F 4/Rect[99.283441 366.889764 215.039057 353.889764]/Subtype/Link/Type/Annot>> -endobj -247 0 obj -<>/BS<>/Dest(name-media-type-registration)/F 4/Rect[518.190391 366.889764 529.370079 353.889764]/Subtype/Link/Type/Annot>> -endobj -248 0 obj -<>/BS<>/Dest(section-3.2)/F 4/Rect[77.905512 346.389764 91.584955 333.389764]/Subtype/Link/Type/Annot>> -endobj -249 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-r)/F 4/Rect[99.283441 346.389764 291.659906 333.389764]/Subtype/Link/Type/Annot>> -endobj -250 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-r)/F 4/Rect[518.190391 346.389764 529.370079 333.389764]/Subtype/Link/Type/Annot>> -endobj -251 0 obj -<>/BS<>/Dest(section-3.3)/F 4/Rect[77.905512 325.889764 91.584955 312.889764]/Subtype/Link/Type/Annot>> -endobj -252 0 obj -<>/BS<>/Dest(name-registry-policy-and-change-)/F 4/Rect[99.283441 325.889764 284.592768 312.889764]/Subtype/Link/Type/Annot>> -endobj -253 0 obj -<>/BS<>/Dest(name-registry-policy-and-change-)/F 4/Rect[518.190391 325.889764 529.370079 312.889764]/Subtype/Link/Type/Annot>> -endobj -254 0 obj -<>/BS<>/Dest(section-3.3.1)/F 4/Rect[89.905512 305.389764 111.674555 292.389764]/Subtype/Link/Type/Annot>> -endobj -255 0 obj -<>/BS<>/Dest(name-preliminary-community-revie)/F 4/Rect[119.373041 305.389764 272.897455 292.389764]/Subtype/Link/Type/Annot>> -endobj -256 0 obj -<>/BS<>/Dest(name-preliminary-community-revie)/F 4/Rect[518.190391 305.389764 529.370079 292.389764]/Subtype/Link/Type/Annot>> -endobj -257 0 obj -<>/BS<>/Dest(section-3.3.2)/F 4/Rect[89.905512 284.889764 111.674555 271.889764]/Subtype/Link/Type/Annot>> -endobj -258 0 obj -<>/BS<>/Dest(name-submit-request-to-iana)/F 4/Rect[119.373041 284.889764 233.730463 271.889764]/Subtype/Link/Type/Annot>> -endobj -259 0 obj -<>/BS<>/Dest(name-submit-request-to-iana)/F 4/Rect[518.190391 284.889764 529.370079 271.889764]/Subtype/Link/Type/Annot>> -endobj -260 0 obj -<>/BS<>/Dest(section-3.3.3)/F 4/Rect[89.905512 264.389764 111.674555 251.389764]/Subtype/Link/Type/Annot>> -endobj -261 0 obj -<>/BS<>/Dest(name-designated-expert-review)/F 4/Rect[119.373041 264.389764 243.959467 251.389764]/Subtype/Link/Type/Annot>> -endobj -262 0 obj -<>/BS<>/Dest(name-designated-expert-review)/F 4/Rect[518.190391 264.389764 529.370079 251.389764]/Subtype/Link/Type/Annot>> -endobj -263 0 obj -<>/BS<>/Dest(section-3.3.4)/F 4/Rect[89.905512 243.889764 111.674555 230.889764]/Subtype/Link/Type/Annot>> -endobj -264 0 obj -<>/BS<>/Dest(name-change-procedures)/F 4/Rect[119.373041 243.889764 211.114008 230.889764]/Subtype/Link/Type/Annot>> -endobj -265 0 obj -<>/BS<>/Dest(name-change-procedures)/F 4/Rect[518.190391 243.889764 529.370079 230.889764]/Subtype/Link/Type/Annot>> -endobj -266 0 obj -<>/BS<>/Dest(section-3.4)/F 4/Rect[77.905512 220.889764 91.584955 207.889764]/Subtype/Link/Type/Annot>> -endobj -267 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-v)/F 4/Rect[99.283441 220.889764 297.688471 207.889764]/Subtype/Link/Type/Annot>> -endobj -268 0 obj -<>/BS<>/Dest(name-creation-of-the-jscontact-v)/F 4/Rect[518.190391 220.889764 529.370079 207.889764]/Subtype/Link/Type/Annot>> -endobj -269 0 obj -<>/BS<>/Dest(section-3.4.1)/F 4/Rect[89.905512 200.389764 111.674555 187.389764]/Subtype/Link/Type/Annot>> -endobj -270 0 obj -<>/BS<>/Dest(name-jscontact-version-registry-)/F 4/Rect[119.373041 200.389764 291.303217 187.389764]/Subtype/Link/Type/Annot>> -endobj -271 0 obj -<>/BS<>/Dest(name-jscontact-version-registry-)/F 4/Rect[518.190391 200.389764 529.370079 187.389764]/Subtype/Link/Type/Annot>> -endobj -272 0 obj -<>/BS<>/Dest(section-3.4.2)/F 4/Rect[89.905512 179.889764 111.674555 166.889764]/Subtype/Link/Type/Annot>> -endobj -273 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsc)/F 4/Rect[119.373041 179.889764 350.083734 166.889764]/Subtype/Link/Type/Annot>> -endobj -274 0 obj -<>/BS<>/Dest(name-initial-contents-of-the-jsc)/F 4/Rect[518.190391 179.889764 529.370079 166.889764]/Subtype/Link/Type/Annot>> -endobj -3042 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3041 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3040 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3039 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3038 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3037 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3036 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3035 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3034 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3033 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3032 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3031 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3030 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3029 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3028 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3027 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3026 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3025 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3024 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3023 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3022 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3021 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3020 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3019 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3018 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3017 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3016 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3015 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3014 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3013 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3012 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3011 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3010 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3009 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3008 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3007 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3006 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3005 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3004 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3003 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3002 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3001 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3000 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2999 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2998 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2997 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2996 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2995 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2994 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2993 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2992 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2991 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2990 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2989 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2988 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2987 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2986 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2985 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2984 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2983 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2982 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2981 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2980 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2979 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2978 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2977 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2976 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2975 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2974 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2973 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2972 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2971 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2970 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2969 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2968 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2967 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2966 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2965 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2964 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2963 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2962 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2961 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2960 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2959 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2958 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2957 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -2956 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1795 0 obj -<>stream -xœ½›ËoÛF‡ð§µ7ñ@ à -zÜ×5°-ÕlËÏ<”CԹؒöØCÿôWj%RŠ»ŽB1¥ù¨Ÿffwg˜”¥o‹ÉYfŒÕ*O¿<&ß’LKwr¶w/~KàH«Tå"Ó”j£S£e–çÔæ2ýþgr›ü•°´x|ÿšüÁ2š~ý;)>¯íü#ŒqžIf•qŸ¹OFðÓÌÌÞ”G‡’éÃùà/Žoß,3éäï"œöNë…Ó÷o–/ÇJ>;ï.káøarÌŽ?·ðzäË-FgFç”ICMjóT1Ák©R#ÄÒÕðí›þ¶ÅŸt¾·ÅŽ[m=cï®’¹K2f'¦RFá¨iÒ«Çäàtðñ·£w)™3&àÚÓ«ûäÓ>Ù&/È+Ø^ö>_$GW«Üé +7™±6§ X/ȹ«åxßÏCI›1•S)ñ(CFä¶ òž·ˆ ×ðïK2€ý-ÂþÆ]H¥vBfLs#yYÐh§…FžÍ¸aQã}æ=9/DéqºOAšéƒ\¶§Üñœ_•ŠŠ¹TJ.üS©^7• üŸ1Áu¾d/‚L‚gBkË95ÑbZõÁ…®ÉD9G:&ÃñÝ¿°Û*”üä´‘p®‹b_ï^ú+îõ¶íîåÙŒë^XB·&QÉ9Í$U ²¤/[gsÙ|›QeC£²a£“Ã`ºâi»›G§o/jt¢Q3¹®ç‘7„í¤Þ´Yu£ÝvÑçÛŒëFXÔª.¦z½^,¼êÜ%û-x¹„/á­WàNC87pCÂÎ×G£ ‰·]4ú6£ÊˆFí&×N“‘ÓkEV_!of(„ò]­©6Vfw,§«Ö"¨’HË´±xÔøÏ5é×& ¡„ï%M­L@¾½¨ ¢à · CßEÔaÃQMØ¥íj—Ž|›qã‹ú” Qj¥ÈÙRfžIÑ"¥ø6£JF}¨O‹jä²"t`ë¶P#¶‹F»ä:]yÔ«¡Eu˜´X¶ú6ãªEºÙK½’Òêi±4õmFÕ:s“|á¹>gH®«£ä§zðg+g QçnRv4ÉõjHY%¯Z¨!Ÿ­pF]º¶O~])†WGJãêÄ‚žÍ¸Z`QEö<›WntOüZUµÕñÒxUXªâÛŒª -U,dê}C ]3é"?6ÕAªLH.[²º^‡ T€ù(“LH‹½‡Hé׌­å$]©ŠÚxÎUNÒ}{Q'éhŠZ.x9DΉ;’ÏN£Ù*¹Éô]ÙŠŒ»Ñ"g!žì³e\4j4ѯVÍ+²íF~TêàÛŒªUx˱k,Lü©Þ3t^‘i;íæï¾Í¸Š`Q5q´F]‘};íæò¾Í¸Ê`Q7.‡‚·LGeòËU Í«#¨ÅÌÞ·U4ªð[˜±¬«[›åÜFqSŽH&vó­‘Ш=%EÁèØ›Œ:FUdÛn»QÇ·×W°¨+SÁ[Öha*òl·ÝÈãÛŒ«UxË™« ˆr^òÁEëüIJŠLÛm7ù6£jƒF]’ß>3-8šÞá±\y…²4³œÊ¢GŒ¿‹b'0›G“±}ñðdlg98ÝœÝ. KÈØ>çvYÄ DÆvƒ“ÑÍ·ðdlc+<ÛNÚ. TÈØMp2º#žŒí>„'c+ýÁÉèÚúvYì DÆV±Ã“±ãNYØ DÆÖgƒ“Ñ5ÐN¹DÆÖÓ±u¾N9íDÆVÈ‚“Ñ5©Nè9 ºöžŒ­­tBÏèúE'tCW “±ëððd쪷:{¢×”]?‡ÍèÔÙ¬i™Âò5·£…öUåS»’Œ{dl‘]²îò×[ªXÜ+­Ø“ ·DùE¦f$¥òŒS®ó§I”ºÛÇÇcøZ0ÞÁö²¬ø!ú\j!Y%C¹&Ö¥+4Èiq3ã?ðt@.Æ÷ÿ¹&hÚöÄk)iÆ”ÑR`à“¾‘»ÝÜYÏï™?&§ ¥5,³V)£ž‹Éí€ë.;ã(ù½Rw -endstream -endobj -1644 0 obj -<>/Font<>>> -endobj -96 0 obj -<>/BS<>/Dest(section-1.7.4)/F 4/Rect[89.905512 771.389764 111.674555 758.389764]/Subtype/Link/Type/Annot>> -endobj -97 0 obj -<>/BS<>/Dest(name-unknown-properties)/F 4/Rect[119.373041 771.389764 218.023676 758.389764]/Subtype/Link/Type/Annot>> -endobj -98 0 obj -<>/BS<>/Dest(name-unknown-properties)/F 4/Rect[518.190391 771.389764 529.370079 758.389764]/Subtype/Link/Type/Annot>> -endobj -99 0 obj -<>/BS<>/Dest(section-1.7.5)/F 4/Rect[89.905512 750.889764 111.674555 737.889764]/Subtype/Link/Type/Annot>> -endobj -100 0 obj -<>/BS<>/Dest(name-enumerated-values)/F 4/Rect[119.373041 750.889764 212.032465 737.889764]/Subtype/Link/Type/Annot>> -endobj -101 0 obj -<>/BS<>/Dest(name-enumerated-values)/F 4/Rect[518.190391 750.889764 529.370079 737.889764]/Subtype/Link/Type/Annot>> -endobj -102 0 obj -<>/BS<>/Dest(section-1.8)/F 4/Rect[77.905512 727.889764 91.584955 714.889764]/Subtype/Link/Type/Annot>> -endobj -103 0 obj -<>/BS<>/Dest(name-vendor-specific-extensions)/F 4/Rect[99.283441 727.889764 227.909174 714.889764]/Subtype/Link/Type/Annot>> -endobj -104 0 obj -<>/BS<>/Dest(name-vendor-specific-extensions)/F 4/Rect[518.190391 727.889764 529.370079 714.889764]/Subtype/Link/Type/Annot>> -endobj -105 0 obj -<>/BS<>/Dest(section-1.8.1)/F 4/Rect[89.905512 707.389764 111.674555 694.389764]/Subtype/Link/Type/Annot>> -endobj -106 0 obj -<>/BS<>/Dest(name-vendor-specific-properties)/F 4/Rect[119.373041 707.389764 245.528315 694.389764]/Subtype/Link/Type/Annot>> -endobj -107 0 obj -<>/BS<>/Dest(name-vendor-specific-properties)/F 4/Rect[518.190391 707.389764 529.370079 694.389764]/Subtype/Link/Type/Annot>> -endobj -108 0 obj -<>/BS<>/Dest(section-1.8.2)/F 4/Rect[89.905512 686.889764 111.674555 673.889764]/Subtype/Link/Type/Annot>> -endobj -109 0 obj -<>/BS<>/Dest(name-vendor-specific-values)/F 4/Rect[119.373041 686.889764 227.320307 673.889764]/Subtype/Link/Type/Annot>> -endobj -110 0 obj -<>/BS<>/Dest(name-vendor-specific-values)/F 4/Rect[518.190391 686.889764 529.370079 673.889764]/Subtype/Link/Type/Annot>> -endobj -111 0 obj -<>/BS<>/Dest(section-1.9)/F 4/Rect[77.905512 663.889764 91.584955 650.889764]/Subtype/Link/Type/Annot>> -endobj -112 0 obj -<>/BS<>/Dest(name-versioning)/F 4/Rect[99.283441 663.889764 150.447504 650.889764]/Subtype/Link/Type/Annot>> -endobj -113 0 obj -<>/BS<>/Dest(name-versioning)/F 4/Rect[518.190391 663.889764 529.370079 650.889764]/Subtype/Link/Type/Annot>> -endobj -114 0 obj -<>/BS<>/Dest(section-1.9.1)/F 4/Rect[89.905512 643.389764 111.674555 630.389764]/Subtype/Link/Type/Annot>> -endobj -115 0 obj -<>/BS<>/Dest(name-version-format-and-requirem)/F 4/Rect[119.373041 643.389764 283.034906 630.389764]/Subtype/Link/Type/Annot>> -endobj -116 0 obj -<>/BS<>/Dest(name-version-format-and-requirem)/F 4/Rect[518.190391 643.389764 529.370079 630.389764]/Subtype/Link/Type/Annot>> -endobj -117 0 obj -<>/BS<>/Dest(section-1.9.2)/F 4/Rect[89.905512 622.889764 111.674555 609.889764]/Subtype/Link/Type/Annot>> -endobj -118 0 obj -<>/BS<>/Dest(name-current-version)/F 4/Rect[119.373041 622.889764 195.333979 609.889764]/Subtype/Link/Type/Annot>> -endobj -119 0 obj -<>/BS<>/Dest(name-current-version)/F 4/Rect[518.190391 622.889764 529.370079 609.889764]/Subtype/Link/Type/Annot>> -endobj -120 0 obj -<>/BS<>/Dest(section-2)/F 4/Rect[65.905512 599.889764 71.495356 586.889764]/Subtype/Link/Type/Annot>> -endobj -121 0 obj -<>/BS<>/Dest(name-card)/F 4/Rect[79.193842 599.889764 101.811029 586.889764]/Subtype/Link/Type/Annot>> -endobj -122 0 obj -<>/BS<>/Dest(name-card)/F 4/Rect[518.190391 599.889764 529.370079 586.889764]/Subtype/Link/Type/Annot>> -endobj -123 0 obj -<>/BS<>/Dest(section-2.1)/F 4/Rect[77.905512 579.389764 91.584955 566.389764]/Subtype/Link/Type/Annot>> -endobj -124 0 obj -<>/BS<>/Dest(name-metadata-properties)/F 4/Rect[99.283441 579.389764 195.971918 566.389764]/Subtype/Link/Type/Annot>> -endobj -125 0 obj -<>/BS<>/Dest(name-metadata-properties)/F 4/Rect[518.190391 579.389764 529.370079 566.389764]/Subtype/Link/Type/Annot>> -endobj -126 0 obj -<>/BS<>/Dest(section-2.1.1)/F 4/Rect[89.905512 558.889764 111.674555 545.889764]/Subtype/Link/Type/Annot>> -endobj -127 0 obj -<>/BS<>/Dest(name-type)/F 4/Rect[119.373041 558.889764 149.23974 545.889764]/Subtype/Link/Type/Annot>> -endobj -128 0 obj -<>/BS<>/Dest(name-type)/F 4/Rect[518.190391 558.889764 529.370079 545.889764]/Subtype/Link/Type/Annot>> -endobj -129 0 obj -<>/BS<>/Dest(section-2.1.2)/F 4/Rect[89.905512 538.389764 111.674555 525.389764]/Subtype/Link/Type/Annot>> -endobj -130 0 obj -<>/BS<>/Dest(name-version)/F 4/Rect[119.373041 538.389764 155.149652 525.389764]/Subtype/Link/Type/Annot>> -endobj -131 0 obj -<>/BS<>/Dest(name-version)/F 4/Rect[518.190391 538.389764 529.370079 525.389764]/Subtype/Link/Type/Annot>> -endobj -132 0 obj -<>/BS<>/Dest(section-2.1.3)/F 4/Rect[89.905512 517.889764 111.674555 504.889764]/Subtype/Link/Type/Annot>> -endobj -133 0 obj -<>/BS<>/Dest(name-created)/F 4/Rect[119.373041 517.889764 154.989252 504.889764]/Subtype/Link/Type/Annot>> -endobj -134 0 obj -<>/BS<>/Dest(name-created)/F 4/Rect[518.190391 517.889764 529.370079 504.889764]/Subtype/Link/Type/Annot>> -endobj -135 0 obj -<>/BS<>/Dest(section-2.1.4)/F 4/Rect[89.905512 497.389764 111.674555 484.389764]/Subtype/Link/Type/Annot>> -endobj -136 0 obj -<>/BS<>/Dest(name-kind)/F 4/Rect[119.373041 497.389764 141.010981 484.389764]/Subtype/Link/Type/Annot>> -endobj -137 0 obj -<>/BS<>/Dest(name-kind)/F 4/Rect[518.190391 497.389764 529.370079 484.389764]/Subtype/Link/Type/Annot>> -endobj -138 0 obj -<>/BS<>/Dest(section-2.1.5)/F 4/Rect[89.905512 476.889764 111.674555 463.889764]/Subtype/Link/Type/Annot>> -endobj -139 0 obj -<>/BS<>/Dest(name-language)/F 4/Rect[119.373041 476.889764 162.639399 463.889764]/Subtype/Link/Type/Annot>> -endobj -140 0 obj -<>/BS<>/Dest(name-language)/F 4/Rect[518.190391 476.889764 529.370079 463.889764]/Subtype/Link/Type/Annot>> -endobj -141 0 obj -<>/BS<>/Dest(section-2.1.6)/F 4/Rect[89.905512 456.389764 111.674555 443.389764]/Subtype/Link/Type/Annot>> -endobj -142 0 obj -<>/BS<>/Dest(name-members)/F 4/Rect[119.373041 456.389764 164.329828 443.389764]/Subtype/Link/Type/Annot>> -endobj -143 0 obj -<>/BS<>/Dest(name-members)/F 4/Rect[518.190391 456.389764 529.370079 443.389764]/Subtype/Link/Type/Annot>> -endobj -144 0 obj -<>/BS<>/Dest(section-2.1.7)/F 4/Rect[89.905512 435.889764 111.674555 422.889764]/Subtype/Link/Type/Annot>> -endobj -145 0 obj -<>/BS<>/Dest(name-prodid)/F 4/Rect[119.373041 435.889764 151.938715 422.889764]/Subtype/Link/Type/Annot>> -endobj -146 0 obj -<>/BS<>/Dest(name-prodid)/F 4/Rect[518.190391 435.889764 529.370079 422.889764]/Subtype/Link/Type/Annot>> -endobj -147 0 obj -<>/BS<>/Dest(section-2.1.8)/F 4/Rect[89.905512 415.389764 111.674555 402.389764]/Subtype/Link/Type/Annot>> -endobj -148 0 obj -<>/BS<>/Dest(name-relatedto)/F 4/Rect[119.373041 415.389764 164.567865 402.389764]/Subtype/Link/Type/Annot>> -endobj -149 0 obj -<>/BS<>/Dest(name-relatedto)/F 4/Rect[518.190391 415.389764 529.370079 402.389764]/Subtype/Link/Type/Annot>> -endobj -150 0 obj -<>/BS<>/Dest(section-2.1.9)/F 4/Rect[89.905512 394.889764 111.674555 381.889764]/Subtype/Link/Type/Annot>> -endobj -151 0 obj -<>/BS<>/Dest(name-uid)/F 4/Rect[119.373041 394.889764 135.060785 381.889764]/Subtype/Link/Type/Annot>> -endobj -152 0 obj -<>/BS<>/Dest(name-uid)/F 4/Rect[518.190391 394.889764 529.370079 381.889764]/Subtype/Link/Type/Annot>> -endobj -153 0 obj -<>/BS<>/Dest(section-2.1.10)/F 4/Rect[89.905512 374.389764 117.264399 361.389764]/Subtype/Link/Type/Annot>> -endobj -154 0 obj -<>/BS<>/Dest(name-updated)/F 4/Rect[122.36352 374.389764 161.628656 361.389764]/Subtype/Link/Type/Annot>> -endobj -155 0 obj -<>/BS<>/Dest(name-updated)/F 4/Rect[518.190391 374.389764 529.370079 361.389764]/Subtype/Link/Type/Annot>> -endobj -156 0 obj -<>/BS<>/Dest(section-2.2)/F 4/Rect[77.905512 351.389764 91.584955 338.389764]/Subtype/Link/Type/Annot>> -endobj -157 0 obj -<>/BS<>/Dest(name-name-and-organization-prope)/F 4/Rect[99.283441 351.389764 265.115473 338.389764]/Subtype/Link/Type/Annot>> -endobj -158 0 obj -<>/BS<>/Dest(name-name-and-organization-prope)/F 4/Rect[518.190391 351.389764 529.370079 338.389764]/Subtype/Link/Type/Annot>> -endobj -159 0 obj -<>/BS<>/Dest(section-2.2.1)/F 4/Rect[89.905512 330.889764 111.674555 317.889764]/Subtype/Link/Type/Annot>> -endobj -160 0 obj -<>/BS<>/Dest(name-name)/F 4/Rect[119.373041 330.889764 146.251459 317.889764]/Subtype/Link/Type/Annot>> -endobj -161 0 obj -<>/BS<>/Dest(name-name)/F 4/Rect[518.190391 330.889764 529.370079 317.889764]/Subtype/Link/Type/Annot>> -endobj -162 0 obj -<>/BS<>/Dest(section-2.2.2)/F 4/Rect[89.905512 310.389764 111.674555 297.389764]/Subtype/Link/Type/Annot>> -endobj -163 0 obj -<>/BS<>/Dest(name-nicknames)/F 4/Rect[119.373041 310.389764 171.179438 297.389764]/Subtype/Link/Type/Annot>> -endobj -164 0 obj -<>/BS<>/Dest(name-nicknames)/F 4/Rect[518.190391 310.389764 529.370079 297.389764]/Subtype/Link/Type/Annot>> -endobj -165 0 obj -<>/BS<>/Dest(section-2.2.3)/F 4/Rect[89.905512 289.889764 111.674555 276.889764]/Subtype/Link/Type/Annot>> -endobj -166 0 obj -<>/BS<>/Dest(name-organizations)/F 4/Rect[119.373041 289.889764 184.695551 276.889764]/Subtype/Link/Type/Annot>> -endobj -167 0 obj -<>/BS<>/Dest(name-organizations)/F 4/Rect[518.190391 289.889764 529.370079 276.889764]/Subtype/Link/Type/Annot>> -endobj -168 0 obj -<>/BS<>/Dest(section-2.2.4)/F 4/Rect[89.905512 269.389764 111.674555 256.389764]/Subtype/Link/Type/Annot>> -endobj -169 0 obj -<>/BS<>/Dest(name-speaktoas)/F 4/Rect[119.373041 269.389764 169.808344 256.389764]/Subtype/Link/Type/Annot>> -endobj -170 0 obj -<>/BS<>/Dest(name-speaktoas)/F 4/Rect[518.190391 269.389764 529.370079 256.389764]/Subtype/Link/Type/Annot>> -endobj -171 0 obj -<>/BS<>/Dest(section-2.2.5)/F 4/Rect[89.905512 248.889764 111.674555 235.889764]/Subtype/Link/Type/Annot>> -endobj -172 0 obj -<>/BS<>/Dest(name-titles)/F 4/Rect[119.373041 248.889764 142.569574 235.889764]/Subtype/Link/Type/Annot>> -endobj -173 0 obj -<>/BS<>/Dest(name-titles)/F 4/Rect[518.190391 248.889764 529.370079 235.889764]/Subtype/Link/Type/Annot>> -endobj -174 0 obj -<>/BS<>/Dest(section-2.3)/F 4/Rect[77.905512 225.889764 91.584955 212.889764]/Subtype/Link/Type/Annot>> -endobj -175 0 obj -<>/BS<>/Dest(name-contact-properties)/F 4/Rect[99.283441 225.889764 187.122797 212.889764]/Subtype/Link/Type/Annot>> -endobj -176 0 obj -<>/BS<>/Dest(name-contact-properties)/F 4/Rect[518.190391 225.889764 529.370079 212.889764]/Subtype/Link/Type/Annot>> -endobj -177 0 obj -<>/BS<>/Dest(section-2.3.1)/F 4/Rect[89.905512 205.389764 111.674555 192.389764]/Subtype/Link/Type/Annot>> -endobj -178 0 obj -<>/BS<>/Dest(name-emails)/F 4/Rect[119.373041 205.389764 150.610102 192.389764]/Subtype/Link/Type/Annot>> -endobj -179 0 obj -<>/BS<>/Dest(name-emails)/F 4/Rect[518.190391 205.389764 529.370079 192.389764]/Subtype/Link/Type/Annot>> -endobj -180 0 obj -<>/BS<>/Dest(section-2.3.2)/F 4/Rect[89.905512 184.889764 111.674555 171.889764]/Subtype/Link/Type/Annot>> -endobj -181 0 obj -<>/BS<>/Dest(name-onlineservices)/F 4/Rect[119.373041 184.889764 188.956781 171.889764]/Subtype/Link/Type/Annot>> -endobj -182 0 obj -<>/BS<>/Dest(name-onlineservices)/F 4/Rect[518.190391 184.889764 529.370079 171.889764]/Subtype/Link/Type/Annot>> -endobj -183 0 obj -<>/BS<>/Dest(section-2.3.3)/F 4/Rect[89.905512 164.389764 111.674555 151.389764]/Subtype/Link/Type/Annot>> -endobj -184 0 obj -<>/BS<>/Dest(name-phones)/F 4/Rect[119.373041 164.389764 153.939691 151.389764]/Subtype/Link/Type/Annot>> -endobj -185 0 obj -<>/BS<>/Dest(name-phones)/F 4/Rect[518.190391 164.389764 529.370079 151.389764]/Subtype/Link/Type/Annot>> -endobj -3132 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3131 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3130 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3129 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3128 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3127 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3126 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3125 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3124 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3123 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3122 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3121 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3120 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3119 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3118 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3117 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3116 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3115 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3114 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3113 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3112 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3111 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3110 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3109 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3108 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3107 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3106 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3105 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3104 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3103 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3102 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3101 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3100 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3099 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3098 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3097 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3096 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3095 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3094 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3093 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3092 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3091 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3090 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3089 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3088 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3087 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3086 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3085 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3084 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3083 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3082 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3081 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3080 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3079 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3078 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3077 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3076 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3075 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3074 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3073 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3072 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3071 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3070 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3069 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3068 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3067 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3066 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3065 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3064 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3063 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3062 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3061 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3060 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3059 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3058 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3057 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3056 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3055 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3054 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3053 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3052 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3051 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3050 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3049 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3048 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3047 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3046 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3045 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3044 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3043 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1794 0 obj -<>stream -xœ½ZKsÛ6ÆŒnº4™(±ìæÀ™¦N”qh€ÄóšÚ²â(~ÈÙ±sh:u.Ig’öô§w’"!‘ÒJ$E’û±° , ðyc4g¡ÖFIüñ­û½*áNf¿®ò{JJ’Ç¡¢Tih%BΩá"øñgwÚý«Ëûùñ¥»ÿ; iðå﮽_™Ù-ŒEQ(˜‘ÚÝóÐ=‡˜f:»P¾9(|M!¿zçmyúÀB$ÿ‹x+™öN«Âé‡×óÍ1"ÊλfÊ_“2+”‹÷ê[nnþ Ylÿó¿EÈ·—ÝÙ³×*ÔŠS&4Õ£:Œb \~ë>¾;|°8t6b¸*¸|èÞ½"ɘLÉ{Ò!WdD®ÉüBM¾÷÷=\q GGP’rWœCýc¨Û…º#('Ggp÷Î%çí=#rGWƒˆ¾"Îî®ïw€f¯_f¿G7pÆ¡fHN¡ hƒO—ÇUÝŽd«ˆ*³Èöz(ÀÞ­ÃH°%’¼„ß}¨:¬k׃iÚÚ´4iåc-“Ãô^ÛŽÜŸp4v½í-àÂZ˜@¿’Ù’‚;³öïCÍ1Ø=…ãØõ=iQbáÚaž;„û–õóPP®uœvïbfî(mdöH'?uek4{–Úû{D/³~àø{ìÚ|x™ŠÀ÷®ßjÉB3¥X ™ -Áñ”à-|Á0Å3ÍÙð¶M¥ªž‹y.W‰‹ývv~rv µa”º–ÄŽñCxìùðØu|š9‰ÿ¨#¡B¦¨6lÎ<˜ëd /´ÚØŸÈ(c^ÙÞ(ˆÁ-´Y! ½J œž"Ša)ÆéZ(Égòyý.1*BÏ죡öÕWN«nrÏõ©g4NÈ’AÄM(%—Q&!=híº¬ØÇÃçìµÀI D(eÀ>Š–‡[ ¹’e*d}þÔ;“Ì·0|­˜‘Ÿ ôÁ+e÷ÞeµÕü*èørÎïÓüzöÚå Å¿9ƒ‰ö'Λ:ªþ•<Å”xÊÓ³ÍyòíµÊê¥ãèÀÍ—0-]8¥œ'ož"ÙŒ¢˜-ºê³MÜ•ëPÃé¼Íh&d’S!ðPÌ"ÒeGq¹,&,kWŽ­Ñ2®„^t»g›¸^+Ïf»\a¡ -I%ÇÎû¦ üWËéѲÄÛ6ñ¸=žÍvéÁBùCÆ-_ÀÁ4]Þ¸µI5ML–zÜÖæ4ù6[¥ ¥Òåï/ IÉxšç®Rº9/‘îµʥ۷תt£¡’ï,] ”ù’A¤Jd{«žlû6ÛDX¨½…UPS"Ç[õäØ·Ù.X¨½4šÏ¦,í"ÆD—mDéÎW²$¢UÞª§Ê¾ÍVYBCÅÎ}† :…©¾šQ"Â[õDØ·Ù.+X(á²7wçó"E>4-÷¥~ ><›íò…ÒD¹4În*·#۱͘UND’•(íÚ¬ä‘o¯Õ‰ åODë,‰e\¢Áýzóo³Õqƒ†Î’Nw‹I§"²Dmûõæ$ßf»|`¡N]ZnDN«™0% -Û¯7ïø6Ûe uᢢw•<¨¨DYûõfßf«< ¡.\ÂÜ®H¬f +õT‰=ÝÞ\O}{­ê)j/ÕŠ«4rÎ3Xcò)¯©3ªDU·ë©ªo³Ý1ƒ…º8ç‘Gp8à0/O Âîj©€’SÛJ–4-ÑÚízZëÛl•%4”†UÜÞ’,§ŽK²Á;›{”o¯UBC™t[A§n›.ñ sˆ€:ä ‘³-¡ƒ¥k~-KR -;õ¼Ê·ÙîxÁBíºIëT2Ý]§;㲜K S"Í;5ÊüoI4ÔyA|¹ðèØmÍ&r=Z;'lX‰TïÔ[æø6[å •’–‘Û,¶°—7©t‡X âK®ðÛ“ý†q±[€Û ãb·ÆÆEo5í4Œ‹Ý»i»òsÃ¸Ø ††qÑû¦q±yðç ãb“ËMãbºÍàB\QD§H{äIÃÈØ4dóÈØ„_/_Ý5ƒŒNª5ŒMV5ŒM õò¥bCÈØ4LãÈèÄGóÈØ4C/_d6„Œ ÜGFÃÍ#cCÐ^ž±kÐ5Œ”GFÇsÈ:u6«€” ´áFRÃq!šÅ1÷ˆ;ä9éÃga0-ˆ¥ ü¤’l%Py^'Œh¤øj$JÜž–{å)yß…§¶’7£T  VŠ!]€|áö Gä€îÿq¯0OîþMçÉš\ - -Q¨V"Æ€'›ßÉË’×ÉËá³—âOÖ¤V3ƒRj¹ -Øî)»÷VžÎÆóî/Õ³™ -endstream -endobj -1642 0 obj -<>/Font<>>> -endobj -15 0 obj -<>/BS<>/Dest(name-table-of-contents)/F 4/Rect[65.905512 711.740936 192.878168 693.020936]/Subtype/Link/Type/Annot>> -endobj -16 0 obj -<>/BS<>/Dest(section-1)/F 4/Rect[65.905512 685.520936 71.495356 672.520936]/Subtype/Link/Type/Annot>> -endobj -17 0 obj -<>/BS<>/Dest(name-introduction)/F 4/Rect[79.193842 685.520936 139.656733 672.520936]/Subtype/Link/Type/Annot>> -endobj -18 0 obj -<>/BS<>/Dest(name-introduction)/F 4/Rect[523.780235 685.520936 529.370079 672.520936]/Subtype/Link/Type/Annot>> -endobj -19 0 obj -<>/BS<>/Dest(section-1.1)/F 4/Rect[77.905512 665.020936 91.584955 652.020936]/Subtype/Link/Type/Annot>> -endobj -20 0 obj -<>/BS<>/Dest(name-motivation-and-relation-to-)/F 4/Rect[99.283441 665.020936 342.423334 652.020936]/Subtype/Link/Type/Annot>> -endobj -21 0 obj -<>/BS<>/Dest(name-motivation-and-relation-to-)/F 4/Rect[523.780235 665.020936 529.370079 652.020936]/Subtype/Link/Type/Annot>> -endobj -22 0 obj -<>/BS<>/Dest(section-1.2)/F 4/Rect[77.905512 644.520936 91.584955 631.520936]/Subtype/Link/Type/Annot>> -endobj -23 0 obj -<>/BS<>/Dest(name-notational-conventions)/F 4/Rect[99.283441 644.520936 211.491205 631.520936]/Subtype/Link/Type/Annot>> -endobj -24 0 obj -<>/BS<>/Dest(name-notational-conventions)/F 4/Rect[523.780235 644.520936 529.370079 631.520936]/Subtype/Link/Type/Annot>> -endobj -25 0 obj -<>/BS<>/Dest(section-1.3)/F 4/Rect[77.905512 624.020936 91.584955 611.020936]/Subtype/Link/Type/Annot>> -endobj -26 0 obj -<>/BS<>/Dest(name-data-type-notations)/F 4/Rect[99.283441 624.020936 195.791742 611.020936]/Subtype/Link/Type/Annot>> -endobj -27 0 obj -<>/BS<>/Dest(name-data-type-notations)/F 4/Rect[523.780235 624.020936 529.370079 611.020936]/Subtype/Link/Type/Annot>> -endobj -28 0 obj -<>/BS<>/Dest(section-1.3.1)/F 4/Rect[89.905512 603.520936 111.674555 590.520936]/Subtype/Link/Type/Annot>> -endobj -29 0 obj -<>/BS<>/Dest(name-objects-and-properties)/F 4/Rect[119.373041 603.520936 226.94018 590.520936]/Subtype/Link/Type/Annot>> -endobj -30 0 obj -<>/BS<>/Dest(name-objects-and-properties)/F 4/Rect[523.780235 603.520936 529.370079 590.520936]/Subtype/Link/Type/Annot>> -endobj -31 0 obj -<>/BS<>/Dest(section-1.3.2)/F 4/Rect[89.905512 583.020936 111.674555 570.020936]/Subtype/Link/Type/Annot>> -endobj -32 0 obj -<>/BS<>/Dest(name-type-signatures)/F 4/Rect[119.373041 583.020936 195.774897 570.020936]/Subtype/Link/Type/Annot>> -endobj -33 0 obj -<>/BS<>/Dest(name-type-signatures)/F 4/Rect[523.780235 583.020936 529.370079 570.020936]/Subtype/Link/Type/Annot>> -endobj -34 0 obj -<>/BS<>/Dest(section-1.3.3)/F 4/Rect[89.905512 562.520936 111.674555 549.520936]/Subtype/Link/Type/Annot>> -endobj -35 0 obj -<>/BS<>/Dest(name-property-attributes)/F 4/Rect[119.373041 562.520936 211.721186 549.520936]/Subtype/Link/Type/Annot>> -endobj -36 0 obj -<>/BS<>/Dest(name-property-attributes)/F 4/Rect[523.780235 562.520936 529.370079 549.520936]/Subtype/Link/Type/Annot>> -endobj -37 0 obj -<>/BS<>/Dest(section-1.3.4)/F 4/Rect[89.905512 542.020936 111.674555 529.020936]/Subtype/Link/Type/Annot>> -endobj -38 0 obj -<>/BS<>/Dest(name-the-type-property)/F 4/Rect[119.373041 542.020936 214.152094 529.020936]/Subtype/Link/Type/Annot>> -endobj -39 0 obj -<>/BS<>/Dest(name-the-type-property)/F 4/Rect[523.780235 542.020936 529.370079 529.020936]/Subtype/Link/Type/Annot>> -endobj -40 0 obj -<>/BS<>/Dest(section-1.4)/F 4/Rect[77.905512 519.020936 91.584955 506.020936]/Subtype/Link/Type/Annot>> -endobj -41 0 obj -<>/BS<>/Dest(name-common-data-types)/F 4/Rect[99.283441 519.020936 197.33349 506.020936]/Subtype/Link/Type/Annot>> -endobj -42 0 obj -<>/BS<>/Dest(name-common-data-types)/F 4/Rect[523.780235 519.020936 529.370079 506.020936]/Subtype/Link/Type/Annot>> -endobj -43 0 obj -<>/BS<>/Dest(section-1.4.1)/F 4/Rect[89.905512 498.520936 111.674555 485.520936]/Subtype/Link/Type/Annot>> -endobj -44 0 obj -<>/BS<>/Dest(name-id)/F 4/Rect[119.373041 498.520936 129.181635 485.520936]/Subtype/Link/Type/Annot>> -endobj -45 0 obj -<>/BS<>/Dest(name-id)/F 4/Rect[523.780235 498.520936 529.370079 485.520936]/Subtype/Link/Type/Annot>> -endobj -46 0 obj -<>/BS<>/Dest(section-1.4.2)/F 4/Rect[89.905512 478.020936 111.674555 465.020936]/Subtype/Link/Type/Annot>> -endobj -47 0 obj -<>/BS<>/Dest(name-int-and-unsignedint)/F 4/Rect[119.373041 478.020936 214.713129 465.020936]/Subtype/Link/Type/Annot>> -endobj -48 0 obj -<>/BS<>/Dest(name-int-and-unsignedint)/F 4/Rect[523.780235 478.020936 529.370079 465.020936]/Subtype/Link/Type/Annot>> -endobj -49 0 obj -<>/BS<>/Dest(section-1.4.3)/F 4/Rect[89.905512 457.520936 111.674555 444.520936]/Subtype/Link/Type/Annot>> -endobj -50 0 obj -<>/BS<>/Dest(name-patchobject)/F 4/Rect[119.373041 457.520936 176.176752 444.520936]/Subtype/Link/Type/Annot>> -endobj -51 0 obj -<>/BS<>/Dest(name-patchobject)/F 4/Rect[518.190391 457.520936 529.370079 444.520936]/Subtype/Link/Type/Annot>> -endobj -52 0 obj -<>/BS<>/Dest(section-1.4.4)/F 4/Rect[89.905512 437.020936 111.674555 424.020936]/Subtype/Link/Type/Annot>> -endobj -53 0 obj -<>/BS<>/Dest(name-resource)/F 4/Rect[119.373041 437.020936 162.889154 424.020936]/Subtype/Link/Type/Annot>> -endobj -54 0 obj -<>/BS<>/Dest(name-resource)/F 4/Rect[518.190391 437.020936 529.370079 424.020936]/Subtype/Link/Type/Annot>> -endobj -55 0 obj -<>/BS<>/Dest(section-1.4.5)/F 4/Rect[89.905512 416.520936 111.674555 403.520936]/Subtype/Link/Type/Annot>> -endobj -56 0 obj -<>/BS<>/Dest(name-utcdatetime)/F 4/Rect[119.373041 416.520936 184.506586 403.520936]/Subtype/Link/Type/Annot>> -endobj -57 0 obj -<>/BS<>/Dest(name-utcdatetime)/F 4/Rect[518.190391 416.520936 529.370079 403.520936]/Subtype/Link/Type/Annot>> -endobj -58 0 obj -<>/BS<>/Dest(section-1.5)/F 4/Rect[77.905512 393.520936 91.584955 380.520936]/Subtype/Link/Type/Annot>> -endobj -59 0 obj -<>/BS<>/Dest(name-common-properties)/F 4/Rect[99.283441 393.520936 194.203852 380.520936]/Subtype/Link/Type/Annot>> -endobj -60 0 obj -<>/BS<>/Dest(name-common-properties)/F 4/Rect[518.190391 393.520936 529.370079 380.520936]/Subtype/Link/Type/Annot>> -endobj -61 0 obj -<>/BS<>/Dest(section-1.5.1)/F 4/Rect[89.905512 373.020936 111.674555 360.020936]/Subtype/Link/Type/Annot>> -endobj -62 0 obj -<>/BS<>/Dest(name-contexts)/F 4/Rect[119.373041 373.020936 159.188959 360.020936]/Subtype/Link/Type/Annot>> -endobj -63 0 obj -<>/BS<>/Dest(name-contexts)/F 4/Rect[518.190391 373.020936 529.370079 360.020936]/Subtype/Link/Type/Annot>> -endobj -64 0 obj -<>/BS<>/Dest(section-1.5.2)/F 4/Rect[89.905512 352.520936 111.674555 339.520936]/Subtype/Link/Type/Annot>> -endobj -65 0 obj -<>/BS<>/Dest(name-label)/F 4/Rect[119.373041 352.520936 142.690424 339.520936]/Subtype/Link/Type/Annot>> -endobj -66 0 obj -<>/BS<>/Dest(name-label)/F 4/Rect[518.190391 352.520936 529.370079 339.520936]/Subtype/Link/Type/Annot>> -endobj -67 0 obj -<>/BS<>/Dest(section-1.5.3)/F 4/Rect[89.905512 332.020936 111.674555 319.020936]/Subtype/Link/Type/Annot>> -endobj -68 0 obj -<>/BS<>/Dest(name-pref)/F 4/Rect[119.373041 332.020936 139.260492 319.020936]/Subtype/Link/Type/Annot>> -endobj -69 0 obj -<>/BS<>/Dest(name-pref)/F 4/Rect[518.190391 332.020936 529.370079 319.020936]/Subtype/Link/Type/Annot>> -endobj -70 0 obj -<>/BS<>/Dest(section-1.5.4)/F 4/Rect[89.905512 311.520936 111.674555 298.520936]/Subtype/Link/Type/Annot>> -endobj -71 0 obj -<>/BS<>/Dest(name-phonetic)/F 4/Rect[119.373041 311.520936 161.068354 298.520936]/Subtype/Link/Type/Annot>> -endobj -72 0 obj -<>/BS<>/Dest(name-phonetic)/F 4/Rect[518.190391 311.520936 529.370079 298.520936]/Subtype/Link/Type/Annot>> -endobj -73 0 obj -<>/BS<>/Dest(section-1.6)/F 4/Rect[77.905512 288.520936 91.584955 275.520936]/Subtype/Link/Type/Annot>> -endobj -74 0 obj -<>/BS<>/Dest(name-internationalization)/F 4/Rect[99.283441 288.520936 195.602045 275.520936]/Subtype/Link/Type/Annot>> -endobj -75 0 obj -<>/BS<>/Dest(name-internationalization)/F 4/Rect[518.190391 288.520936 529.370079 275.520936]/Subtype/Link/Type/Annot>> -endobj -76 0 obj -<>/BS<>/Dest(section-1.6.1)/F 4/Rect[89.905512 268.020936 111.674555 255.020936]/Subtype/Link/Type/Annot>> -endobj -77 0 obj -<>/BS<>/Dest(name-free-form-text)/F 4/Rect[119.373041 268.020936 192.085688 255.020936]/Subtype/Link/Type/Annot>> -endobj -78 0 obj -<>/BS<>/Dest(name-free-form-text)/F 4/Rect[518.190391 268.020936 529.370079 255.020936]/Subtype/Link/Type/Annot>> -endobj -79 0 obj -<>/BS<>/Dest(section-1.6.2)/F 4/Rect[89.905512 247.520936 111.674555 234.520936]/Subtype/Link/Type/Annot>> -endobj -80 0 obj -<>/BS<>/Dest(name-uris)/F 4/Rect[119.373041 247.520936 141.281244 234.520936]/Subtype/Link/Type/Annot>> -endobj -81 0 obj -<>/BS<>/Dest(name-uris)/F 4/Rect[518.190391 247.520936 529.370079 234.520936]/Subtype/Link/Type/Annot>> -endobj -82 0 obj -<>/BS<>/Dest(section-1.7)/F 4/Rect[77.905512 224.520936 91.584955 211.520936]/Subtype/Link/Type/Annot>> -endobj -83 0 obj -<>/BS<>/Dest(name-validating-jscontact)/F 4/Rect[99.283441 224.520936 195.23144 211.520936]/Subtype/Link/Type/Annot>> -endobj -84 0 obj -<>/BS<>/Dest(name-validating-jscontact)/F 4/Rect[518.190391 224.520936 529.370079 211.520936]/Subtype/Link/Type/Annot>> -endobj -85 0 obj -<>/BS<>/Dest(section-1.7.1)/F 4/Rect[89.905512 204.020936 111.674555 191.020936]/Subtype/Link/Type/Annot>> -endobj -86 0 obj -<>/BS<>/Dest(name-case-sensitivity)/F 4/Rect[119.373041 204.020936 193.924066 191.020936]/Subtype/Link/Type/Annot>> -endobj -87 0 obj -<>/BS<>/Dest(name-case-sensitivity)/F 4/Rect[518.190391 204.020936 529.370079 191.020936]/Subtype/Link/Type/Annot>> -endobj -88 0 obj -<>/BS<>/Dest(section-1.7.2)/F 4/Rect[89.905512 183.520936 111.674555 170.520936]/Subtype/Link/Type/Annot>> -endobj -89 0 obj -<>/BS<>/Dest(name-iana-registered-properties)/F 4/Rect[119.373041 183.520936 249.829096 170.520936]/Subtype/Link/Type/Annot>> -endobj -90 0 obj -<>/BS<>/Dest(name-iana-registered-properties)/F 4/Rect[518.190391 183.520936 529.370079 170.520936]/Subtype/Link/Type/Annot>> -endobj -91 0 obj -<>/BS<>/Dest(section-1.7.3)/F 4/Rect[89.905512 163.020936 111.674555 150.020936]/Subtype/Link/Type/Annot>> -endobj -92 0 obj -<>/BS<>/Dest(name-reserved-properties)/F 4/Rect[119.373041 163.020936 215.022943 150.020936]/Subtype/Link/Type/Annot>> -endobj -93 0 obj -<>/BS<>/Dest(name-reserved-properties)/F 4/Rect[518.190391 163.020936 529.370079 150.020936]/Subtype/Link/Type/Annot>> -endobj -3211 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3210 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3209 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3208 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3207 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3206 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3205 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3204 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3203 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3202 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3201 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3200 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3199 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3198 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3197 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3196 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3195 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3194 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3193 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3192 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3191 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3190 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3189 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3188 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3187 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3186 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3185 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3184 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3183 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3182 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3181 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3180 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3179 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3178 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3177 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3176 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3175 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3174 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3173 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3172 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3171 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3170 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3169 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3168 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3167 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3166 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3165 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3164 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3163 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3162 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3161 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3160 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3159 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3158 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3157 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3156 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3155 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3154 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3153 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3152 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3151 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3150 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3149 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3148 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3147 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3146 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3145 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3144 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3143 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3142 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3141 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3140 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3139 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3138 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3137 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3136 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3135 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3134 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3133 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1793 0 obj -<>stream -xœµYËsÛÆÇ oôÁVj'¤™ÁÁq,cÀ>ŽM( ’‰¤öÐvª\ìÌ$í±‡þéùí·»ÀA»Vöñ½ŸË˜Å)®ïÌ—ÊY¢”–"ÿù~üë8‘MúoüuŒ7)b‘g‰LS©d¬d‘äyªó"þí_ãõø—1‹ÍõÛÏã·gIÿüï±Ù/u½…1Γ‚i¡hÏÃxŽ  ™ò+€å=¡*âwå»Ö¼y_¿²DÅö?Äw€H ¸5-ƒé‡7]rtÁý<‘¼¿³ï,x÷ã0¹þ’i‘(.¤äq1‹”3¥@¶’‰’yÊ -•ªpæ]w†53-XÁ¸cE˜?ÉþÇÅ^È$SJy,˜L MYþÎ2ü1® _²¥ho!Q$4’ÅÝïœïoǵé·ñÈ<ÉX¦ ß¾¿ýa6¿ž]Æ–60xžgñíÃø§×Qm£WÑ(úKôg\ŸÿíörÌ,ÍÆ%×ÜÀÄÞï"­‹h­£It†û×ô3Ã#†§"*£e´Â½ÂÇ®\GSÚ5Âý÷6ŒQô-­™ ‘!K­ -ÁBö˜N¸cëet -„ëhuÌÓ×ð8ø´ -þLà®Ëû‹Óïc–%$ñ «X]ö -4VàªØéöÿÅWÈÔyTšÁ9ñ<”"Žð4Ã",ˆnhfŽg#­It‡ À,I -,üH8Ìþ¶ìžÔRÞ>àuuHÐüç 13M5ÏfÏ:1 ®ˆÖ)Æ/0»'!‚5$3©×š‘S1Š6DŽÙiw…²0 -ZÔ*º¤õ^&eô ]Ñ»™Ô fÏ›aYàº&WC,rml_fÒ±x€+'^CØvKЗ¸n0ª´ŠŽ0wBÜM06#Ìf›çrâh»Áh `s·ûŽfíJ#!óv{÷ÒldÊ´‘Bcˆ³\%©E®gB?ö)D·£„§N¨k²ƒøä–4îÑUÄÜ’Æ=rcS ˆÃ -Ü -bNj¶&âÕWámV½>®Im?Ù~JJ^Ó½bXˆ„i ‡æäÞÓµŽ°Ñ蔬Ƞ3ÌÌj£ÏKð–îÍF€’àÏIÓg4vOPWÎ&–NxKòê ‰ÞPbÝbˆA…àD%½;Z£ŸÖ9!Âö† ª„Ft¿ï0[’–g.VT£Wr_ëÒêùŽØZ;ƒ_c¾¤£ž$à 0X¤¨;D®•wƆ°#Úvz[×aŠÓyRä©P¨¼PX¨,•Y+`ûè/Œ]‚>ã_{€sW^|l^mf&Jfª½>¤.“>">86ã™Ðªß+gQ—>|="f¤×<7Ú‚¦z‘gˆ)§(+2ùóÇÄ®Òå{Æû•{õ -•GD¨e’ª\dýŠ}InC!Ⱥj£þX´ÆOxù!3>!§²ù¤$ÇÚ¾¦@6¥’Š lò8sQؤÂíñqŽWCì€'€µ5å Ltûà©ß¡Ü‡ZjCü>š‡½ ,#ûP4ÂÙØê…›ÀV.Ë Ì»n‡pר-E•ivRòý Ÿ/:P°§™BÕÛ `´]ËŠ±Ô€ÿŸgÑs|¿ˆžw¶"B¦)/´èØã.– Ž,†–~‚W„, ûEAÉL‰ÚÄX:ñ?z´DIžæ:·–põ×êú&@ïŒÜV3*Ìn>»Na|ÌT‰˜O‰ù·Ñbûð?Ê5ç.¥?ö¼Ÿà’°¤WˆƒÅ§¢m§æ"MrŽg¾§³®³ØëÙ®i‹Rª)]Ó6ͨÎxü®i·i‘@«Èÿà¶lZW2£žðy0xPádªÝM] (|¼\úÒ»!¤ ¦!Í—Ô瘵å’¢¯Hÿ¨¨41»½bå â–«Di´‰¬Õ%ZUË ^<~[HÎp™öÄ”²Ûí±¹ UWÄÉÈ•ï¥kŸÎI`¾Ú8sówx¶5mSµN\Cè+Ó¦÷p.4‰"‡Ïs¸¡/¼CÄa·{ÚdÿCm6d†#oˆÌ ðÕZtJƒø6T}Ûæb¾è³û!~E‘ ›I&¿}âíöΆغqô¹pÝ–'âEmõÙÒ—ÑWÑH{ƒ¾¤E"8SuWw²‡É õü×nZ៑€Vµ¯U=Aj½×7] ÜèÔÈÎG(ì‘ÛÝ‘·¯)µ‹ÆÂJ²µÓ¾b¤Å¯d&‰ç¢nò,wSß·6ÔØ#†¾×¤‚¹³f:*hcÈ‘A/Ìéæü£ƒy¢Uþõg¨¼HRQäœwàç+¹† P6GŸáº7×±$×_A`gÈc¥ko¶è~‰•ÞÌ?së:µå£ä;)x"ã9²Ø“òL{»ôúXÑ©ÊUp(g‚CÙ­YÂQA0½‹à@Ò“š%æ¥îÑî%ì H¢SAWÓvB1r¹Fû¨ÉºÒ’¬¿ª¬eÓ!‡9Pð¦W[vsݤÕ.™ö1ㆂ·§rèˆG¥BËDæ‹gŸ«V.–Eó “Z~DV®(Î7§­Ö¹¿€3¾vÕ/Ðí/ð-5æöœ&«cDÐtc›Mi vˆÃB£ Bà3ñ·¾ ‚'¦A±$/̯-»ÛÉTl4/M=[օɼ¥f{ààê¾äØ -·C\ÐÏ? ÉG¨Ò‹„wC9!n§~KXÕkƒUäO­K³!ësÇÓŽS='HöüÝ\ /(­´Œ60k“kšm`õa– ™dZ£ êèê#Âìº6É’Ž§T•\áÕj®t%Ü3nCú=)Q¶\óË!t‰V9+ØÞ®=htÿjŸ†‘fè$˜P²È>ùá#ƒF,àHZ ¡Ä!ÄYý«Æó®Pçã߃E:ý -endstream -endobj -4 0 obj -<>/Font 1636 0 R/Pattern<<>>/Shading<<>>/XObject<<>>>> -endobj -1636 0 obj -<> -endobj -7 0 obj -<>/AP<>/BS<>/F 4/Rect[151.905512 752.649529 172.026606 740.409295]/Subtype/Link/Type/Annot>> -endobj -8 0 obj -<>/BS<>/Dest(abstract)/F 4/Rect[65.905512 583.238123 128.239008 564.518123]/Subtype/Link/Type/Annot>> -endobj -9 0 obj -<>/BS<>/Dest(name-status-of-this-memo)/F 4/Rect[65.905512 444.020858 213.239496 425.300858]/Subtype/Link/Type/Annot>> -endobj -10 0 obj -<>/AP<>/BS<>/F 4/Rect[183.799066 316.503201 368.118891 302.903592]/Subtype/Link/Type/Annot>> -endobj -11 0 obj -<>/BS<>/Dest(name-copyright-notice)/F 4/Rect[65.905512 284.803592 188.414789 266.083592]/Subtype/Link/Type/Annot>> -endobj -12 0 obj -<>/AP<>/BS<>/F 4/Rect[125.549555 208.084764 286.09057 194.485154]/Subtype/Link/Type/Annot>> -endobj -3217 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3216 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3215 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3214 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3213 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -3212 0 obj -<>/Subtype/Form/Type/XObject>>stream -H‰R(Tä0u -endstream -endobj -1792 0 obj -<> -endobj -3218 0 obj -<>stream -H‰œ–yTSwÇoÉž•°Ãc [€°5la‘QIBHØADED„ª•2ÖmtFOE.®c­Ö}êÒõ0êè8´׎8GNg¦Óïï÷9÷wïïÝß½÷ó '¥ªµÕ0 Ö ÏJŒÅb¤  - 2y­.-;!à’ÆK°ZÜ ü‹ž^i½"LÊÀ0ðÿ‰-×é @8(”µrœ;q®ª7èLöœy¥•&†Qëñq¶4±jž½ç|æ9ÚÄ -V³)gB£0ñiœWו8#©8wÕ©•õ8_Å٥ʨQãüÜ«QÊj@é&»A)/ÇÙgº>'K‚óÈtÕ;\ú” Ó¥$ÕºF½ZUnÀÜå˜(4TŒ%)ë«”ƒ0C&¯”阤Z£“i˜¿óœ8¦Úbx‘ƒE¡ÁÁBÑ;…ú¯›¿P¦ÞÎӓ̹žAü om?çW= -€x¯Íú·¶Ò-Œ¯Àòæ[›Ëû0ñ¾¾øÎ}ø¦y)7ta¾¾õõõ>j¥ÜÇTÐ7úŸ¿@ï¼ÏÇtÜ›ò`qÊ2™±Ê€™ê&¯®ª6ê±ZL®Ä„?â_øóyxg)Ë”z¥ÈçL­UáíÖ*ÔuµSkÿSeØO4?׸¸c¯¯Ø°.òò· åÒR´ ßÞô-•’2ð5ßáÞüÜÏ ú÷Sá>Ó£V­š‹“då`r£¾n~ÏôY &à+`œ;ÂA4ˆÉ 䀰ÈA9Ð=¨- t°lÃ`;»Á~pŒƒÁ ðGp| ®[`Lƒ‡`<¯ "A ˆ YA+äùCb(Š‡R¡,¨*T2B-Ð -¨ꇆ¡Ðnè÷ÐQètº}MA ï —0Óal»Á¾°ŽSàx ¬‚kà&¸^Á£ð>ø0|>_ƒ'á‡ð,ÂG!"F$H:Rˆ”!z¤éF‘Qd?r 9‹\A&‘GÈ ”ˆrQ ¢áhš‹ÊÑ´íE‡Ñ]èaô4zBgÐ×Á–àE#H ‹*B=¡‹0HØIøˆp†p0MxJ$ùD1„˜D, V›‰½Ä­ÄÄãÄKÄ»ÄY‰dEò"EÒI2’ÔEÚBÚGúŒt™4MzN¦‘Èþär!YKî ’÷?%_&ß#¿¢°(®”0J:EAi¤ôQÆ(Ç()Ó”WT6U@ æP+¨íÔ!ê~êêmêæD ¥eÒÔ´å´!ÚïhŸÓ¦h/èº']B/¢éëèÒÓ¿¢?a0nŒhF!ÃÀXÇØÍ8ÅøšñÜŒkæc&5S˜µ™˜6»lö˜Iaº2c˜K™MÌAæ!æEæ#…åÆ’°d¬VÖë(ëk–Íe‹Øél »—½‡}Ž}ŸCâ¸qâ9 -N'çÎ)Î].ÂuæJ¸rî -î÷ wšGä xR^¯‡÷[ÞoÆœchžgÞ`>bþ‰ù$á»ñ¥ü*~ÿ ÿ:ÿ¥…EŒ…ÒbÅ~‹ËÏ,m,£-•–Ý–,¯Y¾´Â¬â­*­6X[ݱF­=­3­ë­·YŸ±~dó ·‘ÛtÛ´¹i ÛzÚfÙ6Û~`{ÁvÖÎÞ.ÑNg·Åî”Ý#{¾}´}…ý€ý§ö¸‘j‡‡ÏþŠ™c1X6„Æfm“Ž;'_9 œr:œ8Ýq¦:‹ËœœO:ϸ8¸¤¹´¸ìu¹éJq»–»nv=ëúÌMà–ï¶ÊmÜí¾ÀR 4 ö -n»3Ü£ÜkÜGݯz=Ä•[=¾ô„=ƒ<Ë=GTB(É/ÙSòƒ,]6*›-•–¾W:#—È7Ë*¢ŠÊe¿ò^YDYÙ}U„j£êAyTù`ù#µD=¬þ¶"©b{ųÊôÊ+¬Ê¯: !kJ4Gµm¥ötµ}uCõ%—®K7YV³©fFŸ¢ßY Õ.©=bàá?SŒîÆ•Æ©ºÈº‘ºçõyõ‡Ø Ú† žkï5%4ý¦m–7Ÿlqlio™Z³lG+ÔZÚz²Í¹­³mzyâò]íÔöÊö?uøuôw|¿"űN»ÎåwW&®ÜÛe֥ﺱ*|ÕöÕèjõê‰5k¶¬yÝ­èþ¢Ç¯g°ç‡^yïkEk‡Öþ¸®lÝD_p߶õÄõÚõ×7DmØÕÏîoê¿»1mãál {àûMśΠnßLÝlÜ<9”úO¤[þ˜¸™$™™üšhšÕ›B›¯œœ‰œ÷dÒž@ž®ŸŸ‹Ÿú i Ø¡G¡¶¢&¢–££v£æ¤V¤Ç¥8¥©¦¦‹¦ý§n§à¨R¨Ä©7©©ªª««u«é¬\¬Ð­D­¸®-®¡¯¯‹°°u°ê±`±Ö²K²Â³8³®´%´œµµŠ¶¶y¶ð·h·à¸Y¸Ñ¹J¹Âº;ºµ».»§¼!¼›½½¾ -¾„¾ÿ¿z¿õÀpÀìÁgÁãÂ_ÂÛÃXÃÔÄQÄÎÅKÅÈÆFÆÃÇAÇ¿È=ȼÉ:ɹÊ8Ê·Ë6˶Ì5̵Í5͵Î6ζÏ7ϸÐ9кÑ<ѾÒ?ÒÁÓDÓÆÔIÔËÕNÕÑÖUÖØ×\×àØdØèÙlÙñÚvÚûÛ€ÜÜŠÝÝ–ÞÞ¢ß)߯à6à½áDáÌâSâÛãcãëäsäüå„æ æ–çç©è2è¼éFéÐê[êåëpëûì†ííœî(î´ï@ïÌðXðåñrñÿòŒóó§ô4ôÂõPõÞömöû÷Šøø¨ù8ùÇúWúçûwüü˜ý)ýºþKþÜÿmÿÿ ÷„óû -endstream -endobj -1790 0 obj -<> -endobj -1791 0 obj -<> -endobj -3219 0 obj -<> -endobj -3220 0 obj -<> -endobj -3222 0 obj -<> -endobj -3223 0 obj -<> -endobj -3224 0 obj -<> -endobj -3225 0 obj -<> -endobj -3226 0 obj -<> -endobj -3227 0 obj -<> -endobj -3228 0 obj -<> -endobj -3229 0 obj -<> -endobj -3230 0 obj -<> -endobj -3231 0 obj -<> -endobj -3236 0 obj -<> -endobj -3237 0 obj -<> -endobj -3238 0 obj -<> -endobj -3245 0 obj -<> -endobj -3246 0 obj -<> -endobj -3247 0 obj -<> -endobj -3252 0 obj -<> -endobj -3221 0 obj -<> -endobj -3249 0 obj -<> -endobj -3250 0 obj -<> -endobj -3251 0 obj -<> -endobj -3253 0 obj -<> -endobj -3254 0 obj -<> -endobj -3255 0 obj -<> -endobj -3256 0 obj -<> -endobj -3257 0 obj -<> -endobj -3258 0 obj -<> -endobj -3261 0 obj -<> -endobj -3262 0 obj -<> -endobj -3263 0 obj -<> -endobj -3264 0 obj -<> -endobj -3265 0 obj -<> -endobj -3266 0 obj -<> -endobj -3269 0 obj -<> -endobj -3270 0 obj -<> -endobj -3271 0 obj -<> -endobj -3274 0 obj -<> -endobj -3275 0 obj -<> -endobj -3248 0 obj -<> -endobj -3277 0 obj -<> -endobj -3276 0 obj -<> -endobj -3273 0 obj -<> -endobj -3278 0 obj -<> -endobj -3272 0 obj -<> -endobj -3268 0 obj -<> -endobj -3267 0 obj -<> -endobj -3260 0 obj -<> -endobj -3279 0 obj -<> -endobj -3280 0 obj -<> -endobj -3259 0 obj -<> -endobj -3242 0 obj -<> -endobj -3243 0 obj -<> -endobj -3244 0 obj -<> -endobj -3283 0 obj -<> -endobj -3284 0 obj -<> -endobj -3285 0 obj -<> -endobj -3286 0 obj -<> -endobj -3287 0 obj -<> -endobj -3290 0 obj -<> -endobj -3291 0 obj -<> -endobj -3294 0 obj -<> -endobj -3295 0 obj -<> -endobj -3296 0 obj -<> -endobj -3297 0 obj -<> -endobj -3298 0 obj -<> -endobj -3241 0 obj -<> -endobj -3301 0 obj -<> -endobj -3302 0 obj -<> -endobj -3306 0 obj -<> -endobj -3307 0 obj -<> -endobj -3305 0 obj -<> -endobj -3303 0 obj -<> -endobj -3304 0 obj -<> -endobj -3300 0 obj -<> -endobj -3299 0 obj -<> -endobj -3292 0 obj -<> -endobj -3293 0 obj -<> -endobj -3308 0 obj -<> -endobj -3289 0 obj -<> -endobj -3288 0 obj -<> -endobj -3282 0 obj -<> -endobj -3281 0 obj -<> -endobj -3239 0 obj -<> -endobj -3240 0 obj -<> -endobj -3310 0 obj -<> -endobj -3311 0 obj -<> -endobj -3312 0 obj -<> -endobj -3313 0 obj -<> -endobj -3314 0 obj -<> -endobj -3315 0 obj -<> -endobj -3316 0 obj -<> -endobj -3309 0 obj -<> -endobj -3233 0 obj -<> -endobj -3234 0 obj -<> -endobj -3235 0 obj -<> -endobj -3318 0 obj -<> -endobj -3319 0 obj -<> -endobj -3320 0 obj -<> -endobj -3321 0 obj -<> -endobj -3322 0 obj -<> -endobj -3323 0 obj -<> -endobj -3324 0 obj -<> -endobj -3325 0 obj -<> -endobj -3326 0 obj -<> -endobj -3327 0 obj -<> -endobj -3328 0 obj -<> -endobj -3232 0 obj -<> -endobj -3330 0 obj -<> -endobj -3329 0 obj -<> -endobj -3317 0 obj -<> -endobj -1639 0 obj -<> -endobj -1786 0 obj -<> -endobj -1638 0 obj -<>/F(rfc9553.xml)/Type/Filespec/UF(rfc9553.xml)>> -endobj -1787 0 obj -<>/Subtype/text#2Fxml/Type/EmbeddedFile>>stream -H‰¼WÛrÛ8}Ÿ¯@ñ%I•I]3θdMyœu6v\¶7³¯ I“ -+_3ß2_¶§Á‹.–dGRÖ.—¾œî>Ýèýþ˜ÄìAh#Uzúª4_1‘†*’éøôUnGþ»W¿÷ééQÈp25'òÔ›X›4Óé4˜v¥Çv³Ùjü÷" ã<^-ÐëxLfúÔ³:7‡~k¶=©ðŠ'âÔ‹4Y_ -¨ y,­ÿ— UjyhýÖ¯Kód(pû··o!ÈäÃD’{7Ëpûâ»sἩÉSÝ!·b¬ôìÔ36òÈꓘÃO¤SC£baN{,Ï"^þ´*,¯Ä˜Yr#FµT£´]üδÈî$9Ñn¶»~ó­ß<¾kŸtš'Í&œN#ñ¸*1Ô2³0PI¢Ò£ÁLË8–áÑ'-ÄýÑ¿xzôonù=OùÑneêÌ:™ý_ëÅ2½g-FE ¢¸Õ<¼: (]<qã9tµˆO=øñà56Ê~ "%ÄV3hwß7 -E<Ü}[¡SÀøTH®ÓÄ+=i7›~ë¸ÝÚpg¤aýÂo+m,aש÷ùvPìõëŸ'ìû|ûõŠÝØÃ}äS#Vž`g€¤×p¢J±Fh)ÌE:R,u©ws>@šò8uzY-xR¦U£¼Çs;Qá”Vò±» (u!äÖŠŒ§âÞc£<ŽKÁ -)kY½U‚(€ÈSù½0ÖLÔôkzNŽ_óq•"ýsnlÂeÜk,ž®Eð(‚ǦúÆJ¦Œåñ|K4ë_eÕ#kwº½Fµ¶xŽü¶?PÈÁÔÀà€ý)Œí5Êų¡´³þ¥ˆ‡ -®‹^Ã}/ÐbL†~»ôåï¥û*ýwÍæ1®ÒÏå½<µzÖÿ†Ð<–œÎKO54|o¬:ß„]_«ÞJ$-b„*n³‚²±„%>] 7Eýr1ê_Ôh¤E¤£~ɵT¬Þù¡ _\Üùƒ«›}b^†ì›äìRéüûwyÄZ›#y- _Dš·¿¶ÚÝ-aº€îÙ¾!J® .áz/¥ Âôe(LÄÞ LJüØ|ë±™àºàãyý¢¦û\C®ûU,N•¾k•gý‚{ùJqâ^Ì°õ‰gzêky¯´l¨Ôý¦#%Ûšû\G7¿ >Üœ­nò! (.Cs5"¤Tñ«ÅyÚY×€R \¼µGý–׿›HÃL&B9’a‘¡‘ÉTÆu`‰˜ñ4bŸù¿uý‹}þaìJ•¼ûš@zf_eãÒ{F^Ö AÁ:)ÎØ §Ý” ˈ¶ -Ũ` -qªÅc8Aÿ¸ÊJÌÎè°Ô°Ížñ,‹K/LÀ.,ã21蟵â!IcUë‘›°@°‡ì+Ô¦9­Ø$«PÝC9ÎUnŽ`ˆić±8rGŒL²Ø‰É´ -aô¦Îk ò©—j%ÈÉÍ¿œÆBÙ“–a©²„ºó‡%ðCcLVmœÇD<¢ÃD!J&µ24l:ZÔŠ!D«LKTIÀГ—Ãnʸ³TLKU" biœ"ÐyϨµ … -‘²º#Ó¡Z«»ÔõkëÊ-3¯ü* Å0®ÎÚ2I!.D‘ÓüÆmn|5ò‘¨jÑ©7+ š&õ .R4óz #F½Çr]Ìý•AË[à$¢pfâ| DDTŒ¦´æÏ °¨•ÂŠþ­[¤wt‰Å^ƒŽ/HÜXK6ø‹VП( td%ª AèO°;òhxÎ)4ÁËÚWÝ^§º’íl ¬ŽrDžRÖý‘Ž‘,¨¡wÜܳs¥C±$í5 QoF…Xƒqbêy½–‹£XM’ívVÜ™p³$U!P²Ëò!Ê߹꒓ƒ(]º?”,Rœ+hf8[’µÑŒlÅOÔ È‡ÛOäÃy®qG/ Y¤1µ6ZáZñQ×m™Ümò{I²—¿ë¶öŒhg%¢ &r n¶€?ך"lê,¶‹‘'f[†Kh Ú9Z$ÂYF‚„ˆ†”“Ð ‰µfÄ™jh90·K‚z(]hãz,ìü…AoH¼(|jRÚ½4Ûù+cèž6ôlJUJ/†µ0aÖ)@ÙH&¡ÊðÞOìAy¤ý"©uû ybæT+ÔG±²ƒ´Ÿ0È\îëð £Q¨¨¯;éºhlH‚LhC´/Iƒ3–qWK²j6(†.´·qÌœtè¤5ªm¯¤m?OC&/Æ ¤ÝÇÁ5ê¤vbî×+þˆ1—$]S’×Ýn´QaCˆ»uV*X&™×ë3Ô’ -!)ìÈå'ˆ&|ÊÓ5ùù†ª]ŒFdµrsƒª-i[d¨Õ* Øu,0*T<øˆÖZéJÐ;dvTÆp†nn0ª¡gx®U#Ø4«eXôü©´“’¥©ÀË’5Ìø—dðx“µrâÚbB‘f}æ$”u2uE„0 ¸óñöŒ})0d¢ÈîÊ䧗DU´Ù DÕ0Š\v_Œ29,*vŠœƒ ½%qS:KílU§¼ÆÀ—M¯ñd˜é=62ööæ ì¼p†±Ô€h„¡Á”¢‡Áßõ$ 9(—ž°O³!°,_¨L$™UU]·=L‘r/¯šg©³;'uÎJ®pŒ§Ü暀vEs[/ü„×qÒ!¼›ö`§ƒóS™Å3Ÿ[×W“;8wïBÌ:ÙT>2|>2çùØ( }ãËͪk¸pŸí>‘‰r„e9&üî›°ÿ¯J;í É×q”üv{ÙžÖ}"„ûDÖîM¹O„wŸÈ}#ç•ð+QT²–/²^Ã6JܾŽ¸w ÈÚ¢)Šð9w É î+ñ(+ø+DöfÓzuq}áߌsî^ñÜíº|4Õå#|—œwy%*¡^¶€ßôƒ³“¶kúÑTÓðM?rÞô›â¹(¿o@éÆfçL­9S3gŠçLsE³Š×ðNCè6ó§qˆ|m‡ÎÕrbtˉMüc,ýØuËEV*¿Z‰T>ÈÔ‡r®C²,@„¯ÝÜm?G>s§m<1¢ñÄÖ'žj<1¾ñÄÎ϶Ž›žµ­ãœÞ[· xªÅø;oAÛÜÛf~^[ ]laRbÕaá\¥} ìD“ŽOëR „K-¬]j1åR ¼K-fp©V¿»ÍçEuöïF*±…#ÝÝ&ÉM? ¿6ƒW-¬½j1åU ¼W-œ{UÚ(w*xÉe7@zòó¹ÓöUÛWìSi[iU j •p®W ‡Ï}¼ÝzÓ®w|/ï=~tw£ýŒu¡Ÿ{ÐRÔ<ã5S‘þèìFÎz÷ã»~€RVé1>Á¨š…nΕ«×+á%ÿÖ_nÃ`@ƒñ f˜X jo%Š½äoþÓDk¢™h€'¸6v%x-ÀÛûƒyˆ†ÖDC3ÑO4tLôþ#/ÑŸó°¤Ö,©™%ų¤ŽYæ¼xlø#èp4SfÍ”™™2æ!ùÓûNÿa¢Ô°hõ:š®X®²®5õ¦ß7ù[ÜWšÈïêþ‡7v~tãwÝ÷Û^d~©y!¿óöwVz»ë%×0I`’ü¹1I>ëIUKa ¶MNî¹ð—¨þ±\ÕëádÀªOeñ¨9,á°6ݽ3Ê×É`±nºµc’&±b­îåôýéÞ„ö+p Kó²°Xî—†LŸõ¹ñpª5ÕÀL5ÀS SÝô ûætº¡5ÝÐL7ÄÓ Ó­V‚?×%²íá]y1UjM•š©R_' L’Ûqòl‰"5´NÔp*QC|¢†ÎuÐÒxèÞ§Bë\ §r5Äçjè­‡á­F¾Ñ®ßfÉ î§PO$5ܦf°Ã÷ª±')QŘ6çéØn·üz½¾²ª;5`G 'ÈL›‰ýkæ˜ÖìIÉÃÈÒ1Àfcà<S%Zb~ùà×OÂÿ«‚EPËé+/¹ì'Iù@`’üv{ÙM°×俪lVîpï -ÐÃp›,›óÐìßÞµ¿*s™®¡öe~úÄ‹Gá{Éõs;I`’\¶“ºº§"kÔ)«{Gõ¸êÞßcQÝÇ'õÄ[“{sZ)‘Ë¥,8È -@—M!ë5(ý"…—|~„$é'aùÀä7·­i‡ïõãÌèÑÞåÞ½ªæ~)ÁªÄߨjøGÚ÷’Ûv0·ã¤.‰Žòyxã;ÿø3o¼y9·¯LTò±àµÈ|ñ”Ôº{Í¿yÉÆò©™õÇï Æ'˜™#wÝ­Žº‹‡Õ˜ËÇ„‚ÝÁ¬Å.ÓÀÈMß9û½íèÅÔŽ¾ÂöMO ~ÚÌ™Zgv8•Ù!>³C白!d§Õk3ó’ýB’;'—sok¡ut‡SÑâ£;t݊也vO¨6–˜—\u“¤|e·Äæt@Šv@j’Šb…¢'sÀ•É!št ¢:“ R„ Rk¤S&Hñ&Hg4ÁÕ(W&¸CË}Zû òAŠ÷AzJ,1Â#WÚœ^ÈÐ^ÈLr1¬Xìd^X›¼ðn½:› 2„ 2kdS6Èð6Èf´ÁZ+õÚk±iƒoeœÑ™µ²)dxd'uÀâ <|Íé~Úý"“TV¨èdî'Lî÷©h–ä+Ï›³y`„ðÀÈÚ£)ŒðÍèôò_Z½:'ÜôÀ]b dNKŒ¬-1š²Äo‰‘sK4ÈQOêÑžÏ,F`-F`#À‹œ2ŸêCêX´‹©í«¶¯Ø§m¸¥é´–á~ Cœ~¡cí`¾Q²^kñ* kS -<í¶ŸÐªmLìSÅm*…;Ìl¯*{’èuŒ bó'œ!}à±+®*@§ííÏkò¹;Û¿JŽ©gážø8Œ¡!6Blh„Î#Þæ>'¼äËÍUo7ÇðÃú=Ú7è~¢Ç“:¦ J©¦y3ŸÆèî@Ñî@Íî@±î@»CÑNÀ3Þ¨r=Œ’i}Žs Šv jv Šu êÜ-dñ°“êÕë8’+ÖEØÑ.Âö“~åQ”…ÇðT¾Z‰"“ÿ¼ã€ÚeÞÔO¥ª|žeJT•|Ñ ý‹\ c»á¾Å¶ õãûþg»¸¯LõáÇ÷ -þÒöp)³,ýýå„)üô/ž,jUfM;訦÷ s6Øêÿ˜Tyó(¤È®ál|×6~ް׳ïõãö*þ“þ»'Y‘¬L›%\Ú<Èê4'¯9Y–™Èµ<¤ß8‘”«¬›ký#Ïפ©D?Az9È}Y>¸%“ -~¨Të‘7¼ ¹L»JÜ2PZ½HX ïÈUM¸\VÀ‰Ü ˜#<‡e\tKuó¹¼{cH÷B /Ðü?óÕ¶Ü6rDe -yˆ]ER¦(Y–ãe…¾ÅÚÒm-)›<É96À˜(úkò-ù²œîºQÙT¶jË"€ééËéÓ§_ö_ÕxB4²ˆm+¢ÖQX!Tˆ°Éá.åP‰ïj›FÏÑÅœ>ËY®SŠ©&$½ŠãtiÞ†WaèUÍå8òSÐÅAÿ«ôk°îW¸K®³ÞöúÎïÐ)®ˆ¥EKZ›ëqa3O‹xJUY¤Æ¢ÞºÕvå­qäŠýGº9…ë·>%†ÁA–8ºIõ”¡ c=+P-åæÙB~G10Fõ5Àð’çüpÌà_ l”Àǹ(ý|Š[{ÑðSÅfaŠÉœ2GÀ&¨¼ò†ò–X|ön<Éú{Ó«‹KqzvùnÇý±’ -‰Ì´´"CÈÊ¥N‡|Yª„vobêžy¹çÒÚV¨æŒ¤_~ hà#’ö &Ô¯g§âÅQ—þ}y§8Ø;ÜžÎùðΰSźœkdZ“62@5´)Æ~\’s컯ÉÍÉ\&3u§oov÷·§R>LTwe€¥ÊCöú9-9£­c" Q¡³Þ› 9ŠAòQxH7†§©9J(i´ÊÓ4g”(@y#u,Ç:vW]›U³KFWÞÀP±^€¦,‹Ëå$†®´j}HÌdÖ§.…æò>mLØ"ÍÖu8›p M÷†ÿÙb¼×¥Ô‚|‘B¬º«‘²nèG4<©^r>¿ú—”fžñÍýCooéϦŠ¿·§z^É·Häÿ¡Î¢ÖHÚÀì¾ÁË©ÔXü2@xº¡™çHìë#6»žø’.¦Zg•ü%spà l‡×yZÌæ˜/±Õ4LšZ@ÛJ˜³zMn•º—©E¦DNFâFÖv÷v_o5><,‡ó ±™ò¾ŠÔÐx %P‹ò@7 gX‰W²áš+÷r™ÿDÆÕÆ0ª#QäÇæÔ쨚oÑè+(œ,…5¨¡„ìC¯èŸä•;Ÿ¸ØCôbãb²né´T2½F -‚{ÙYá$‹Br=il…Fn è\ŒÎL8…ìcÛº¤f:ïžctä’Z‡ÜèŽ%­´k›Ñ¾I³¹µ‡¡z ¶U%#®’°zÁCz™këŠCÓhªP@xÐ×JÚPK,A‰bÌÍÂ:Å:Á†Óµr -µpaÁ¯¦&%! q8Õ²j¡_(Ä›¤ Ê+UCÒ>Îõlãxž.½3xNŒ?QÔ4áÅœYu“Æ7ˆëw˜í°<®ûü™4%`ëDŒ[Eå8-!ž®”$7jxBZà¡ Ã-’ø`Jxê:͉§´œÓkz 3 Œm•¬Ð‡ˆ®¦CW#µ Œ‘gÁ€DÔ2­Zu(+_Š&.g9ƒ¨šAÐD«ÀÛû¦ÃáþþöË*nL‡'d1ó€kÛï‰|¸Õ5B# -7áíÉ só4ON •¤·MáöÝœ¾]ÛúÚfsÿ9³¹ß ‘üþöЯ·O+nÜÙ˜»,C†lRªáf  å'Çì;Oß0œ#Ûd"^õÄ{4Sp-†W¬'š°^PµˆX¼"¡¦(ˆ âõcMñ=1šLÒ|Š§D%<eN.Îà[NÁ4h´²üp/¸Õí¥HÇ­­w™–}©Ö­;>¯w -Y¸-]sw’ÌËæùjv÷QjöŽÛ‡§ÕsR%åó§ˆÕÝn©§©¾#ÑK$Þˆ(ØQËý4ê4‡«käV³òõ×O¿]}ýô±åäÅ—Ñññ]Ïï1yñåìê¸Ý ½¸×™g''ŸN?¶úƒs¢õ‹†“Ñ?ƒ³Ô図óË£³ÓQ’FâºêØM4Bh5ëp É3Éõ˜×,ñþÃù¿ÿÕßkѹýþö*Þ¶ì½ýƒí§ -†U¦^Xzw?]ËfF<Å…ñ‹3Ó-€oè5 øD@‹¨-È{—Ô#Avôþô³£3íxk#ý$o‰Ê&"¼™‹ýÝÁö¹àÃ;Þó&/b唣٠vZGý™PšÔÙ}ƒá¿áh`ÿE)!m™L"þ_?wÄïçññ·«³ËOñ÷_F_;bt|þeäêýñèoG—/>ÿC¶Ù-™šÆH×®²š5[hº˜›ÔÝ„ÛàQ4Ývõð#µK<%[?‰ DÐ,ÕË@A ¼s:ÀšõÊ:Iãt¶"à³@òÞç+yÇ=R ªÞ£{nPö\0´ý@˜©%œ%€½'šDp}3R &,tLtá”ÄŒ Åûˆb÷1|Òñ7Ü­i¦Hæ¹\EÖ¥£xÐ^§­8z¡Ý¦Ç÷¼ˆŒÍá !ªwÕç?Çi+™˜’Å“"Ž£—kíþ»¨7©twÿ°Â÷/ÑÓäâ±N¾ÿÍ­ÍÌÛüzÒÅgÓ¼—æ3úIÿÓªjÑÎÈä³’³&˜[Æy3ZTA#ÎRw•;(-u6—šv™.LZ£?Ø;l/Véðð¨K`x·C¦ÂU5nW]jÃ0WX21I§Š -+¨›<¨'×4x≮ÒiTR×0bzâw.†l ñD 98äRD`7«$MV‹´0aJD_‘ÃNEðÿ×ȹc¯S¬OJîÖ‹ãóÅð ×ÂÙt7ÓÞáÁð,¨ýyõ|o 9l†ð#h ¿’4F|7)Ù.q£ •ÃTN§Ø‹ ¾L=<‰ß´i| SXÈâx8&¸ã´±¬R(¿ÎbÚ|bI<¤bEªÁü…=P·r·è -H ïœ2 -ß9ÿmS ]İ—ôÉ֨ƽëWp§F2Ñ?tëŒøôƒi6R?È°wÐ9sGÖ¯Ó8N—èÍ·aeBäágW•’S™Qâ!29Á9ZËÌÐP–›‡êÃlu·.ØŽuÛW½°G -°×‹†#Ì=ý£pÆå )JEž?ŽF§£uѦeâeû>_mÇ•¾ ½×Ñ0ªOâÂDЄ(¯*µùN¬—‹ÝÍ\ì"g aC,Rˆ+³ã<×˹F°:)á(©ÖÈÓp)pÚdjÂÝÝÔ<¥¼[‹ˆZ¢ ß·j°ÕÀGå­¯Øó©ø+›Y]6&‰ƒ5j5™{!VÃKÖ[£'Ž’µ˜f*Q¹Œ;n)¨îž¦~H”“pc$JY4|뉶سÐOiaãö±B†qÏ¥k¯1ÚÒün'ŸÂ­'"«î/=2 +Å0Э Ãà\ü±¦s<°¨Ù&³î7ãùºNÉÄÕþQ)é÷š{KÒû®VÉ4Í»ޘ˷–o#Û9ðfÝ`,)“DxÃ8@vrõ£Ð¹çpjÆ¢Mï®} p{®p é£Lær–Ël.t$- K…“­#Á+ ž`™ï[ô9M#'ÃÇògäNl“×S¨–ž^yL1BnH‚!0’Àßèi:MÂÞzDÿá½Z{ÛÆ®à_!T p¶’[v®c¬œ6€ElÛÅ¢¸")‰Å«å#Žûã;sîƒQ6å¸ýÐnD“÷žÇœ™9UÄëM¹uŽÄ9ûþd¡µõ£`Žû½1q…˜öˆÍne.)ËEÇÞ ©9¾áW³µrå\ùÅÇMPM‰— -ÈQº›D#Á,¾#ì7eEW=ÍÉå¾·µçeðIh½‰vBãÑÞ#ìºYãI(Ö²«ãT¾a¹Ç10É‚zÜ­ÍI–è h½ Þ‹Ù ŽÖÀ¦‚åÞ>{D†v¤p`Æ_ãÔ%g¹j@v*“Eu‰P–yŒ)Ì©LYð\f†KÔN@ò÷ÓçCJgéõì_Äþ/LÆjŽ]`‹´°Ý4Gº5©v¾5·/ÍíKbù¶ÞzÎkdY­6½wº1žc÷ÒF=ù5//ÝTgâÉ]Eðø,ž–úåUÿ?Bp‡ª*ìt&H4!ïwà”ʼn¬"V ¬³ñvϽáÉôDBs¢ˆ)²ÉŒ3@z 6”2à-\=ξ<žÖcè zïÔ‰±Tê<"ÛªK^‰TƲe ùØà,GøÀˆ* ÉW%xu^•ØÿF¾„ :c¾¯. Ëæ ýIuzµšÐkce«a“êVß´QjòØ$/¬)ÌãxRÒ`DqæɦYËV{Ìßç–.Š(“°‰ZT¹À  DÖ\2¤ì"Rò*2¸MŠ»:±±7Ù'Þ^ȲW$ËL•‚€Ä - âÈùR‡Ø ³0­"ü‚[Þf?¿{»W„Ûò{%{F‘VKÙÞãxÿ?é^}Íí0øä\ðµáŒ}69µgÔ‡ŠS[‚2ƒŽ4#~xo‹)-¨²ž‰‚4d&Z‡ ªÑ7Ïõ­.@qùŽ÷q¾/ï1¯ßirÎ&]ƒÓgðÅÀ8šË]½ïÓz~ã ªd·H¡„]ÍÝw+(ÊpÉ·ž7nÍD4üVŒåÖ)÷×¾h\;7_z/„yöëÍo\úŠ&Y®´ÌtG=l~‰·Bä"y&åŸb¼9 Ì× ó(OŸû0Už«-oµ1øà¸ÿ”«ÁŸ7‡`‘hø£h¹.ÎUŠSô‡C±àôò9SpTúøB]¥‘q¹[y¦ -WºZ®ÈÀ:)K|` ¸F9çbi$å¨ù–êС|zk*Œu*æóg] hçÝõÁq&ŠÑö[¡^cŸ@¤•Ptñ½¾‹®«²s§æ¦€7IÉhÅDhH:äpÔ=®2ûo»=ÚŽhÀ÷±ìés=ñöäIäo:Pþú®¿þèLÃÌ?nؤèpÇSZ”ó‰#â*ßè‡×F-cìWqº ’õ&¹´)»Ëñìd±µÑ÷O“2kb+ðfŽy¼Á>‰ƒ -T¶sA_™…+áQ+¨ªqRᤵÁRÝu’†‹é0ÏC x‡r×ÞÞ8 Èmìâ^kôp½¡5·p’m…,`Ëzêím9«‚3‹ iÅ!& +ø5°N0íh®(ª5pßÊ\‚ŸkTÇì=7²îôæz¯³¨ øÒi¼Þ”[ÿ«1Ï;³¾[Œóî@§Iß[èYæ#d"¨ •U’5õ™­‹hÐ2XÁh6ò€šýâñÔk¸‚nWp!à¹o@ ø|Cú™IŸvºh¤cæ䪠ÖÁ'Ì¿;éi2¬\gOW®?o‚£¦N³g÷V°§fµKèx Ù^mŸÖ©Ï ³oØ©±<ŠUd†¬‘GmÍ]ë¬A·í{ }QËа|³ÇöoÚ×?Y7OÉE3Š -Ük»[êÍZ~ …@² EIŽ‡é–»ÞW,×1M„œ“‘çjûl< Cí¹7ë«“ê>³û kyÌb;a:âBž`¯lÒÐ~Û³{ñõ[yüƒ¥%¬vöÉûÔ@ü ´@E‘L»×¤’ûT5Ú&×ÑñPWPGéýJ¥W„ÒMœî´šMšŽ¶Ç÷¢ -õR{ÜhRyM¢'hÀñé@ï‰Û®o£sy_¡OYꉀŽn/ÆI ‰Œ@]¿1¹d«ŒOu”R—A+LÔ©”HA½¿%ëjÍ¿]\@ˆË¸!.’?âq þü é'9a Cö€‹ÃJåèE A_äz-­}þù'9à]’ÆR‘OjÚÍá^œWy -ÆÙ¬Ôœ¢£ÚûŠe3Ætõ-¡Y*_Æ(zpþâüÔÙ”çµÏõÂ?z3º‘¿ä¹åÌNÌQ±è§$ûòf´*ËMqyr’/ÂI êüXçKþäÿxÁ_\ù/ü§„›4ÈÅpr=ÆZE°Ð¢ˆ*ª+ÞŒžqí,c¦C|_Ùý¯Q=Nÿ4ûôööÖèDaó­£Ñlòo5ùãùäõ ·ÚnÈúG£ ¡ä­û*+/B“FÿAHs„áYíþ6© -ã¶}»-c­6ÄhU 7ãû˜Ÿ~‰·&GÚQ2ïm$qu7Ú0LSÃ-D‘³³n—a ÄÃkf»öãÔ -.âx‹²ùAHÖlÇd£¸]4}UHji=z¬ P80ßB:8^‚ç#~‹Ââ²Î6IÛwÓáBät­…ܲ0)ˆ,Zf>[×6¸lÌÒaÄ70_¡š§oÃ+Ý[(þï(—c_h7f™ÂDDfá—©‡å"Ùu]*eìvõ ÿœš‰çŒ@…¹.Š`AKHï_7Ù}º IOªßFØŒÏYãfÉòŽuµ Ó7öPA Â*UyÃm”I¢0Ó@G‚f<Æ`tÆ%… -At -"[™¢Ù˜)BÔò"6-¯`Q¸ÿàlu…E)£û1žãN;{ô ªQj×"Ζi·If°€,ˆGqÑËmŽ !¾= ØØ]fûdµcþ‡\ðÜkŸu²\•œê:êÛHPˆßIÞ -—#ÁÓòf¥K]4¥9ø7°hNâ…ãæÁ¬kÿ1ºg_×*I­Ô¯4ºÖº´y L<$e¥Ä=‘ÊefÁ -–•$Ve&sœ ï±lÙ^€îX½>s‘•“*ãB™ÉʧpgC®F™Z׃¼K©Ýgû¿õ"gM/”˜î6e¼Œ}s•Y'gWEµ¹¾˜¢”øïßNƒ¿¦åßßØÁüÛ¼Òê²{rJŠL@ÌIa³pGsúíX!ðÆL¨`‘jà![N6(*aV¯¤³ÂêXëÖ÷Ò¹GÓÕµÓ–­Qýï)ßóCËÕŸåC™ Á¹È™˜§Àøt Æ›×^äòãPLO‰éYÐ8mqed¬ô¯?ü6’áyÀ]HP±QS`§ªÿ¤‰Ï·ÚC“ÀoV­î¨æöL£¢8ê#Q vß5Ç/^??}÷»O®ü3¤Âh–ÊÚ¯éHÙ*ÄóŒNFã ÐÆ$QDz=,ü7ú?ªÞ€eXÐÑÏlanåÈBÖï·Ô9Y?zö¦œ½™iL­±ÝnsA Š¿ð†s¡iànHƒg5‚)\vCЩAEjCéCá7*Ä×À+KŸâš…7Ð$bKþ±nÿ8;MúÞÂÖY·±b qÞñèZÚg‹êÌÛìïݼGD¼E±¿0C¹‚3šW%³gæ)7ÆúÕR‰3Ç?öðVŒÉö$©Ä7‘sû…ÔÞ0UÃOï?´êò ƒ)í+w«Hç9ŠåWh—b!YÁ˜f8 ’"¨HÀJRð]°iâõ 4•xí¦¹ë3ê ½)’ã•zéäý›Õk%ŒÑ‘…g–mß×’§ -É*Xë5« ³\ÝŽðm“`!rYº9™nŠ}ùÉŸkÚ#†ÝƒÞ¤|wP¾ù“/«%Ìfu™¦K@à¦Þƒ9rp.…¡3]¥¶á*YqãætÑj~¦‡zsŽï(¼Ñ±ñ=:®¢É2-\³Ÿr7{ÅSA¸m9 Héx£¦:*ðìÜÇ—?ЈÇÑö,¤Ý·t¬¥­3̨"Ž!Üe-ëJ×Ò¸]f^?¹<2‰+棕G´Ã¼¬zŸ™dm‘Ÿi\½,1ÛãL²)$.D•$à¡V®Ã-¼Âµ¾ZHÔ©¹ÂZϾóä’ Ýr´™5Y¡rIwZÖ]‘`O2/6apd߆ØXrÀÌ -ºî–½*Jbõ6äKäÈÙ‰9²Üsþ§ûÛ¹ rF ’(Ö/Ä¢V@,ð «û±MÁHjUO‹=ÿòAä­¢Íùäø¾™‚Ï>u³àôíÏ÷gA~™²àGA²ÀäÞ‰u´M™ü*sê¹G;_Ó%$6@3:*Ëc¥ÕRÝB,ítYåå’C³‘n92¤wŒÍu|…ñzßD+þ úEp‡ON76¸Y+øiüÑwT|!¦¤¬Ë={̾=A³+ŽŠ«Ñ9ª[Öït)GÌl²-Oæ~í -[¥×êùŽ“®0×D;“»W;Ÿà²Uø8Š‹ö«qï«;\¿}"ˆ -ï̼uÒTçˆ7øb ~¡ W Bç͆£ÆÄÓbAÑ.Ê)wå H¾2R¶FÒ?0¬šqÚMBÑ×TÇø´ U@tì;Ãëìæë3š1kõÛžÖõñ7µ³*„`-—Ýhí¸Ä¥çêŸX Þpóמî ÉaðI§½kY»A´W²å¦Ø'Z?äKAÔBßE¡óNr;µÐð±Û\Uu.<§Ð÷½….qfí¾Sý¾€ýá£LçP‡ÇþO|[«üÁè ûŠù X‡Î*ûòn°.Šyòe4”à?‡:_ÑGú—6øÉßrzTw.¬;,SŠ}Åsg.CùϽÅçÅí„wÊ7¹]®·üòhÞž ¦êóOÀÕ‹yN±Þæá[a|­þýw­)²ÿ\V´ñmoÕü.„ºÝZÁWcÆhªy+¶xŸt‰“Ã_ãÚ€@Ùñr|!bðgˇàsfÔ -“ô„àuY­&½µÚ°w’Y$»XÈð÷DXzÔ.uø_ÍñòѲחnzMé >‰XÈ亹wåç}mM"çå½Åòüx¬*üÂõe™ü°,øœœ—ƒ¶EÅ…J_$ -Ý…êÛÎ??ø><ãùè΢ږ7%!‡ z@Û í5mz„i:}{y’¡—GóNZ&-·¹!'²VÁ…l$²@ò9(­8úvŽx êΣk`l—FÇœ$¬H‹­ ÂàWú`½®¤³Ò*±±®ùq°ÍiØîïÉZ5.˜¡ße®oü÷—\‹¯8[.TB}¡— qŒÌÌ6çCçÜ9%Ø&0x(iîUæVËO4„R€éËö^rî(äüJë}é&‘7Á`r;¾òŸçñíÿ oo§ 茨 C…Rêb[zúÖ>­2[Å¿tìe¤óœÂ¨XÇ VÓ»:xèf9ï~Ñ{O¡=ü}ãÞ$„fë£xð»Ï?ðWÁåWm8Ö7&€ßµ)¼ŒU+[ÛrÆ:Ú¦x3ÙȇŠvaµÄ碭sú[ «¶`øÞãŠD£m4ö^G7t¼¯²¹ØsÿáÊÎäd`¸” À< - $\‹Úž´”á1«çºÏW­b+-ÿÒ…´\ƒ£™ÆúˆƒçcOÄp×6Ý©eI˜™M¢"Uàuª4ö¦ÂÊırI³]+J ÂÅ‘j9³keŠ¼Ùi2UîY:ØŠÁ§Ix‹RïñŠô‘ÉÈN>Ëp<ø‘µá§èÔôIÖÆ.Ó5„G̾:=â±íe™ÑB°A©F§ØRµZV be -4W^Ó/¶¹†ñ²Óùûr ‚¯v§/S±g Òα4 -ˆð4EÍY¬¯n‡¯cÕè‰+ÿ$œÂ½Îín˜±í0/ƒTØ–¤S«?¡ê×ØÂN¾ñŒáëÇʉ|Y,*Ô¢b wù Ô-ž©³ ÓG*¾Hî3Ó,NR]é¹SI‰2Ë ‹‡Öb\ë}ߺT«vêëÜ,‡÷7 ¨‡vÍ{Ú°í™ãÞ-'W¦›b_~ªxϦ9Ã&‰:ôtÈ™qþphš|/¸Ÿè7S´Ç\¨óö¾hØÎßX/a xëÝýq´MZìtut©G«ë%ar¢$Ø mÄ|y1˜œ$+˜{¢L¬ÐÌòë˜ct¤h¬*ã@¬àl{ÚA k蟃ß`^àóÇ a#Úg!½Í# ÆzÞoTŸ°¿qÅŸ+gmØ$bß1Yª½síõ³JW¹Ø¬iÂ-Q?ÑRðÖ•;2Û(bªm¾@^c²T×ÚєƠËImŸj ¾±‰r‰€þ/à0´| ôOOD?ï7§ÿ¾<ö§'aj±OGx>gF­ iOYq"þ§ ©7@ïÚ•Î"a½b|üØö€)1hƧÃËì‚ŠnÏ‹s>´!™¬E9–~RiØlêIÃôí„;:f`Ýì 8„³¹ÈV¼ý˜7¾½ ƒz‡£:Ñå\k6wव†ãï‰ü*¼Ö©BUÙ{»16”‚”Âýƒ§eéz#ØÌÙAý:xŒ*Ö*l\±;ÂP7¶|™ÚbÄi¬uŽ^5‹–ËÄ)¯î½‹»†&ÕÌ_;|TlmÈà5\hìÅÀsxk˜p¢AºØFòíhS) Lâ?¬ËKq©PÑKðÜìTžó{ÎýßzøîhÓgC—˜–:IôŽpUsܶÑÁZ憎ø!Ó[ê‹p³ç†,ÁmÅŠ›i)*÷þAäqËuû‡¯M0c2Û~±VC›q†‚C㘅XFBGël¨¾3t¯ŽXoØüÔWt ƒ~ƒIOD¾'±7ÃÛ1àÃZAíé4ã7±½A·ã‘ëTdê;=þ;> 8/*‘º|´±-½å(â ·165õÄ‘yhLOñ’j;¶e°Omñ«­‚3Í&½Ý[¾¹[C V28tÉjnÚìò>Û““R›¢‚›Ù.qÿç‘èLÁ!mY¡-ÔN Ó…M¥Å.+à—ae›jᆲA5¬0YÙo•§¾ä'[&r®þ›½)dZÇ«kŒ$Ðó¾Ge9î`hZÈíÍzaäáiQz§Žö‚q_±ŸéÆîÊT±[¾µ¯0uµn -tw?»/Aön0ap -?ªìË»Áº(6æa4Ê—ÑPƪÐy¨ó}¤i“Ÿ|¥Ümû³Œæ—¶ï®Ö>ÆÑí»?Óró;a;ø¶—í4×ÿ%¾êv7Îè}ž‚`nÖ¨~²–7NÝX€²Éf•:¶»¶E/FäÈš5E*ÒZ!È}/Û>FŸ ¯è3õ|ß †¤dË^´A»"9óýŸs¾zý‹’;}ÐYÙ¨š„¼)î û<Ôx žBêª[[¡@b3(àäR3¼>-„—mÊ_5h±Cw’Û #‘Úö5E­Ä â¨1’49½œ<-utp<%I3ˆÈ»,*7‰V 1“YAõÙŒÔ~‘ ò÷›^ÿÜó÷éÃÛJ ¼ï®.Î=möïŠÚÉZ D\šÉcªÔøV%ôïgI?U·‹Œû…ÿEè;ßsÛÒ+«>s®â8sMÁ^]{m.£×¯Ë`ÌÎh:‘A½ä: -ÞeÑ›¯Ô×êi jŽbßó¦D>K<äæ¦q0.u„RÔêæêº,ÖRÜ¡§ˆW³…È<)‚…“™R˜]‹(#¢¦Xµí.öcCä.V±"[_9>L¢Û$űeÛéšgÞùEåЛ•q­Þuĵá{à†ºð$,ÁÏ€%ô0æ¡Ò«HlŠ~‚÷3ÍÐöÔï(õn÷.ïq5[³!ã—W²¦2Ï[íùRlÈ8ý…€`5•7@æ•_Èt«”kÑÑG”ÃGJž*í åöC+ GÅk¥±mB‰U©Í¿í)Ã<ƒ93=s®fÇ„9úíŸ?m`ŠÃÃÆV¹£»f$!†´qyøCØgÌbˆDÕ)i¦aR¦üŽÁT’,Å1„h°%éA -o90ºžv%㸌ýÔ.öIÍ™ŠïNýE–­ôÉp˜Îƒ¾ U–¤ƒ$½¥Ÿô‡L|Z”— tçõyuœ-6ºE²6´£#2¯!\q'¿â¥Ñ¿Ò+TÑB.1t(^hˆÿ[{vîù–ž7Ë3èÞN®øϼ3Åœv•a†Ez/´tËäwi,žx^]I•uò½Ê ¾ŒÚPoL÷aúií[;?PÞC!¹$v›«PËš6<ÓøG—›ñ%A(ãÙZμYš¬õ>Pô°TfºÄ?ý÷ÚŠÆçKåãGIåNÛã?–O«ÚG*žIuŸ«Àt:Œ.Í•^ g2[KIy†HòhåaÞpðï}fAO™†=ñ¦“óI¯p%¨V‰:«¡†y|'ë¸ö¸ç­Š6`©™YM÷ø(ˆ+LÒ~á~ûŠšÕÆen7.êW=­§‹™y‰™yÉZfRòdöï=D£b£"Õœ%%òª2½%Uðß~¾Mï¬õ¡­u˜9‘B‰cëÓ6ë£JáË%P“?Y¸ Hªåç]Ü2#6a>à±í z41y“¸4RÝ& ‡™K–µKiGª[¥if œeå¥y±’Ýt(Bd‚¹`…@/Û¬$ßÁùRç5»Lˆ…Ã-NšBË>¢Ð¸ð^e›€$^©Z¶Ç¯éÉUõd?etlÖªIT«Çu¦ÚG”J‰`¡¢H'ë)²îø¡šÇÔ.„+dy ²hmEgfH¨w×JKËP`U¡ôN9^V}Ÿ"ÙÕ ¢>¢Ž]QÕsÃîѸ4#ÃÿPÍç$à*‹½3YâML<'‚ÒÇ&t†¦&2xÉMŠÖSN„4˜]±2»ŒÁfÎ#cMßWA÷Q¯¿&©`¢îT;pÐÔ€MŠ»ooyP^’‚·w}9$3㎩â^t|°ôñ!ûxpô€æ³ Óf®'í>&(‹c:5ÑÁE‚.¬hÎèc÷£^Œ™Óß•ï¼ËòݾˆÁ»”“bÀC28dDSQþæ¾_'P&µ"#E,„Ó•Õ9óeºq·–<"€äYÔ-8'Ð]Â45@ò¼&M9„Ô’:uUÖs|6•ç8ò,\Ù¥À¤»q¶Ç@[OXÆ)ÚÚ·×ñ°QÇǮՉr[Å•œ -©ˆ‰KB@ÈŠÃ1[Ì¢­» ŠÞ‹ÿ f°&éVC©4¢ÏЉ›²­Y µUŸ‚š^$4æ!†w u -›ÐÔ&Ç`ye±>šÆ¹WI„ªh¾»&wZSUÆÝ -B©:Ù1[òÌÿŸEölòQ³É·!‹œzý½ó‹ªxuCcO®^O§ü+M"/Xˆ¹$aðâæ7Ÿá?Ê3ýëåwìéÙñ›ƒžÉäÅÙŹ91š°ê Ç¸¹¸ž\Oñêûɻߛ÷‡‡»:“¥‰ãš«t¢øŽ€VÍWan>¶;9»|;aÔùzúíôÚÂê–Np´õêptT–úÔÿ -bvŸN8SñÝ©¿È²•>ÓyЗ¡Â†2HÒ[úIÈħÐEXõÔ‡>[höQáHƒýmf__|ÿý7ï^O'gÞäÚ$ö賃*%ƒ=Ú¢¾$a½aˆnä(JÖØÊœŒX->K[ÐÊ”Þ? *ö_9F]æÇïìÃgȈɈ$gDxÖÒ‹^/DA•`ÏØ<“Ø#ûxÐÁ-³ºÇ qO@+*Ÿ9©u6t{“™_óæ°^(FE4Ê›h¹€ä(Ž€D¨­ËO ä‡Ì.R¥X¢+|ô¨Ù)1‹¤ï -ò²nÔÙ,FÌÒg” -oMZÝÆ"Ë!Eºî&-¸iïb•æ %X‘V+G27¹°ç·L_!ëø,³ë`/r‘â+L‚œ -^8£yµ+]„†:HÕ ¦fãÝ2ÔœZfF„’Š-€ü°Ç045÷ö5FÇüW{(q2ŒÀý"@9p‚#òË,à­\“–ÞåKk [³î/ÉsöåÄs») ³ö5á–k¸T5<(‹ãÛ,ãÁ=ºAW2Õ­U¶¨w§­h½ˆ9ÁÙ±„ôh8ƒ ‚<¥ò×nP1o4Í&´`c©n™·h+XŠU©t1Í÷à²$í"¬e¹68, óREY3ñpP(=«I`ê†t./4“< ÃFO ÃÈiç^zUu‰óÎæ/Yé1ÍôH¦ê°>¾±:Oµš½Ug±Áº$9°+ml>vßj@ÔÊÙz¨ݵÇÊ{Ç0!ݨ =¯7l ú3è<ãt·¢i·kÈ.ÿK{Õ5·ÁwýŠ ªR%ùJ¢$]ÄŠÎ’.¼RIÎQv*Kr%Á& Z¦Sùïé™Ýv’æ‡ópgŠvfg¦{ºåg„ ¶çõlH`âÕ&u©¿ ™³†%¥ª4‰Íûµ rHøüFÙIÌX UGDB3_³7ØÄn£˜›’ZáC‘„0I‘èÂDÙÌ^wœiÝ`ý”Ô¯&X¶E.v„šéG±F©*ˆDSŒvÒúŠÍYŠ³5û9üy¶&6ƒw¯Ê¯ÄGþjSö<#öìÓn•c¿ç šðbö²Z“[‹¨&³Ç>ªzb‚ÌOmU •ý+¼FHŠ‰ZÿHT#Vþœàm’àRÔgvÞ2s˜âe¤ïâÛœèb…eX`i[²¯4rØ_`f¨ü¥£ÙÕʼŠºQ5ÔFÛÀ¨¦\À¿RFÝõÖÂ2Z ü‡7«±A9Õ»ÑükRƒ«”½M½U>­ ÓæuÔÖ/Y‘A¾‹B:„Ðk¼Ë¡»"ƒîGó[ß ÷Uù[Ì« üš€lŽ²Š‡Ž |#q¯Wpõ ?$ã+ÀXC•³s£ÁÔ†Š籚iõ0{ݱØäÇÊq;æñ~[ô©»Õ­ûô‰"ùMGx›€ßè=´ðYÜ^´ð1Ê -–"A[v³™³™ Yá—ËG ?ng„W¡‚ü”W%PÊ|Jÿà/¬­›c ¹B31Y €fÇd¹#žNH2ùph†« hû]ÅZ‘½ÀæÊš “I${¢ì†‰¨‹uÂQ†«<8‡`þT¦SyÝ>^sӮȢ×m ²i8—‹µ™µ ©^c -c:åm‡Ž}Ccì¶Ì­;h…‹XS¤Ñlh¡öF_+ŽŠÄÅo·×b p¯sw.ÁˆkXdEìj¸¦²ç—‚ˆK]tÁ¹³Q6‘›¡¢93Tž9A¸„w˜¹Bu¨ -$Øb'—@r(Üž( J'UN \šÐ4¢?ÇXOÂM€Ãw|trºòܡÝF8Û%Â[0¯Q¢Š‡v–?FÜÒ%Ò³WséÖ# Яî¯ÃÊÚ^Æ3çs¿–ù6Þ1¶È÷½›Ë+±ÿá—££WWœEÿî¦wù¡o¾ì\ˆá“̱“T®Ó[°ÄÌÕ—YBÜO™@*=”S"©g²“´Fô—„-¸»ï3^%«KýòÍÑñÖ¥æ—kͤÒñ:u󷥑$öè¬Ç‰ÇÿöqE -1!î{NÉúÛµtæÔŽÄ -SIB#‹µžã½)Ý…`Æž ²–Ö\@bðüÌ—ÎN®(ÉixEÓ4$)>&³t¬´6ÇÓ#•m,ɇV®tì¶=½'Ø5bŠ|Ìåôi‡&žD]B -3l>×™—Go ãv/_myތֶ¸…2sVÝ²æƒ ƒÓb0›{BºÏÙ¹'™ŠÁ#åî#æw\Þ£B-ö{—·ú  ™7§oÞl ~ù°û+¥s‘Rˆõj’’Úx‘±¦/ç¦D²PõõIK2›y¯P} gÇ Lõ@7÷-•9+HWµý!yœåª®k\F±¤¨}ÄDŒÕUh6%<é¸HŠ± -4Œ9¬ø冎ù*1Š虨˳ö'ß“¿DÐÌMŸ›¢†T$õPO ÅŸG«æóÈ\k"óÏ éå2,>e)æMº8_c·ŽÞFøƒÞÛ+¿¤ßÇD¼ØÚ‘ûë€1ߟ£œˆ1h]zŸ_ìûßGqtPý¸·Wýv..nÞÿãÏ\ö~ïÝãßÛ»Ûø¢ÿ®×ÃíÅ€(/OÎŽZ¢çíJ;q.Ž_ìÿ«ÿžÂü%Âÿÿú­sw:9Š_üCøT"ßj³Á" Õ´ïîo`A.ÿùáîþªåV!{³*÷`zËswhfe -:«ñ‘!Sàa³äH¥rf¯ò›-§ bê"O†§£ŒE–ÃS(!È$ -‚ctzìײ[¢Nöpv››­Õ¢‡ CVsMùó™æW]i¼A(G©{#ZËoÛâÍ2ÏppËßW‡¸ú&‰h¶ãÂkCdýÞnÏ2e -ÍÉÚDc#è8{¨»¦¨{e¤>lb›B†1̲«¼dV‰lNía6yûeÑ[ dµ¿tðÓ—槾G{ÿÝ[xÒ$°£5óý3ÜlgK7k3h8Ùüý¦.¶Óp±ý ‰T›ºwq{çê1wÂ}}aùaEŸ“qJ-嶸K•²m!AŸ`^Ãàg$ºàŸwÚÇíÓ¨kN -gòBu=çøü”PFè¤"NÐÆ9 >™Ü…È^¢™¯µd>H@#ù¼A8–ýÂz2-.|p¡*(ËÇ¡”´o€ÆŒ–\Naå¤T­Ú­¨ ÏÒu–-LW˜/› -'ýS¨ô´nÅ*2§QJôæ<[KnC’=Ý”d‰ce Í%ÉÇÊË2¤D°?"ÖNÜ1ÄʘOú4ÊœùóÔH§±{Ì•48´+K!T:D@ùˆ!a˜ZÀ´aÁ?×(²tˆÆ5ð“PŠYEB– È£A`ÀFÞ€!›‘#z›,þ…Ðü¢¹rÂ'„Rs',Úážë÷ƫݪ}PFÄpŸëS²ªOoˆó¯pÎÏP½‡vþ*ÖѨ®l90Aý[@+y ÚKs~ìúÃÍèßß½§Vçè!ª¿ÿá—££ÎÕA+;õ7˱‰IGØ?;´OÒÄ‹§ä‘àJ™{¼g[eòAÜp€Š1œ‘Ôƒ–&¡†¹7ç5Ɖ`V «yê6€½‡¹W8ÔB\üv{½ŽÜßLП­-è‘Y,é Tü  f€ñ˜E]” so…>7f,éLU¨éSñ¢=(VôO“gtþ'íÊz.Ž_\ö~ïÝ‹¨¹Ï¨ý†ú]ïá,Ç"+*­´;¬;kººûÎ|áj½)t;Ý{XIáls­p¢F/Pfr£ã6ÎÛeZ!1K5G?æœ|¾`»—´§Ž£ÃîÁÖþ¥þg£™¬óë »µ¨Ÿ~%«î­èű†ÀïÑòþx½±9³šQº¦O³Á'üθa=M,úZ %-,VÆô€y·p;ßè -‡eI±Û5=“å2M¾Û7mé¼½×èê[ :=l‚JF뙫ŒHaýŸ•þawÃ|!pÔÔ7IJ$ÞÞ^v~‰dÊ*ë§ìY³¼ÔØZÜ0¢Oê­i€ˆþÈžRq™©-5]·½NÌ_E6dºœëœþèßݲòiÁQŠ'©ƒöwî@©ì {„³|Ä)ãòÙX­hÅÝ›sÜ>iŸ.i[g¤a6\r/=n]ŽOâ´W[oÛÆ~÷¯ x^R@”(Q¤.Q„:ä IƒFyè)ú°"—ÒÆÉðbÅ üßÏÌ^H‰¤lJ¦]Ô‘W»3³;3ß÷MäÄà9‘-{#¾óÓÛ"YU¤=MeßRäˆÇ¨ldŒ9ýk:O>×tô¢£æQzuùZÎ<ü{4z;úmòî½1ŽLc\º6Ô  >Óq»i¡XTJW€` ÒP‹V´Cmvzž‚ÀÉ©TmŠõ´¸(B:S_LªéRcÀ xµbJ‚W+uFõI%sÜ×+÷™¢ƒ“`·ªÂh$_ñ–ÇÜ®ù9ÁÐçY±Õ²ï•Ë¥üÐ}ß[­úÞ}/£˜k_W¿½ƒO+q¿ŠbÜG‚¶½o•½ÍÙ7CKû- K¨ßÉéÔë_Ú EÊÎl†éÅÍ =67ƒüòE›ÁRÍ îŽòÚ sfXæj8ž[ö|hþ¯ëîàr¹ƒÖ·l îo‰¿»oŠq«¦‹¦ÀJ&TÍðZ“Tp<«´í‘±Q|çc"[œéEgaTJ9¡NÎîËÎJ(–?NGý#EÛÞ‰lßcR¤|šðê¼ú\Zœôm}YZ] ÐÝR‘6Iè¼zÃmò†RXÃÙ"ùtg÷Å_UÒ|u«–p°S»1eþç0Ϥ -`@ŠB.`çÙƒ§ß$Q£)þ³Óq`†çšÏg熋EÉÌ‚K6$dÿòéç|CÐÁAäòÃ$6§§©•óÍA xôŽ¹‰OÅ8±’8N‹0èin´‹ó 'Bx -pM³}”Üj4 ;x˜ó};ú’Û/o“F~¶'H5åz“ÝÅ *m~!‡ `=“Àfº3„®G•—d¯±b/~ëcì옰nr²¡]–Ý’´ -ŸKõ©{ò²[‘—-ÈK…Q'°¶Le_ÀTö!S©€G6=lj ¸Ÿ*°±s­¨ÃƒeJ™d09¦ìJÝ„ÁG^ÞE(yJ½Pð& ?ðf—ÐÈ÷ -î5Q2øŠÄó˜X†E-–ž‚-<~㬯}Š@ó€$¯©)÷ú¯Ã!ñ3`ÿŠgÁó•·‘ßs?Ï$Þoµ„ÄÏ‘“:J~Ž%>ôŸbçK±ìÜ3Qqh^ ‹Ê'@c‹ºyIh´4×xô¨q½êwñ0í–À¨\.å‡îaÑi‹Ž€E…BÅ¿ßFQ@IøÏùðè\Î!<¦4C…‡`“ -œ@õ! -Ÿ¥R ⦾vCené½B -´Àèä¬kª]þ¨™A8<§hp-ž@îR õõËê¥Dôµ2¬Â6«Ã„…HLEGιÌ(ΞòÅï¬?‰2í^[N4QG)D†àÃ(Óð>}íúà}µ=  ˆœC¾ àIä;«œgT,u™ø}í!䥹‹ž¶Î!ÚLùOè÷œA‚­ZÙ6‚½ž]H<D—2;òXóKÖi–7V‘¶Î¢jûm”–F±ÜnÃhâ¤ÄмxñW´¿é÷4ýÃÍê½ö™$sYL`¤„÷¥p¿À¥sa¿Öù­a_ºDA\‡}õB/‰úNU‹ªï]ñxaá'¸Óý<ðK,áwDHv,¸×¯`ô<~•'á<‡Ïs²[C“Ã'c ކΌ©o® Ë­gthÛŽ3Aûêµ¥‹â¼i“ÚCßð†`dlMmcJlË £™9²‰ëM‰‡°szG×Ó‰3™N&ÆzL†Æؘƌ¸®a›¶gM‡30:“¯:¦4ÈŸ÷Áë‚Ñ&- =ÂË/…çîùlÒŠÏ&‚ÏD—‹üÉ,69d1†Ûð‰’¢{0¦Üͧ¹ %ÂœÔÕœBC<Î9pˆ)Íê¸ -Pæn B¸ ¢póbȤÊë\`ª¾i{`å…ÿÄu`á¼(.M.É«Â\ÿöñFÃi<Õ®ãX» Ø…PVßîZ¦&4ÀšYE]´õ´e[K§ÐAá¿û架jî©hî"ŽB®þ‰+°ë½:½ Ó§'ôª­¿Q¬Þâ"LEe“¯Šæ½C è@í·I¡9¹ˆ-”k!oj~$åspB¿–âQž=-÷Áž -O<Ž”–*)òU´-qøQD{„ey?FÓy%ˆÆz*ŠHÔüAyÕc°Z•“…Iüa@•R몱ªoýß/8º¨‰'8Ìÿ)‘¯^MïiŒ3BÿÑÜœ¾™%Öë^c‰<Èæ¨vAIÿÁ#mß=V|v÷À™~µßÅ멈Ó-‹›êû°›z²ºAëc/É>Tøó§ÕZGÐdéá¨(¬µ?üºì£”3 m˜3Ÿ Ÿºášf{*Âlø‡êvÌ?œjy–ž=ŠÈFe!Ë ´€¥ü ? ->I²¡pš×Ð3`ˆ·Ðñ1v¾’¥Ì/L¿—둯ë&ìŽzØ <ˆ/’Ì€I—¥ÕÅÝ-+‰hÌÜ­@®ü}¸þt Ä´xù¬w0ÿö+ä²HÎ/W}¾QÆ ¬v¥•¬ YŸ|«öçÍï׫›w§1ûÕq”ÀÍŽe›EDot§ÿòï,¼}£o³,NçƒAâ»õX%ý(ÙàŸø?:ùJ½tQ½±Še°üeÞ¢²ò@[“¤$s^’Å_°\Cðæ2¬b5w°S» ˆû='  7të³ì<'utçN6p·¬7]YñίëuDæÖ#è™”&ø°OùØG(¤;ðàœð…mò.r<9áówö§Íö“<Ýv`}ÖhÝLíÀøÐl´N´¡Ü:¼]ࢹý„Ñ°‹.¨ ›âç–…]oîà]'oßÜ¿À=]onÜ]žvzsÓ†”m¶ë¨ T67-s7¸6lnÚ”­aöØtá ¹oÓ8ê&£æÎMAh‚Z!I»GZ òàxíÉ©Ðg›Yàßm”€nüAvq@ )ß³H×HÀ6u@}”5y¥FƲ x-aɨõØ"¦¥A¾a>£Þ'ø ´ü6”3OܲtjÄúòF|É5üÁ@±Š´ÏR¬-h¥â,òÄ¥näQ-äžt.MßèßRÏ@ "Ï¥GçC 9záNŸk?Á…ž'á<Ï™7÷§CoìjL<êágdâ؆iÓ ©³öyŽ)\¬ÀšKXÁyƒ/>À™ºÄõüõÄú¾·¶g¿ÊGê»Ñ®Ù*?{õpµ”w?N¹ÈL¹;Å•–äJQpS]¹¿F­þFLF0ǹotþŸøªknÛÆ¢ïù>%3’lÉŽ;®fÝØݺÓØÙÈÞÎn& K¨)B%¨(J&ÿ}Ï@‘"!E_Þ¾$ ð~{î¹a<‰ð+#õY\'¢Kó¹Ø6Ë¡@æºø§^Óó(®KÒ’\MÄ=.–{ЬN¬ó(ó¢ºS}Y/KaŒ=ñsY¥³-´MVýHäýH}|­ÞéÌ2}‘0£ò(3„xž1®µ -%`h*·gâ©Ý,)•îö~½½ÿýòüÀþºË8»ÿpÃj«Ðëöq{»m-¿|Ðm°þ$3M€꾌e6cS™yä–ÛÒ·=5˜ÌòÐß]üg7à¤òà¯ìÊÑéëÍöÀ²+æòA} -©ÍL|Él‘Êõr«¬©Í²ÒÉÄœ &¶¡j&Q÷ÿôåIgkÿÍåƒnëi>‹W:Le}0ÂmIcá3XД„ûDÒOÇ3úû/¤æú2o%Ížßß__êoýŸ_dÇLêi'!ãy+¹èÑNÃN»‰7Gí»Nç¬óê¬}øߺ¦þ ÚD&;¨vS¥žÈ¯F…æ#…Þ½»ÊjyVøtoŒ4$oK/óòÀÉjV)´µ×ݳ"OfR³"h«ÖŒ¯„šÍ)ò–ŒŸ1¯ 9Ó~ÂQ¦ Ô‰·ÕE#µè…<1J4™Ò »ô­AËèWœ°J:"ªH—De ºNÅ€Çs8‚Á?­Í”u<ø`0"¾8ŒÔRÔªÕb5ØÈ5ü­ùá%ßUýMV ¶®nɺ-ëAűšÒ:X´ûY] î -B¸àY}@¤“”¦ò]ÕÁ% 4×릘Ù*~ë‘øæ?GY±vzöÄw÷½»òªPÀñ\™Õô"ªVGxtiT R¨m˽Íü´ºûV…^ÒëÁ÷ZmÛ»‹ amîçvkNÏ5“µÕ)Ç}~@ƺ„ÀÉõQ[ŽâhÏÙ²â "TƒéIçéƒ*£÷o˜Âët*µ0œ²t§¤ê’ýZ&YዥμΠùgPRƒ8L˜Îè9EÉä!¦}aG…§|˜µ‰Ç0j6æ)ÏTT‘çYÞÖ/{DZK)ÕKó¢ÒˆR4ZMËa™Zï5ã´*„~¹nx"ât š)—gdHSôhBJ³kôœBÕH˜ŽpÀª oþ ™·xRߺª9WÌ’ú^S‹¿¶%• S’\2tÀ­¶«zy¡ /I*U¿1•ÙpIœ>X™¬¨2ŒØ}ÊXW1çàO‚j¢¤áïà s“ÎËDã#(~6p³°ï«(Íçj…(Ô‡T˜cš*mǼéD(¿?†F¤…¶5æÞ5œe÷ÿa!¡ämÊÜeÒ€¹«õ¼ç•„ËR9$C±×¢SÑ÷™à¶ºµÒÙ¡ Zbˆ6“á$æ©ÅC KÁºl:ÙÙk-þ€8ÙÍmq7¤™ˆÄñÅ)´;À·«‘½Ì©¾Ï¬gêîT«—AwqÜ »ùZñ•MÕEÙnêýbVQÖ> êÞ!ì7@aÂœE²Q@%ø7Ö Ø„ýS †A‹Ý¨L˜­hÞ >pc”Ψ ÃÉc;B’,RlzÝt>ØprAìÏØ|€LÇâr4“â×Mpy¼¨ íÇšÈ/5Ë%qnU=4ySORóPÚ„D¾r‰4ª¿g_ZßMûƒ‚õIggS«IBéD6­?‘ˆ?b{ÕôtµZßP'FàÛ}áŒ}ƒ¥ èD<ùhlc5~DÁ %0Õ£'®ôûÞ¨v!/Ÿ#„}ÇñOt'˜3ÐT{öýÙùA¡§¼¶$ÛöÑ«•}äÜîìÖH¯ü$ãx¢3 -IVF ú€´Š…‚Ñ,V‘Œy"õÐÉÌ‹(’Vjç½hguh‚à=6­KÚ‡£YPiÆu‘ƒPMaºVÚ§þà‰^ý&c¢¿ÚÜLÅ#VlgüˆŒïƒ' -lJ¯v" -ƒƒÜz•(,H_<=A¼Þ .¥¨uéᮧ|ÅéÎÂñŸyšJ¸¢ô“ð VÙ¨¾ÊfK²…é<·|Æ~V - Už«±m×7¹ª8˥ϋ ÔPyEK œØ ‘¡Q%Ò¯Öe²TS•„|k³è€éª*:sËR㦽ö4Ê]¡¿ -yí‘ö~­l<ô$nåx¾®Í×lºË02W+64ðm¬ü¹.”‰¡ß|÷ó)ËòÎ’ë¤EÚ#wæÞl7gzö³Éìx¹ Ž=˜'ºLõÿÄ—Zå´o${Žv@$‹ÅP3YIÖšœ~ -,û@‹ƒ‰Ê|jz3Ÿ݇IïÛö¡'ÝëHö¡áÓêU zòÍó&ßIs¨Ý˜ù??é«¿.¾ t£4o8=ɽ͇¦ Öšhž&‚4V›6˜bhæíg2öÞEúÔcUîعi2¾—¶Øoj˜°µØûI?–aƒ]é¿ZÁÿe0µ}˜#}w¡ó^øhÿûTÍMZÄÇHkµˆI¡Ü²89_d¨)1øâxfœ/Fæ]*bÛ+8®ð"5oæã`BëÏœæ^Õ¦à¶ÏÅl>MG|lé_xfnéŽ%ÅQ-hœ>Ü1m‰N;­Ã=‡¿Km]ôA¡“…p4—4Ɔ¼Î÷lÙ§rþèýz{ÿûe•Ý1Jµ4t΢‰q–œk±^ÙEž±‘Ô48=f=&%·8ô±Pƒþ–ÔÆ£œ -›z,BAhsmïzln8·öÆë}qűÚÙ’Í¡µ„Ä9áIFÞºÙþà9Ö¢9Ù‘&Y•”Ò<™ë§Øs’:}«é‹ƒþ`¢îlƒþH…×g´ªöÖ°“,±l`4äÚX1®Ð±ªP¾û-ÏQÐõo¨v%à¸ÞN°ýb‡e›ÖSO‚dO@®›h‘GYi‹ýª˜Zè~[)E±kù£¤Mƨƒû Læ,ÍôPMâˆÐ¢EFšsn¹ Ö^ÐQ` …O^2òx þ–¨²š&%'"©S1àД -ºÂ¦‰O¨É`Xø¥ŒVƱ.xìü*Í”·Y]͈—™t†àcŒo¨˜™ë;͆jJn†’¥láâëoì„šJ C%ª—›Î3Ÿ¸¦^ ÝÊ#Ïh‘ŒL†½0•ãÌ'‘w“ÇK6=mìY¤¹~·€ö’Tîe©z¢žíŦ³ÍüænËV»õ²uìë_ÂÐH¥Ô‡öûtš{hx¹ì梣—Îá2÷xÂœ¹Ý¶¨öËUð™éLŒöŸ“mÕäÉŠ…kŽ&m¼^áV¸û;·öþ.ôýkržÄ•'KÐ…Y½ézZÃËú;¨µi¶ÐúêæÉê-tè‘]>é:–Ïo° -O>›ßX@B‘ÖS3›‚ õÒ“ªö½á=ÛY8üžO|'>X8Úøfo‡<à.|¢[ÍŒó•7í·Yé’5â.üÄSc?ú65Û -^féD<ûþìü HiP¶æ€ªè’ a…ÎØV¹Õ&Oê°šsZžÅ*„c_ üùjÙÛÈ¢{}E+èG¤–ì¤G"ËŽ##~ ¶Ëj²º»l6Ùa‘’iCÀìæ˜od‘]€ùd€ù‹9·Š,6_-öÃÀha7‹Åº·Î½÷ÜsmªI¡îN6“dÝìX'˜N¬ïé;ŠÄ%šã#P ŸéÕÏóþ<ˆÍ‹•„lNÉ;ÓçÏ_ÿe3íŽ þã÷_ÿüí·5»Ë9üŸü½óÞÿþí÷?þýO“ÀHa›|%ð‹‹¦Iqë …a¹_Ò¡Ò$vzÍ›´F¢M?ñ8¨l*`~c¿Ðø¥Ipؾù°´ùsÌçë¾8*}±àÁqûÞQiï?PgëíÛíÆ…‰Ý& K‹Ùš-VòúᰠYLˆ Î"‡Eb^‹«àç.m‚Ç¡KEîú‰×˜îG•Âm/Û²ñó’„h*À»ÌQevQ‘"áä6±97c¢ìHk-m±kíôÔó™Zrûà+õqß±¶GÀIÜø˜6ÖýQ¿ŠC›F<"Ùåœkbȅ࠻ܣÏ릌`{öšÇõéð|D0ˆ˜1Ô̧wyx|þüíë7§Có›†*§„$JZN¡mâíå0ùŠaJ-4/*Ããq¥÷7¼vÛŒTˆÊÃ+ÝZ*æB\M²e±ØKƒ. C(8Iíâ&Œ<…FåÎRÇy"ÌxV jFŸ†³¹³,ˆA÷€Ê6Ò_·Fù“k퀊ªNˆˆÇÂëëP¨]¥üC‚§8õtHæÎMœã‘wQÈXLÊz‚ïm!‹Å2NíÓJÅ·aÖTz0äËö/g­{ƤñAûaft™^£ƒ4šÊO=&³úèóh@íô¹¢ÿ(cIáËÍMÃ]Ý ašé:œ=¨3²AxèlŸÊHÅú•Iz¥¢±Ô,mi{”Ù>"ã:‹â9_.ê1¾ÂL“Æ5h™ª±…ÈÙBzžŸ¥!Åã( Ò…tbz[}~¢üØæ -`œÌ!ºCö³†žÏKàMùBúéNÐX»Ë‘`R½ÌÅep–Äﺿu/ Óaâ×ÈFú%–O8…Æ —´‹û›JÔ ¥7.$+M¡¶È“+ZÆ- -ø ¬tÜÀO1óѵ–|5²1¢z¬<“ê^T@{mºš44» ’T¢ªÈ@ß΂;ê¦4¬áùÝÂ+¥ð6ÌŽMKµaRº ~U$õИQKóXYtYX­"­Ñsû³><î:ÐéѲ2"ÖS»HÜY?ÆìÊ{÷"{z¿>ß›²Î;2¹nÏ̳”š-²9 K…ú$Õo.yä ªA®…xíD §× –»žg?Q4Y˜†¾ÞP õ0®(îÝuB|DˆOómÎ+Á5¨wÂúÙkª%t3FÇæ€ Vk[y;9lP*`dªöjµUë¯åf@ÀhÍNCaÛ%/™'Ô¶¾A’ºÄ8Ÿb•û÷îQ‚Mƒ­2}DšòîƒæTR³7s Ù‡ òÖ°{îõZþÌØ?küÙ!jypmÌÞJÎÐÙ¯ÐÆ·BæÛÆÒáàXRIyïËëÐEÂ7}è…1©*K!w4¬ìÜèNàjŒ4•3 -¶›ds…à1XÇ3ÇSr(Yõ©>xÐ/óˆ9©TãìÖ.’õû«0Ú_:çOÌK­|ã¿ÊDE½áP{ “ÈŤæQræ8šOÎœ* œl°Pkð˜¨í`¥­ŽÙ˜p>Ž¾;Ì~ãI3ÍÃH8‚ÔÁâíÁíúµ5_FÝ€³Yg£äg£Ÿ÷ÑÝG»{Ùðyéqÿ]~Ô©ËL—/ù¢;ýË••-8pTt{Ò¯oë*D‡Î1¥æ[üz·Ui­qÁ|Iù9-yÆ}“HåÈ#ŽC¡Ñ)W=—"â‘;OÙ=1˜ zŒ³™g_"ó©d§JÍYH 9~¡vK•f5cbÅŸ¤›ÃÉ}?ÕhÕR¨Yã”HT$Ã¥dÅ&i„daZ|aèíZDœ²`ÊÜÔº—‡è‰*ä—´Œ–ö,ÝUŒæ*å}ñ×Õê†Öõ´Ö0¦¤Ú¾^¾Û«H×TøM›JÏ{ÅÃ6£RÄøréK’Ÿ‘,S\=¶$&Ô\.é,Π8du”V° ¤‘š}KˆOt¾Ü“ÿŸ‰`Ó^{œ÷Z"´.mv¼÷FxÒ©žlßO¾^#$Ôvì'õ¸€Náq¥Ý‹ãdÃ&˜µšm]>ÙŸP'Ügw¹›”óþZ-n"¨|q-ü2w—ÙÚl*#lý–¾æQÄSøŸšñ®Í=¦%IšæŸ7`ãB…È×tŽŠÍ-ûÈf£b³k©—í˜Qve(cÜ—3$–/¦Ä¦Ér ¥ú±Œý2å˜ÓúGU&hŸþrƒ¸RH¬vΟ˜—ºSVC­Ø« ¯úHãm˜D®pCÏ€{æ8š~ÎœÀÈAï‰>¢#­áËÄ„Nˆ1û3Nx˜ýÂo:OÎÅ£Ë휞y¡Ó oÞeŽ})ö¾@}ÍÙÅ=Èå{œ‰@‡Ýöꛟ“«1Ò ¯õÛ÷™C ™mk··§ÃâæåÀ›ØkØi.¼²”­ØtPKÁ?¾ a… õpá9q”±8tϸ~âá)‹ðZ\?ÿpÙŠi™:ÛSBC®À~¹ýzŒwíˆÇýû(¬ âüçæ\L‡m%#R4‰šA ÂNÅæá Q÷<*±Ó–±Bà -Pž‚kñšŠ•qj¾¡D‚Š‹Y^òÈÛ§Ž9îÑLU ÐAÈôˆñ2õ¯L)û¢ë,ô§¿p;4å’Ë8*“@­œÙ& Æ¥ËíUB÷Gf´­„¢O¿Ž„²ÛID‘UX=‚MZ¥j­#u±uW‚â›Aµ®sWƒzŠ(<‘jŽüE}68SñB%zâBôÄžü#-ïMÅBHÔû5ÃäwiwäÊUnB‰}ßdJyr uaÆòú:…vžž’h-N=’¹s“Ÿ@6ãjD‡q-ÈÉJ¥jeã >¶Å)Ë8µO+UÜœõ²‚_¶ínL!ÂWQ?ièËÍÎoòG‹¸Eìáøz•Ò_ž8{0P/Lú“ÁþªŽ«æÏ&ó,Ô§"ú D‚ºétüé0ñ·á'DçE Ó¹ãfbòBTKÆPÞh©$D¤IUïÏøÂÓ€"èˆ+Žæ¯ìhT»…kºÈà®ìÞ¦¼AÙ•÷îUöð~u4jˆÉÝ€>h%|+,Ò ê6T4ÌþÏæ‹…þµPó©Š:&•#ÕED÷.eªåÕß“ÿq_mÍmWø]¿ƒ>´ -¤ †²ÅÈˉÛhÆI<–ýÉC–",Ë`KLFÿ½ßÙ î¼T›éƒeb±8g÷\¾ó}Ý©Ì䙨Œ [O&3¡.,*×0ÌìÀKy²9¼h'-`X.¾uoô¥Pf4]‰®Ë¾fÁÀÒWÐøßE`––UxK6\Ò¯³bÈ?Äm3¤ª¥?a"ì¶ð]ÿRŽ$P$@·´Á"ÊÅn/&à‚ 4û²â ÑfŠ*è²ßtM,J›Úœ=¦yb}Ë9¤GÜ •&„JŸ4xUŠR4>Òjº#Á©zléZŽ1Ñ—eQcg]#ô’JŸ-¦ÖçXÍŒ›8í™W[JŸt*‹ý¼¿s$FèiÝË5Ë.¿¥ÝÂ[åÑÞOòÔ?–ã½±l ü"¼Ë†¶Ä$I@£U;"Zhp„-Åt l£ -á`^GU\V–·!.cŠ‚ˆ²»p²à'<ëñ×1ÎpmáRNSî gmÏ4œ˜‘få'¢#ûêjHVjÎÏŸù KO¶Äç×öÁc¼+¹g‰Ø1PÔ¶‹L­?àÂnÈC¼°ɲI:Ù&ùú¬Ü.ó‡ê†óìóâ5J`j¹òùé\›»ÛL<²ác˜4¾©ïÏèßÓÙÕ°HµTºŠ5ìTq(-镼:dÒQPEsôE€•$CS5ÖÛè‹ðù&þøÏï¶Æ¹:¶·—ˆö8Sÿ73Þ—@Lœ:¶·a vQU¨CHzø‰~v@a²ä*þÂç–²(ÇiûÊ”µæ"”sÅ€ŽdÇÄ•ZàÆó|ó—ƒ~,nâ¸Äâä…þnâ4£5㮎>} -'cÖ‹¿ÑÙp}ªêܬ´s·Te5±Ð ˆÖTÇ» ­ï‘ûâ.¦?¾µôL#ì“a;ærǪ©ÉN5Å“;/ÖÜ í†è ß2óHç7A’'X·|UýJ¥„_à C]7ü¡H€ŒH𜥠LõŠ­rÃOÝúQŠÎ'û´ŸòVl_qŒê”­Ö<ñ’Mé'ˆ­A ZçI&‚Þ•]ºòî½Þ+  °²*a,ñPPŽìžÞñ%UUaÕ°keÜò6=à6Y ¤|¾ÂOcŽs\BTÓMþT°ö»×AKz‰Âm»óñq5ŒÂã¾D”© -Ú>¼fѬc«‚;—«ï& ¹Öe ·ç"Hó<É‘µä¯¤=–P‘ -¨ðcÉ¢=ès(…5dåXþZGÒÃù«òèЬlòW=ꟓ¼NœoyÕW×Ì5b—%NŠÊ¶sÖ,“œÑâGŒ/ANný’'RûLsQûÞm¡º¬Ûø Ñæ=ófè©]-5ÚÇ][qÔó³ÊÛüؼäп~ûݹuû»?¿m.Ô鮯ØSŸþÔ·ŒÛ+«ÅóÌp•ùZ½†vaö˜ˆî'j5sK 1x:Ž?”èåJtñ,D#zlå…Ñ)"Vä;úQyœ©ÿO-pŽÄ‚ÜE'V‡báý¼ž£5ƒ2¨G­4jyÊ%åÇ%®»b óbˆ­òµþûÊα_9È]Ý”ƒúôy”C9t=„:"¢ +¢³†P†Ú5D¥æèrÀ-÷òÉ¥½ŽX3_W -†B"Î5Έ柌]·•ê%TÄ€¦[“Ljæø>Œï_ÛË4]‹ép˜,|‡!"0Àp¡GúGNþbn­íÕ‰§9ËpÖ5 «Ô‹ì1Íòë[ŽQéź_êÊ„±ZiûL0E¡jyºŽGðêôœÚÑ1†úRó Ø=N` €§ÅÔú“naÁMœv‹O;%ã<±_ˆÞrˆ(Š ‹E 9v$u„ÝGòÐ?†ã1¼´g‘7gQÑù]â7zÑàµåg"å+KšÏY¬ìåÝA‘ôÊþ£ œj! ¯®5Œ:‡³‚µžÜã™hš\zÒä]wð/¿­³yúo7¿ôµ>_:•h{ùC/fÿ8{SþHÛ—m4µFý9} å1‘ˆ[–| ý“ø%Ø^ʳ0žgÕ“œžžºÑSWÑÓêa$Mý¹¼ÔaR¹OUÖ-swÔ½—Zõ¦Ü="¤aº<„¬*Æáƒ[€a¬PNÞ"Tƒ+ãéÜ’ö#l BÈç"Œh|H!ü‘˜²“ »š W"w>§‰¤F8f oÏ’ÐL`¦'f÷fÙcœVN~RríD®ÝîäÚ}6r]ÉF/ví*v­‹«ûŒu·’k 憕¦¡:@ žx4(öšK_ÿR¾³ï­Ãóíwô™´õGÌfÉÚ{å¯Âz`s¦ ݱ^ŸK‡îbI—ÄÆtö¢skž¥Ò÷VÚY"€@Õb¿eh¾P^hSó ‹¨wßÌ c4:\cúG›¥G¤aÿ+LÈæHœ}ïÝ{ÜVÍkÿˆ&áÆ_×Lbž£¿úeñ¢5‹!µÁRLù F]ßLùq%µUÍûç7µ¥¹ö¨­ñå«‹=j«ŸÒ"…ÒjUYò ݘ¯«ÔÁd¿t¶ ÙhÝ“xo¬E˜CKcÒêÑ`ržméÈäßþðóç÷ß×@¿kÀ.O*K]-öèÒrXþÔ‚TÞgtE*Mµ¶¦$5©o£†Õü™U¨¼í¸· •fš3òÿH†Ö…ȱr´>z—£%!Ò”£Õc=«,u,­…BËÓÇ’<Å &Õø¸Z¯§”_Õ¹Ø|,‰MÝ,ôYN´À¤AAëo*¦Ü²ÕÍT+oªÏìg‘§ë%O#KÇÊRíq¦þ?½ $CÇJ†ªCHùù~v˜DãBvJk:”‚Fu>|£(öëÍ~’pL’P^å8=±j¤ÚÆÝUÛøÙT›ŒY/µ6VjM¥¿˜D+¨ôtsxAmSkåú"ŠÍB9¦=¢á$ŸˆõYDdpáÍ:ô!…èð—leÔMŠ©T§ìMz~qÑmt™‡õããt¶×v‹3÷bÔÝ}<œ)‘èø÷-sÞŽÙ„b[0/¨ž‚²Ž[õÛ¾vÆ7ƒ: ™z@¡R¡p1gEåkiP)˜•·¡JÇ0 -(܃ÜU#–ëÎ9oø}@ÍY̬Ý3²G5îY+–.y [OÙ«0íi:9kÔÕº`83K<Ç‘z3ó—”ÌÂjãZWCò?+_D]¶Í´!rÓF³tbjã'Î8ÇÇ9Z²Õ:ÝäO%XmÏzçà% -·í¦*YñySÓ%rªÓŽ_ĵ#ùRÕJ6 -3ã|åà!UëDyí°‰¨0Ê䶞^[H5 Þ’ò·ÛoÿÞÁ€õk0¾Å‰|G ¥d’LÇú@¥­¼0vÌ$¨e™ÀÛjoŠ ¥µ^Òl‘ ˜QØâÞBS{–,­xÓlL‹¾ç¸õ7(‡ga‚Ó9Aˆ9PES¢ôBÜ4Ã:j2âÆ-qì½/TþäŶÔ`À¤Ú¤‡5ã¤$ž,™'‡%–Åš1Ä"‹ÐGŸƒ¥tHÁK ·÷¸%ÉÀ¹€¼aG'ã¯ÀQ„Í̪;Êwt•9càY­®†Y4ë8•p7B|DúTSé•¢¯Æ*ê£`®¥ªÜ­yþ²w´WönÏ%Òƒ£M­Ï±€ÄeÁ ¨S\F/Úi¬KxÈi¦)ƒ4òä-:.Ù™–»#G&ûGmÜ#j#ŒÈ›³¨`®BÖœZ×–Ÿ‰”¯,i^6Ijèøî¨Èú‡ÅÝ–†ÆZ„w`RÀJÉБG8™kWðJÖk;b : päI8uQU)3Žû²®ŠHôZ"ÊîÂEÈ‚Ÿð½…¿Žñ„;;ˆ’öèP8ìÙ;õ2¡zi}Pzns5$5O‚g‰Ï| J¥[’›×öÁc£(¹GuîPtßHúië«O­?`ŸTÄ ýOyß›¬­‘0-,É“«OjhÙ†§–·KÎжYµÞÏé?FÎd21ÿ&ßÂëkúaëݲ¦ÖèL Æ»úÀ“ûƒ»/”ó#wLêéìéìjXÄ·ZP*õÅvª°––ôʨ/·Þ¶q,ŽÂû2 øRÛIÚz“`<™‡õ hMƒ¦O´DÛldÑÐ%©çÓï9¼Ê"¥8– Ì>%Š<üŸÛïØ0S…%cñ'š®K䜞.,¾Q° u%ºéñ4JÊ~el+žÙ"…Q¨Ñ…‡³dsèÙÓ{ú­o‘d×q…|SÌÉä€nSödÈšíÔç›P‚Uˆ¾AdFñ7óó?ðþ„.ˆ»OT´'«ƒL8=eaeÄ܃ÛñbÌ•‹ˆãH¡H_ÝÑ,¾ZbZ羋X3'Õ[鉌l4&®·hÎNå?Ò¬6˜twÍô(×LÑ5¿b]1Ýãhݧ9ÝðÇÃkå,¦­Ò@MŒí£eUº^ŸðŽº§4G4qŠ½QíçÚã–¦1-D¶?>Èd2†ƒ ïÙpj×A‡\#éC3ÏÅȇJÁåÕÅÕimÓ|<ª»äTå.Ï -«¸ãÕ°êDý{ãê…Âù3àê…ÃxOmìÕ•9½<ÇaÄù{pëÑ€è o…µ§Ãšë Xó;×Ï· n¾$â’±##È;,58õ^òÐ+™„·_e¶Ÿ¸í§§lÂÒî,ç?¨£]DíëßúÆ 6,.üéÚwwÚ«²^sܶÓ»½s/Áú˜<Ø—&^¹Om4#ùN67#Šê]y\d–83ˆ±°gØ4wl¥±+c˜Åð:àr_¥®J­ltÂ9„ŽÄjwè­ýóÜ ÖÑrÚmíèlþæ~¬öÓØ\‰)Oe’í(í^ëCU†þ\+H"Ä)wd•16X–ùTPýíDÕh®¤jsá*QÓ$©†£¶û°ã™kumx˜¦_ôf×#<ã–JRYàû6Øäw¸Oã˜+7©D’?òÙ*‡S@™%Í\ð°í®ØÛ_•(ó"ÐWÐZ5«°CQvÿ -³Ç4òzÂ;Ü)^ øƘü ÅP¶,èÉjÑaP0¨$,Ãp /×™&ß#3»]M|¨Í ¸qV¿Ú¨ðn[ªÉq!–Æ´E|%¥·žØ1“ó›I'”˜ºŠ_lh!é“ò4ÇÊ‘aBš -Qo W4ʇ¾y^´¼ftè’D¢ß ÕŒ¦˜Žªo¹R…Å«Üå}ùXÓa«šnmŒ¬3Qî´ñÇÙ|=*“ÛÖ<¨¯h‚ãJû{+<™‰í¡ƒÏÄöåODaô¯Fa'€&`x0w‰‰Ù2¤ž—ÇÇ/l of£‘y?ÔwFb‹çCå= ¨PB°½ ¨‚‰©Ú ›¢ØåM`€ÜžÝ¡5HŽÀæqŒ!q&­%Vsì¸ã©=þ6`Óùñir>M>,’ õP~QMQUpØÊØô²áÑ o)¢UÄ ¡¸úXùš§Ï¼ü”w¨‰(ï¢U’Bì8¦šÕ©¤³Ë< ºL¢ˆÄy(OvE$Ð3<`ߦpaI7•C¹¢s<ýçÐYÍW) †˜ ’_,²wÓƒáÑ]VÇv±2W¥;dvB‹”4¨4ö (yü²À~®FÁ¸v.Ok”ÕeúñÃU¥ô#4ziÎúÄÓ§[_³U4`Ñ"Šl?ñð£ÉÔG4cÃèöT/Ø¡:ìG‘W}ûMˆ„Ñô¤R1^éáKïŠÂéò ¼UëÈÌ“ „Õ'ÌÖÙ¬+È^Bâ®ÕûÞ-@ÉjFÓX…Å‹´8M£Á°ÆÍ¡«¥‘Í__'”3c‰,¨¨€eY°.·+ŠguWsÚAMà·„.Yâ*Ä)JŽßyRÎITæ…ع½»·Æœüº»D“W%òú]+IèÔ<­Ëu<5WHȧæ€m?•Ÿ'†ŸC¢h’–¯ÆŽt5Ñn)O -1ûN!ûµÂ³gXÿAguì  ÉD8$éζ—7{·Å À)]kà%ù¤_wrŸuÛí)V¶]#„j¯yÃdíD^Ф‚•xøš‰uFwÐ>à•1^幈8-Xìz¼ÏŠ·2†¹a *®¹£Y<¬8¯RcšüÄr©ÊÜ29rT ú³Æ °æˆñB®B»éÁPqê(¡¶Ó£„s´îuzrhp[Š0à™(<.N\”¼>W4¸Ü÷uÈ»Òÿì‡ö¿wÑ¡§î«©¨`Ýeß½ü¬žm ‡g£oç)yÃ(ÔG7(N£üË "R "PwðgZÀ¢Hˆ,æ)¤^Þ¯µÝH”i‘íï höɪLtLÁ·ìOܧºa¾˜Õš£FãÔðG¦`¬ãÊc&³†Ø–ŸûGg>kŸÊBÜÕvÉú˜ªügÜ<3sg};Èuÿè7äOtÇÄ3öü±*‡¨¦“Çß ØÔqœ‰Œ×#<ïÜy±¥OŒ”;é; ‘jÚÑëIÂ!sB^ÜÐgv˜[ óEmŒ©Iɨ`rr¯B>,JhØŽffÄ^ÝÄ9^؉«9îÞæÿ¾üô{5¡`qTYZÿ²a)jÂ3e4Üøõ»€¼Œ±dSÏ0¢³«·†Ox¬*†r$ÄeÄâ!Y@À ˆ{Ä´-˜¦! ¤1$†ô Ïï•‘ƒkú ¥ªüY%…[¬ªaRUÅÑ"öqÔŽèx}0>v†" ¶Aô Ü÷ -’ÔFTƒˆ¬! Ⱥä1•3g -ŽoFx€ß¸ž§9l~/^KçUÛò,Àå õ瑱qVG $È()c<)/Ÿ‹¾,d"íCû7½U¥É®ÌvˆÕb¥rȲ—ºAô bz‡Ú³Ø3§Æä“g—4iš]RQ§T¼¤«Ú{ôõ!žAÝ&,ÑG¹ ßnšG9áBaÀ~  ‡ç¬@m®}GQ3²¨“rÖ0ƒÆ<•ÅK¹1 ×Õá ÒÀ;¿;¬hÚBkP·¢¦d†­O ºÍ±üK‡UÁßDûr|Ð8· Ð0Ax›¢çh:ÄÌ°bÖS+0G¼1‚wpïyLs¾NY¼—Ÿº“w ¡‹g€iÄLpXHJ¡*$T:bLÀ»Ì¼dy%Æ}wíÞ㦠|b…ÝœXðè!Êø®•…Nh3 u@”:—ç©F£iQ›8JøÖPm¯ˆ®—wþ¢»ð!¬´Âï™·ç>Ä”2ÆŽ¹<øÀÿo¢Ã“m¼NÍS5­Â"*Î~ÐíÚðT €Ó©£Ì½*` ¢Qïòb:“{ú¾ë“/,/îædònüñ]¿fýãÃày®Éš¾>Wµú|mÝì*³ö]Å/$_¯øºÌe¢Ènzúø1§Ch…ø¦—°QîvòMÁ‹Ä3꯶LýâsS$É“rÍWœÅŸá×Íÿh¯–Ý6’+º÷Wz`“"õðXCã±=ÍÃXžˆáE³»(–ØìîôC4c`$«$‹ Û¬²Í"Ù &È׌ ‘s«ª«_EÉ”4‰]¯[uï¹çžëÐXù\7ž¹^d¬ŠÈÍçÎ䉎bÝú°"hŠ¼<ÐcY\¤>÷ã@u¯GŽÃòu‚ÿgY9lé¥ žf«·¡£º-ÇоsÈÞÂŒ³@‚«Ÿø0]M9‚±Uœ.ðM ”ºè•kËŠÙWzõ[ cĉŠå”§N9’iH‚Î)Oh¬®4K}³/&4Ö)Û‡1t¿È× -ðö JA7–ÿòá-Üò;§6ÖÊt³¯×ò½±œ‘]ȵ¯Mä²Gt²\á艶´¢Yœ¥g`ªb{qçâÎxPa­ÍW*ê£X­`ÖÔc&»òRaƒG™v O–ñ9?ŽžñÈ€8}J^êo¬nçÍÙ¶ï*ڨ왜°%áUÜy°:µìJÕá$h»n'¨,jIJOÐ6Å&/ù2É×æ«–À›üfË$X -Åæäë4Ž¡ÂÉ¥ô«I#r®Y¶'û^²L¼˜à¡ØÞ.æ¡ŽäKœ£,A'p4´piÀ©¯UýeVøs¦¹Îl07)"‘ËûLã7zðš÷AÏÂ8NÕ]äO:7äçoðÑtmM?Y<8ø÷gº§øEVÚÏÖYΗ·—zCð·6¢Þ©?n„ª=Âjªæô©H afœÜõë @]¹aN(ì|î\×,È9.½T§~RLCá‡k¶ˆWB`EepÆ= y9…25ËE^ä¼ÍA’˜5Á[㥯þrN•þ˸ ·9/¼3ö­7GÃp‹Ñ:P°|6› Ÿ¿©° ’¡±ZA¿¹1™feãzS’/'ykÆÑ#ä+Î#–¯bX•Ý¬y„3«•Fafµ¾ÃêWÝ–­Kjv–åPi›sžNÁËê6=º#T‘·LB¤¥ÇæëdŽËùs -™r 䉽Ö R,¨«×qêçâ”r¤ãs8×— Š#+|bÛ~‚n£lx`옮K"Mê·¬Þ‹±§Ïª~LDΔ®†ÒAÔ -É‘6J‹sî¡&Áüº<òäËgßó¸} ï ­'Uä…¡)r(PÑÞ©ÖɦbÓͧtvNcÍGÏ4bŒ»ŒjÒ‚ýãh<(ÂN[µUS¼'s<&~ÕÇʼnÒ?Ûv¥ r<,*"ª’øÔû%¹Ô®cYåü†»dè"ž -¹Giñœ:Nˆ§g¸ +Ÿq"KÞŒø©HòÒ’à °µÂÕgÃ,Ưv;H»ÝòÄ›¶‚ûöƒI;ÎÝÈa¤ßñ@›i ê1ä²R|äh*r5' qU Ƀ#'O vÊ—ñ9?ŽžñÈt‰yì£é}#¹ÆÖ(î¶ZıŒh§D¸ÁS|94æ¾Pr;W™<4“&%žèÉñ€¶·¬ä¦}ݱÞÊ*ÐÍâ0ŒW_m‹AÀRSiêD©*¡T’µQ¨³wÐcCvR,æÅò:v0„úêëyG§­p½>-¸×c/Q!ÀŠøõ9:“E¼`Ãáp§ºðÕèVJ­¤ÏÄ)è2‚ú Æ}P èdÐì9!ŸÚŠ$Q3"¹‰!ùGåNânŒXi/ž¹^d¬Š†=g¢ã#u}TYdžg á2.RŸKaI[Ù:Áÿ³,ŽFÂ…§Yãòíà¢"ã%¢ŸCöfœÅh_ÿÄGU0öJßâ-9qú¨É´4´wà°‹že)îÙXhÃ}k­3jœ °cÐbßlÝipeßS6!=€öZì66ˆZw”MAÓ'n¬—Ë_«]N[ ÐBlÒ³¦êa˜(£w.î€Ï FÚ̧p¼-´YŠ±["‡‘{ßAá¦E£5=öh.Öq๋‰/ÖqËðpgÇýäÁƒ=Gjj‘gì+/ñ"K*t¿Qòn³ÐÔç²›”wäÏ`rï†ôs–lO?Ý@\‡~âË؇|.}{ ß~Sw)fK_ÿ|Ü´gç&"§CNØ©žcSD|ÑH0`­–Ž ’1éU_ïnXm!¾ÑV³ «­tUåƆ]Vª²hÂëM΢ÈßÊC6ð[™¸ŠâJŽ»‚ä ß‹0Ôñ»Š+*v(7[(’8²w§Åº"'M44 · {Wx÷?ýçûÿþ¿wÿ®ûìÊ8~øã»÷ÿúÛÿòøqÓF+lÞÿðÃOïþôá÷¿Û´ëÊüØ2A¶É+±òÓoÿÜ‹Á‹0Ž™-ñR;Ä8¿îOã" ¬j¿ 2òÛ×VKgÑê´; PÚt«^«Û|ÈFCDºÑ°µ"M¶=¨U’Í5Äfzò\²ïÌ`»\&)Ts!;SõPÄS ªÔ{IR89:šòó²,öäEÀV"ŸKa#È,¢Ú‰ÌM×ræ‘—ýFYî¸ÖO×IÍ×·áQY¹jÁßèUeuAV'Õ º5u„,K< ;Iš„Žñë.nÌW!·ù>î°Ý^¹mݼºÈ!;^=*?_³»q¢zË{ðfÐV9A`=q¤Huêiê%sá×"™ÁN–Óä ):|ŠÿLøRBnwKxl -~+Aƒ ™œAØø¾ ³x^ô·°xz†i6Ç#¼0¬cW+Þ¦-Ÿ~3í9ìïõ÷ª ÈÆ„^îI¥Õ3Žj<½Rê(jBSeü8lx¥àq²©—VãË$_›¯;@íz°­^Ç¡°­êv>£U ƒ¬l<õ“áÞäÛïO^Œê7›r(ž20($bŸæí臢ýb«èï©;u{žl¯2†? qÆSúQÍßä<%GÛs ßöô†v¡ÊK·+k͛⒎vwÖhÔDõxº§ˆh@ž/?»ª¸c {Öš™Ó/X»j×ÞÿýûÏ‘«Þð…çIÙ{žTîÇ‚Ò›ê͉Pn/„ŽxŸØ÷´m´ºm¯#‘‡ËÞý²Ò›½Ö¬ìµFb§3šxü¸bm”êàføC4ÇfsÔo)C9± -×Ü ámPÝn%I{@Âl«>jâà±) ý ¤ÙÍPìîUsГ9ái,ö8å¡Í=U«Ì~L¤?­Þîú-ÍPG´Òö¨jHóêx:þ1Ú BïµÆ?G+c«ŠÊFn{œôºL¬²Ÿ´5mÜ™¡‘Ðé£Éín4²µ3¾W:Êr,ÝrR[É~?ÎZ}½¦IK¯‚ª³_‰UävÍ…%?’´þHšýšKo¯ãûš(½vÆÂÃb;´ý¬ú6™.žÜp÷« -'T´æ0±Š8Î%íæ©Ò´Gº×žKÛ²XQÖ“Š¼—Ú¦oŠ¿ÄŽÆËSÙ™I³8wû«ÙZ&VLgÓÁ³$Ôöc£ù·ñ&¶ù'AÌæíYE¨j?ä¥6RŒþ\—ÂCm4X¤þª’Z¥Õ)£çÊãÞäGç§lt¬iG|·;­™P®È«Ú@m5éƒ&Šå./4,§ÿ(&óÒÃyûz8hÛiõÖpÚÃÌìØS©÷ µô: ƒ›㦠tîïuZWãÄ*Âu»ÛéMG“æHzý‰Ð_LÊâŒVlùétåðG–³@¦¾GAß„ÑITHŠh<¬ãÔÓ­€•]°x¦¸µ¶ E‚+-Ôüƒ3‚¬ldÙg‹ú£ÜVqyxå•<ÙºÊtMr~¹¶ iñ¡ÿÂy¹»ò•ÊùÆ醅\[•aÒÉŒ0îK‹ûM]ÝaUÓÍo%xßg¾„|+­»£Z~â£~ †CZZ »=8¼„» -d¡žÖX˜ÔGsŽ.Ëx–ƒ“šøRCw½ iÁtÁ©JÊíŒ}} «±þu#I Š'ª©¨Ö¨ÄÁOáé™NxO´Á)#ÅYëj*\j0¾”Ö$™…0PÃ=>>4}¡©¸ì ß÷ªc±LÿqeœÇ ×lü —„í«Ñæý¤6 enZ¦Ê2 Àë®e-ÿœŽ"(„pÛ`g‰•‚ˆR1hŸôÄûx(ö†DØÙÙ"ªäû•¡¾àQ´¶±¸EhL#IŽt­"w“®ÄwI6í^„L%ɶM¿ µ ‚úiÌ"/Æôñ“Ä¢róýêÕµÌ+ÐX¢ÀG ÷7É ¼¯3ýA¬â¿†w¸ áÝ‘Ê«ýpíèø3Íól·^*Á/Xÿ˜,¨y Ù[Ö²ôªXj©§"óÕrkmƒz²ù…•‚ªš Ih2œ¡ ¢á?A¸’õÝO!D˜ª²V°ÖßÛætØÁ\+Àu¾Àb‘.k@Ö±F\NkDÞ‘?—·C\.;ÄQ;Dö@ŒÐ3¼:Ãq‘"káÁ Åùð˜Ä ‡µåa[»jQFð_8XCõŒÊ‰jqt&rÔáÓþíŒNÆd.—3âÎtFøR>eŠ¸3LwÔíðÿ艸“<y"b2dï¹cl&ßjº¬åñA+´Ã¥á¯¨*_ Àv_¨]f«ÎÉ5¸[¨È¬TEGT‹õ׆Ö~ãA¦É~ ¿ƒ.þÌ9Z¾œ -$`‘”vZ¨rÿN\áŠ<ÅzpTð.‹þm§àa…tóêþ—ÿŒáÊAF¸4%"º%ð9)¼#.O |.Jà)%=JèãWg`aíƈ°™``ÛšåY Ùš[`Ðæ¡/ BáASñYá^r]KÖ±B†£Ò—‘T»¾#*—Ä žâIËßO~Ù2 2¬[-ÖÈ(F3þóh‡û#XøNø»~ì‹ Já‹t^_Šdlf‡&D£"Æ2/D?dhÊ=ÆܾŒªGœ›n2Ú¦c ¼¥…겉á’É«¿&ÑÏKd“­äídà»ÄÛKƒ7ì*x“§ðþ{©3Ï°ÿúy²6$°y2ŠÓ¥Ocÿ7Ó$éË ŠFLÆð¶ J '”@–}ƒÇ>8°% 8à £2 ÇzÉ «pŒ1Ïñ¼âmtì`‰"ï00‘á©Ž müÂWßt×ÃeŸN`]À¡“Ç¡ðÜbÈF±qaÄÚˆeª;w -Þ™‘ÞSq±ï ¶I\¤Éúàú†¿9/ÁKw_ÉN"<$‰;Vrä¨Á'ú8´`—Ùì£=´<- €áÀ€ Ùø¨?ʹUýî&§ùØ€5]Ū{oÝǹçžž-U™Îwס`ï}¤é»tîÞPLéM;¯¼¦"GÅÂÑ RÅɽºÓ gÛ¹Ãox@ ϘVßðCOXž½ò;ÝÇ,ÅïpC\ø ±ùi!ymx«"›ìd£èŽõ.yÐ-«««ÿfLÐ9«¿¯~X}ÿ༓VÿXýøéÏŸþ¸ú.ÿôé/ë/Wùkõ·Õ÷Ÿþ´úiõŸO]ý¸ú!ö[ì;úOîп÷G÷GƒVšnyü•E± @Ö(‰{ÁS÷x3<‰àI6 }T>ZŽcÐÂgz4G]©M'óA£‘ÂõrZ‹õFèuEÏiÈaÐCÐò÷FµÈm[b\µ/¦9Ü_i¯¹ ½ÐΠe«W‡6U¶òRyPô¥î?ÿKg¯~þ§÷MÈ¿UŽP+²rcHP-‡BmeátÀŒ©R‘…AU£ð ØHM­@kÅB8u°Àõ”­« 'åóã­òF´NÒÓ¬%éžš&¬Âœp6‹6/”À*€šJÄÍtçzå`Ø\ãü³L¬O–jåÃËd;N l“bŽœ©ûͤ?~®àTi‰Bž-älãǪåñ;Ë “›¾¨@}NÁ<ÞÌÕ]ÙŸŽ°ñ|ÐÔƒøQ$pÂË+æ–傘vyˆÌ ˜_ØpØz«T­ fPuŠìÏÙÒgWæûËdgù=q£ã)|kE±f¥Ø6˜³<èé#`Š‰Ø XŽÉ@Žˆ+ÊÑ‘3,¬@0J€šÑ2;¯˜f¾ªÌÚ3™C.–yPÝlÍ.c׶Ý]š|ý"xïŽN­pt(¿&üì³ëÀƒºÚ.ïËsç£|qMU§áb“¹Lø )Nlœ‹”ŒçÀB¬1œÍ¼=…­\Ñ ŒZÇOeOfHȺ|ZÒPÓÝ’†‡òwšÅZ‰}GÖ‘ÇÒYJ—P„{ÈoS¾ôwã=×TihS©ƒ©Ê@ ÀëÙ -Jï3)Kd) °.'YÊgó`™¬2é\í¥r~A‹m­;M^Y^0íƒAˆS_f]9hÙÖvaÉu)Q|ì-¹àhg΄dFŸ¬†ØA+´‡;–A¯äHÇ>{£|tûs,þpcÍ@º@Ç2Uñ‹ÒéFDæøÎõr²C½ˆ)”ª€¬Ž%㮘(¿ôøÄEOv(Ç<*4ý5PÃ-Üò( S—H¨WŠä\¾8‘Y@w(ÃmŽÕ»›gàû‰ó|Î…1‚`Ö[œz˜šRÆ™%µQà üôa(ºEÁßX?0PÍmÝ@@Á«ˆçïÒp;ÄèÐçôH„îû®AtÈd ¸¶ülŒ0ò4'͆¤T¤¼"Š”Ü)jkïÎ ,¾Ìú5öcÒéýlÜ ¶:¼²é*ȹ¦Z0 ÁœÆ–\÷èï x;%©ñ–È*y±'~&Ñ› †Aoo®PćêÌéíÎzÄ2ÁÞ“+ô™)<ýúoB¾½s|kâpóÊ ²U$LO²ŠÄ–’{½!ˆ†È‰>[#½¾…'7K„ÜFŽúF9ga1A©2ýÊ>»ˆ²V~kmäçXÖt”’H^‰QÑN!´°’\z;‹ˆ7¥|r}MH÷ p ൳*¯‘õõ¯×Õ þ-êrôG8'VžŒ¦Îž¹3¸’}éÒiXÑÙ[>w}‹Ø{òìËÏß>-6â3ûâÙi¯}¾/·ŠP)†XÓõTÎ kl%Òȶ7å ¥ X¶½ÎIÙ<–YWPYÕý^»q=H+;I¹™5™Rò7¡E \´Dí?ˆŠ—G¤UôÁC]m 4¦y·-*½[cêÜ+£büã£b[mK@Lža!MužÃ¬Éï±®žß¼ˆÖ/{ù 5ß©YóRáPü9|µwjU{GV»°¡Ï®Ì÷ÄOv¨ñŽ¬qªÖ´L…T9®è”ï¾ï–N`J”bÏtÏlîG;j›ÆA¬~‰¡£vjù¹³ëÄ@WËðyˆ‚\¶×ì@¦_ÏDØã7æƈ¢†šïóJ¾J<pNêv5¾W2Þð8ehaJËaÇ7œÈ7¡MGÌE‹)wÒ7°²6R¿ë{ŠÃ+czÝúìRü=ÀKÎäK¤Ü-‚°mQ#ê—Nlvºn-‹©…f¼A3÷AœÌtåâ&õ5ty9w­) ÔBÃ\³7\s®:–½Ýá¢÷Hp!c±'`ôª­/Œ=3´ã…è»q~ÊtÝÕä2L„žu@‹O¶dÇâNÌŽß½½Š':­E·ˆjÈR‰~0’±¤mj©GÖf¨B¡*ª¸ÌP%ÃxLzÚQO$=•¸©£%¬øÆ×ßÎæîxlœM¡Ô¤G;9>‡dÚ©Öcϯoì$¿ð,¥!¯GˆOÚÇmÌ=šÚîÜh½þ±Öï´¿ŠÉ8&ZI/^C·¾p§Ž"6ïèÿCób¸Ö§ì¾rÆî!èq·&=ŽõZ¤w˜µâðd¹[‹,w%YΚ"8ó›ÌÆܹ›rçX4£Gã"PSY£yœj ÐèÑòP$º+Itö%¿™îÖ"ÓÝÝÉt÷ÑÈtÖu{õÈn%©¾…Eª»’ToÕrÄf±Jbç‘u䲪ü•Î|ô8\ª{0Â=Â=UxEž¿PL>ÖC›ºŠÔþ"ÚwÇ -3¹gÝq“%켎 JkžRN¥Z¤n(Cæ—L0÷‹¯/6Hl…É<ÂÝ$}ùl,“U&Ï«½WN<(±­u§ÉÛü£¨4y®3¤-Üœì2ôA†Ñôu{в­ítÀ¦©;-I¾øØ^’ÕB@€J¤8,^TI´B{3Y_ˆ°ˆgeÔÏü2Ù󌄅¼ÝÑÌò fó;nˆ.vå¶uíž­­]a])«øÿ‰¯ÒÞ¶‘$ú}~EC ÌL°¦ËÇ:‰m¬cáÁø@ììb?6É–Ô ÉÖ°I9šÅü÷}Uݤxȶ,ÏbD¼êêªWïe39S)LÂ²ë º]íÿ¨yˆÿ÷S{ò¬©=qSÛ{_ˆ¹žÍûfž5k'n\7OU¬ËôO0ßß;ôÖþV¶_2Üo牶Åľ_2 q¡â ôÞd -ÜàõÆ_«›„j#ÙB³Ó3Š…Þ“I²‰Y§µærIªKuœY¢´¼=SZyîà3_Ìöjwû8àR${±¿«Ü ;^/1`šÄÑƼÐã9iÂÊøäßµí* ·¥9F?3™êú¼5 `š-£9î&?®Ýiü‘b# á@»P¨~´+¼îc¾nÔgôH’&"*maRÁæ‡âVuŽŠðÓ—BÛ&ytþx z Þ©·Z˜©ï’J´Ó ù&jJ1• R 6€tHÚ´Û »DðaAVùCæÚ¥)ÐçÝC*Kk¸xhn|3õ…éÍZ«ŠŒ ˜Ÿ ¾ÂÀ@¤2ÿ[HGKÛ:õ­ø¼ zìâ‚&WƒzÏ öÜîYzÍUŠöÏWÕÞô„†o€{ì9³û}³¼#{&s%c4é“û«]Û·ù#jý.iiuÔ³ì–ÛþáNGëú¶›Ë5ÀúÞte­nunt/ýUÝŽZf2ˆ À;¦}G XÞ!’ˆÏEŽàEa"¼™EIã*W©Yª‹ìó§÷Ïw½ŽîÊMnÏ/&Wñ¾u³Ý{›£§ÒÉ€ºïÅ‘·hÀÃѯ=¹šQïq´ƒóKz îHŠ~n<èNÐÃĈánŽMT2•X錸Sé¤.l Öw¯‹¹øå–Ð -lX€YKr _´»~¹½¾¶(×iœˆLÝÖàÒ#_0, -° Â]Èç7¨\Jümà»ðî>Y¹X$:ò5ëàêF7èµÛ2,žé èùÕF®b%ÀÚÎxígõ[©Ñ_b!søèÛ-}vÌã=€÷©„WØÞ¶¼]¨3×~¿>?Ô®Ry*TV)KØçcë®ò'?û~¯ã8š¥ZY^IÞnEÿ:î¹Yhâ}…sQ4©˜¸º^Ó1EeÞ¡©É•cg&‹ó»¢ .*Æçœy%ãyæ: 6ë`hªøX«À§³¹“!–õ¸.vÉ;©å½2“ëÔg#M…?AÞÿuÖœd—éìЈP3¬1¢|m¼ß²Ip{h»¦»ÒýV›-óѬ‘dD¾Gßxëp±}\X 'ã£7Áß:€ÅöÏÍÒ¯:ûv6˜žòi« “M>£KúŸ<ü¥JŒu¸Š¢M2·«4QlPÕ2×àÿ»•zLÚº¨]%ëí÷ÃKxõ!ÒmùÄñ¡âÍÑÑÁeÀJ¸ F3 Cì^¬‰ÍuÒZËÊ ]p !—FÇB¦!X™æC—¥$«ð/”«ÕØ=qOÐÁ æ„W%G§9t‹A'·QÉo&_T´ºñ›u{Bs(•§kc=*ÖV¹"ýP‰7[Ó{'Í ƒ‘0~¶Ëž·2Áˆ0—…)gG¤`¿…9HøPÜ‘=•Ê¬Ð‘ ­ÄÀ<*ê{Ó¨Y•m*W"lwWLX“jª¦‹1'xkµ¾lN²ÝãT¼¤áº½¿|þµÂd÷…Ip£P÷Ê¡vË-Åç£Ú¡Á@nÊ0ÑvŽ°=¤¸ø¶m,pªÁ·ô‰}>iÔÁ8Ñ?^VkZ¸m'›ìa¶ý¤ò›bó~ëê{1ZF2›4ÂÖ¬c@ÃãR&8Ð F—j¸ejØŸr9c¦«‰(Bç»ìËbÂŒWÜî^ÌX߶ëDŠ=æ½àöæ­püæõ~Î"“¦²±Ž_¶ÈG½Ž7®c—µ0ÆZ˜ÄpéÈ Î\ ÛwëxüL:8föæXïSÃÇtJŒŸÅãB„|uÃ{°ø£À.%ðÏ ÅŸí«^«ÄÝ]&ÝÚ?á;é-Œ‘ʈ¹Ù<îâùˆFE cçbJ1¸Ñ5±Ú!„ãBÀäùÜpŒ²Ü€ÉbµüD'°Nt"dc{ÑÚknB1-sÚ”»t0*‡gõtõw­Š)Þ–92Œr¶µ–E¥Þ__^^_méèo¤-¡tä)lö<'Oæg€ÜIYÌM¾¥õƒ×L y Ü—ö'1qç¤l „-æ¶],˜È÷_3Ň›$Q[‡…Y¼øx÷©í©Ù‹§#ÿE}£ŠTf²ð2í«õVë´Ÿ Š¼0&ÂÛY””1®r•š¥ºÈm ]í›°tšñ²I9cõq…«³Ý ¢\q'f ºÍHPÿ°ÚÂkJõÙ‡)þ‘›rq:"[ wô8@Á/&W1Çâc÷Deé`k󔞷?#ûŽì©×÷ycjת^cNqtæžè§÷B$C UbðcÍlÙn[ñÌS«‚ DæO8²ƒ­Ž¬ã6YDÜÁÍ°/Ð ?DÀ±ðí}“›HÅ%Fæ9çu@çU[•–´ÑOÙ4L\‚v·‰ ”­œÆË´ÙþXÊèÛ=¸Ÿ PLZˉŽÓy<.w‹úBäM¢ÝîÙT~ŠûÀÜùÃwNÕfLþém éo»¦QP ÙÚ†kËê8~ÝÁðÒ謲¼Ul¤±n œ!%/&®$?÷(âÉ>àþ)ŠxˆJ¾ˆ$’—š$²µ 4‘C¿jצYWíf]´mÔg€3\­x÷¤_ÈŒ;IoæÆuÒ›Àä©ñNS©bEa0Tß*/ÄÏ>¾Âíº5š¢]—à¯Õ†^É«rÑØ»[î4ÂNÿzs>\S·KËÐæßm¬£— ñQÇ5¼‹:ëk˜÷£<¬žx$%hdž`õ6ÌdjÏåØ™_ -`œ*lb)ãßUn†b’5Zõ˜„…ðDnz–ZÁ¼´+–ž^hMD±îpŒ¶É"„…mt?×ÑêÔ€X` ìõË–Sô¹†ÿ¡¸p ¶3/ Ç'c>t ðÃGNĵŒ‡ç‚¾T™)gs ->6QÉWMÑ(‚[£ Ÿ”r½`wºPiEPÝìrðNu7©,¸¤NÃh±x~ùåöîtä~ƒ&Àª­[4˜báiGí‰xŽÖÃoœöÀ„Ö$ªPƒ‡â*Ê|­úTº(VõUCñÕr0£>OúI¶Ôßi¢ûoè›ÔÑúøáÁÜ_®¶÷º˜ ;—4½:$+tÄÝ'ì -Só]È(7%veñºŠ/‹ 0A Ĩîm, FΖèHÍo¡ L•$d†ä°™É(ÑOg6æÌêêûÜüõ:9ÏÐêö¦dMYøîs”­Jáɥѱ`Ôi¬-½ÇÕš–ØLCÓÒÙ/rÚe„¢0W)f™º[:Bب¸ºîU‰6˜¾«ùh9åRTpTÖ ™ª=²ûF0<€ˆ‚^J=˸ז‘k匵ËO£ª³¥Ltüü“ aÊÿ@›9T°"3‚È°Ê}êÄÁ 2åßáJ”½þjf´jÒÀâó¨E(Càh¨JLÒ ¢"ßœŽ™êU…Èýd×GÿèqíÔÐH¢Zrƒ/ð‘ôW»Nb‚mÐt LKVÃV†XΫû†º¥ 3>nörZ ÂnPnÒQ§ªq³/Ú…}AœŽÊd[>rô£®u\j´Yüî -UqOÇë³´{",‹z•¶ÀêÃ:/“¤¹Á +idrWxš· Ç /Ôºsö }5÷ Õ”önl,ÌNûæØ¥ÚÚ8‹J¹¡$9¦“4|ó;€^ÊŸ1}ÅÙÆ ÞÐR5 ùR¶iƒ$q*h”Э+þÅì÷¿ÔWÛŽÛÈü‚» i<3Ö&^ÏÖðÚÉXÛ°ÇYä‘[RÛ”¨4É‘•¯ßªÓÝ$›ºX—1¼Ø#Qì>·ªSÅ1(®Ù¨®„VÓ®¨°Üƺ+4Æ¡'t`hQ‹j:EÆ‚yä4ƒ„·U±…p´<ÏS¹=¸ùW¡§cµ´3è&g$~á°Oq?Z{Ö¯Hñ¤ýì@ÒÞ¼üö•µ‹ï믎¥ég¤éw`fLÙ??¾Ê]¨6¦S“WKZÑ,¡E„'mЂIàÐXŽp¡ðw¨žgçl»ý³‚l›Çœ„b³'¸_ù¦vEoÛ"m‡’.‚K«Â2˜·œ>2ÿû“1ÿŒëa£†v瀤„¢¦ª¤¥Äܧ/pÈ Ï±\a æ#å¬nÏîJ묟Á ¢?•s EƬѺÞÆ4ÊÁ#%¤ÌÐÂàj‰ ©œJ­Ü謘#ô€Názð<„š(1\È„[uÓ‹Öõvm!ò`îÜüb+•b™³Ö5¥žO múÜCžXõòB>é#Íþçbl§ªÿuý†mFî_6ÜÈy†u—_÷ ¶p« „Ü)zp~¼qAÜ H8pYìJ·ò1!ìJ3þ‚ i’’ó’,ËWÁr´ÂÓÈ(áŒæ¾yò™ÊKz®.AÛ…–8»½7Í+«uêøð;ñ„Ð(#ÃÀMfEnRŒ1½&¹áȬŠ—¸êjÀTs§&üq"ë }÷çGÝ$ywn‘îu']¿IЖ¼*!º,WÞ|5 -ÝK H¿«#–9„*fŸÂ+ÁSô2©²2ŽÜ=oÜ÷ù$FŸacTÊJD¬èö.nw5ì ðõÁ£n¥z.”1-äuÃiïÏ.ò¢{뉓f+_Gçûwš.“1Æ׳ªÙ–Èûaì<±Üö+æLÞÏ7iÙ}5Ýúª‰RP@3ÙgÉAtW¶dí)†(¨µØ®H†AËEš–fúz:ãÆ ðqD‚ÎñÌ“¯z^Í¿‘hÀ=^ÇM‘È",¾ìÿ‹=+6n³ -ÑK(GiQFpbE.d¿ ˆ^mpI½8ƒ¸‚¬¥{ƒÝ[||ÎNð ["xëñŒCyfE $Y}wk‹bÅÙ‡‘c¨âø-ú Æ\ ®IÎMGN·fæ¶Ë\„¾{·œÝ‹Å`C¤Ê™¾úøÔß!YpÇ!b¿@ëÙpåÝM9÷‘àfáö .â¶3­7¥é~%?õ±gjRÊò;âã%æ%_ù¿C’C™fgœµ•WÎ<óƒš`ða[·ƒï:¹óW5º)Gyº>°néaq]â¦VñþÓ3ßÖ£çÃáõ¶c¶–¥[|ÅA>_ç/Å•ëGúÃ3…þrŸÐoã¥Î¢ëpGÀsÔ »M˜,ŽMw2Å, ’²ÂY`f@ˆáa]šâ›ýæÍó -UÃȃ£‚ÙHw˜¼ÖØøQmØ=(âà¬f¯²Ü¾†!¦ -;PÖüí¸·‹ŒáÃ?p8« Áú[.AáLñ©#5l”ƒÞSõS|ûu>Oú…Z&FT‘Í©èîÔ'[v’t|‹ÃÅ.9å;ÍG'±ÿùiÎx AÀc ¼“2ÇL ÄÆ{$C<Z!ÚC0ÎíÓŒn"<û”¶$K&ÑØÞÓÈzÒ<­,Ú°ß½¾#‰ ÿa}L>ß"1ù+’¯J槧øA‰>»áÂßT16zY‰YŽ#ØÀ 2©OˆlÎꈓô6ÉÔ—®ˆ˜Sº%Ÿˆ|žWEw¯9¯ÔU°¨g¹3ÍÇÕœ›µ¾ ¥Ûxƒf·ÓjŒÑG˜Õ2åB÷bçÂm[Ò´‹×N}ûâÌçºä5{Û…ÏYËY^¸šo6qq¾Ù¼:ÐlÊ'Y}w?ŸôQ(1¡Üìò4r®éf¯ Ýb>ËÚk>Ý*­%™s’“ÛD  SP­Y5e‚óD£nH0ÞVêÞ “¾ÆvØ „/¾<í³ÚñŒ -ÌmŸnð’¼-äÐ ¯°8óà²^ÌIô|8¼sV†E•"ù™ª¹zc®bä ÇòKü'ûUÔÜ6n„ÿ -'϶¦’eŸ;ÓvªÈ™Ž&‰­9É/õä!`  p@ÐWeîÇwA2MHm. âh÷žïRø°ß.¾ÝM/¦šÔ?>Y%ÿ­NL=ÔÔž?vnö´óôÝߎ–C½ÄV†~e˜0¶ŒtäÏXU×TêBÉØ#ôœTfeAàÏ1dYþâþÿ¼6˜€¶mˆ³ÌFê,»Î;lÐÍWEÑ_%Ý'môû®÷wÝ„èeã7œ±ª· ä!3JAÓ½}Œ4fÜî51=pT!g‰šËøìbêü! 'ZnÆ*b±êÁUëòúk¥A(ºX `!0.Œ9Q´‹‚Íä´9É`Ý$^(©µ£Ã™Ô¾Ðò#ó2”:ëÊaÝpFéWµŽµpåŠïCNxvâ•1ãCC]¸¸>AS¬@û—£UÔæ÷QØ©…åb×Ùf20 Ð–úgF9é”#ÂÆ`º—÷^Á†h½%qRý V0é›Ø…ÆŽïCXi¢M\Q™eXnôÁ’òyÒ±Õ#ô‰Ûö#Àïó¢Ù Ç=HR$ž+½• -IÉ,Ä!}©qøLIÆ%*@ÍÎíQ}ìášøÉ b±º[¯Ì†ÐÐ"Oé‘XvÛ.¶†mS›»ó°•|btx.Í·$gá86§y2 ¶ÃuñÓð¸Ù&bÑ 7ø7šäF.ÞK™1"^I!Ÿ%®‡ô­ÿ€¤ö…–ÙÞƒr4֕úá -ŒRyXÔ:Hî•[y£--gÉ'"6Ù°¥Áè@ðSŠQ÷QØ©…åb×…ËÀ€Ã‹á3£œt!rcÄCØ nyºÇ´ËÚÑÁL\AÜ ‡­˜zâ©'ÛÎ)r˜jCÿFj{²å ¥MÙr jï¡1ˆÊa()d%¼gUŒìÖr [«tËh©ÙœxÉe÷|˜Ó&y£d–•~Êë+“—Ø'+•²gÀXÑL}à€L” 4éj†,Î]üÑÓ/kuùÍ.Rû–Šrv˜þ:w,n¡Ô~.é –©·Å­bP³IÉýznvË5ϱšEýɬ¾#–Ù±“ó[©ýö 6t8™£À ’ì%Qš“̤îW“»R“¼À¾!€Uê%W€¹÷:æ+¡d}!¢„¯].ioˆàæŠ+VE`1ú?ÒyУcëØðSeÔVÒZj‘Ì/èÃ=lÿ¥‡†Òº)~¯›Äc˜å„gÈý`αåÝ¿Í=ñëWÄâ}„£R†÷‡÷RfŒ,·ý﶑ȭ²ìE}Š¾Q$‡[ñ”dÿ`®5„$® -Fvk9óÒX:žåi<Žyy§à*èÌJÎ/$ê Ù±ý/RÑaµc-Ù]¿Dœwv\`ŸEȾ1—y½WèÏ#uþïdÒ¼“Ùa¥ÛÇØöÎ’9É@ê‰ê¢¥ÖŽFš>#)SÈ8`ÜÈ7¨}¡åGæ1—:G€ñßsØWúß5Î’O\ìº8Ø \4Ÿå¤ ‘#búÜN¾(Ó -‚=§ÉósZÂ{‘‚d ñ(½ÁºåÃ?'åšëÌktÚŒ)—×µ(Úœ‘¯lC}DÁz«zò!'<;1ú1ã °nŽßtÝ ¸2[1õÄSïq˶3q¿—r-· ¾’1Êæj•n­€¯Í‰ê+»àÁ§ ££d–•~Êë+“—Ø'+•¶V’TVpœú.@˜Bj&"hçàBÉâ¼ÖÏ=ú²Žaô»I¿ØTdÆ¡þþéî‡$/­hÙ—¥û"ণcoÅÊØÓ0Úxd}‹Ä®élHbôÁ4Í/}<”€7¡¥ža½%|ÅèBhäIQ§´·ùB$Ìéü©pzXnï¾þ êåÑ´oŒåú§f.ŽÃu=ãÕ¨°û`6ä‘Ñõ¾È(Ô,¼Þvjí&g»ÄÍݾëA9GÕ³XQ%ö l§­½æ­3?‚ãÖšQ¬–…Ö¦1¼—2cD‘.?…õEñ+ÇUDõüí`f©%Qš“ì†hÖ%—|©’„xì×1[® 9¶7Üâ8ÖlÍÍ°Tšz}]di´³Jo¥ò$@H¢:m£¸åéÎì¡X;iâšÞÚaÚ.šlù ^ï×qÀÖ\g‹Ú`\F¬~—xüïj«—Nº@#± wÚr+ýöRXâ±¢Ná˜>ÍWHheÆË!èr+…W¡…1¢½ˆÉ¨°Ø±SO< Q«wíóú(Ú—ÆsQ\Û}A‡PÅoe(x12(âÖq½Ôp^¢ X?¥ ÙB‘Ü9?çôX*Cdpü;dp_j–¿¦ ¦²òÔwÑû&3—‘”…á{Š@‰*‰Ú{Y;¸xˆµ7&½’—{QÂWŒ.V£©ÚœdLP¢ºH©µ£±¦$µ/´üȼ’Iuå°n¸£ôË“ZG€â¼rÍþCNxv"aÌøŒp6®ODl*²aKƒÑᦣS ËÅ® —-‡ ÂgF9éBäƈ‡°AÜòt'Žuk°#Ú‚¸@[1õÄSN¶Rd1ë%¤×0”Ѓ½"/ Fvk9 À ÍÕ*Ý2ZQ›ïªì~€sÚP9JfY)á§,±¾2y‰ p²R)û±Éd @&Ê„št_°,ÎÍ3þÑ“/ëLü¶­¾  ÓåC[ô¾ œE£ g,Ú%]Ð! òÇÉ5·Ã:ý•ÐZæl,èƒLlÕ®œÀö­¼qV,#šÑµ £?›ã Œ>´ápU|_G&pÃðû^ÊŒ4½.Moƒâ#^/¼±§’îotŠÄ|3:¡áÅô#Q,•žšÞš°…|{lq¾ïGãWI,¶tÕ†þí¨"Ë–/Àda·G@¼\Ç‹”L7|…šîúûW9 jž³J1·M²K,iÌXZ/ãêæ: 1¨¬Í9} 'ÍñÅzÓŠÓ!Ôé16ájø¡úÏ©„þ€­NÛf°Õ»AFb¸ fÙBrs¿žßÀ1ké>ª¶¹#¾rÇŠH¬âCPY¥·Ry“²ÔxQ½vƒÜœdLP⡤Ö`[$µ/´üÈö”s ±®Ö W`”ÊâÖÁñ^5KÜYò‰‹]¶Å]›¤ÏŒrÒ…È1µ}{Áõ$²íD‡uáˆ[¥[F+8zsb.+»àÁ§ ø(™e¥„Ÿ²ä%$ ÈJ¥È]t 8†Ø‘ÿøãXÉÔ,~UEâW§ƒéºæˆR“¼ð¶!€+U’jws³y"Y5¤}q.ó6X¡O,Ž©ó‡Ø ­8Þ’œÄà :y]B¹HA²…x”]Ì¢åÃWÓô7VSBD -ÃÐ_ßq"Èy¡$\GïÏÛðR«ý¹)t8û¦êš#†PwÇ&ió!Lô8Q,÷Œ`›Ñ½(á+FB#OZ¥ùدºÞ¶,úW|Ù>˜tlÙù誼Ž ¸»u[)°#rdNKÍ°3C;Ú_¿çI‰¤WÅ°Ø-9¼gî9÷^ž‘öþyôOæ:Y5âŸg¢õÈ1©ïçUÀräSEN §á½ ˆ;Ëôjy ,A,sx#•¤Ü 9躴•–?›”3Ó .øñž2â±cK¢y@j®E ´âw©´¬æä‘·q™rËdÇ aŽ7W³ëà\Nü¡»ëËUX_#Æöþå»óóIÔF¥ˆÏ°–ü -½<ÔùmëDPWIŒœ…)aôV¾ö¥È2›r!EBz\ -oø+ßÃSÛ<á“tih‚÷»°cô² û'‚}zLÖ:N ß®˜ÝüK÷,ù -ßR€`z[³U~0[ž>Ÿ]Os7ÄÁD$5¸½ŒÝÕÕxüAØØÈÜ•aËæN2oßát‹àÏÜëžRÈ ï)‡J;Æó<“1qàÏd¬&KO3[_2¶£­z(û®|o°ƒèåηO˜WÕ¶ÔzÚš—ØÚÐ@U,ç(ïÒg -¬ºNÇ8¨â¬HéüR?Šþ!XðÌŠn·yÝÀõË2Áýz‚ Ùt˜pª—uÏÙÈ&)‹ewU°]‘|® ¾I.n/XÊ-óîEÒíhÞ|³™QÏÌ “k+Ê`ДxZŸ ~ä4ãZ&Ì'‹ZCS…OÛ¸+jY/¸?l}³C‘=ÊŠÑÔž ›~G_ò,c wÜhÑ–xÛbÝÊ.ýšd£Fu¸}:-g…uŽõ`µ‡³<åsáÀã,Cþ(&‹~™ÐL¡ Àæ«VÓ·OÀb©"võ{£eOªFÐ\­J#_÷¤7P‰±€•úkóÈãÊtá2‰‘‘Âo3¾ªÅ!×ЫU?îO¢ xÿ¥„þ˜‘¡¨ -T먵EoŸ)Æ×\3˜æÓ¦#›U‘n/Ó$£ Ð×±Õ79œ9Q@pN€f;â»r=MÜ®S”áºð¾Ÿ'®ûY²ó³ªæ= •êPæ,t»õOºSÆ ¼Ÿïâ+6k KìpG‰ðœ`ž[Mâ¼ ¦s¬œ’dä—r5|AH¯K@6w]m— ÿžR§¥zF~}À+<šsT)õ7ÓyœŸœ½ÿéÓýlz\þMÉjE`wšAÏiKŽ¥ˆÕR[«ÕŽØÛð*Ï„³ï¬Ž¯WÊ`£ù} Ñg~Ïð]ÔiÚûÞÓÚb̾âžÞ~éžø;ÌúªÄÖM=¡ Ö5•üŽ#mÄ“®yaìöçÖ¥ùöä‰è¦öfËûn%QÞ’L?gÑ -Gþl‘ü_–Å;ŒB)WÂoA“…0/(“WØ£ ‘ÖPוª’ã¾$Gшߥ£ö¤ô†‰†¤>½ú›mÍwÁÍÕìÚÂÐgÐ[^Òá‰év‚/¿:û“æªE4¶­— i¿`sL d²¶ÀÊ ªžê±ºo¦¯'"…ÇbVM6±o–»öè•íÙÕÁÀOxGþkÓL£D]óÿn•üR:òyàð;{føßo¶ˆËjµ‡˜-N÷œ-|-ñlí»µPõ¯YE$ûÒ%à¦Äè”F «…&9¡Â÷‹ÃØo䪊pÝŒ¡yèçë¹u[_¶ö†ëjlït7|fK%® -£Õ©¾‚“èUP¾k‹)-Ú‘V–o·„ÁíÙyDÕÜòK…¾UÝØ>Œ¨™ÌÞŸO¢Vy¹6¦£º”ÖZÙ-§/žÉÀž‰…+/Àžug¸½çÏ'4‘ÚúÖüI/7wåg¯í¢ RÁ;ÚCOM÷‘?ÚÎ fTü<Á-ë§úïͨ ¸ÒvÖ:wܹ]6ñ¬/ÚÊkêæ:Yí™k²_ŒI¹³ð·â ¬l}É:m˜—nú-]§ÑyD»ÀñŽHwÄ¿êÀºÔKt[„öP‹k‡€ïtDø”’4†qÒ÷‘[»’¢wÕ½µæ -q/t¡Cà4§h,=\ ”o–¸+L_ÈN¢É˜|¼ä™P ¼¸âÊOï;“ˆ—Ü$Ã#e’ž YåNÿS .îqí¨wA½³ >Hƒ@ôðÍ0© ¾S¯®–\fßh`ä«7\“1ëëfp¹’=Åêd\E¿~‚—Ê……¢yA$²ïOpH¿qõPðñ [ŽÂ‘ÔN@ų¡“ê·¡!Ëàãú>âÿ8‡†iINúÃ4b1Ýò¥|„¾ F'cª;Át©—¹Vbx'¼âÚÙ!€Qçoeü›ú5Vùé-Z§£¢¥ÝðHÁGo”ÞŽ)í·År.ÌÐ8¹U.B¶¸+L_ÄN02ŒXW?+4tq/Ì£Œ/0Ýtv€QkLÜÌWò?œb¶†¯¨ØˆüjŸ”¼Mþïö‘'yö¯þ\) `,7ò]`Ä‘ì#wqúóüWD3øI®´wÕ· œZg¸x­xv£zp̾ú×ÙˆÒÇsøàh‘“ôÊ1‹Ëh¥ e‡†Êæ‚ÿ6Óü«êNdßdª0äG$³Þ<‰ÞŽ‡Ö}œŠ¤ÀXùp‘$Ƈ/²®Ãþä<s½¯Ió;÷‚Ë\ý_æþÉÎäRXÇ—ù_ìþ¹lðÁ‘“ñ|<œ>)âˆHnÔàƒ¾T.,*wø»ÿ°?"#?Í.i¡$b [áâ®\õ‡¬G¥áÉ\'«æC<âóL´9&Uâý¾ -XŽ«ÃIô:: ' f*G–é'´æ-°LZg™Ã©¤“Y®°ðÈŸ‡’+ú^U'noaé¿Ï;U3U|)˜ÍŠ¹"¹Å¯zþjã%ï†OÒ¥•ýà}BF/›°"اÇd¨ãXðíŠÙM¨tO½FŒ"di;wõµ662¯ö€-›; |;¯éVÑ?“ëÞë‰Õ…‰WSùé/=¦Å}dcz\ÅS?Ú~PÓ®æŽçPÅrÍ›€á×—Ÿ€'¦@ÖNÇÔuâ¬H ÄR?Šžþ,xfEWŸÞ40ý2§b#ürêEˆ‚ipLï/«—µNm8v…èØ/<+À´»*ä.¹žÏ7!®üæâö‚¥Ü2„HºZØpÒTDRܼ0¹¶¢L‰§õR0§QtäÆ5¡G £sa¼h‰Ï( [¥fÅ’+'ãRù6þsÞÉZM肪ï}T»âqÊlÿªÃ+Ͳ†ß”?B#qf¾.}tȸ²Ó¨·/€§eïY[¥ŽB¡Zmìç)Ÿ£ÍÆðHPj6*¡¥ ÈÁæ+ܦu˜ÅRÙïYð±N…êt“ƺ£FJ›ž^ŸKj•”½%¸—ÔH~);S@ÝË$嵂UÎ{ÆÙì?W¿h¥­<éµê}Š“Š¸ÆXز¸¯«MÌŒž%>¶Í«ª Ö×êÓ…Ë$ÆBŠ®34Ï×­1×™ŒWýôlM f_Jýufó‡Ë<  ¨²2Êš}—Ú°uΪÀ·›û³WÍR’‹ÊB=ü¬/¹ÉÚÿ²_½Ïm"Iô_¡ôåì*˶@’¥=ÇU^'{•»MâZgïûFÒ¬à Ȏî$„À† ΞªTÊ æG¿î~ïõ~EdÓŒó{íiÈ–É^°VŽ‹'am1N"± >|bÃD¬7/43몜0ï+ÌÔ^»ÿr}á„Ù¥NîÒ˜€ô“à4¡â-"Wš@—PQøA§±"cFÁSÉ€ýõÌöÛ/>|¿¾ˆþ†/2¢Á‡õ‰ý•ý~{b/gDÚÉš¢h€b~«Ê0'€4ÏóÙ_ð¡ôí),ŠÀBdˆïS"€QƒÃˆ3ˆ¼®Ã²š±Å -=uø?NDøÌñ£:ýPûO °©egÃ¥6—N54ì²@uöô£öãûÉpÿž—Ì–Q¤ùWhÑü4#q%Rɽ­Ù—õäm²ÛN#êv+–[º9 (ͨÇvŠ7L™E ù.lòqªš,ð˜‚sr’5)J™C©¿š¯gè > ¸KÁ8þ=*džeÖdr•Ú!•[ãë·t~%%a’PDr± *½xã{Q†ç¿´c@CìñüzR® bø?­§)Pî’x *¥oJE…š\‚šA,Øò"¨`nô!{ /‡.èÙ0x;:-Vo´–›¿é*9é}þôý7 ˆŽüà«ìñ+°£d¥ýÄø*yÔ–fó# lÁü°Zg @˜o˜ä9D²ÝÁˆ"ˆÝ:õ½Ý«(¶À•Ýx”T#Öæy6.xv«˜/+ãP¾ò‰„ò ‰?¸};ª®@ŽUR¥R?&*+óµkšäâÈgÐ̘j|ÞÚ¼äû|¾ïåž)s\Ϭ_k»nÜîYË$6ÊèL*n¦¾öœS HÖ–P‡/bé5µïÒBwy}߸ڜšþ`ÖÂW§ù¬<"˜¯™˜dl8Ôúô`°3i Of© ÀŒ&€ÝJÒŒ¹³ÿ 3²$þ˜"‘†(¾ƒ¥fúÌáÖ¦¯‘6#‡®búÌ—ú ¦¯¬Ó{ †î TŒ†ª‡3£¹ ’…‹7U7rҺŻ$®|¸ÓÚ–ÍŒk)ËÖ´MS4‰+kÂX%m@lú¶g÷ù¼aÆö wó96…w‰cŒaxÙ Tu:‚ßЀeÃ2c°4/%À\iÝO¼œllšx“ˆµöÄe¨78¿ìE¿íñÑ^õÀw‘z¢/ÚLî$ËüL ÖÎAÁ4ic:Y…V1²![¯aóü LRdLÌ\ÀÊ+2"÷ bÞKöy‘ØüåZ׊LÇ]´¨ÂI`7néà ƒù§è²3R~(B—-ÿÒ1YçÙaH!H`«2’ÀúŠ~w-`S—ÎÃ(¹¶?>Ø´ºÇ‡"íÛE+8¹…q’dÒˆ³szØØIhKJœÃ÷ø‹È{-—ìGis2  8þœüòÑÐFËš›meå"¥)EûÂûœËã×¹Á^‡3îl*‚à”»÷ †Y¨y8;å -;å®62ˆDùVó;19‚©=œ£ïÉ¿qA,ù¨7¢C]¸(Ê“FQ=tî "܈hæSÄXÊBÙ Ÿ¹x|ß(ÂÛ<ʄרvmÁ K9ƒ¡º©ª˜ª¡Š©¢©º#.õ"ÎŒ;±ñCþ/º93>2_r~ZæÆÚ~füÆwMô -ž˜÷xf|¡#gÆWf?¢òŸß<ÄóŠ'fÓ³L⾉ñØIäÉï—܃€”Ç×ð`/©³F‹ÏÜOçOOï¨TzGµŒß¨ªñ{Õó]5åùxEÓW©zrz^¡ž*WÐi§h‹z‹ª}AC@j_Ð5_0.%cu_0FÕ˜S®ÔÊú‚±Š/£/¼ÚpYíÊ䪖â^UU\£ï'hêî¤!Ý¿$»É-R²+“sªeìH26'?Z#_ÌtMÖ5Ï- ÎhXB¯e4£B£¨Ž"Ÿ1·='õöôaìШ7*‘†¯|~ä±4†Šq?1‡rŸ:~œÙïµþº6?fG‰ü1h¢>?NpZ²”™MÜP¸(;HNTÉ ’>%ßùíÁÌú3Pœ–BqZk˜œV&D ä$è§à_Hø 'Ël ò…ÉrñÒdyP ©s›6=fG3‰Ç ;­td¼.G›ÐöÑ8 ’•Ì¶ÆP9ô9]1µgUß&ŠÌÓ ÝŒ+ØkWWcÍÐ=ºÑþ½W »æÿ—¥¬ëàR}€µà\áe]?¬P°ý° -|ÿ­ãw ~^Ø -ˆÙz,kPk€å'aa'Xô1 …Þÿ äþ -æÿñ%óWHùýlº´í7Žeû}"•ì˜vÈ9[u9ztŽ Ò¥›¹Ü~ÔX6ƒåš¹0´†³8m¾öB±Ñh6‚¦ÃDt5gCx¡`¶Ö¡fàœ»œ·6p½q,]â9+"´¬7'·á»P Q3pâडlÊõjF5k6¦ÏƒÐ掮Íæàü6Ÿ3›þÊhLÁTÐ…6ðÉùJCÙ”õ‰ ¡6ðMṞéñ2ývÆMöxMf.Ý}}áìí ÏîÞ³ãŒÍ¼Å‡KlˆÌ£Ï.óè‡Þœ¸íÌsd8æeÏðÄ8ò¾u~unõfÓk'ÌýìÀ¿ܧ"Ü_Áöþ× ³küµpÈ#Ü#Ð §Y½™ˆa•s†½›[σ,Š€ˆM+øYåð³¿Ï q¸Ä‚ò¡YçÙÙÁÐGè{ûí…GÈåýA^S]ã\cîzÁæŒ:˜î=|×ÿ ºÊ ¨è˜'â®iЇö‚Sz7ÿ|¸‹~5>Á¯Æ¿å¯Ø|ÞÁ8IRj¤²tz};ç\"\R’ßZŤ´,G#»ëAç-knöSA=›^|¤-˜FÆ&wßBZÈö:—.^¡$—Θ—­qò6ãŒu yÝÔs(Ñ0Ö‡ñ™:0ñû²sö`XNÞ†5ìÁ°²=*Ùƒ!Úƒ;âRÏ!¢ðFåÀÕó£ªÞÀŽ1Ìצ¯„ÃÝU ‚WÁ!$‰ÒöÀ8’=°·­Ò#'çÕfãa—dm.(ýulÞ/ŠÓ´q9Z×дqeM+iÚ8Ò4qpÎOîªpWõô쪺ž ç ³šÓ0§’ˆ G ˜q$#¾ï2›Ä·m…}£*¬G¼èéÎÈ—CŸ˜M5|ŠQ/_û=Ũ!öÄœ5q5„ŠQ»\`­¨¹X¼Kì:çÚ'åÌ礆kŸTví%×>A×þ‘ xËŦô¦åЛֳîÓªÖÝI@4àkaÓW|ü°A߯`ä·ÉÒnÞ8’›wvýÒ'2Ôeå1ôEg îö¾Aìš´ÁÛ2äl^ªK¬­(m°BAÚ`PôïÌ{l¸l„2¨¥j°¼¢ªA%mÔ¤ Ù s¤ÅÌ8’˜Åil‹…± à_ëòo¶½ hĬÁ¿feþ5•ø×DþýBFZAÎ*‡œU€­ª¼BJ2ð¸Qæ(X¦Is°q$vù‚·EÀ² ëð°;S„¿ä¡†O9l &Ô‚÷_çäXNĆ5äXYþ‡Jò?DùÇ«Ý܃¨[A0;ÅÄ4ªgFUm -«ñŠ ¸jÖx|À^¾´0Ž5“ ŠEµÙ/ïÕg]~†éú£3· $N½F³.špM dS@šÉ,õ 48ÌÀ\ OCÙ”ºÇÀ2d¡ûsóê¸Ü´5®1¯Ž+Ï«c¥yuŒóê=÷ˆûÙ›óVÌÎz!]ÕW¯ªŽ«~Œó¢Úǽ^Z' ­a…©55=´GZélo´ÆÒ~*íuIzÝß­[òÙl£Q¬=ƒë „ïÈÎ9†¬NÞ¤†c˜Tv %Ç€IºùùÒ›–CnZÏ*L«ZiÌ_1Ù«ËM똃¾YÁÈi_`ÉÞÞà&‹1¨?±º#c­¾ïkêe]–â`ëR]½`-p›KŸ¨[V¾`‰‚|Áª# ¼V¶ BÔR1XÞÀÀ+“P(jf¶ä -¢æþýj[nG¢¿‚Ò¾$UºÄ·ÜÆv•+³©õÔ¬ãŠ=û0oIˆH€@ÉÊ×ïi€”HÙrs'“­ð!)“îÓÝç<&e!†îªvýq$m¦¦³ŸúZñ¿15ËÖÙgR¨"û©aüá<¶òìP¸Ãáä-Ÿ-½JnVÎËlo³pø$³pHfáB+ë‡h¿ –GûayÔÎ-}³[°F›º5püÝ&á¡ÑzŠIÈ3 ÍN¨¹…FÁ:»Àþ&» rþÝ(„2¨ú¡G O~$©û´*|‡b[s¥W?7Š?œ_8ÞOãŽ[ø…c8+S sO§pü$§pLNá㎳þOöð¤I8ùV“Pá½þc·K¸¿óÓ\‚}Ì%TaÔüAU¦Î°¿ÉðäsÁ -†Ð¿/‡Fâ¶õî`øúÇQ6>Et„mROf*„­ 4i*ù´è†¹%ŒAÃ:Ûëá”èx±=KcçÒv0¶‚ÑnÖAØ&uœ:Û¤.3‰ôt²ê`l“úÄ*©;¯Ø*õ¹Ò€mRÏ:.l‰_g ÛX¸®[¥®¥šÎƦsÖ­RϹí.y-Swjœ*=í@lbn:Jl‹áRJ?“ÜþÄ·c#VÛ?à5§²ùút$;ã9Ý<ŸŽÊ ªW[/¶Ë'Æu23ö¬‡çÂ*¿$F;…Ô9ýìzLÙXZ)Îz޲ǼIÎzJ'i!ðdefòR|ÿî¬7á©Ã»\‡íèûÁñº4§šg’¹´˜ª‰’â -Og=z7ØuôùMù{×øátDŸ­÷õLi -ôbë샪ÇZKN9+ÇÒ®XŽúòd…Úc{ZÙ¥g ×Hk!yÊОLÑÞ¢ÏR“„ïû,ôùÖ7!³<5« k˜óÜ®u0:ï¹`33+‰×ôàL‚­˜–~i윙 ã ôb)ǼåÚeʹX.,÷Æò©dpežåúPa´Dôèø"MW(4^RòžM¬ÉXnÑ¿DbVrìíŠdƸc’/¤Öä9¤¡ôó”#ãL:G')hbêB¦²™kf*ZACûœ{lìýÜ ×é÷)Úaïü¸ î9²CVº6$‡ë—Ø©M‚`€f8ãVQ¿S¤U¶šÊA×—ŒŠ 1b?~¬F¨ÖRq¾è7:i¢Rù`ãnóæ'ºÝ: Øš,‡u%ÛM˜3Ï»ùpÅ®ãS“-Àð€è‘&­âßmxͤ®6 %E¯OÞ™ÑãVx¿`gœ«((&­5ЄZ³~í0EìJ3]6R…!¦.ßœ·;îàS*{TŽfËD†æ þ‡Pá \Æ$bÉ©ÿKu Ã2¼ËeÐd4ò÷Ô ôd¦ÚpXKø1‘Š‰V¸B;°e€¹¹]§•$ÁXJ‹òMˆ½ÆD.cª[;C‘QPÓ)±O¿Ì±Ê6õ|Ž Bdõí`0°âŒ‹O< â`X³ÚiÏ4PŽŠç!dšßתÚï'·^“µÅ˜ñ©åùìù“ê {y9a%ƉG@Åêå/âz„D]Sú÷ú” EÕ«PQä´’Šš€2Ø7‹p\Õ]q#ŒнŒ¿ `á -ŸÉ»œ,†¯¾H¥žú†šð°Ê߇D SR!i¡þà½BÖÎE` SØ„6œqXÒÐ:8˜´]Çiaf©Ü,øÂEb©‚‘BÕbI¤<ؘ´ò¹uâZ7'qHèiƒ}çd ‰NÁð:X`Þ.Œp2ÀÞù -ù¸îBß—dÐDXñÍ©öÁýÛͶCÁ ž²ý•ex¸— -×N<ÿãã%ûOøû[øø¦düÇÄTçd·Ñ<Á3bìïH ãyQîLí;‹¹Vè {`ø˜˜½yýòAí._õ^= õ¥°ÿ®ôü¬7ó>woG#;Iº`ìÐØ)=Ò?:àUæ¯ô!††'Ê%…#_[J/å>Î)!óê8$ð^–ZG-áåz´f G¥ADgáÜ!]DuÜ£ôáÁ´Žƒé6KIW¶”i:ˆþ=7Ö£Z¡çë^§\L×3“ÜžM¥¦.HqéúDûþëöözDÿÝ”ó‰ D‰{Üõù‘wûããïë …Ÿ.Èߎ5í¶%ÌÄEÕá4¢ 5PtUX¾É“hœt’ürOV²Ý!0;ìò¼N.š€ -Re&(iíÐj°Ÿã ØB»¦ük%ƒº_lnji4¬Û¥¨Í¢K/Ñ^5?œaÈV,¥Ž/é¸.4»Œ˜ðè:óbœ‚'ö‰ a ª±1óò†Éïí†û“K¬Âjn1ã"%)Ç—BÒ-G‘€«¥ÀñMº®êfÕwµ»^`í0n`†ÐLؤjdDvžŽM/ÍE"JÜ\¼÷ñzµ8¢ÓÅ’µƒ\ZÃ(N3TâÄ=ŸïÃØÇÓQ¦„HKžŽ±C¹9Ò´QÐõÒŸ¬éx7o>í\ÿÝ$ãûïyíÒ±yÍÓ®ª·l×¹õ“×zuyqu1¸ý³·fáŠ?—ËåPqÍ{z…s¿Mªö¹GÝ*ŸÊJ×J½ØÚ²N¡§‹¨¿¡!£MÎo±7û{³_!Íct?Ê~i®F›aûæK¼Fx\W·&têòƒ~Og]Ã,•žSD§£úÊ­½G÷7?m…|:Z£÷uD°ââ+ rˆæT»6Z`²Ä roû‚OÙç°˜ý³<âÿã›プ/a\ö€j³xO¨ÞáêåÛª’¸&¸Š‰´hªýB…±$….µòúj¡\çÁ€]sëÙÁ[H­%-ò/€?Š'-8~¨AyÜxˆú—ï¾µPx+è’áÔÙYBë{l…«ÚYïðÅዦaºW×`” §KHo€/”¥äY/–çíöNû¶\ÛÁ‹£ã‡çmË’ø“Œ|µyª­÷ìœ_¡„ÐùØ ÒýDæ>¶Ç„'*Uä‹«>ƒ¾¦¡ë!û·Iæ¸ç¢Ç@ -Jãk˜ú–¸°qY}Í葪]áºA¡ªÛÁ›×¯î}ÀÇ°p/÷š°îˆÎoIµ Ýø∠á¡öÿå¾êšÚF–è_™ÊËBöÛÈ›1I.I öÖV݇AÛÚÈíHÂhýžî‘ä‘ŒdØÔ­û’êîùêsú°7d"oÕ‚…äaq-4ÄÄ4‡[AoB‚RT©âZóó‰I”$3†*VÅØ|[!IóP×»\FkS›/5$h)’Bˆ$‘ÅfõR¼v‡:!¯ Ñ‚7²Qø¬À€(’Ib@H‘¿t¶ag3¤ÜF¥¢ínTºVŠ“VÝš¶,0öƒ{n›é쪂ÍI wßEã^7ÑÔÇ/Ä_Ý^;ñÝ“³ÁùÙ?J ìÌÓ¶ÈZ4[ë÷b‚ J1ËãÆsð¦+>¥|^7.¼ì×ïpòƒ:—·‰N ¢g‹9!í z1| Tá5ÀWâÃÑb -T¤ dŠe^šU†î¸¢ MóÓÌJe•GÅ")¥V*éŠOg£›«ÑýÕ´3»¿ü÷-±å¢…{kO´lç¶AËÉÉE;´pB#´PdC´|Q¹Xkã[_r%nE ¼°z|b6%îÕY`˜jÅWõ¨Â¦™¢·ô#jÈMcOk]|ßÕÕi¼¥ÓÒûNŸë:+ÊѱÖwà”HúæЂÓQOÛ;‘èi8¸Œ$XDÁ^¦…Tü Ë6O¶ÆLM,n"v5ý-xÙ™èûWy §ïÏÅ”ð tæV!¯‹áÀ¼(/„9 -U\†H¼%¤”Úu*p<]ª©¢&Á-^9Ü#«KNÆ8¢<*CbésÁç¾G:êÈ0^Ê Ï[J:+&ѳñ~0ç~K7{-Ó{OF4¥ ŽËˆŸiÓ¸=÷Üvn ÀöúƒV€³ MÇ‘ 7ÊÔx´Ë›Ì‹Ó”ø$¦®ëHÞ‹¾7ÜUWŒö¾Õ½Ùàf4íÛÎ_ýâäºëŠ[Ø(†nå;Èå÷³KF™4îøÚWæUc(UÞÒöpÍ®%…=‹”õzvÀaDñDC0_¶=ã”vD°ÀV}rX¾À—¤P—°”YÒ¹‘™Q@àQh(…ˆ¬¿åÁÈ~\Âë=(ì!ÖqJ¨HÜÂÂÚÕjûõM³É^áäjßGKõ™ndˆÆÑ€¸b\+Mvp°laàÁé‰u.1r%V>„jkúâ&bÈsc.ƒJ‚%Ö´ùjtÓѨ6­Ž—xÔá£"”¯˜,T¸<ÔVhTÔÅE†tB,òH_´Z:ô~±¢Gô”e †¶02Z¨ÒëÖOÍŒšd1ŽC Yl›–´¯Ø÷¦rÑYÑîi£D¨ž¸=$²ò?ñÚ…8IIö[ƧIÞaϾÌßÊ‹ÓÙUÅsÃYÑeQæœ=Yt;· ‹ö{½v,Ê X”"²hõZ´>Ì£S¦ ù¬v¯°Ç·mV{†/ËèvRåUV¶’*E?²â™ƒ‹ƒë q,Žª§T¬l\¡Ö%€A$PÁœ$CIăD5Nsƒ³¯µùFÈyç˜Û• 0ÊÂ?„/»£ƒ’IïÕÌmWŒ>&´¼ú¡è÷ ±ÖËÀ[Š MT8'àc7Š¤ÍŽDÎ{7u=í»¸,:º¿mnlF×Q\[òr)Æó±ðJ‰ÐîtÄŠ…cz¨À³¦(Á˜X›"!òŒ¢€7 È¢êzÁ¨ªz0Ê;2Ûý™ -‹‘´/7lå¶á†á`ØŽ8¡7PdSK# 7Ã5!*˜çôd_ñJ=|CŠuÅÝ2à N\Ž=ÏUø‹¢jÒ…¯4Ü“ç ÛØ]Ô3UqªVuò¹ø|ò3/Í †¸‡•À?Ø?ÛéO"DAê9 ûŸâÞÑÅ«K0lN\™›¥ž×ÝàÈõl›ˆÉjÜ…3•‘‰ºåÆn¹*`§Ì"µá§“ã7GrçÐ ò5/6×Vל%4#xtßÿùE$Þàá®ìŠ‘¨^AeMZ1^æ {Œ²s“H׺#ÈF©Ž¬,cXÐ0DAD·²iÖ$5­lja莬“Ï.3ilä3Z´SíéÐñU2/ÌœšË,Lw®eyÔ’úoÚ„>uŸ物8¹8ˆƒß>M;çƒÃŸ)]Sû²ÄVn –öOÛ±„MhÂÙ%Ç$d ;uuCôO![† -u€ ש ×MÄ.¼Ž²E–¤bOÞHQÐ µ­g‹E¥°ÃœjTl™Â$õ»zâÉÊ¿âÝÑ iNƒÙ•òAg¼jðøÎÌ™V}S©”{ º‹îQ±V -ðè,EÏíÅóUˆW4¹¾½@© E¶§üÑXáþ‚˜Ä -œQ¼ÔØ"# †oø5µ,sjXhÀ6ó-<Ò‡¨”zÝÃm™ È¿»$³ zƒÞéý;´˜œ۟ضØ0Ñ;ë_üDpr+ï ÎíÜ6à¼8>iNNhNŠlÎÏòQN¡+ãTܲà7:µÝwðyz{s(î4ëÀ†X½ëŠK“ËÈÅéÝó6Àƾ8¯¿tÅ¿òØ­ùÅÅ>}kbPp4ÂßR®º'a'«@1‡©ô÷$ºðò¾+N‘f¢‰$Rùd•°ce©<Û¡b¤Kž»/¿m Ô7UÓ5pQ+î ®­Üà:\ô[Ë&4G6)—ë¿êüJ†ÌŽÁ†`š˜dî6ël–º«M'nÎiÓÓ=Û´8ÒA‚ÝÚéö®²vôåÝ!É0‰™GëÑL‚º›˜+pœ 3,þâ½Z›ÚF²è_éâT“06M'4~Ïú“²8ãYÀGä*ÈHk’Oà¸õ®õ†çöxcÃ/Þ]¥á÷wWkx¾Ðªáédˆ¿6ÉιUcc5Š2PAn½«ƒ<”•H!UÍr"#}iKM4Ä‚æýóÄ ²j54£ØÔ嵶Û#¶½SH)óâªç¿.eóŽø·¼ÏÝD=ÔM×MU^ÄÙÆðy ª3¿™9š­µ¦[l’<ÛßßÛß"Û.OSì]4×I£öv^{Kµïˆ^&.S9:1Ó†Gg Ç¿«Ñi÷_b'ðÿâé½Ãã[óëµ0Ä'‚wŒ#åƒ=¬”î!p0QÓ§>ý2 ‘y+,Ü]Ž>ì¬þBà“-Aà<×´jP‰¾[],=¢×½î¢ÕPe¼ÀíåÄ-G}l ¡åHCÌ@›™dQÈUƒX|^:ÔŸ:âR鑬úT7ä¿.µ®¾–í·ÈÖs1é?¿ y¢jÈpøFd¸’ÉŒ(13ÁÒË{UNiJêÒÑ_PTË”š{šu™¤3˜¡Rgò‚jrW©´ -À‚ɾ1ØFfAÌ„9ÜØ%àÃêVQHh˜ÈÄD>x>@ËÔxØÏ3ÞÄ1ò‰Ø&SÚD"ÍCô X36Ô‰$±1‚r<·2¢¡Çq¯LuH‰ÞÙÍçyz¶½×$ªH¶@¦DÞF;»®,×y<"ôérPê6©­·ž‚ɼ6¾’MÅŒ[¬ÓÇ6ḆFq©p9݉ñ£$iÊ¡— äG”+r ¹Ã4s -r<`Åt¢ƒ ƒ\‘yh³< - eáù6þSEüÿ ^¤„ -Ç&¬ðžË®á ½U+Ð5–¡Ú¦%JdQøgHŠ;ꩱ÷ äpyÈs -ºÏ·ÅxH¸kŸ0”9B$C4~•©òÅç°Þ†‹#—a1HçÖ7¸Æü îŠô½‚Ž,” ·c‚¬JÖ¢ö”)íŸÂv††T¾€>µ4þAÖŒÚ1ƒ#̸»»kåªO'ýŠ{€ëK˜ªÎlÌod¶Å»+1ÛÞ‡™.´c6œlÉl·‰F{ŶÎä.^#`'6o×®­íwÄPÛvº ú¯Ný:YÔÏ,åž‹Žø˜7Èç¢n¯üþûtS«£5ÐOW<›(ÎS±>9ÐóL£1æ8ÖÛòHgKàõ@G´ 6N +?ÎDI™òó‡¸]*@ot“8%ÉæðAç¦|ÆIáv˜gœØ%ÇìP\©âàhyôÞêÊÛŽøNÆÒ2}‘I7Ò=n7»ÂGp ¹ ¤‹Š³ [ÔFÐÛD S9«2@ŒìÝòpà|kk»ÄL˜OLè5WHÌ£€á°º£~äú´6eƒ²jä ~d¨Õ ü|6ž*•n1¦ùó²p xÿÎ?.›÷}¥œ3–L0ºˆIÖÎÌ“ë}ÕYIŠH€¥ÅâÒ#°ââ9 n^û¨|Øæh<20F2Uì6Ø»ßöÞ¯œ›p pz3Ü6ï®·‡{+Â-]h·8Ùn»ñHƒ×QämŠñ $D×fZüï (LJcñUÍÄwH…¶KÄ¥2¯äl €YE0§ÀÄx²u&¦’Gƒ°0b-Rä•o('·Ø¿RÇ,ë,'P< ²J-tWÈ„È÷⯘Šç¶ß?œt‡gxMŽU¡Ùj±ˆgmǸz'€h±’4ûî—I–{«I–Ã¥ç_ž¡æÝUfhwÿxµâ ­fˆN¶œ¡èB>È!ð3ÍÄ·ÑÿT‰kS(ñÍ‹á7pò©Ì¤È`"Tû3ÑAÖrŽn:â“¥Ah.¾´Qý¹á#­ }m¦NU ˜×0XË#g5éñ$›*ú/N=f;#` 6¦ÉÈÑý R²t-YÌYGô@fØ­Š‚a 21ÈÙÉU·ð¢oÍËQL³vYà Dºíò©¶G¹Ë®pà,LŸ…YÓæQÁ¼›É¶W«Rðb}ËBŽò [†ìuË=¥«bó hK­4H@àÄœ -*„k"½I1l“/Rƒ[›;²–W:"NswGä«SšFLOºÏ,/Z#B•«ÝZñdxsZMüñû•ð„¦ï­x²p÷<©ýäªßæ?‰4ùsá“I›îwvk8ð‘Þ.ÊÇD!á5{B¿íh/ï2´åÎÜÔÆ_½ùïPâåïßÑ¥Wñ­×ï>m\¼„‹-£tb ·Hå¦9RÃ] ˆ#ë-á­WOô‹E·xñ5{2ðÄõÓwª›˜é·ä3=ÜÇŒžþ×>¾«|ÒOl?iÇHä·ÝƒÕö^¡ ‰ðÉ–Yöú¿‹¡‚nFfz òœ¤~¡?ZòÖÔ>ÛÇ/.ªóK×Þ/1 &yôò?Qu‹_êëg–Ú<ïˆCE‘©[<¯[œŸXj¯ P7“Äe&©›ëÖÍU–ZCû´Ú¹¦µF«K­ ¿TÚ{W·5h¤Î^jéª#¾Ó#ÕWuSå÷¥¶Î¸ªâÁÖ-”ÔxMG\äÔ¥†x¿ûF ѤÄù&úÊ<ˆMLÌÑœiì·ÉTšY:C[¨ŒÀç[s!OœX%‰æ·Hèu¹gLÔ¿Aðë%'èç-䀴€@Ê$ãMŠ`~Lå¡òZX ›‘bœ€éÔçQ¦c@‹!±æä¼÷ öa”„ÑÿÞt¯O»ƒÓáÎÍ {òõ¿ë¤ê:ù2j½‘|ﮂÃÇ«á0_h…Ãtr1‚‰ÛA;å¦*ÞuNŠ¹íâ»à|]°¿ß[Ë°âÃF:—¢Þ¼M4iÈgr‹*õè.²[ ´mpëû?ùæ|pmqÓPÞ ÅhV…Äg“LÔÝ1#ÐÉpu»GïþÉΧ>ykç/Ü]©óVíü£ÖÔºó_);zbÐÛú]œ«Ob8Ãô¸ÂêJ@hÝÎ¥R‹ì|g­iC«ŸµŠBÀô‹ÄZXjí²#®¤c]]·vY·Vx•e’K;« éþ‡´+––ChÚ_§°úù‘sca= &’^ Õ/›Èl>ƒŽé²p€Ø,Ì-ÕÀóØ\)Cu§“!ÆE м;nf-IüŠyw šd-z ¥cµÍŠÝ‰õx’‰‘B¼øù݈bF—˜oi%U¿K`Ë-­ª E‡/–]óÏ‘_¹ãÐñžUóO%{˜ª9\Æ#ÅØÊ:³HýâòykÃØšF]‡l–¼‹Ì”¢BuœFŠ ˧(3$ -à=Œš !¸4€:h6ÖÌiòLÜ'Þ&]ôàºSf§äÚò3lC=(;©ÒEj^Wû|Ù bLLVÄKáRñ|¾ËÈ)Ý>™t÷”$*R ö„jêæè•Æ+Þ/L|‚9€_ ÙÃ›Ó -‚—vàþÀý €?\à[üa[€÷óÀUCSÿDmŸÁ'6{h‡­–àŽ­ä4Ç­ìÅ¥¤øÜf¿æ$×mø¢­êÀ?‹kI‰‰šÎ× åa`»9KR̦եÄoo‰5Ø2àïˆ.V"L›¬çm—æ€s{R~Å^•±Ì L¨Þõ†ßþÏ~µ65®#Ñï÷W¨Ø UÁ¼CÝ<î0<' ÃýªØJ¢‹ce%9!üúínÙŽ“@°Í£nmí—bKr«ûœÓ§ÙÎöAýfC˜¦PŽh?"¥TsA)jl2Àø¡àQ¢é´Ò]ì’FcRMÆ-@ œÕ´iæD ON$l:sŒÞ’T,—%9UΧ¨H–Ÿ­ ›@¢0FDù¨Ä£ú샸¨Ÿª°;$4‰>‘W<(@ó -Ki #Þ€š2¸Ñ< m¦yŒ•Ä|P§¶²+C8[$S¥x¤ 0lªžp Úy–k|8kjº Íw:<:£PMSäP ®1×RÅ&ËdÑÄ­qãeú|w¢ -B{á²á°Ptt÷sÛ ]ÕÅøKE1>ØÛß)%ÆnC1¦•Åø±:vÌÆøû÷õÐ}H EAù½óXG@ÝxÎ)ð]^5g+VÉf#îÇ(ã©jî켫j"rñšäxªuîúOPú‰ÓU«"þ÷–Á_ýË^9üцBøÕñç2y~Ó>- 7WvèÕÆ¡ÍF蹑®3×®skVA¯-|1ìâðõAà㮆ˆºµÜm×2Me…Ì/ F9a¤wóÍ T]§t)jîdó™8ƪWÅñÂÞr8®—Åq½0Žëåpüăý=Ý`þY'äÎ5¥¶ƒZò[`¡/Ú‚ÛAAÄ_zìJæ~™:¼zÕß6á!»<Hsîzûi<¬ËMŠüº·½8*ç3܆"d¦•ÉüÂá˜zÆÅÝ›Ôq š)ŧÔK1‘ƼȞôý*æ\ðh8õ·çy›½Fw^C`Ò•{ W¦NìÚèrg–È> =¼h«ÎµfÆ»@ŒRŽeCŠh±Zj†»ÑÇÅ#ŽBè¢ØD”H¦x/†\†hñ±ãÈGìÛ›<¦Ú$¾]„€ =­ôÜ}é -¡ììDà¿5ºÏ&öÖ #HÔy_lR6Á¤<˜"+]Ld¢†Pºpê$ºô9®%p:á2o¼â.!½"w÷–àîáÁv9îº E¸K+ß:#œ·77ù± m·¢/1í„F²e ßGG×ÑÊ*_…lý¶ÝèldýǾ«0QWøyâß剟[òj'¾Åað3ÍŸv;?KÐëU*rÍó -rô÷sïË®=kÁiO_ij36µ”©¤nx|ÃÙGc|ƒ„§Ü8}`ëTý †½Ÿ6ð@}YÌ Sú̈kø$„•ys,¸žÙG8Êé0#È™H|>®†,¯ -v`€v¤@5€À&D°Š’±¸·„dÕÊyw·¡ˆdÐÊ‚’Ѿ¹c?…ÊH…ª?-ÞÝ¿«^oÈ£»{úþU†_zì[ü—œŒò‡]æˬf¹F·‘ò|·ºS¬­ §FD&T”C¶©ÚÀ^™AC ¸ç!´»@=  dÊm”Â8ÂØY†)ºÓ±‘£®?EˆÄ¢c°0£„|I‡MŽÃj¶ÄPp°`VܵbŠ IŸèÔ%bŸàŽ ,ìImR 0ļ²õNpV¬u¦sÒf]j:ÅÛäZ&ëôéàOŽß샾¤‡.³wµºÆ#¬¬Á²Ý½íC¼»ÛìMQ0ÝífáÜÁD€ k”¬µÝ4®ÿXóعeªkT(Òóx¨ž5ŒC+¡Émp¯ûRfV@l‡ ÞÔù±€¢KŸLÓ["1™‹(¤z*Ž(9:'œ´¡ù®‚Ölu2Ú]ìp«õÔ¢¢þ-î-£ûûõrúG -é®|›e"¨_ܵ\c.¨Š· -ú­ewVŒx$^t,Ù‚%FÀ}y$Ÿ\65ù}ÃÐ;à¿“ûž~ãÆ¢á?Ùʯ^B÷ZÄ ™R±+j˜T>àë|ÀÙ‚JŸŸÿÜlÝÜVˆ÷E·¨í¥›>A¤*èö–}¹9Ám(úÂsBìc¶fB2¥°~HÒhñØÿ¾²×]Ü[ -ö»%aŠÁV„ý}›µ!¿ÿ'†yªYOÒœtÞ6EGÝËéŒ<0ž¶ùXš«{[ @-i|•¸Oó°oj°3uïª`š¹™9}_)êûÈU¼G¼0e\ Žžþ…ý­&aAZ2³¿¸€ZýÍè -à®L×ù½Eézß”mùœwz+@ˆð¦õC‚Bú¼4@~}oüüu¶y{µŒ’X‡ž ß› ¸ô)À‘;±(Bn¯Ø•£kIAòî¥wQ½±Ô<Š¹.£ Ï”!÷ȸgÏ<1Ž Y™\hf¦\-ŒТ¢xNM_×z ¥P-†j,Î#‹ì™Uþ×5 "#¸FÑ×µääMîFØGge:A,2Æ}ì¡Á !Ÿm.þ´áý“5Òg'[¸6;,i¯ÙÇÖ3—Æ÷ð”'Iôs)cy¸PsñhqíiçkªG¶»W?ÙJŸÍ¯4V aO[* %Ì™wÖc¿„3y1¿Ú‡uz-®‚4ˆ“-ú=¿D‹>ýçy QÑ_F)ÊÄéáööØŽ.¾#«§P€‡’ã*÷è¹ï,€w9'3zªU¿÷’üZÁ‡ž¯@7ÝËØ2¼H©eL<ïÐ_6÷%!ñŠk/Žˆ¤œJή•ŽŸždí¬ªrGþl©hû;»õ•<‡¦ïS¼!¦Ð “þ.¥õüH{Ò–- Ü׉þ<Ùêrÿáô·tø§¿ýW€ïmˆT -endstream -endobj -3331 0 obj -<> -endobj -xref -0 3332 -0000000005 65535 f -0000111794 00000 n -0000000000 00000 f -0000000016 00000 n -0000922721 00000 n -0000000013 00000 f -0000112440 00000 n -0000922890 00000 n -0000923085 00000 n -0000923226 00000 n -0000923383 00000 n -0000923580 00000 n -0000923735 00000 n -0000000094 00000 f -0000112694 00000 n -0000896607 00000 n -0000896763 00000 n -0000896905 00000 n -0000897056 00000 n -0000897208 00000 n -0000897352 00000 n -0000897518 00000 n -0000897685 00000 n -0000897829 00000 n -0000897990 00000 n -0000898152 00000 n -0000898296 00000 n -0000898454 00000 n -0000898613 00000 n -0000898760 00000 n -0000898921 00000 n -0000899083 00000 n -0000899230 00000 n -0000899385 00000 n -0000899540 00000 n -0000899687 00000 n -0000899846 00000 n -0000900005 00000 n -0000900152 00000 n -0000900309 00000 n -0000900466 00000 n -0000900610 00000 n -0000900765 00000 n -0000900922 00000 n -0000901069 00000 n -0000901211 00000 n -0000901353 00000 n -0000901500 00000 n -0000901659 00000 n -0000901818 00000 n -0000901965 00000 n -0000902116 00000 n -0000902267 00000 n -0000902414 00000 n -0000902562 00000 n -0000902710 00000 n -0000902857 00000 n -0000903008 00000 n -0000903159 00000 n -0000903303 00000 n -0000903459 00000 n -0000903616 00000 n -0000903763 00000 n -0000903911 00000 n -0000904059 00000 n -0000904206 00000 n -0000904351 00000 n -0000904496 00000 n -0000904643 00000 n -0000904787 00000 n -0000904931 00000 n -0000905078 00000 n -0000905226 00000 n -0000905374 00000 n -0000905518 00000 n -0000905677 00000 n -0000905837 00000 n -0000905984 00000 n -0000906138 00000 n -0000906292 00000 n -0000906439 00000 n -0000906583 00000 n -0000906727 00000 n -0000906871 00000 n -0000907029 00000 n -0000907189 00000 n -0000907336 00000 n -0000907492 00000 n -0000907648 00000 n -0000907795 00000 n -0000907961 00000 n -0000908127 00000 n -0000908274 00000 n -0000908433 00000 n -0000000186 00000 f -0000113466 00000 n -0000867530 00000 n -0000867677 00000 n -0000867835 00000 n -0000867993 00000 n -0000868140 00000 n -0000868298 00000 n -0000868456 00000 n -0000868601 00000 n -0000868767 00000 n -0000868934 00000 n -0000869082 00000 n -0000869249 00000 n -0000869416 00000 n -0000869564 00000 n -0000869727 00000 n -0000869890 00000 n -0000870035 00000 n -0000870185 00000 n -0000870336 00000 n -0000870484 00000 n -0000870652 00000 n -0000870820 00000 n -0000870968 00000 n -0000871124 00000 n -0000871280 00000 n -0000871423 00000 n -0000871567 00000 n -0000871712 00000 n -0000871857 00000 n -0000872016 00000 n -0000872176 00000 n -0000872324 00000 n -0000872468 00000 n -0000872613 00000 n -0000872761 00000 n -0000872909 00000 n -0000873057 00000 n -0000873205 00000 n -0000873353 00000 n -0000873501 00000 n -0000873649 00000 n -0000873794 00000 n -0000873939 00000 n -0000874087 00000 n -0000874236 00000 n -0000874385 00000 n -0000874533 00000 n -0000874681 00000 n -0000874829 00000 n -0000874977 00000 n -0000875124 00000 n -0000875271 00000 n -0000875419 00000 n -0000875569 00000 n -0000875719 00000 n -0000875867 00000 n -0000876011 00000 n -0000876155 00000 n -0000876304 00000 n -0000876451 00000 n -0000876599 00000 n -0000876744 00000 n -0000876911 00000 n -0000877079 00000 n -0000877227 00000 n -0000877372 00000 n -0000877517 00000 n -0000877665 00000 n -0000877815 00000 n -0000877965 00000 n -0000878113 00000 n -0000878267 00000 n -0000878421 00000 n -0000878569 00000 n -0000878719 00000 n -0000878869 00000 n -0000879017 00000 n -0000879164 00000 n -0000879311 00000 n -0000879456 00000 n -0000879614 00000 n -0000879773 00000 n -0000879921 00000 n -0000880068 00000 n -0000880215 00000 n -0000880363 00000 n -0000880518 00000 n -0000880673 00000 n -0000880821 00000 n -0000880968 00000 n -0000000275 00000 f -0000114401 00000 n -0000839242 00000 n -0000839390 00000 n -0000839549 00000 n -0000839708 00000 n -0000839853 00000 n -0000840020 00000 n -0000840188 00000 n -0000840336 00000 n -0000840486 00000 n -0000840636 00000 n -0000840784 00000 n -0000840944 00000 n -0000841104 00000 n -0000841249 00000 n -0000841416 00000 n -0000841584 00000 n -0000841732 00000 n -0000841882 00000 n -0000842032 00000 n -0000842177 00000 n -0000842336 00000 n -0000842496 00000 n -0000842644 00000 n -0000842795 00000 n -0000842946 00000 n -0000843094 00000 n -0000843246 00000 n -0000843398 00000 n -0000843546 00000 n -0000843692 00000 n -0000843838 00000 n -0000843986 00000 n -0000844132 00000 n -0000844278 00000 n -0000844423 00000 n -0000844586 00000 n -0000844750 00000 n -0000844898 00000 n -0000845052 00000 n -0000845206 00000 n -0000845351 00000 n -0000845512 00000 n -0000845674 00000 n -0000845822 00000 n -0000845976 00000 n -0000846130 00000 n -0000846278 00000 n -0000846427 00000 n -0000846576 00000 n -0000846724 00000 n -0000846870 00000 n -0000847016 00000 n -0000847164 00000 n -0000847316 00000 n -0000847469 00000 n -0000847612 00000 n -0000847770 00000 n -0000847930 00000 n -0000848075 00000 n -0000848238 00000 n -0000848402 00000 n -0000848547 00000 n -0000848714 00000 n -0000848882 00000 n -0000849027 00000 n -0000849194 00000 n -0000849362 00000 n -0000849510 00000 n -0000849678 00000 n -0000849846 00000 n -0000849994 00000 n -0000850157 00000 n -0000850320 00000 n -0000850468 00000 n -0000850633 00000 n -0000850798 00000 n -0000850946 00000 n -0000851104 00000 n -0000851262 00000 n -0000851407 00000 n -0000851574 00000 n -0000851742 00000 n -0000851890 00000 n -0000852058 00000 n -0000852226 00000 n -0000852374 00000 n -0000852542 00000 n -0000000337 00000 f -0000115317 00000 n -0000819080 00000 n -0000819225 00000 n -0000819392 00000 n -0000819560 00000 n -0000819708 00000 n -0000819876 00000 n -0000820044 00000 n -0000820192 00000 n -0000820361 00000 n -0000820530 00000 n -0000820675 00000 n -0000820842 00000 n -0000821010 00000 n -0000821158 00000 n -0000821326 00000 n -0000821494 00000 n -0000821642 00000 n -0000821812 00000 n -0000821982 00000 n -0000822127 00000 n -0000822294 00000 n -0000822462 00000 n -0000822610 00000 n -0000822778 00000 n -0000822946 00000 n -0000823094 00000 n -0000823263 00000 n -0000823432 00000 n -0000823580 00000 n -0000823751 00000 n -0000823922 00000 n -0000824065 00000 n -0000824228 00000 n -0000824392 00000 n -0000824537 00000 n -0000824689 00000 n -0000824842 00000 n -0000824987 00000 n -0000825136 00000 n -0000825287 00000 n -0000825430 00000 n -0000825580 00000 n -0000825731 00000 n -0000825876 00000 n -0000826036 00000 n -0000826197 00000 n -0000826342 00000 n -0000826504 00000 n -0000826667 00000 n -0000826811 00000 n -0000826968 00000 n -0000827126 00000 n -0000827269 00000 n -0000827421 00000 n -0000827563 00000 n -0000827706 00000 n -0000827849 00000 n -0000827992 00000 n -0000828135 00000 n -0000828277 00000 n -0000000357 00000 f -0000116017 00000 n -0000811312 00000 n -0000811454 00000 n -0000811597 00000 n -0000811742 00000 n -0000811909 00000 n -0000812051 00000 n -0000812194 00000 n -0000812337 00000 n -0000812480 00000 n -0000812623 00000 n -0000812765 00000 n -0000812907 00000 n -0000813052 00000 n -0000813214 00000 n -0000813356 00000 n -0000813498 00000 n -0000813641 00000 n -0000813784 00000 n -0000000375 00000 f -0000116381 00000 n -0000802743 00000 n -0000802888 00000 n -0000803047 00000 n -0000803250 00000 n -0000803393 00000 n -0000803536 00000 n -0000803677 00000 n -0000803878 00000 n -0000804020 00000 n -0000804167 00000 n -0000804329 00000 n -0000804483 00000 n -0000804637 00000 n -0000804782 00000 n -0000804938 00000 n -0000805099 00000 n -0000000384 00000 f -0000116729 00000 n -0000797641 00000 n -0000797788 00000 n -0000797943 00000 n -0000798095 00000 n -0000798242 00000 n -0000798401 00000 n -0000798548 00000 n -0000000396 00000 f -0000117005 00000 n -0000792262 00000 n -0000792407 00000 n -0000792564 00000 n -0000792711 00000 n -0000792852 00000 n -0000793055 00000 n -0000793198 00000 n -0000793337 00000 n -0000793475 00000 n -0000793622 00000 n -0000000407 00000 f -0000117305 00000 n -0000786544 00000 n -0000786691 00000 n -0000786842 00000 n -0000786985 00000 n -0000787130 00000 n -0000787275 00000 n -0000787420 00000 n -0000787566 00000 n -0000787708 00000 n -0000000427 00000 f -0000117597 00000 n -0000777989 00000 n -0000778192 00000 n -0000778334 00000 n -0000778476 00000 n -0000778625 00000 n -0000778773 00000 n -0000778915 00000 n -0000779061 00000 n -0000779208 00000 n -0000779359 00000 n -0000779502 00000 n -0000779647 00000 n -0000779804 00000 n -0000779951 00000 n -0000780099 00000 n -0000780240 00000 n -0000780381 00000 n -0000780533 00000 n -0000000452 00000 f -0000117961 00000 n -0000768153 00000 n -0000768300 00000 n -0000768445 00000 n -0000768592 00000 n -0000768736 00000 n -0000768883 00000 n -0000769029 00000 n -0000769172 00000 n -0000769316 00000 n -0000769465 00000 n -0000769614 00000 n -0000769757 00000 n -0000769901 00000 n -0000770108 00000 n -0000770251 00000 n -0000770403 00000 n -0000770556 00000 n -0000770694 00000 n -0000770832 00000 n -0000770972 00000 n -0000771112 00000 n -0000771254 00000 n -0000771396 00000 n -0000000469 00000 f -0000118365 00000 n -0000760677 00000 n -0000760821 00000 n -0000760966 00000 n -0000761109 00000 n -0000761276 00000 n -0000761421 00000 n -0000761581 00000 n -0000761728 00000 n -0000761882 00000 n -0000762022 00000 n -0000762169 00000 n -0000762313 00000 n -0000762456 00000 n -0000762660 00000 n -0000762802 00000 n -0000000490 00000 f -0000118705 00000 n -0000751931 00000 n -0000752076 00000 n -0000752236 00000 n -0000752397 00000 n -0000752544 00000 n -0000752700 00000 n -0000752848 00000 n -0000752996 00000 n -0000753150 00000 n -0000753297 00000 n -0000753463 00000 n -0000753617 00000 n -0000753771 00000 n -0000753918 00000 n -0000754065 00000 n -0000754270 00000 n -0000754411 00000 n -0000754558 00000 n -0000754717 00000 n -0000000512 00000 f -0000119077 00000 n -0000742882 00000 n -0000743032 00000 n -0000743177 00000 n -0000743324 00000 n -0000743482 00000 n -0000743632 00000 n -0000743779 00000 n -0000743936 00000 n -0000744090 00000 n -0000744243 00000 n -0000744401 00000 n -0000744559 00000 n -0000744704 00000 n -0000744870 00000 n -0000745025 00000 n -0000745187 00000 n -0000745334 00000 n -0000745500 00000 n -0000745641 00000 n -0000745783 00000 n -0000000528 00000 f -0000119457 00000 n -0000735608 00000 n -0000735751 00000 n -0000735894 00000 n -0000736061 00000 n -0000736220 00000 n -0000736363 00000 n -0000736530 00000 n -0000736677 00000 n -0000736839 00000 n -0000736978 00000 n -0000737118 00000 n -0000737280 00000 n -0000737436 00000 n -0000737579 00000 n -0000000550 00000 f -0000119789 00000 n -0000726678 00000 n -0000726823 00000 n -0000726973 00000 n -0000727113 00000 n -0000727252 00000 n -0000727400 00000 n -0000727546 00000 n -0000727696 00000 n -0000727847 00000 n -0000727994 00000 n -0000728161 00000 n -0000728304 00000 n -0000728471 00000 n -0000728618 00000 n -0000728773 00000 n -0000728934 00000 n -0000729077 00000 n -0000729221 00000 n -0000729372 00000 n -0000729519 00000 n -0000000569 00000 f -0000120169 00000 n -0000718893 00000 n -0000719036 00000 n -0000719199 00000 n -0000719344 00000 n -0000719503 00000 n -0000719650 00000 n -0000719794 00000 n -0000719941 00000 n -0000720088 00000 n -0000720239 00000 n -0000720382 00000 n -0000720549 00000 n -0000720696 00000 n -0000720843 00000 n -0000720986 00000 n -0000721153 00000 n -0000721300 00000 n -0000000584 00000 f -0000120525 00000 n -0000712738 00000 n -0000712890 00000 n -0000713043 00000 n -0000713186 00000 n -0000713353 00000 n -0000713500 00000 n -0000713648 00000 n -0000713790 00000 n -0000713938 00000 n -0000714086 00000 n -0000714230 00000 n -0000714398 00000 n -0000714545 00000 n -0000000600 00000 f -0000120849 00000 n -0000706114 00000 n -0000706258 00000 n -0000706426 00000 n -0000706573 00000 n -0000706719 00000 n -0000706863 00000 n -0000707030 00000 n -0000707177 00000 n -0000707326 00000 n -0000707479 00000 n -0000707632 00000 n -0000707778 00000 n -0000707922 00000 n -0000708128 00000 n -0000000615 00000 f -0000121181 00000 n -0000699659 00000 n -0000699803 00000 n -0000699971 00000 n -0000700118 00000 n -0000700261 00000 n -0000700403 00000 n -0000700546 00000 n -0000700688 00000 n -0000700831 00000 n -0000700974 00000 n -0000701118 00000 n -0000701286 00000 n -0000701435 00000 n -0000000628 00000 f -0000121505 00000 n -0000693905 00000 n -0000694049 00000 n -0000694217 00000 n -0000694362 00000 n -0000694529 00000 n -0000694676 00000 n -0000694820 00000 n -0000694970 00000 n -0000695122 00000 n -0000695269 00000 n -0000695417 00000 n -0000000641 00000 f -0000121813 00000 n -0000687843 00000 n -0000687987 00000 n -0000688155 00000 n -0000688311 00000 n -0000688466 00000 n -0000688631 00000 n -0000688775 00000 n -0000688943 00000 n -0000689092 00000 n -0000689241 00000 n -0000689385 00000 n -0000000650 00000 f -0000122121 00000 n -0000683275 00000 n -0000683429 00000 n -0000683578 00000 n -0000683735 00000 n -0000683884 00000 n -0000684041 00000 n -0000684185 00000 n -0000000658 00000 f -0000122397 00000 n -0000679287 00000 n -0000679431 00000 n -0000679599 00000 n -0000679749 00000 n -0000679903 00000 n -0000680054 00000 n -0000000669 00000 f -0000122665 00000 n -0000674200 00000 n -0000674346 00000 n -0000674491 00000 n -0000674638 00000 n -0000674786 00000 n -0000674931 00000 n -0000675075 00000 n -0000675243 00000 n -0000675390 00000 n -0000000676 00000 f -0000122957 00000 n -0000670203 00000 n -0000670351 00000 n -0000670495 00000 n -0000670663 00000 n -0000670810 00000 n -0000000686 00000 f -0000123217 00000 n -0000665333 00000 n -0000665484 00000 n -0000665637 00000 n -0000665783 00000 n -0000665932 00000 n -0000666080 00000 n -0000666225 00000 n -0000666369 00000 n -0000000698 00000 f -0000123501 00000 n -0000659921 00000 n -0000660068 00000 n -0000660214 00000 n -0000660366 00000 n -0000660519 00000 n -0000660663 00000 n -0000660831 00000 n -0000660976 00000 n -0000661134 00000 n -0000661281 00000 n -0000000709 00000 f -0000123801 00000 n -0000654971 00000 n -0000655177 00000 n -0000655320 00000 n -0000655468 00000 n -0000655613 00000 n -0000655758 00000 n -0000655901 00000 n -0000656068 00000 n -0000656215 00000 n -0000000725 00000 f -0000124093 00000 n -0000648282 00000 n -0000648485 00000 n -0000648628 00000 n -0000648776 00000 n -0000648924 00000 n -0000649068 00000 n -0000649214 00000 n -0000649357 00000 n -0000649524 00000 n -0000649669 00000 n -0000649813 00000 n -0000649956 00000 n -0000650099 00000 n -0000650251 00000 n -0000000739 00000 f -0000124425 00000 n -0000641839 00000 n -0000641988 00000 n -0000642136 00000 n -0000642279 00000 n -0000642425 00000 n -0000642569 00000 n -0000642737 00000 n -0000642884 00000 n -0000643042 00000 n -0000643183 00000 n -0000643332 00000 n -0000643480 00000 n -0000000751 00000 f -0000124741 00000 n -0000636503 00000 n -0000636647 00000 n -0000636815 00000 n -0000636960 00000 n -0000637127 00000 n -0000637274 00000 n -0000637423 00000 n -0000637567 00000 n -0000637711 00000 n -0000637864 00000 n -0000000768 00000 f -0000125041 00000 n -0000629816 00000 n -0000629960 00000 n -0000630128 00000 n -0000630275 00000 n -0000630434 00000 n -0000630637 00000 n -0000630780 00000 n -0000630927 00000 n -0000631071 00000 n -0000631216 00000 n -0000631360 00000 n -0000631528 00000 n -0000631673 00000 n -0000631840 00000 n -0000631987 00000 n -0000000779 00000 f -0000125381 00000 n -0000624778 00000 n -0000624928 00000 n -0000625083 00000 n -0000625235 00000 n -0000625386 00000 n -0000625532 00000 n -0000625675 00000 n -0000625815 00000 n -0000625957 00000 n -0000000791 00000 f -0000125673 00000 n -0000618886 00000 n -0000619038 00000 n -0000619190 00000 n -0000619333 00000 n -0000619482 00000 n -0000619630 00000 n -0000619780 00000 n -0000619924 00000 n -0000620092 00000 n -0000620242 00000 n -0000000798 00000 f -0000125973 00000 n -0000614965 00000 n -0000615118 00000 n -0000615271 00000 n -0000615418 00000 n -0000615568 00000 n -0000000803 00000 f -0000126233 00000 n -0000611291 00000 n -0000611435 00000 n -0000611604 00000 n -0000000813 00000 f -0000126477 00000 n -0000607445 00000 n -0000607589 00000 n -0000607757 00000 n -0000607902 00000 n -0000608061 00000 n -0000608206 00000 n -0000608354 00000 n -0000608498 00000 n -0000000825 00000 f -0000126761 00000 n -0000469027 00000 n -0000469171 00000 n -0000469339 00000 n -0000469483 00000 n -0000469652 00000 n -0000469799 00000 n -0000469950 00000 n -0000470093 00000 n -0000470237 00000 n -0000470389 00000 n -0000000839 00000 f -0000127061 00000 n -0000462255 00000 n -0000462399 00000 n -0000462567 00000 n -0000462714 00000 n -0000462859 00000 n -0000463003 00000 n -0000463147 00000 n -0000463299 00000 n -0000463451 00000 n -0000463595 00000 n -0000463763 00000 n -0000463910 00000 n -0000000854 00000 f -0000127377 00000 n -0000455764 00000 n -0000455908 00000 n -0000456052 00000 n -0000456205 00000 n -0000456358 00000 n -0000456501 00000 n -0000456668 00000 n -0000456811 00000 n -0000456972 00000 n -0000457119 00000 n -0000457272 00000 n -0000457416 00000 n -0000457560 00000 n -0000000860 00000 f -0000127701 00000 n -0000449929 00000 n -0000450093 00000 n -0000450237 00000 n -0000450405 00000 n -0000000870 00000 f -0000127953 00000 n -0000445541 00000 n -0000445685 00000 n -0000445853 00000 n -0000445998 00000 n -0000446159 00000 n -0000446306 00000 n -0000446459 00000 n -0000446611 00000 n -0000000879 00000 f -0000128237 00000 n -0000441142 00000 n -0000441284 00000 n -0000441440 00000 n -0000441584 00000 n -0000441728 00000 n -0000441896 00000 n -0000442043 00000 n -0000000889 00000 f -0000128513 00000 n -0000436200 00000 n -0000436344 00000 n -0000436512 00000 n -0000436659 00000 n -0000436804 00000 n -0000436948 00000 n -0000437116 00000 n -0000437263 00000 n -0000000898 00000 f -0000128797 00000 n -0000431868 00000 n -0000432021 00000 n -0000432173 00000 n -0000432323 00000 n -0000432475 00000 n -0000432618 00000 n -0000432762 00000 n -0000000911 00000 f -0000129073 00000 n -0000415436 00000 n -0000415579 00000 n -0000415738 00000 n -0000415883 00000 n -0000416046 00000 n -0000416212 00000 n -0000416378 00000 n -0000416581 00000 n -0000416723 00000 n -0000416881 00000 n -0000417022 00000 n -0000000925 00000 f -0000129381 00000 n -0000409201 00000 n -0000409346 00000 n -0000409513 00000 n -0000409658 00000 n -0000409825 00000 n -0000409971 00000 n -0000410116 00000 n -0000410259 00000 n -0000410464 00000 n -0000410606 00000 n -0000410811 00000 n -0000410966 00000 n -0000000935 00000 f -0000129697 00000 n -0000403812 00000 n -0000403959 00000 n -0000404126 00000 n -0000404273 00000 n -0000404435 00000 n -0000404582 00000 n -0000404746 00000 n -0000404893 00000 n -0000000951 00000 f -0000129981 00000 n -0000396983 00000 n -0000397128 00000 n -0000397295 00000 n -0000397450 00000 n -0000397597 00000 n -0000397764 00000 n -0000397911 00000 n -0000398077 00000 n -0000398220 00000 n -0000398387 00000 n -0000398532 00000 n -0000398699 00000 n -0000398855 00000 n -0000399002 00000 n -0000000959 00000 f -0000130313 00000 n -0000392381 00000 n -0000392531 00000 n -0000392693 00000 n -0000392853 00000 n -0000393014 00000 n -0000393161 00000 n -0000001020 00000 f -0000130581 00000 n -0000372660 00000 n -0000372803 00000 n -0000372955 00000 n -0000373103 00000 n -0000373244 00000 n -0000373385 00000 n -0000373529 00000 n -0000373674 00000 n -0000373820 00000 n -0000373967 00000 n -0000374109 00000 n -0000374262 00000 n -0000374402 00000 n -0000374543 00000 n -0000374681 00000 n -0000374829 00000 n -0000374973 00000 n -0000375114 00000 n -0000375264 00000 n -0000375414 00000 n -0000375563 00000 n -0000375712 00000 n -0000375861 00000 n -0000376008 00000 n -0000376150 00000 n -0000376292 00000 n -0000376436 00000 n -0000376581 00000 n -0000376735 00000 n -0000376890 00000 n -0000377034 00000 n -0000377183 00000 n -0000377325 00000 n -0000377467 00000 n -0000377610 00000 n -0000377759 00000 n -0000377900 00000 n -0000378045 00000 n -0000378194 00000 n -0000378336 00000 n -0000378484 00000 n -0000378628 00000 n -0000378774 00000 n -0000378920 00000 n -0000379066 00000 n -0000379214 00000 n -0000379357 00000 n -0000379512 00000 n -0000379653 00000 n -0000379795 00000 n -0000379937 00000 n -0000380083 00000 n -0000380234 00000 n -0000380384 00000 n -0000380527 00000 n -0000380670 00000 n -0000380815 00000 n -0000380970 00000 n -0000381115 00000 n -0000001054 00000 f -0000131293 00000 n -0000359016 00000 n -0000359160 00000 n -0000359304 00000 n -0000359448 00000 n -0000359590 00000 n -0000359739 00000 n -0000359889 00000 n -0000360033 00000 n -0000360173 00000 n -0000360314 00000 n -0000360461 00000 n -0000360603 00000 n -0000360746 00000 n -0000360890 00000 n -0000361030 00000 n -0000361171 00000 n -0000361316 00000 n -0000361460 00000 n -0000361600 00000 n -0000361741 00000 n -0000361886 00000 n -0000362039 00000 n -0000362188 00000 n -0000362334 00000 n -0000362475 00000 n -0000362621 00000 n -0000362769 00000 n -0000362911 00000 n -0000363053 00000 n -0000363203 00000 n -0000363353 00000 n -0000363501 00000 n -0000001099 00000 f -0000131802 00000 n -0000342271 00000 n -0000342417 00000 n -0000342564 00000 n -0000342711 00000 n -0000342859 00000 n -0000343002 00000 n -0000343144 00000 n -0000343286 00000 n -0000343428 00000 n -0000343579 00000 n -0000343728 00000 n -0000343871 00000 n -0000344027 00000 n -0000344172 00000 n -0000344319 00000 n -0000344463 00000 n -0000344616 00000 n -0000344770 00000 n -0000344918 00000 n -0000345060 00000 n -0000345208 00000 n -0000345357 00000 n -0000345507 00000 n -0000345649 00000 n -0000345795 00000 n -0000345942 00000 n -0000346089 00000 n -0000346237 00000 n -0000346379 00000 n -0000346521 00000 n -0000346664 00000 n -0000346808 00000 n -0000346958 00000 n -0000347099 00000 n -0000347241 00000 n -0000347386 00000 n -0000347531 00000 n -0000347680 00000 n -0000347829 00000 n -0000347971 00000 n -0000348117 00000 n -0000348259 00000 n -0000348401 00000 n -0000001140 00000 f -0000132410 00000 n -0000326086 00000 n -0000326237 00000 n -0000326380 00000 n -0000326530 00000 n -0000326679 00000 n -0000326822 00000 n -0000326975 00000 n -0000327124 00000 n -0000327268 00000 n -0000327408 00000 n -0000327548 00000 n -0000327691 00000 n -0000327831 00000 n -0000327980 00000 n -0000328124 00000 n -0000328270 00000 n -0000328416 00000 n -0000328562 00000 n -0000328710 00000 n -0000328853 00000 n -0000329008 00000 n -0000329149 00000 n -0000329291 00000 n -0000329433 00000 n -0000329579 00000 n -0000329730 00000 n -0000329873 00000 n -0000330019 00000 n -0000330165 00000 n -0000330321 00000 n -0000330466 00000 n -0000330611 00000 n -0000330766 00000 n -0000330909 00000 n -0000331054 00000 n -0000331200 00000 n -0000331345 00000 n -0000331500 00000 n -0000331651 00000 n -0000001172 00000 f -0000132982 00000 n -0000312293 00000 n -0000312443 00000 n -0000312593 00000 n -0000312739 00000 n -0000312883 00000 n -0000313026 00000 n -0000313166 00000 n -0000313316 00000 n -0000313460 00000 n -0000313601 00000 n -0000313746 00000 n -0000313891 00000 n -0000314036 00000 n -0000314184 00000 n -0000314326 00000 n -0000314468 00000 n -0000314619 00000 n -0000314774 00000 n -0000314919 00000 n -0000315070 00000 n -0000315220 00000 n -0000315373 00000 n -0000315522 00000 n -0000315670 00000 n -0000315819 00000 n -0000315969 00000 n -0000316111 00000 n -0000316280 00000 n -0000316427 00000 n -0000316569 00000 n -0000001188 00000 f -0000133473 00000 n -0000302957 00000 n -0000303103 00000 n -0000303270 00000 n -0000303427 00000 n -0000303575 00000 n -0000303743 00000 n -0000303902 00000 n -0000304062 00000 n -0000304210 00000 n -0000304380 00000 n -0000304524 00000 n -0000304677 00000 n -0000304826 00000 n -0000304967 00000 n -0000001214 00000 f -0000133820 00000 n -0000292699 00000 n -0000292845 00000 n -0000292985 00000 n -0000293132 00000 n -0000293280 00000 n -0000293423 00000 n -0000293562 00000 n -0000293714 00000 n -0000293869 00000 n -0000294010 00000 n -0000294151 00000 n -0000294292 00000 n -0000294442 00000 n -0000294588 00000 n -0000294730 00000 n -0000294882 00000 n -0000295033 00000 n -0000295183 00000 n -0000295333 00000 n -0000295483 00000 n -0000295631 00000 n -0000295780 00000 n -0000295923 00000 n -0000296069 00000 n -0000001234 00000 f -0000134257 00000 n -0000283286 00000 n -0000283442 00000 n -0000283588 00000 n -0000283740 00000 n -0000283890 00000 n -0000284033 00000 n -0000284185 00000 n -0000284333 00000 n -0000284475 00000 n -0000284644 00000 n -0000284789 00000 n -0000284931 00000 n -0000285100 00000 n -0000285267 00000 n -0000285413 00000 n -0000285580 00000 n -0000285736 00000 n -0000285884 00000 n -0000001245 00000 f -0000134640 00000 n -0000277097 00000 n -0000277259 00000 n -0000277420 00000 n -0000277590 00000 n -0000277738 00000 n -0000277907 00000 n -0000278069 00000 n -0000278229 00000 n -0000278377 00000 n -0000001266 00000 f -0000134942 00000 n -0000268978 00000 n -0000269122 00000 n -0000269266 00000 n -0000269416 00000 n -0000269566 00000 n -0000269710 00000 n -0000269879 00000 n -0000270048 00000 n -0000270198 00000 n -0000270348 00000 n -0000270492 00000 n -0000270662 00000 n -0000270831 00000 n -0000271000 00000 n -0000271170 00000 n -0000271340 00000 n -0000271482 00000 n -0000271623 00000 n -0000271764 00000 n -0000001288 00000 f -0000135334 00000 n -0000259719 00000 n -0000259861 00000 n -0000260003 00000 n -0000260145 00000 n -0000260287 00000 n -0000260431 00000 n -0000260600 00000 n -0000260769 00000 n -0000260914 00000 n -0000261060 00000 n -0000261206 00000 n -0000261352 00000 n -0000261498 00000 n -0000261644 00000 n -0000261788 00000 n -0000261957 00000 n -0000262126 00000 n -0000262279 00000 n -0000262432 00000 n -0000262585 00000 n -0000001312 00000 f -0000135735 00000 n -0000249478 00000 n -0000249631 00000 n -0000249784 00000 n -0000249937 00000 n -0000250090 00000 n -0000250243 00000 n -0000250396 00000 n -0000250549 00000 n -0000250702 00000 n -0000250854 00000 n -0000251006 00000 n -0000251159 00000 n -0000251312 00000 n -0000251465 00000 n -0000251610 00000 n -0000251779 00000 n -0000251948 00000 n -0000252098 00000 n -0000252248 00000 n -0000252398 00000 n -0000252543 00000 n -0000252713 00000 n -0000001333 00000 f -0000136154 00000 n -0000240219 00000 n -0000240365 00000 n -0000240511 00000 n -0000240656 00000 n -0000240827 00000 n -0000240998 00000 n -0000241139 00000 n -0000241279 00000 n -0000241419 00000 n -0000241560 00000 n -0000241701 00000 n -0000241842 00000 n -0000241987 00000 n -0000242159 00000 n -0000242331 00000 n -0000242479 00000 n -0000242627 00000 n -0000242772 00000 n -0000242945 00000 n -0000001356 00000 f -0000136546 00000 n -0000230806 00000 n -0000230948 00000 n -0000231093 00000 n -0000231267 00000 n -0000231441 00000 n -0000231583 00000 n -0000231725 00000 n -0000231866 00000 n -0000232010 00000 n -0000232184 00000 n -0000232359 00000 n -0000232509 00000 n -0000232659 00000 n -0000232809 00000 n -0000232959 00000 n -0000233109 00000 n -0000233259 00000 n -0000233409 00000 n -0000233559 00000 n -0000233704 00000 n -0000233880 00000 n -0000001375 00000 f -0000136956 00000 n -0000222368 00000 n -0000222517 00000 n -0000222666 00000 n -0000222815 00000 n -0000222960 00000 n -0000223137 00000 n -0000223314 00000 n -0000223456 00000 n -0000223599 00000 n -0000223744 00000 n -0000223923 00000 n -0000224102 00000 n -0000224251 00000 n -0000224400 00000 n -0000224549 00000 n -0000224694 00000 n -0000224862 00000 n -0000001399 00000 f -0000137330 00000 n -0000212967 00000 n -0000213117 00000 n -0000213267 00000 n -0000213417 00000 n -0000213562 00000 n -0000213731 00000 n -0000213900 00000 n -0000214045 00000 n -0000214190 00000 n -0000214336 00000 n -0000214482 00000 n -0000214628 00000 n -0000214774 00000 n -0000214920 00000 n -0000215066 00000 n -0000215212 00000 n -0000215358 00000 n -0000215504 00000 n -0000215650 00000 n -0000215796 00000 n -0000215942 00000 n -0000216088 00000 n -0000001413 00000 f -0000137749 00000 n -0000205610 00000 n -0000205756 00000 n -0000205902 00000 n -0000206048 00000 n -0000206194 00000 n -0000206339 00000 n -0000206508 00000 n -0000206677 00000 n -0000206821 00000 n -0000206985 00000 n -0000207131 00000 n -0000207284 00000 n -0000001431 00000 f -0000138078 00000 n -0000189872 00000 n -0000190018 00000 n -0000190169 00000 n -0000190373 00000 n -0000190517 00000 n -0000190661 00000 n -0000190812 00000 n -0000190958 00000 n -0000191119 00000 n -0000191310 00000 n -0000191515 00000 n -0000191713 00000 n -0000191912 00000 n -0000192111 00000 n -0000192309 00000 n -0000192508 00000 n -0000001453 00000 f -0000138443 00000 n -0000179261 00000 n -0000179460 00000 n -0000179659 00000 n -0000179858 00000 n -0000180057 00000 n -0000180256 00000 n -0000180454 00000 n -0000180653 00000 n -0000180852 00000 n -0000181051 00000 n -0000181250 00000 n -0000181449 00000 n -0000181648 00000 n -0000181846 00000 n -0000182045 00000 n -0000182244 00000 n -0000182443 00000 n -0000182642 00000 n -0000182841 00000 n -0000183037 00000 n -0000001475 00000 f -0000138844 00000 n -0000167911 00000 n -0000168110 00000 n -0000168309 00000 n -0000168455 00000 n -0000168618 00000 n -0000168824 00000 n -0000169030 00000 n -0000169229 00000 n -0000169427 00000 n -0000169625 00000 n -0000169822 00000 n -0000170021 00000 n -0000170220 00000 n -0000170418 00000 n -0000170617 00000 n -0000170816 00000 n -0000171014 00000 n -0000171212 00000 n -0000171411 00000 n -0000171609 00000 n -0000001491 00000 f -0000139245 00000 n -0000158752 00000 n -0000158951 00000 n -0000159150 00000 n -0000159349 00000 n -0000159548 00000 n -0000159747 00000 n -0000159945 00000 n -0000160143 00000 n -0000160339 00000 n -0000160535 00000 n -0000160722 00000 n -0000160909 00000 n -0000161067 00000 n -0000161253 00000 n -0000001492 00000 f -0000001493 00000 f -0000001494 00000 f -0000001495 00000 f -0000001496 00000 f -0000001497 00000 f -0000001498 00000 f -0000001499 00000 f -0000001500 00000 f -0000001501 00000 f -0000001502 00000 f -0000001503 00000 f -0000001504 00000 f -0000001505 00000 f -0000001506 00000 f -0000001507 00000 f -0000001508 00000 f -0000001509 00000 f -0000001510 00000 f -0000001511 00000 f -0000001512 00000 f -0000001513 00000 f -0000001514 00000 f -0000001515 00000 f -0000001516 00000 f -0000001517 00000 f -0000001518 00000 f -0000001519 00000 f -0000001520 00000 f -0000001521 00000 f -0000001522 00000 f -0000001523 00000 f -0000001524 00000 f -0000001525 00000 f -0000001526 00000 f -0000001527 00000 f -0000001528 00000 f -0000001529 00000 f -0000001530 00000 f -0000001531 00000 f -0000001532 00000 f -0000001533 00000 f -0000001534 00000 f -0000001535 00000 f -0000001536 00000 f -0000001537 00000 f -0000001538 00000 f -0000001539 00000 f -0000001540 00000 f -0000001541 00000 f -0000001542 00000 f -0000001543 00000 f -0000001544 00000 f -0000001545 00000 f -0000001546 00000 f -0000001547 00000 f -0000001548 00000 f -0000001549 00000 f -0000001550 00000 f -0000001551 00000 f -0000001552 00000 f -0000001553 00000 f -0000001554 00000 f -0000001555 00000 f -0000001556 00000 f -0000001557 00000 f -0000001558 00000 f -0000001559 00000 f -0000001560 00000 f -0000001561 00000 f -0000001562 00000 f -0000001563 00000 f -0000001564 00000 f -0000001565 00000 f -0000001566 00000 f -0000001567 00000 f -0000001568 00000 f -0000001569 00000 f -0000001570 00000 f -0000001571 00000 f -0000001572 00000 f -0000001573 00000 f -0000001574 00000 f -0000001575 00000 f -0000001576 00000 f -0000001577 00000 f -0000001578 00000 f -0000001579 00000 f -0000001580 00000 f -0000001581 00000 f -0000001582 00000 f -0000001583 00000 f -0000001584 00000 f -0000001585 00000 f -0000001586 00000 f -0000001587 00000 f -0000001588 00000 f -0000001589 00000 f -0000001590 00000 f -0000001591 00000 f -0000001592 00000 f -0000001593 00000 f -0000001594 00000 f -0000001595 00000 f -0000001596 00000 f -0000001597 00000 f -0000001598 00000 f -0000001599 00000 f -0000001600 00000 f -0000001601 00000 f -0000001602 00000 f -0000001603 00000 f -0000001604 00000 f -0000001605 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000000000 00000 f -0000152173 00000 n -0000151676 00000 n -0000142369 00000 n -0000000000 00000 f -0000143801 00000 n -0000143190 00000 n -0000142513 00000 n -0000000000 00000 f -0000199346 00000 n -0000198885 00000 n -0000198228 00000 n -0000000000 00000 f -0000422372 00000 n -0000421930 00000 n -0000421151 00000 n -0000000000 00000 f -0000475437 00000 n -0000475046 00000 n -0000474321 00000 n -0000000000 00000 f -0000454781 00000 n -0000454569 00000 n -0000454012 00000 n -0000922819 00000 n -0000101940 00000 n -0000946370 00000 n -0000946245 00000 n -0000000000 00000 f -0000000000 00000 f -0000896515 00000 n -0000000000 00000 f -0000867454 00000 n -0000000000 00000 f -0000839166 00000 n -0000000000 00000 f -0000818988 00000 n -0000000000 00000 f -0000811220 00000 n -0000000000 00000 f -0000802651 00000 n -0000000000 00000 f -0000797549 00000 n -0000000000 00000 f -0000792170 00000 n -0000000000 00000 f -0000786452 00000 n -0000000000 00000 f -0000777881 00000 n -0000000000 00000 f -0000768061 00000 n -0000000000 00000 f -0000760537 00000 n -0000000000 00000 f -0000751839 00000 n -0000000000 00000 f -0000742790 00000 n -0000000000 00000 f -0000735484 00000 n -0000000000 00000 f -0000726554 00000 n -0000000000 00000 f -0000718769 00000 n -0000000000 00000 f -0000712614 00000 n -0000000000 00000 f -0000705990 00000 n -0000000000 00000 f -0000699535 00000 n -0000000000 00000 f -0000693781 00000 n -0000000000 00000 f -0000687719 00000 n -0000000000 00000 f -0000683151 00000 n -0000000000 00000 f -0000679147 00000 n -0000000000 00000 f -0000674076 00000 n -0000000000 00000 f -0000670079 00000 n -0000000000 00000 f -0000665209 00000 n -0000000000 00000 f -0000659797 00000 n -0000000000 00000 f -0000654847 00000 n -0000000000 00000 f -0000648158 00000 n -0000000000 00000 f -0000641715 00000 n -0000000000 00000 f -0000636363 00000 n -0000000000 00000 f -0000629692 00000 n -0000000000 00000 f -0000624686 00000 n -0000000000 00000 f -0000618762 00000 n -0000000000 00000 f -0000614873 00000 n -0000000000 00000 f -0000611183 00000 n -0000000000 00000 f -0000474181 00000 n -0000000000 00000 f -0000468887 00000 n -0000000000 00000 f -0000462115 00000 n -0000000000 00000 f -0000453872 00000 n -0000000000 00000 f -0000449805 00000 n -0000000000 00000 f -0000445417 00000 n -0000000000 00000 f -0000441018 00000 n -0000000000 00000 f -0000436076 00000 n -0000000000 00000 f -0000421027 00000 n -0000000000 00000 f -0000415344 00000 n -0000000000 00000 f -0000409109 00000 n -0000000000 00000 f -0000403720 00000 n -0000000000 00000 f -0000396875 00000 n -0000000000 00000 f -0000392289 00000 n -0000000000 00000 f -0000372568 00000 n -0000000000 00000 f -0000358924 00000 n -0000000000 00000 f -0000342179 00000 n -0000000000 00000 f -0000325994 00000 n -0000000000 00000 f -0000312185 00000 n -0000000000 00000 f -0000302865 00000 n -0000000000 00000 f -0000292607 00000 n -0000000000 00000 f -0000283178 00000 n -0000000000 00000 f -0000277005 00000 n -0000000000 00000 f -0000268870 00000 n -0000000000 00000 f -0000259611 00000 n -0000000000 00000 f -0000249370 00000 n -0000000000 00000 f -0000240111 00000 n -0000000000 00000 f -0000230698 00000 n -0000000000 00000 f -0000222260 00000 n -0000000000 00000 f -0000212859 00000 n -0000000000 00000 f -0000198120 00000 n -0000000000 00000 f -0000189780 00000 n -0000000000 00000 f -0000179169 00000 n -0000000000 00000 f -0000167819 00000 n -0000000000 00000 f -0000142277 00000 n -0000158724 00000 n -0000946283 00000 n -0000946498 00000 n -0000111689 00000 n -0000111765 00000 n -0000927690 00000 n -0000927820 00000 n -0000924834 00000 n -0000920499 00000 n -0000894682 00000 n -0000865824 00000 n -0000837467 00000 n -0000816645 00000 n -0000807658 00000 n -0000799761 00000 n -0000795291 00000 n -0000789222 00000 n -0000783403 00000 n -0000775010 00000 n -0000765213 00000 n -0000757742 00000 n -0000748944 00000 n -0000739860 00000 n -0000732683 00000 n -0000724010 00000 n -0000716655 00000 n -0000710383 00000 n -0000703544 00000 n -0000697230 00000 n -0000691212 00000 n -0000685407 00000 n -0000681109 00000 n -0000676902 00000 n -0000671714 00000 n -0000667744 00000 n -0000662936 00000 n -0000657728 00000 n -0000652517 00000 n -0000645434 00000 n -0000639527 00000 n -0000634399 00000 n -0000627462 00000 n -0000621916 00000 n -0000616490 00000 n -0000612206 00000 n -0000609849 00000 n -0000472051 00000 n -0000465866 00000 n -0000459665 00000 n -0000451168 00000 n -0000447972 00000 n -0000443247 00000 n -0000438623 00000 n -0000433987 00000 n -0000418886 00000 n -0000412934 00000 n -0000406258 00000 n -0000401281 00000 n -0000394235 00000 n -0000390165 00000 n -0000368475 00000 n -0000355030 00000 n -0000337675 00000 n -0000321267 00000 n -0000307233 00000 n -0000299839 00000 n -0000288770 00000 n -0000279906 00000 n -0000274775 00000 n -0000265758 00000 n -0000256205 00000 n -0000245987 00000 n -0000237226 00000 n -0000227598 00000 n -0000219556 00000 n -0000209238 00000 n -0000195120 00000 n -0000186248 00000 n -0000174820 00000 n -0000163556 00000 n -0000139592 00000 n -0000151198 00000 n -0000142652 00000 n -0000144018 00000 n -0000152395 00000 n -0000163406 00000 n -0000163255 00000 n -0000163104 00000 n -0000162953 00000 n -0000162802 00000 n -0000162651 00000 n -0000162500 00000 n -0000162349 00000 n -0000162198 00000 n -0000162047 00000 n -0000161896 00000 n -0000161745 00000 n -0000161594 00000 n -0000161443 00000 n -0000174669 00000 n -0000174518 00000 n -0000174367 00000 n -0000174216 00000 n -0000174065 00000 n -0000173914 00000 n -0000173764 00000 n -0000173614 00000 n -0000173464 00000 n -0000173313 00000 n -0000173162 00000 n -0000173012 00000 n -0000172862 00000 n -0000172711 00000 n -0000172560 00000 n -0000172409 00000 n -0000172258 00000 n -0000172108 00000 n -0000171958 00000 n -0000171808 00000 n -0000186098 00000 n -0000185947 00000 n -0000185796 00000 n -0000185646 00000 n -0000185495 00000 n -0000185344 00000 n -0000185194 00000 n -0000185043 00000 n -0000184892 00000 n -0000184741 00000 n -0000184590 00000 n -0000184440 00000 n -0000184289 00000 n -0000184138 00000 n -0000183988 00000 n -0000183838 00000 n -0000183688 00000 n -0000183538 00000 n -0000183387 00000 n -0000183236 00000 n -0000194969 00000 n -0000194818 00000 n -0000194667 00000 n -0000194516 00000 n -0000194365 00000 n -0000194214 00000 n -0000194063 00000 n -0000193912 00000 n -0000193761 00000 n -0000193610 00000 n -0000193460 00000 n -0000193309 00000 n -0000193159 00000 n -0000193009 00000 n -0000192858 00000 n -0000192707 00000 n -0000198374 00000 n -0000199571 00000 n -0000209087 00000 n -0000208936 00000 n -0000208785 00000 n -0000208634 00000 n -0000208483 00000 n -0000208332 00000 n -0000208183 00000 n -0000208032 00000 n -0000207881 00000 n -0000207730 00000 n -0000207579 00000 n -0000207428 00000 n -0000219405 00000 n -0000219254 00000 n -0000219103 00000 n -0000218952 00000 n -0000218801 00000 n -0000218650 00000 n -0000218499 00000 n -0000218348 00000 n -0000218197 00000 n -0000218046 00000 n -0000217895 00000 n -0000217744 00000 n -0000217593 00000 n -0000217442 00000 n -0000217291 00000 n -0000217140 00000 n -0000216989 00000 n -0000216838 00000 n -0000216687 00000 n -0000216536 00000 n -0000216385 00000 n -0000216234 00000 n -0000227447 00000 n -0000227296 00000 n -0000227145 00000 n -0000226994 00000 n -0000226843 00000 n -0000226692 00000 n -0000226541 00000 n -0000226390 00000 n -0000226239 00000 n -0000226088 00000 n -0000225937 00000 n -0000225786 00000 n -0000225635 00000 n -0000225484 00000 n -0000225333 00000 n -0000225182 00000 n -0000225031 00000 n -0000237075 00000 n -0000236924 00000 n -0000236773 00000 n -0000236622 00000 n -0000236471 00000 n -0000236320 00000 n -0000236169 00000 n -0000236018 00000 n -0000235867 00000 n -0000235716 00000 n -0000235565 00000 n -0000235414 00000 n -0000235263 00000 n -0000235112 00000 n -0000234961 00000 n -0000234810 00000 n -0000234659 00000 n -0000234508 00000 n -0000234357 00000 n -0000234206 00000 n -0000234055 00000 n -0000245836 00000 n -0000245685 00000 n -0000245534 00000 n -0000245383 00000 n -0000245232 00000 n -0000245081 00000 n -0000244930 00000 n -0000244779 00000 n -0000244628 00000 n -0000244477 00000 n -0000244326 00000 n -0000244175 00000 n -0000244024 00000 n -0000243873 00000 n -0000243722 00000 n -0000243571 00000 n -0000243420 00000 n -0000243269 00000 n -0000243118 00000 n -0000256054 00000 n -0000255903 00000 n -0000255752 00000 n -0000255601 00000 n -0000255450 00000 n -0000255299 00000 n -0000255148 00000 n -0000254997 00000 n -0000254846 00000 n -0000254695 00000 n -0000254544 00000 n -0000254393 00000 n -0000254242 00000 n -0000254091 00000 n -0000253940 00000 n -0000253789 00000 n -0000253638 00000 n -0000253487 00000 n -0000253336 00000 n -0000253185 00000 n -0000253034 00000 n -0000252883 00000 n -0000265607 00000 n -0000265456 00000 n -0000265305 00000 n -0000265154 00000 n -0000265003 00000 n -0000264852 00000 n -0000264701 00000 n -0000264550 00000 n -0000264399 00000 n -0000264248 00000 n -0000264097 00000 n -0000263946 00000 n -0000263795 00000 n -0000263644 00000 n -0000263493 00000 n -0000263342 00000 n -0000263191 00000 n -0000263040 00000 n -0000262889 00000 n -0000262738 00000 n -0000274624 00000 n -0000274473 00000 n -0000274322 00000 n -0000274171 00000 n -0000274020 00000 n -0000273869 00000 n -0000273718 00000 n -0000273567 00000 n -0000273416 00000 n -0000273265 00000 n -0000273114 00000 n -0000272963 00000 n -0000272812 00000 n -0000272661 00000 n -0000272510 00000 n -0000272359 00000 n -0000272208 00000 n -0000272057 00000 n -0000271906 00000 n -0000279755 00000 n -0000279604 00000 n -0000279453 00000 n -0000279302 00000 n -0000279151 00000 n -0000279000 00000 n -0000278849 00000 n -0000278698 00000 n -0000278548 00000 n -0000288619 00000 n -0000288468 00000 n -0000288317 00000 n -0000288166 00000 n -0000288015 00000 n -0000287864 00000 n -0000287713 00000 n -0000287562 00000 n -0000287411 00000 n -0000287260 00000 n -0000287109 00000 n -0000286958 00000 n -0000286807 00000 n -0000286656 00000 n -0000286505 00000 n -0000286354 00000 n -0000286203 00000 n -0000286052 00000 n -0000299688 00000 n -0000299537 00000 n -0000299386 00000 n -0000299235 00000 n -0000299084 00000 n -0000298933 00000 n -0000298782 00000 n -0000298631 00000 n -0000298480 00000 n -0000298329 00000 n -0000298178 00000 n -0000298027 00000 n -0000297876 00000 n -0000297725 00000 n -0000297574 00000 n -0000297423 00000 n -0000297272 00000 n -0000297121 00000 n -0000296970 00000 n -0000296819 00000 n -0000296668 00000 n -0000296517 00000 n -0000296366 00000 n -0000296215 00000 n -0000307082 00000 n -0000306931 00000 n -0000306780 00000 n -0000306629 00000 n -0000306478 00000 n -0000306327 00000 n -0000306176 00000 n -0000306025 00000 n -0000305874 00000 n -0000305723 00000 n -0000305572 00000 n -0000305421 00000 n -0000305270 00000 n -0000305119 00000 n -0000321116 00000 n -0000320965 00000 n -0000320814 00000 n -0000320663 00000 n -0000320512 00000 n -0000320361 00000 n -0000320210 00000 n -0000320059 00000 n -0000319908 00000 n -0000319757 00000 n -0000319607 00000 n -0000319456 00000 n -0000319305 00000 n -0000319154 00000 n -0000319003 00000 n -0000318852 00000 n -0000318701 00000 n -0000318550 00000 n -0000318399 00000 n -0000318248 00000 n -0000318097 00000 n -0000317946 00000 n -0000317795 00000 n -0000317644 00000 n -0000317493 00000 n -0000317342 00000 n -0000317191 00000 n -0000317040 00000 n -0000316889 00000 n -0000316738 00000 n -0000337524 00000 n -0000337373 00000 n -0000337222 00000 n -0000337071 00000 n -0000336920 00000 n -0000336769 00000 n -0000336618 00000 n -0000336467 00000 n -0000336316 00000 n -0000336165 00000 n -0000336014 00000 n -0000335863 00000 n -0000335712 00000 n -0000335561 00000 n -0000335410 00000 n -0000335260 00000 n -0000335109 00000 n -0000334958 00000 n -0000334807 00000 n -0000334656 00000 n -0000334505 00000 n -0000334355 00000 n -0000334204 00000 n -0000334053 00000 n -0000333902 00000 n -0000333751 00000 n -0000333600 00000 n -0000333450 00000 n -0000333299 00000 n -0000333149 00000 n -0000332999 00000 n -0000332848 00000 n -0000332697 00000 n -0000332546 00000 n -0000332395 00000 n -0000332244 00000 n -0000332093 00000 n -0000331942 00000 n -0000331791 00000 n -0000354879 00000 n -0000354728 00000 n -0000354578 00000 n -0000354427 00000 n -0000354276 00000 n -0000354125 00000 n -0000353975 00000 n -0000353824 00000 n -0000353673 00000 n -0000353522 00000 n -0000353371 00000 n -0000353220 00000 n -0000353070 00000 n -0000352920 00000 n -0000352769 00000 n -0000352618 00000 n -0000352468 00000 n -0000352317 00000 n -0000352166 00000 n -0000352015 00000 n -0000351864 00000 n -0000351713 00000 n -0000351562 00000 n -0000351411 00000 n -0000351260 00000 n -0000351110 00000 n -0000350959 00000 n -0000350808 00000 n -0000350657 00000 n -0000350506 00000 n -0000350355 00000 n -0000350204 00000 n -0000350053 00000 n -0000349902 00000 n -0000349751 00000 n -0000349601 00000 n -0000349450 00000 n -0000349299 00000 n -0000349148 00000 n -0000348997 00000 n -0000348846 00000 n -0000348695 00000 n -0000348544 00000 n -0000368324 00000 n -0000368173 00000 n -0000368022 00000 n -0000367871 00000 n -0000367720 00000 n -0000367569 00000 n -0000367418 00000 n -0000367267 00000 n -0000367116 00000 n -0000366965 00000 n -0000366814 00000 n -0000366663 00000 n -0000366512 00000 n -0000366361 00000 n -0000366210 00000 n -0000366059 00000 n -0000365908 00000 n -0000365757 00000 n -0000365606 00000 n -0000365455 00000 n -0000365304 00000 n -0000365153 00000 n -0000365002 00000 n -0000364851 00000 n -0000364700 00000 n -0000364549 00000 n -0000364398 00000 n -0000364247 00000 n -0000364096 00000 n -0000363945 00000 n -0000363794 00000 n -0000363643 00000 n -0000390014 00000 n -0000389863 00000 n -0000389712 00000 n -0000389561 00000 n -0000389411 00000 n -0000389260 00000 n -0000389109 00000 n -0000388958 00000 n -0000388807 00000 n -0000388656 00000 n -0000388505 00000 n -0000388354 00000 n -0000388203 00000 n -0000388052 00000 n -0000387901 00000 n -0000387750 00000 n -0000387599 00000 n -0000387448 00000 n -0000387298 00000 n -0000387147 00000 n -0000386996 00000 n -0000386845 00000 n -0000386694 00000 n -0000386543 00000 n -0000386393 00000 n -0000386242 00000 n -0000386091 00000 n -0000385940 00000 n -0000385790 00000 n -0000385639 00000 n -0000385488 00000 n -0000385337 00000 n -0000385186 00000 n -0000385035 00000 n -0000384884 00000 n -0000384733 00000 n -0000384582 00000 n -0000384431 00000 n -0000384280 00000 n -0000384129 00000 n -0000383978 00000 n -0000383827 00000 n -0000383677 00000 n -0000383526 00000 n -0000383375 00000 n -0000383224 00000 n -0000383073 00000 n -0000382922 00000 n -0000382772 00000 n -0000382621 00000 n -0000382470 00000 n -0000382319 00000 n -0000382168 00000 n -0000382017 00000 n -0000381867 00000 n -0000381716 00000 n -0000381565 00000 n -0000381415 00000 n -0000381265 00000 n -0000394084 00000 n -0000393933 00000 n -0000393782 00000 n -0000393631 00000 n -0000393480 00000 n -0000393329 00000 n -0000401130 00000 n -0000400979 00000 n -0000400828 00000 n -0000400677 00000 n -0000400527 00000 n -0000400376 00000 n -0000400225 00000 n -0000400074 00000 n -0000399923 00000 n -0000399772 00000 n -0000399621 00000 n -0000399470 00000 n -0000399319 00000 n -0000399169 00000 n -0000406107 00000 n -0000405956 00000 n -0000405805 00000 n -0000405654 00000 n -0000405503 00000 n -0000405352 00000 n -0000405201 00000 n -0000405050 00000 n -0000412783 00000 n -0000412632 00000 n -0000412481 00000 n -0000412330 00000 n -0000412179 00000 n -0000412028 00000 n -0000411877 00000 n -0000411726 00000 n -0000411575 00000 n -0000411424 00000 n -0000411273 00000 n -0000411122 00000 n -0000418735 00000 n -0000418584 00000 n -0000418433 00000 n -0000418282 00000 n -0000418131 00000 n -0000417980 00000 n -0000417829 00000 n -0000417678 00000 n -0000417527 00000 n -0000417376 00000 n -0000417225 00000 n -0000421291 00000 n -0000422588 00000 n -0000433836 00000 n -0000433685 00000 n -0000433534 00000 n -0000433383 00000 n -0000433232 00000 n -0000433081 00000 n -0000432930 00000 n -0000438472 00000 n -0000438321 00000 n -0000438170 00000 n -0000438019 00000 n -0000437868 00000 n -0000437717 00000 n -0000437566 00000 n -0000437415 00000 n -0000443096 00000 n -0000442946 00000 n -0000442795 00000 n -0000442644 00000 n -0000442493 00000 n -0000442342 00000 n -0000442191 00000 n -0000447821 00000 n -0000447670 00000 n -0000447519 00000 n -0000447368 00000 n -0000447217 00000 n -0000447066 00000 n -0000446915 00000 n -0000446764 00000 n -0000451018 00000 n -0000450867 00000 n -0000450716 00000 n -0000450566 00000 n -0000454159 00000 n -0000455010 00000 n -0000459514 00000 n -0000459363 00000 n -0000459212 00000 n -0000459061 00000 n -0000458910 00000 n -0000458759 00000 n -0000458608 00000 n -0000458457 00000 n -0000458306 00000 n -0000458155 00000 n -0000458004 00000 n -0000457853 00000 n -0000457702 00000 n -0000465715 00000 n -0000465564 00000 n -0000465413 00000 n -0000465263 00000 n -0000465112 00000 n -0000464961 00000 n -0000464810 00000 n -0000464659 00000 n -0000464508 00000 n -0000464357 00000 n -0000464206 00000 n -0000464055 00000 n -0000471900 00000 n -0000471749 00000 n -0000471598 00000 n -0000471447 00000 n -0000471296 00000 n -0000471145 00000 n -0000470994 00000 n -0000470843 00000 n -0000470692 00000 n -0000470541 00000 n -0000474467 00000 n -0000475683 00000 n -0000609698 00000 n -0000609547 00000 n -0000609396 00000 n -0000609245 00000 n -0000609094 00000 n -0000608943 00000 n -0000608792 00000 n -0000608641 00000 n -0000612055 00000 n -0000611904 00000 n -0000611753 00000 n -0000616339 00000 n -0000616188 00000 n -0000616037 00000 n -0000615886 00000 n -0000615735 00000 n -0000621765 00000 n -0000621614 00000 n -0000621463 00000 n -0000621312 00000 n -0000621161 00000 n -0000621010 00000 n -0000620859 00000 n -0000620708 00000 n -0000620557 00000 n -0000620406 00000 n -0000627311 00000 n -0000627160 00000 n -0000627010 00000 n -0000626859 00000 n -0000626708 00000 n -0000626557 00000 n -0000626408 00000 n -0000626257 00000 n -0000626106 00000 n -0000634248 00000 n -0000634097 00000 n -0000633946 00000 n -0000633795 00000 n -0000633644 00000 n -0000633493 00000 n -0000633342 00000 n -0000633191 00000 n -0000633040 00000 n -0000632889 00000 n -0000632738 00000 n -0000632587 00000 n -0000632437 00000 n -0000632286 00000 n -0000632135 00000 n -0000639376 00000 n -0000639225 00000 n -0000639074 00000 n -0000638923 00000 n -0000638772 00000 n -0000638621 00000 n -0000638470 00000 n -0000638319 00000 n -0000638168 00000 n -0000638017 00000 n -0000645283 00000 n -0000645133 00000 n -0000644982 00000 n -0000644831 00000 n -0000644680 00000 n -0000644529 00000 n -0000644378 00000 n -0000644228 00000 n -0000644077 00000 n -0000643926 00000 n -0000643776 00000 n -0000643625 00000 n -0000652366 00000 n -0000652215 00000 n -0000652064 00000 n -0000651914 00000 n -0000651763 00000 n -0000651612 00000 n -0000651461 00000 n -0000651310 00000 n -0000651159 00000 n -0000651008 00000 n -0000650857 00000 n -0000650706 00000 n -0000650555 00000 n -0000650404 00000 n -0000657577 00000 n -0000657426 00000 n -0000657275 00000 n -0000657124 00000 n -0000656973 00000 n -0000656822 00000 n -0000656671 00000 n -0000656520 00000 n -0000656369 00000 n -0000662785 00000 n -0000662634 00000 n -0000662483 00000 n -0000662332 00000 n -0000662181 00000 n -0000662030 00000 n -0000661879 00000 n -0000661729 00000 n -0000661578 00000 n -0000661427 00000 n -0000667593 00000 n -0000667442 00000 n -0000667291 00000 n -0000667140 00000 n -0000666989 00000 n -0000666838 00000 n -0000666687 00000 n -0000666536 00000 n -0000671563 00000 n -0000671412 00000 n -0000671261 00000 n -0000671110 00000 n -0000670959 00000 n -0000676751 00000 n -0000676600 00000 n -0000676449 00000 n -0000676298 00000 n -0000676147 00000 n -0000675996 00000 n -0000675845 00000 n -0000675694 00000 n -0000675543 00000 n -0000680958 00000 n -0000680807 00000 n -0000680656 00000 n -0000680506 00000 n -0000680355 00000 n -0000680204 00000 n -0000685257 00000 n -0000685106 00000 n -0000684956 00000 n -0000684805 00000 n -0000684655 00000 n -0000684504 00000 n -0000684353 00000 n -0000691061 00000 n -0000690911 00000 n -0000690761 00000 n -0000690610 00000 n -0000690459 00000 n -0000690308 00000 n -0000690157 00000 n -0000690006 00000 n -0000689855 00000 n -0000689704 00000 n -0000689553 00000 n -0000697079 00000 n -0000696928 00000 n -0000696777 00000 n -0000696626 00000 n -0000696475 00000 n -0000696324 00000 n -0000696173 00000 n -0000696022 00000 n -0000695872 00000 n -0000695721 00000 n -0000695571 00000 n -0000703393 00000 n -0000703242 00000 n -0000703091 00000 n -0000702941 00000 n -0000702790 00000 n -0000702639 00000 n -0000702488 00000 n -0000702337 00000 n -0000702186 00000 n -0000702035 00000 n -0000701884 00000 n -0000701733 00000 n -0000701582 00000 n -0000710232 00000 n -0000710082 00000 n -0000709931 00000 n -0000709780 00000 n -0000709629 00000 n -0000709478 00000 n -0000709327 00000 n -0000709176 00000 n -0000709025 00000 n -0000708874 00000 n -0000708723 00000 n -0000708572 00000 n -0000708421 00000 n -0000708270 00000 n -0000716504 00000 n -0000716353 00000 n -0000716202 00000 n -0000716051 00000 n -0000715900 00000 n -0000715749 00000 n -0000715598 00000 n -0000715447 00000 n -0000715296 00000 n -0000715145 00000 n -0000714994 00000 n -0000714843 00000 n -0000714692 00000 n -0000723859 00000 n -0000723708 00000 n -0000723557 00000 n -0000723407 00000 n -0000723256 00000 n -0000723105 00000 n -0000722954 00000 n -0000722803 00000 n -0000722652 00000 n -0000722501 00000 n -0000722350 00000 n -0000722199 00000 n -0000722048 00000 n -0000721897 00000 n -0000721746 00000 n -0000721595 00000 n -0000721444 00000 n -0000732532 00000 n -0000732381 00000 n -0000732230 00000 n -0000732079 00000 n -0000731928 00000 n -0000731777 00000 n -0000731626 00000 n -0000731475 00000 n -0000731324 00000 n -0000731173 00000 n -0000731022 00000 n -0000730872 00000 n -0000730721 00000 n -0000730570 00000 n -0000730419 00000 n -0000730268 00000 n -0000730117 00000 n -0000729966 00000 n -0000729815 00000 n -0000729664 00000 n -0000739709 00000 n -0000739558 00000 n -0000739407 00000 n -0000739256 00000 n -0000739105 00000 n -0000738954 00000 n -0000738803 00000 n -0000738652 00000 n -0000738501 00000 n -0000738350 00000 n -0000738199 00000 n -0000738048 00000 n -0000737897 00000 n -0000737746 00000 n -0000748793 00000 n -0000748642 00000 n -0000748491 00000 n -0000748341 00000 n -0000748190 00000 n -0000748039 00000 n -0000747888 00000 n -0000747737 00000 n -0000747586 00000 n -0000747435 00000 n -0000747284 00000 n -0000747133 00000 n -0000746983 00000 n -0000746832 00000 n -0000746681 00000 n -0000746530 00000 n -0000746379 00000 n -0000746228 00000 n -0000746077 00000 n -0000745926 00000 n -0000757591 00000 n -0000757440 00000 n -0000757289 00000 n -0000757138 00000 n -0000756987 00000 n -0000756836 00000 n -0000756685 00000 n -0000756534 00000 n -0000756383 00000 n -0000756232 00000 n -0000756081 00000 n -0000755930 00000 n -0000755779 00000 n -0000755628 00000 n -0000755477 00000 n -0000755326 00000 n -0000755175 00000 n -0000755024 00000 n -0000754873 00000 n -0000765062 00000 n -0000764911 00000 n -0000764760 00000 n -0000764609 00000 n -0000764458 00000 n -0000764307 00000 n -0000764156 00000 n -0000764005 00000 n -0000763854 00000 n -0000763703 00000 n -0000763552 00000 n -0000763401 00000 n -0000763250 00000 n -0000763099 00000 n -0000762948 00000 n -0000774859 00000 n -0000774708 00000 n -0000774557 00000 n -0000774406 00000 n -0000774255 00000 n -0000774104 00000 n -0000773953 00000 n -0000773802 00000 n -0000773651 00000 n -0000773500 00000 n -0000773349 00000 n -0000773198 00000 n -0000773047 00000 n -0000772896 00000 n -0000772745 00000 n -0000772594 00000 n -0000772443 00000 n -0000772292 00000 n -0000772141 00000 n -0000771990 00000 n -0000771839 00000 n -0000771688 00000 n -0000771537 00000 n -0000783252 00000 n -0000783101 00000 n -0000782950 00000 n -0000782799 00000 n -0000782649 00000 n -0000782498 00000 n -0000782347 00000 n -0000782196 00000 n -0000782045 00000 n -0000781894 00000 n -0000781743 00000 n -0000781592 00000 n -0000781441 00000 n -0000781290 00000 n -0000781139 00000 n -0000780988 00000 n -0000780837 00000 n -0000780686 00000 n -0000789071 00000 n -0000788920 00000 n -0000788769 00000 n -0000788618 00000 n -0000788467 00000 n -0000788316 00000 n -0000788165 00000 n -0000788014 00000 n -0000787863 00000 n -0000795140 00000 n -0000794989 00000 n -0000794838 00000 n -0000794687 00000 n -0000794536 00000 n -0000794385 00000 n -0000794234 00000 n -0000794083 00000 n -0000793932 00000 n -0000793781 00000 n -0000799610 00000 n -0000799460 00000 n -0000799309 00000 n -0000799158 00000 n -0000799007 00000 n -0000798856 00000 n -0000798705 00000 n -0000807507 00000 n -0000807357 00000 n -0000807206 00000 n -0000807055 00000 n -0000806904 00000 n -0000806753 00000 n -0000806602 00000 n -0000806451 00000 n -0000806300 00000 n -0000806149 00000 n -0000805998 00000 n -0000805847 00000 n -0000805696 00000 n -0000805545 00000 n -0000805394 00000 n -0000805243 00000 n -0000816494 00000 n -0000816343 00000 n -0000816192 00000 n -0000816041 00000 n -0000815890 00000 n -0000815739 00000 n -0000815588 00000 n -0000815437 00000 n -0000815286 00000 n -0000815135 00000 n -0000814984 00000 n -0000814833 00000 n -0000814682 00000 n -0000814531 00000 n -0000814380 00000 n -0000814229 00000 n -0000814078 00000 n -0000813927 00000 n -0000837316 00000 n -0000837165 00000 n -0000837014 00000 n -0000836864 00000 n -0000836713 00000 n -0000836562 00000 n -0000836412 00000 n -0000836261 00000 n -0000836110 00000 n -0000835959 00000 n -0000835808 00000 n -0000835657 00000 n -0000835507 00000 n -0000835356 00000 n -0000835205 00000 n -0000835055 00000 n -0000834904 00000 n -0000834753 00000 n -0000834602 00000 n -0000834451 00000 n -0000834300 00000 n -0000834150 00000 n -0000833999 00000 n -0000833848 00000 n -0000833698 00000 n -0000833547 00000 n -0000833396 00000 n -0000833246 00000 n -0000833095 00000 n -0000832944 00000 n -0000832793 00000 n -0000832642 00000 n -0000832491 00000 n -0000832340 00000 n -0000832189 00000 n -0000832038 00000 n -0000831887 00000 n -0000831736 00000 n -0000831585 00000 n -0000831434 00000 n -0000831283 00000 n -0000831132 00000 n -0000830981 00000 n -0000830831 00000 n -0000830680 00000 n -0000830529 00000 n -0000830378 00000 n -0000830227 00000 n -0000830080 00000 n -0000829929 00000 n -0000829778 00000 n -0000829627 00000 n -0000829476 00000 n -0000829325 00000 n -0000829174 00000 n -0000829023 00000 n -0000828872 00000 n -0000828721 00000 n -0000828570 00000 n -0000828419 00000 n -0000865674 00000 n -0000865523 00000 n -0000865372 00000 n -0000865221 00000 n -0000865071 00000 n -0000864920 00000 n -0000864770 00000 n -0000864619 00000 n -0000864468 00000 n -0000864318 00000 n -0000864167 00000 n -0000864016 00000 n -0000863865 00000 n -0000863714 00000 n -0000863563 00000 n -0000863413 00000 n -0000863263 00000 n -0000863112 00000 n -0000862961 00000 n -0000862810 00000 n -0000862659 00000 n -0000862509 00000 n -0000862358 00000 n -0000862207 00000 n -0000862057 00000 n -0000861906 00000 n -0000861755 00000 n -0000861605 00000 n -0000861454 00000 n -0000861303 00000 n -0000861153 00000 n -0000861002 00000 n -0000860851 00000 n -0000860700 00000 n -0000860549 00000 n -0000860398 00000 n -0000860248 00000 n -0000860097 00000 n -0000859946 00000 n -0000859795 00000 n -0000859644 00000 n -0000859493 00000 n -0000859343 00000 n -0000859192 00000 n -0000859041 00000 n -0000858891 00000 n -0000858740 00000 n -0000858589 00000 n -0000858439 00000 n -0000858288 00000 n -0000858137 00000 n -0000857987 00000 n -0000857836 00000 n -0000857685 00000 n -0000857534 00000 n -0000857383 00000 n -0000857232 00000 n -0000857081 00000 n -0000856930 00000 n -0000856779 00000 n -0000856628 00000 n -0000856477 00000 n -0000856326 00000 n -0000856175 00000 n -0000856024 00000 n -0000855873 00000 n -0000855723 00000 n -0000855572 00000 n -0000855421 00000 n -0000855271 00000 n -0000855120 00000 n -0000854969 00000 n -0000854819 00000 n -0000854668 00000 n -0000854517 00000 n -0000854367 00000 n -0000854217 00000 n -0000854066 00000 n -0000853915 00000 n -0000853764 00000 n -0000853613 00000 n -0000853463 00000 n -0000853313 00000 n -0000853162 00000 n -0000853012 00000 n -0000852861 00000 n -0000852710 00000 n -0000894532 00000 n -0000894381 00000 n -0000894230 00000 n -0000894080 00000 n -0000893929 00000 n -0000893778 00000 n -0000893627 00000 n -0000893476 00000 n -0000893325 00000 n -0000893175 00000 n -0000893024 00000 n -0000892873 00000 n -0000892723 00000 n -0000892572 00000 n -0000892421 00000 n -0000892270 00000 n -0000892119 00000 n -0000891968 00000 n -0000891818 00000 n -0000891667 00000 n -0000891516 00000 n -0000891366 00000 n -0000891215 00000 n -0000891064 00000 n -0000890913 00000 n -0000890762 00000 n -0000890611 00000 n -0000890460 00000 n -0000890309 00000 n -0000890158 00000 n -0000890008 00000 n -0000889857 00000 n -0000889706 00000 n -0000889556 00000 n -0000889405 00000 n -0000889254 00000 n -0000889104 00000 n -0000888953 00000 n -0000888802 00000 n -0000888652 00000 n -0000888501 00000 n -0000888350 00000 n -0000888200 00000 n -0000888049 00000 n -0000887898 00000 n -0000887748 00000 n -0000887597 00000 n -0000887446 00000 n -0000887296 00000 n -0000887145 00000 n -0000886994 00000 n -0000886844 00000 n -0000886693 00000 n -0000886542 00000 n -0000886392 00000 n -0000886241 00000 n -0000886090 00000 n -0000885939 00000 n -0000885788 00000 n -0000885637 00000 n -0000885486 00000 n -0000885335 00000 n -0000885184 00000 n -0000885034 00000 n -0000884883 00000 n -0000884732 00000 n -0000884582 00000 n -0000884431 00000 n -0000884280 00000 n -0000884130 00000 n -0000883979 00000 n -0000883828 00000 n -0000883678 00000 n -0000883527 00000 n -0000883376 00000 n -0000883226 00000 n -0000883075 00000 n -0000882924 00000 n -0000882773 00000 n -0000882622 00000 n -0000882471 00000 n -0000882321 00000 n -0000882170 00000 n -0000882019 00000 n -0000881869 00000 n -0000881718 00000 n -0000881567 00000 n -0000881417 00000 n -0000881266 00000 n -0000881115 00000 n -0000920348 00000 n -0000920197 00000 n -0000920046 00000 n -0000919895 00000 n -0000919744 00000 n -0000919594 00000 n -0000919443 00000 n -0000919292 00000 n -0000919141 00000 n -0000918990 00000 n -0000918839 00000 n -0000918688 00000 n -0000918537 00000 n -0000918387 00000 n -0000918236 00000 n -0000918085 00000 n -0000917935 00000 n -0000917784 00000 n -0000917633 00000 n -0000917483 00000 n -0000917332 00000 n -0000917181 00000 n -0000917031 00000 n -0000916880 00000 n -0000916729 00000 n -0000916578 00000 n -0000916427 00000 n -0000916276 00000 n -0000916126 00000 n -0000915976 00000 n -0000915825 00000 n -0000915675 00000 n -0000915524 00000 n -0000915373 00000 n -0000915223 00000 n -0000915072 00000 n -0000914921 00000 n -0000914771 00000 n -0000914620 00000 n -0000914469 00000 n -0000914319 00000 n -0000914168 00000 n -0000914017 00000 n -0000913866 00000 n -0000913715 00000 n -0000913564 00000 n -0000913414 00000 n -0000913263 00000 n -0000913112 00000 n -0000912962 00000 n -0000912811 00000 n -0000912660 00000 n -0000912510 00000 n -0000912359 00000 n -0000912208 00000 n -0000912058 00000 n -0000911907 00000 n -0000911756 00000 n -0000911605 00000 n -0000911454 00000 n -0000911303 00000 n -0000911153 00000 n -0000911002 00000 n -0000910851 00000 n -0000910701 00000 n -0000910550 00000 n -0000910399 00000 n -0000910248 00000 n -0000910098 00000 n -0000909947 00000 n -0000909797 00000 n -0000909647 00000 n -0000909496 00000 n -0000909346 00000 n -0000909195 00000 n -0000909044 00000 n -0000908894 00000 n -0000908743 00000 n -0000908592 00000 n -0000924683 00000 n -0000924532 00000 n -0000924381 00000 n -0000924231 00000 n -0000924080 00000 n -0000923929 00000 n -0000925009 00000 n -0000928021 00000 n -0000928151 00000 n -0000931162 00000 n -0000928294 00000 n -0000928475 00000 n -0000928625 00000 n -0000928777 00000 n -0000928971 00000 n -0000929113 00000 n -0000929253 00000 n -0000929442 00000 n -0000929593 00000 n -0000929798 00000 n -0000945536 00000 n -0000942968 00000 n -0000943148 00000 n -0000943334 00000 n -0000929973 00000 n -0000930150 00000 n -0000930328 00000 n -0000941483 00000 n -0000941619 00000 n -0000938828 00000 n -0000936419 00000 n -0000936563 00000 n -0000936706 00000 n -0000930510 00000 n -0000930689 00000 n -0000930856 00000 n -0000934514 00000 n -0000931317 00000 n -0000931479 00000 n -0000931625 00000 n -0000931010 00000 n -0000931823 00000 n -0000931980 00000 n -0000932133 00000 n -0000932324 00000 n -0000932471 00000 n -0000932619 00000 n -0000936248 00000 n -0000935771 00000 n -0000932811 00000 n -0000932956 00000 n -0000933091 00000 n -0000933280 00000 n -0000933419 00000 n -0000933558 00000 n -0000935622 00000 n -0000935473 00000 n -0000933747 00000 n -0000933880 00000 n -0000934022 00000 n -0000935309 00000 n -0000935003 00000 n -0000934212 00000 n -0000934365 00000 n -0000934843 00000 n -0000934679 00000 n -0000935154 00000 n -0000935934 00000 n -0000936125 00000 n -0000941330 00000 n -0000941180 00000 n -0000936901 00000 n -0000937031 00000 n -0000937222 00000 n -0000937363 00000 n -0000937499 00000 n -0000941024 00000 n -0000940874 00000 n -0000937701 00000 n -0000937856 00000 n -0000940398 00000 n -0000940545 00000 n -0000938065 00000 n -0000938205 00000 n -0000938354 00000 n -0000938543 00000 n -0000938679 00000 n -0000940239 00000 n -0000940088 00000 n -0000939032 00000 n -0000939196 00000 n -0000939798 00000 n -0000939942 00000 n -0000939644 00000 n -0000939332 00000 n -0000939486 00000 n -0000940705 00000 n -0000942816 00000 n -0000941758 00000 n -0000941906 00000 n -0000942060 00000 n -0000942210 00000 n -0000942362 00000 n -0000942515 00000 n -0000942664 00000 n -0000946054 00000 n -0000943546 00000 n -0000943711 00000 n -0000943891 00000 n -0000944108 00000 n -0000944277 00000 n -0000944461 00000 n -0000944674 00000 n -0000944840 00000 n -0000945021 00000 n -0000945230 00000 n -0000945388 00000 n -0000945887 00000 n -0000945718 00000 n -0001017891 00000 n -trailer -<<8504DAADCEB9B2110A00000000000000>]>> -startxref -1018790 -%%EOF diff --git a/specifications/contacts/rfc9553.txt b/specifications/contacts/rfc9553.txt deleted file mode 100644 index 0b72c682..00000000 --- a/specifications/contacts/rfc9553.txt +++ /dev/null @@ -1,4043 +0,0 @@ - - - - -Internet Engineering Task Force (IETF) R. Stepanek -Request for Comments: 9553 Fastmail -Category: Standards Track M. Loffredo -ISSN: 2070-1721 IIT-CNR - May 2024 - - - JSContact: A JSON Representation of Contact Data - -Abstract - - This specification defines a data model and JavaScript Object - Notation (JSON) representation of contact card information that can - be used for data storage and exchange in address book or directory - applications. It aims to be an alternative to the vCard data format - and to be unambiguous, extendable, and simple to process. In - contrast to the JSON-based jCard format, it is not a direct mapping - from the vCard data model and expands semantics where appropriate. - Two additional specifications define new vCard elements and how to - convert between JSContact and vCard. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc9553. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Revised BSD License text as described in Section 4.e of the - Trust Legal Provisions and are provided without warranty as described - in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Motivation and Relation to vCard, jCard, and xCard - 1.2. Notational Conventions - 1.3. Data Type Notations - 1.3.1. Objects and Properties - 1.3.2. Type Signatures - 1.3.3. Property Attributes - 1.3.4. The @type Property - 1.4. Common Data Types - 1.4.1. Id - 1.4.2. Int and UnsignedInt - 1.4.3. PatchObject - 1.4.4. Resource - 1.4.5. UTCDateTime - 1.5. Common Properties - 1.5.1. contexts - 1.5.2. label - 1.5.3. pref - 1.5.4. phonetic - 1.6. Internationalization - 1.6.1. Free-Form Text - 1.6.2. URIs - 1.7. Validating JSContact - 1.7.1. Case-Sensitivity - 1.7.2. IANA-Registered Properties - 1.7.3. Reserved Properties - 1.7.4. Unknown Properties - 1.7.5. Enumerated Values - 1.8. Vendor-Specific Extensions - 1.8.1. Vendor-Specific Properties - 1.8.2. Vendor-Specific Values - 1.9. Versioning - 1.9.1. Version Format and Requirements - 1.9.2. Current Version - 2. Card - 2.1. Metadata Properties - 2.1.1. @type - 2.1.2. version - 2.1.3. created - 2.1.4. kind - 2.1.5. language - 2.1.6. members - 2.1.7. prodId - 2.1.8. relatedTo - 2.1.9. uid - 2.1.10. updated - 2.2. Name and Organization Properties - 2.2.1. name - 2.2.2. nicknames - 2.2.3. organizations - 2.2.4. speakToAs - 2.2.5. titles - 2.3. Contact Properties - 2.3.1. emails - 2.3.2. onlineServices - 2.3.3. phones - 2.3.4. preferredLanguages - 2.4. Calendaring and Scheduling Properties - 2.4.1. calendars - 2.4.2. schedulingAddresses - 2.5. Address and Location Properties - 2.5.1. addresses - 2.6. Resource Properties - 2.6.1. cryptoKeys - 2.6.2. directories - 2.6.3. links - 2.6.4. media - 2.7. Multilingual Properties - 2.7.1. localizations - 2.8. Additional Properties - 2.8.1. anniversaries - 2.8.2. keywords - 2.8.3. notes - 2.8.4. personalInfo - 3. IANA Considerations - 3.1. Media Type Registration - 3.2. Creation of the JSContact Registry Group - 3.3. Registry Policy and Change Procedures - 3.3.1. Preliminary Community Review - 3.3.2. Submit Request to IANA - 3.3.3. Designated Expert Review - 3.3.4. Change Procedures - 3.4. Creation of the JSContact Version Registry - 3.4.1. JSContact Version Registry Template - 3.4.2. Initial Contents of the JSContact Version Registry - 3.5. Creation of the JSContact Properties Registry - 3.5.1. JSContact Properties Registry Template - 3.5.2. Initial Contents of the JSContact Properties Registry - 3.6. Creation of the JSContact Types Registry - 3.6.1. JSContact Types Registry Template - 3.6.2. Initial Contents of the JSContact Types Registry - 3.7. Creation of the JSContact Enum Values Registry - 3.7.1. JSContact Enum Values Registry Property Template - 3.7.2. JSContact Enum Values Registry Value Template - 3.7.3. Initial Contents of the JSContact Enum Values Registry - 4. Security Considerations - 4.1. JSON Parsing - 4.2. URI Values - 5. References - 5.1. Normative References - 5.2. Informative References - Authors' Addresses - -1. Introduction - - This document defines a data model for contact card data normally - used in address book or directory applications and services. It aims - to be an alternative to the vCard data format [RFC6350]. - - The key design considerations for this data model are as follows: - - * The data model and set of attributes should be mostly compatible - with the model defined for the vCard data format [RFC6350] and - extensions [RFC6473] [RFC6474] [RFC6715] [RFC6869] [RFC8605]. The - specification should add new attributes or value types where - appropriate. Not all existing vCard definitions need an - equivalent in JSContact, especially if the vCard definition is - considered to be obsolete or otherwise inappropriate. Conversion - between the data formats need not fully preserve semantic meaning. - - * The attributes of the card data must be described as simple key- - value pairs to reduce the complexity of the representation of the - card data. - - * The data model should avoid all ambiguities and make it difficult - to make mistakes during implementation. - - * Extensions, such as new properties and components, MUST NOT lead - to a required update of this document. - - The representation of this data model is defined in the Internet JSON - (I-JSON) format [RFC7493], which is a strict subset of the JSON data - interchange format [RFC8259]. Using JSON is mostly a pragmatic - choice: its widespread use makes JSContact easier to adopt, and the - availability of production-ready JSON implementations eliminates a - whole category of parser-related interoperability issues. - -1.1. Motivation and Relation to vCard, jCard, and xCard - - The vCard data format [RFC6350] is an interchange format for contacts - data between address book service providers and vendors. However, - this format has gone through multiple specification iterations with - only a subset of its deprecated version 3 [RFC2426] being widely in - use. Consequently, products and services use an internal contact - data model that is richer than what they expose when serializing that - information to vCard. In addition, service providers often use a - proprietary JSON representation of contact data in their APIs. - - JSContact provides a standard JSON-based data model and - representation of contact data as an alternative to proprietary - formats. - - At the time of writing this document, several missing features in - vCard were brought to the attention of the authors such as social - media contacts, gender pronouns, and others. This highlights how - vCard is not perceived as an evolving format and, consequently, - hasn't been updated for about ten years. JSContact addresses these - unmet demands and defines new vCard properties and parameters to - allow interchanging them in both formats. - - Two additional documents define the relation of JSContact and vCard: - [RFC9554] defines new vCard properties and parameters, and [RFC9555] - defines how to convert JSContact data from and to vCard. - - The xCard [RFC6351] and jCard [RFC7095] specifications define - alternative representations for vCard data in XML and JSON formats, - respectively. Both explicitly aim to not change the underlying data - model. Accordingly, they are regarded as equal to vCard in the - context of this document. - -1.2. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - The ABNF definitions in this document use the notations of [RFC5234]. - ABNF rules not defined in this document are defined in either - [RFC5234] (such as the ABNF for CRLF, WSP, DQUOTE, VCHAR, ALPHA, and - DIGIT) or [RFC6350]. - -1.3. Data Type Notations - - This section introduces the notations and terminology used to define - data types in JSContact. - - The underlying format for JSContact is JSON, so its data types also - build on JSON values. The terms "object" and "array" as well as the - four primitive types ("strings", "numbers", "booleans", and "null") - are to be interpreted as described in Section 1 of [RFC8259]. All - JSContact data MUST be valid according to the constraints given in - I-JSON [RFC7493]. Unless otherwise noted, all member names in JSON - objects and all string values are case-sensitive. Within the context - of JSON objects, the term "key" is synonymous with "member name" as - defined in Section 1 of [RFC8259]. - -1.3.1. Objects and Properties - - JSContact defines data types for contact information such as - addresses or names. This information typically consists of multiple - related elements; for example, a personal name and surname together - form a name. These related elements are organized in JSContact - objects. A JSContact object is a JSON object that has the following: - - 1. A unique type name registered in the IANA "JSContact Types" - registry (Section 3.6). - - 2. One or more object members for which the name and allowed value - types are specified. Such members are called "properties". - - 3. One property named @type with a string value that matches the - type name of the JSContact object. In general, this property - does not need to be set explicitly as outlined in Section 1.3.4. - - The following sections specify how to define JSContact object types. - Sections 1.7 and 1.8 then define the exact requirements for property - names. - - The next paragraph illustrates how a JSContact object is defined. - The names "Foo" and "baz" are only for demonstration and have no - meaning outside the example. - - A Foo object has the following properties: - - @type: String. The JSContact type of the object. The value MUST - be "Foo", if set. - - baz: Number (mandatory). The baz level of the contact. The value - MUST be an integer greater than 0 and less than 10. - - The above paragraph illustrates the following: - - * It defines a JSContact object type named "Foo" that has two - properties, named "@type" and "baz". - - * The @type property adheres to the rules outlined in Section 1.3.4. - Because of this, it is neither defined to be mandatory nor - optional, as this depends on how the Foo object type is used. - - * The baz property value MUST be valid according to the definition - of the Number type. - - * The property has one attribute, "mandatory", which specifies that - the property MUST be present for a value of the Foo object type to - be valid. - - * The free-text description of the baz property describes the - semantics and further restrictions for its values. - -1.3.2. Type Signatures - - Type signatures are given for all JSON values and JSContact - definitions in this document. The following conventions are used: - - String: The JSON string type. - - Number: The JSON number type. - - Boolean: The JSON boolean type. - - A[B]: A JSON object where all keys are of type A and all values are - of type B. - - A[]: A JSON array of values of type A. - - A|B: The value is either of type A or of type B. - - *: The type is undefined (the value could be any type, although - permitted values may be constrained by the context of this value). - - Section 1.4 defines common data types, including signed or unsigned - integers and dates. - -1.3.3. Property Attributes - - Object properties may also have a set of attributes defined along - with the type signature. These have the following meanings: - - mandatory: The property MUST be set for an instance of this object - to be valid. - - optional: The property can, but need not, be set for an instance of - this object to be valid. - - default: This is followed by a JSON value. That value will be used - for this property if it is omitted. - - defaultType: This is followed by the name of a JSContact object - type. A property value of JSContact object type is expected to be - of this named type, in case it omits the @type property. - -1.3.4. The @type Property - - @type: String. The JSContact type of a JSON object. It MUST match - the type name of the JSContact object of which the JSON object is - an instance of. - - The purpose of the @type property is to help implementations identify - which JSContact object type a given JSON object represents. - Implementations MUST validate that JSON objects with this property - conform to the specification of the JSContact object type of that - name. - - In many cases, the @type property value is implied by where its - object occurs in JSContact data. Assuming that both A and B are - JSContact object types: - - * An object that is set as the value for a property with type - signature "A" MAY have the @type property set. If the @type - property is not set, then its value is implied to be A by the - property definition. - - * An object that is set as the value for a property with type - signature "A|B (defaultType: A)" MAY have the @type property set - if it is an instance of A. It MUST have the @type property set if - it is an instance of B. If, instead, the defaultType attribute is - not defined, then the @type property MUST also be set for A. - - * An object that is not the value of a property, such as the topmost - object in JSON data (directly or as a member of an array), MUST - have the @type property set. - -1.4. Common Data Types - - In addition to the standard JSON data types, a couple of additional - data types are common to the definitions of JSContact objects and - properties. - -1.4.1. Id - - Where "Id" is given as a data type, it means a String of at least 1 - and a maximum of 255 octets in size, and it MUST only contain - characters from the "URL and Filename Safe" base64url alphabet, as - defined in Section 5 of [RFC4648], excluding the pad character ("="). - This means the allowed characters are the ASCII alphanumeric - characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). - - In many places in JSContact, a JSON map is used where the map keys - are of type Id and the map values are all the same type of object. - This construction represents an unordered set of objects, with the - added advantage that each entry has a name (the corresponding map - key). This allows for more concise patching of objects and, when - applicable, for the objects in question to be referenced from other - objects within the JSContact object. The map keys MUST be preserved - across multiple versions of the JSContact object. - - Unless otherwise specified for a particular property, there are no - uniqueness constraints on an Id value (other than, of course, the - requirement that you cannot have two values with the same key within - a single JSON map). For example, two Card (Section 2) objects might - use the same Ids in their respective photos properties. Or within - the same Card, the same Id could appear in the emails and phones - properties. These situations do not imply any semantic connections - among the objects. - -1.4.2. Int and UnsignedInt - - Where "Int" is given as a data type, it means an integer in the range - -2^53+1 <= value <= 2^53-1, which is the safe range for integers - stored in a floating-point double, represented as a JSON Number. - - Where "UnsignedInt" is given as a data type, it means an integer in - the range 0 <= value <= 2^53-1 represented as a JSON Number. - -1.4.3. PatchObject - - A PatchObject is of type "String[*]" and represents an unordered set - of patches on a JSON object. Each key is a path represented in a - subset of the JSON Pointer format [RFC6901]. The paths have an - implicit leading "/", so each key is prefixed with "/" before - applying the JSON Pointer evaluation algorithm. - - A patch within a PatchObject is only valid if all the following - conditions apply: - - 1. The pointer MAY reference inside an array, but if the last - reference token in the pointer is an array index, then the patch - value MUST NOT be null. The pointer MUST NOT use "-" as an array - index in any of its reference tokens (i.e., you MUST NOT insert/ - delete from an array, but you MAY replace the contents of its - existing members. To add or remove members, one needs to replace - the complete array value). - - 2. All reference tokens prior to the last (i.e., the value after the - final slash) MUST already exist as values in the object being - patched. If the last reference token is an array index, then a - member at this index MUST already exist in the referenced array. - - 3. There MUST NOT be two patches in the PatchObject where the - pointer of one is the prefix of the pointer of the other, e.g., - "addresses/1/city" and "addresses". - - 4. The value for the patch MUST be valid for the property being set - (of the correct type and obeying any other applicable - restrictions), or if null, the property MUST be optional. - - The value associated with each pointer determines how to apply that - patch: - - * If null, remove the property from the patched object. If the key - is not present in the parent, this is a no-op. - - * If non-null, set the value given as the value for this property - (this may be a replacement or addition to the object being - patched). - - A PatchObject does not define its own @type (Section 1.3.4) property. - Instead, the @type property in a patch MUST be handled as any other - patched property value. - - Implementations MUST reject a PatchObject in its entirety if any of - its patches are invalid. Implementations MUST NOT apply partial - patches. - -1.4.4. Resource - - The Resource data type defines a resource associated with the entity - represented by the Card, identified by a URI [RFC3986]. Later in - this document, several property definitions refer to the Resource - type as the basis for their property-specific value types. The - Resource type defines the properties that are common to all of them. - Property definitions making use of Resource MAY define additional - properties for their value types. - - A Resource object has the following properties: - - @type: String. The JSContact type of the object. The value MUST NOT - be "Resource"; instead, the value MUST be the name of a concrete - resource type (see Section 2.6). - - kind: String (optional). The kind of the resource. The allowed - values are defined in the property definition that makes use of - the Resource type. Some property definitions may change this - property from being optional to mandatory. - - uri: String (mandatory). The resource value. This MUST be a _URI_ - as defined in Section 3 of [RFC3986]. - - mediaType: String (optional). The media type [RFC2046] of the - resource identified by the uri property value. - - contexts: String[Boolean] (optional). The contexts in which to use - this resource. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the resource in - relation to other resources. Also see Section 1.5.3. - - label: String (optional). A custom label for the value. Also see - Section 1.5.2. - -1.4.5. UTCDateTime - - The UTCDateTime type is a String in "date-time" format [RFC3339], - with further restrictions that any letters MUST be in uppercase and - the time offset MUST be the character "Z". Fractional second values - MUST NOT be included unless they are non-zero, and they MUST NOT have - trailing zeros to ensure there is only a single representation for - each date-time. - - For example, "2010-10-10T10:10:10.003Z" is conformant, but - "2010-10-10T10:10:10.000Z" is invalid; the correct encoding is - "2010-10-10T10:10:10Z". - -1.5. Common Properties - - Most of the properties in this document are specific to a single - JSContact object type. Such properties are defined along with the - respective object type. The properties in this section are common to - multiple data types and are defined here to avoid repetition. Note - that these properties MUST only be set for a JSContact object if they - are explicitly mentioned as allowable for this object type. - -1.5.1. contexts - - contexts: String[Boolean]. The contexts in which to use the contact - information. For example, someone might have distinct phone - numbers for work and private contexts and may set the desired - context on the respective phone number in the phones - (Section 2.3.3) property. - - This section defines common contexts. Additional contexts may be - defined in the properties or data types that make use of this - property. The enumerated (Section 1.7.5) common context values - are: - - * private: the contact information that may be used in a private - context. - - * work: the contact information that may be used in a - professional context. - -1.5.2. label - - label: String. The labels associated with the contact data. Such - labels may be set for phone numbers, email addresses, and other - resources. Typically, these labels are displayed along with their - associated contact data in graphical user interfaces. Note that - succinct labels are best for proper display on small graphical - interfaces and screens. - -1.5.3. pref - - pref: UnsignedInt. A preference order for contact information. For - example, a person may have two email addresses and prefer to be - contacted with one of them. - - The value MUST be in the range of 1 to 100. Lower values - correspond to a higher level of preference, with 1 being most - preferred. If no preference is set, then the contact information - MUST be interpreted as being least preferred. - - Note that the preference is only defined in relation to contact - information of the same type. For example, the preference orders - within emails and phone numbers are independent of each other. - -1.5.4. phonetic - - The following properties define how to pronounce a value in the - language indicated in the Card language (Section 2.1.5) property or - the language tag of its localizations (Section 2.7.1). Exemplary - uses of these properties are defining how to pronounce Japanese names - and romanizing Mandarin or Cantonese name and address components. - The properties are defined as follows: - - phonetic: String. The phonetic representation of a value. Any - script language subtag in the Card language (Section 2.1.5) - property MUST be ignored and not used with the phonetic property. - If this property is set, then at least one of the phoneticScript - or phoneticSystem properties that relate to this value MUST be - set. - - phoneticScript: String. The script used in the value of the related - phonetic property. This MUST be a valid script subtag as defined - in Section 2.2.3 of [RFC5646]. - - phoneticSystem: String. The phonetic system used in the related - value of the phonetic property. The enumerated (Section 1.7.5) - values are: - - * ipa: denotes the International Phonetic Alphabet [IPA]. - - * jyut: denotes the Cantonese romanization system "Jyutping". - - * piny: denotes the Standard Mandarin romanization system "Hanyu - Pinyin". - - The relation between the phoneticSystem, phoneticScript, and phonetic - properties is type-specific. This specification defines this - relation in the Name (Section 2.2.1.1) and Address (Section 2.5.1.1) - object types, respectively. - - The following example illustrates the phonetic property for a name - (Section 2.2.1): - - "name": { - "components": [{ - "kind": "given", - "value": "John", - "phonetic": "/ˈdÊ’É‘Ën/" - }, { - "kind": "surname", - "value": "Smith", - "phonetic": "/smɪθ/" - }], - "phoneticSystem": "ipa" - } - - Figure 1: Example of a phonetic Property for the Name "John Smith" as - Pronounced in the USA - -1.6. Internationalization - - JSContact aims to be used for international contacts and address book - data. Notably, text values such as names and addresses are likely to - cover a wide range of languages and cultures. This section describes - internationalization for free-form text values as well as Uniform - Resource Identifiers (URIs). - -1.6.1. Free-Form Text - - Properties having free-form text values MAY contain any valid - sequence of Unicode characters encoded as a JSON string. Such values - can contain unidirectional left-to-right and right-to-left text, as - well as bidirectional text using Unicode Directional Formatting - Characters as described in Section 2 of [UBiDi]. Implementations - setting bidirectional text MUST make sure that each property value - complies with the requirements of the Unicode Bidirectional - Algorithm. Implementations MUST NOT assume that text values of - adjacent properties are processed or displayed as a combined string; - for example, the values of a given name component and a surname - component may or may not be rendered together. - -1.6.2. URIs - - Several properties require their string value to be a URI as defined - in [RFC3986]. Implementations MUST make sure to use proper percent- - encoding for URIs that cannot be represented using unreserved URI - characters. Section 3.1 of [RFC3987] defines how to convert - Internationalized Resource Identifiers to URIs. JSContact makes no - recommendation on how to display URIs, but the WHATWG URL Living - Standard (see "Internationalization and special characters" - (Section 4.8.3) of [WHATWG-URL]) provides guidance for URLs found in - the context of a web browser. - -1.7. Validating JSContact - - This specification distinguishes between three kinds of properties - regarding validation: IANA-registered properties and unknown - properties, which are defined in this section, and vendor-specific - properties, which are defined in Section 1.8.1. A JSContact object - is invalid if any of its properties are invalid. - - This document defines whether each property is mandatory or optional. - A mandatory property MUST be present for a JSContact object to be - valid. An optional property does not need to be present. The values - of both required and optional properties MUST adhere to the data type - and definition of that property. - -1.7.1. Case-Sensitivity - - All property names, object type names, and enumerated values are - case-sensitive, unless explicitly stated otherwise in their - definitions. Implementations MUST handle a JSContact object as - invalid if a type name, property name, or enumerated value only - differs in case from one defined for any JSContact version known to - that implementation. This applies regardless of what JSContact - version the Card object defines in its version (Section 2.1.2) - property. Section 1.7.4 defines how to handle unknown properties. - -1.7.2. IANA-Registered Properties - - An IANA-registered property is any property that has been registered - according to the IANA property registry rules as outlined in - Section 3. All properties defined in this specification, including - their object value types and enumerated values, are registered at - IANA. - - Implementations MUST validate IANA-registered properties in JSContact - data, unless they are unknown to the implementation (Section 1.7.4). - They MUST reject invalid IANA-registered properties. A property is - invalid if its name matches the name of an IANA-registered property - but the value violates its definition according to the JSContact - specification version defined in the Card version (Section 2.1.2) - property. - - IANA-registered property names MUST NOT contain ASCII control - characters (U+0000 to U+001F, U+007F), the COLON (U+003A), or the - QUOTATION MARK (U+0022). They MUST only contain ASCII alphanumeric - characters that match the ALPHA and DIGIT rules defined in - Appendix B.1 of [RFC5234] or the COMMERCIAL AT (U+0040) character. - IANA-registered property names MUST be notated in lower camel case. - -1.7.3. Reserved Properties - - IANA-registered properties can be reserved (Section 3.3). - Implementations MUST NOT set properties having a reserved name in - JSContact objects for which this property is reserved or all objects - if the property context in the registry is "not applicable". - Reserved properties have no type, and their type signature is "not - applicable". Any JSContact object including a property that is - reserved in context of this object MUST be considered invalid. - - This document reserves one property as described below. - -1.7.3.1. extra - - extra: not applicable. The reserved property "extra" provides - implementors with a property name that is certain to never occur - as a property in any JSContact object. Implementations might want - to map unknown or vendor-specific properties to a variable with - this name, but this is implementation-specific. - -1.7.4. Unknown Properties - - Implementations may encounter JSContact data where a property name is - unknown to that implementation but the name adheres to the syntactic - restrictions of IANA-registered property names. Implementations MUST - make sure that such a name does not violate the case-sensitivity - rules defined in Section 1.7.1. If the property name is valid, then - implementations MUST NOT treat such properties as invalid. Instead, - they MUST preserve them in the JSContact object. - - Implementations that create or update JSContact data MUST only set - IANA-registered properties or vendor-specific properties. Preserving - properties that are unknown to the implementation is to allow - applications and services to interoperate without data loss, even if - not all of them implement the same set of JSContact extensions. - -1.7.5. Enumerated Values - - Several properties in this document restrict their allowed values to - a list of String values. These values are case-sensitive. If not - noted otherwise for a specific property, the initial list of values - for such properties is registered at IANA in the "JSContact Enum - Values" registry (Section 3.7). Implementations MUST only set IANA- - registered or vendor-specific (Section 1.8.2) values for such - properties. - -1.8. Vendor-Specific Extensions - - Vendors may extend properties and values for experimentation or to - store contacts data that is only useful for a single service or - application. Such extensions are not meant for interoperation. If, - instead, interoperation is desired, vendors are strongly encouraged - to define and register new properties, types, and values at IANA as - defined in Section 3. Section 1.7.2 defines the naming conventions - for IANA-registered elements. - -1.8.1. Vendor-Specific Properties - - Vendor-specific property names MUST start with a vendor-specific - prefix followed by a name, as produced by the "v-extension" ABNF - below. The prefix and name together form the property name. The - vendor-specific prefix MUST be a domain name under control of the - service or application that sets the property, but it need not - resolve in the Domain Name System [RFC1034] [RFC1035]. The prefix - "ietf.org" and its subdomain names are reserved for IETF - specifications. The name MUST NOT contain the TILDE (U+007E) and - SOLIDUS (U+002F) characters, as these require special escaping when - encoding a JSON Pointer [RFC6901] for that property. - - Vendor-specific properties MAY be set in any JSContact object. - Implementations MUST preserve vendor-specific properties in JSContact - data, irrespective if they know their use. They MUST NOT reject the - property value as invalid, unless they are in control of the vendor- - specific property as outlined in the above paragraph. - - The ABNF rule "v-extension" formally defines valid vendor-specific - property names. Note that the vendor prefix allows for more values - than Internationalized Domain Names (IDNs) [RFC9499]; therefore, - JSContact implementations can simply validate property names without - implementing the full set of rules that apply to domain names. - - v-extension = v-prefix ":" v-name - - v-prefix = v-label *("." v-label) - - v-label = alnum-int / alnum-int *(alnum-int / "-") alnum-int - - alnum-int = ALPHA / DIGIT / NON-ASCII - ; see RFC 6350, Section 3.3 - - v-name = 1*(WSP / "!" / %x23-2e / %x30-7d / NON-ASCII) - ; any characters except CTLs, DQUOTE, SOLIDUS, and TILDE - - Figure 2: ABNF Rules for Vendor-Specific Property Names - - The value of vendor-specific properties can be any valid JSON value, - and naming restrictions do not apply to such values. Specifically, - if the property value is a JSON object, then the keys of such objects - need not be named as vendor-specific properties, as illustrated in - Figure 3: - - "example.com:foo": "bar", - "example.com:foo2": { - "bar": "baz" - } - - Figure 3: Examples of Vendor-Specific Properties - -1.8.2. Vendor-Specific Values - - Some JSContact IANA-registered properties allow their values to be - vendor-specific. One such example is the "kind" (Section 2.1.4) - property, which enumerates its standard values but also allows for - arbitrary vendor-specific values. Such vendor-specific values MUST - be valid "v-extension" values as defined in Section 1.8.1. The - example in Figure 4 illustrates this: - - "kind": "example.com:baz" - - Figure 4: Example of a Vendor-Specific Value - - Vendors are strongly encouraged to specify a new standard value once - a vendor-specific one turns out to also be useful for other systems. - -1.9. Versioning - - Every instance of a JSContact Card (Section 2) indicates which - JSContact version its IANA-registered properties and values are based - on. The version is indicated both in the version (Section 2.1.2) - property within the Card and in the version (Section 3.1) parameter - of the JSContact media type. All IANA-registered elements indicate - the version at which they were introduced or obsoleted. - - A JSContact version consists of a major and minor version. - - Differing major version values indicate substantial differences in - JSContact semantics and format. Implementations MUST be prepared for - property definitions and other JSContact elements that differ in a - backwards-incompatible manner. - - Differing minor version values indicate additions that enrich - JSContact data but do not introduce backwards-incompatible changes. - Typically, these are new property enum values or properties with a - narrow semantic scope. A new minor version MUST NOT require - implementations to change their processing of JSContact data. - Changing the major version number resets the minor version number to - zero. - -1.9.1. Version Format and Requirements - - A version value starts with the numeric major version, followed by - the FULL STOP character (U+002E), followed by the numeric minor - version. Later versions are numerically higher than former versions, - with the major version being more significant than the minor version. - A version value is produced by the following ABNF: - - jsversion = 1*DIGIT "." 1*DIGIT - - Figure 5: The ABNF for JSContact Version Values - -1.9.2. Current Version - - This specification registers JSContact version value "1.0" (Table 1). - -2. Card - - This section defines the JSContact object type Card. A Card stores - contact information, typically that of a person, organization, or - company. - - Its media type is defined in Section 3.1. - - Figure 6 shows a basic Card for the person "John Doe". As the object - is the topmost object in the JSON data, it has the @type property set - according to the rules defined in Section 1.3.4. - - { - "@type": "Card", - "version": "1.0", - "uid": "22B2C7DF-9120-4969-8460-05956FE6B065", - "kind": "individual", - "name": { - "components": [ - { "kind": "given", "value": "John" }, - { "kind": "surname", "value": "Doe" } - ], - "isOrdered": true - } - } - - Figure 6: Example of a Basic Card - -2.1. Metadata Properties - - This section defines properties about this instance of a Card such as - its unique identifier, its creation date, and how it relates to other - Cards and other metadata information. - -2.1.1. @type - - @type: String (mandatory). The JSContact type of the Card object. - The value MUST be "Card". - -2.1.2. version - - version: String (mandatory). The JSContact version of this Card. - The value MUST be one of the IANA-registered JSContact Version - values for the version property. Also see Section 1.9.2. - - "version": "1.0" - - Figure 7: Example for the version Property - -2.1.3. created - - created: UTCDateTime (optional). The date and time when the Card was - created. - - "created": "2022-09-30T14:35:10Z" - - Figure 8: Example for the created Property - -2.1.4. kind - - kind: String (optional; default: "individual"). The kind of the - entity the Card represents. - - The enumerated (Section 1.7.5) values are: - - * individual: a single person - - * group: a group of people or entities - - * org: an organization - - * location: a named location - - * device: a device such as an appliance, a computer, or a network - element - - * application: a software application - - "kind": "individual" - - Figure 9: Example for the kind Property - -2.1.5. language - - language: String (optional). The language tag, as defined in - [RFC5646], that best describes the language used for text in the - Card, optionally including additional information such as the - script. Note that values MAY be localized in the localizations - (Section 2.7.1) property. - - "language": "de-AT" - - Figure 10: Example for the language Property - -2.1.6. members - - members: String[Boolean] (optional). The set of Cards that are - members of this group Card. Each key in the set is the uid - property value of the member, and each boolean value MUST be - "true". If this property is set, then the value of the kind - property MUST be "group". - - The opposite is not true. A group Card will usually contain the - members property to specify the members of the group, but it is - not required to. A group Card without the members property can be - considered an abstract grouping or one whose members are known - empirically (e.g., "IETF Participants"). - - "kind": "group", - "name": { - "full": "The Doe family" - }, - "uid": "urn:uuid:ab4310aa-fa43-11e9-8f0b-362b9e155667", - "members": { - "urn:uuid:03a0e51f-d1aa-4385-8a53-e29025acd8af": true, - "urn:uuid:b8767877-b4a1-4c70-9acc-505d3819e519": true - } - - Figure 11: Example for the members Property - -2.1.7. prodId - - prodId: String (optional). The identifier for the product that - created the Card. If set, the value MUST be at least one - character long. - - "prodId": "ACME Contacts App version 1.23.5" - - Figure 12: Example for the prodId Property - -2.1.8. relatedTo - - relatedTo: String[Relation] (optional). The set of Card objects that - relate to the Card. The value is a map, where each key is the uid - property value of the related Card, and the value defines the - relation. - - The Relation object has the following properties: - - @type: String. - The JSContact type of the object. The value MUST be "Relation", - if set. - - relation: String[Boolean] (optional; default: empty Object). - The relationship of the related Card to the Card, defined as a set - of relation types. The keys in the set define the relation type; - the values for each key in the set MUST be "true". The - relationship between the two objects is undefined if the set is - empty. - - The initial list of enumerated (Section 1.7.5) relation types - matches the IANA-registered TYPE [IANA-vCard] parameter values of - the vCard RELATED property (Section 6.6.6 of [RFC6350]): - - * acquaintance - - * agent - - * child - - * co-resident - - * co-worker - - * colleague - - * contact - - * crush - - * date - - * emergency - - * friend - - * kin - - * me - - * met - - * muse - - * neighbor - - * parent - - * sibling - - * spouse - - * sweetheart - - "relatedTo": { - "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6": { - "relation": { - "friend": true - } - }, - "8cacdfb7d1ffdb59@example.com": { - "relation": {} - } - } - - Figure 13: Example for the relatedTo Property - -2.1.9. uid - - uid: String (mandatory). An identifier that associates the object as - the same across different systems, address books, and views. The - value SHOULD be a URN [RFC8141], but for compatibility with - [RFC6350], it MAY also be a URI [RFC3986] or free-text value. The - value of the URN SHOULD be in the "uuid" namespace [RFC9562]. - [RFC9562] describes multiple versions of Universally Unique - IDentifiers (UUIDs); UUID version 4 is RECOMMENDED. - - "uid": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6" - - Figure 14: Example for the uid Property - -2.1.10. updated - - updated: UTCDateTime (optional). The date and time when the data in - the Card was last modified. - - "updated": "2021-10-31T22:27:10Z" - - Figure 15: Example for the updated Property - -2.2. Name and Organization Properties - - This section defines properties that name the entity represented by - the Card and its related organizations and roles. It also describes - how to refer to the entity represented by the Card in spoken or - written language. - -2.2.1. name - - name: Name (optional). The name of the entity represented by the - Card. This can be any type of name, e.g., it can, but need not, - be the legal name of a person. - -2.2.1.1. Name Object - - A Name object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Name", if set. - - components: NameComponent[] (optional). The components - (Section 2.2.1.2) making up this name. The components property - MUST be set if the full property is not set; otherwise, it SHOULD - be set. The component list MUST have at least one entry having a - different kind property value than "separator". - - Name components SHOULD be ordered such that when their values are - joined as a String, a valid full name of the entity is produced. - If so, implementations MUST set the isOrdered property value to - "true". - - If the name components are ordered, then the defaultSeparator - property and name components with the kind property value set to - "separator" give guidance on what characters to insert between - components, but implementations are free to choose any others. - When lacking a separator, inserting a single space character in - between the name component values is a good choice. - - If, instead, the name components follow no particular order, then - the isOrdered property value MUST be "false", the components - property MUST NOT contain a NameComponent with the kind property - value set to "separator", and the defaultSeparator property MUST - NOT be set. - - Figure 16 shows an example for the name "Vincent van Gogh". Note - how a single name component value may consist of multiple words. - - "name": { - "components": [ - { "kind": "given", "value": "Vincent" }, - { "kind": "surname", "value": "van Gogh" } - ], - "isOrdered": true - } - - Figure 16: Example of a Surname with Two Words - - Figure 17 illustrates a name with a second surname such as a - Spanish name. Additional examples are shown in Figures 19 and 39. - - "name": { - "components": [ - { "kind": "given", "value": "Diego" }, - { "kind": "surname", "value": "Rivera" }, - { "kind": "surname2", "value": "Barrientos" } - ], - "isOrdered": true - } - - Figure 17: Example of a Second Surname - - isOrdered: Boolean (optional; default: "false"). The indicator if - the name components in the components property are ordered. - - defaultSeparator: String (optional). The default separator to insert - between name component values when concatenating all name - component values to a single String. Also see the definition of - the kind property value "separator" for the NameComponent - (Section 2.2.1.2) object. The defaultSeparator property MUST NOT - be set if the Name isOrdered property value is "false" or if the - components property is not set. - - full: String (optional). The full name representation of the Name. - The full property MUST be set if the components property is not - set. - - "full": "Mr. John Q. Public, Esq." - - Figure 18: Example for the full Property - - sortAs: String[String] (optional). The value to lexicographically - sort the name in relation to other names when compared by a name - component type. The keys in the map define the name component - type. The values define the verbatim string to compare when - sorting by the name component type. Absence of a key indicates - that the name component type SHOULD NOT be considered during sort. - Sorting by that missing name component type, or if the sortAs - property is not set, is implementation-specific. The sortAs - property MUST NOT be set if the components property is not set. - - Each key in the map MUST be a valid name component type value as - defined for the kind property of the NameComponent object (see - below). For each key in the map, there MUST exist at least one - NameComponent object that has the type in the components property - of the name. - - Figure 19 illustrates the use of the sortAs property. The - property value indicates that the middle name followed by both - surnames should be used when sorting the name by surname. The - absence of "middle" indicates that the middle name on its own - should be disregarded during sort. Even though the name only - contains one name component for the given name, the sortAs - property still explicitly defines how to sort by the given name; - otherwise, sorting by it would be undefined. - - phoneticScript: String (optional). The script used in the value of - the NameComponent phonetic property. See Section 1.5.4 for more - information and Figure 20 for an example. - - phoneticSystem: String (optional). The phonetic system used in the - NameComponent phonetic property. See Section 1.5.4 for more - information and Figure 20 for an example. - - "name": { - "components": [ - { "kind": "given", "value": "Robert" }, - { "kind": "given2", "value": "Pau" }, - { "kind": "surname", "value": "Shou Chang" } - ], - "sortAs": { - "surname": "Pau Shou Chang", - "given": "Robert" - }, - "isOrdered": true - } - - Figure 19: Example for the sortAs Property - - { - "@type": "Card", - "language": "zh-Hant", - "name": { - "components": [ - { "kind": "surname", "value": "å­«" }, - { "kind": "given", "value": "中山" }, - { "kind": "given2", "value": "æ–‡" }, - { "kind": "given2", "value": "逸仙" } - ] - }, - "localizations": { - "yue": { - "name/phoneticSystem": "jyut", - "name/phoneticScript": "Latn", - "name/components/0/phonetic": "syun1", - "name/components/1/phonetic": "zung1saan1", - "name/components/2/phonetic": "man4", - "name/components/3/phonetic": "jat6sin1" - } - } - } - - Figure 20: Example for the phonetic and localizations Properties - -2.2.1.2. NameComponent - - A NameComponent object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "NameComponent", if set. - - value: String (mandatory). The value of the name component. This - can be composed of one or multiple words such as "Poe" or "van - Gogh". - - kind: String (mandatory). The kind of the name component. The - enumerated (Section 1.7.5) values are: - - * title: an honorific title or prefix, e.g., "Mr.", "Ms.", or - "Dr.". - - * given: a given name, also known as "first name" or "personal - name". - - * given2: a name that appears between the given and surname such - as a middle name or patronymic name. - - * surname: a surname, also known as "last name" or "family name". - - * surname2: a secondary surname (used in some cultures), also - known as "maternal surname". - - * credential: a credential, also known as "accreditation - qualifier" or "honorific suffix", e.g., "B.A.", "Esq.". - - * generation: a generation marker or qualifier, e.g., "Jr." or - "III". - - * separator: a formatting separator between two ordered name non- - separator components. The value property of the component - includes the verbatim separator, for example, a hyphen - character or even an empty string. This value has higher - precedence than the defaultSeparator property of the Name. - Implementations MUST NOT insert two consecutive separator - components; instead, they SHOULD insert a single separator - component with the combined value. This component kind MUST - NOT be set if the Name isOrdered property value is "false". - - phonetic: String (optional). The pronunciation of the name - component. If this property is set, then at least one of the Name - object properties, phoneticSystem or phoneticScript, MUST be set. - Also see Section 1.5.4. - -2.2.2. nicknames - - nicknames: Id[Nickname] (optional). The nicknames of the entity - represented by the Card. - - A Nickname object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Nickname", if set. - - name: String (mandatory). The nickname. - - contexts: String[Boolean] (optional). The contexts in which to use - the nickname. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the nickname in - relation to other nicknames. Also see Section 1.5.3. - - "nicknames": { - "k391": { - "name": "Johnny" - } - } - - Figure 21: Example for the nicknames Property - -2.2.3. organizations - - organizations: Id[Organization] (optional). The company or - organization names and units associated with the Card. - - An Organization object has the following properties, of which at - least one of the name and units properties MUST be set: - - @type: String. The JSContact type of the object. The value MUST be - "Organization", if set. - - name: String (optional). The name of the organization. - - units: OrgUnit[] (optional). A list of organizational units, ordered - as descending by hierarchy (e.g., a geographic or functional - division sorts before a department within that division). If set, - the list MUST contain at least one entry. - - sortAs: String (optional). The value to lexicographically sort the - organization in relation to other organizations when compared by - name. The value defines the verbatim string value to compare. In - absence of this property, the name property value MAY be used for - comparison. - - contexts: String[Boolean] (optional). The contexts in which - association with the organization applies. For example, - membership in a choir may only apply in a private context. Also - see Section 1.5.1. - - An OrgUnit object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "OrgUnit", if set. - - name: String (mandatory). The name of the organizational unit. - - sortAs: String (optional). The value to lexicographically sort the - organizational unit in relation to other organizational units of - the same level when compared by name. The level is defined by the - array index of the organizational unit in the units property of - the Organization object. The property value defines the verbatim - string value to compare. In absence of this property, the name - property value MAY be used for comparison. - - "organizations": { - "o1": { - "name": "ABC, Inc.", - "units": [ - { "name": "North American Division" }, - { "name": "Marketing" } - ], - "sortAs": "ABC" - } - } - - Figure 22: Example for the organizations Property - -2.2.4. speakToAs - - speakToAs: SpeakToAs (optional). The information that directs how to - address, speak to, or refer to the entity that is represented by - the Card. - - A SpeakToAs object has the following properties, of which at least - one of the grammaticalGender and pronouns properties MUST be set: - - @type: String. The JSContact type of the object. The value MUST be - "SpeakToAs", if set. - - grammaticalGender: String (optional). The grammatical gender to use - in salutations and other grammatical constructs. For example, the - German language distinguishes by grammatical gender in salutations - such as "Sehr geehrte" (feminine) and "Sehr geehrter" (masculine). - The enumerated (Section 1.7.5) values are: - - * animate - * common - * feminine - * inanimate - * masculine - * neuter - - Note that the grammatical gender does not allow inferring the - gender identities or assigned sex of the contact. - - pronouns: Id[Pronouns] (optional). The pronouns that the contact - chooses to use for themselves. - - A Pronouns object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Pronouns", if set. - - pronouns: String (mandatory). The pronouns. Any value or form is - allowed. Examples in English include "she/her" and "they/them/ - theirs". The value MAY be overridden in the localizations - (Section 2.7.1) property. - - contexts: String[Boolean] (optional). The contexts in which to use - the pronouns. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the pronouns in - relation to other pronouns in the same context. Also see - Section 1.5.3. - - "speakToAs": { - "grammaticalGender": "neuter", - "pronouns": { - "k19": { - "pronouns": "they/them", - "pref": 2 - }, - "k32": { - "pronouns": "xe/xir", - "pref": 1 - } - } - } - - Figure 23: Example for the speakToAs Property - -2.2.5. titles - - titles: Id[Title] (optional). The job titles or functional positions - of the entity represented by the Card. - - A Title object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Title", if set. - - name: String (mandatory). The title or role name of the entity - represented by the Card. - - kind: String (optional; default: "title"). The organizational or - situational kind of the title. Some organizations and individuals - distinguish between _titles_ as organizational positions and - _roles_ as more temporary assignments such as in project - management. - - The enumerated (Section 1.7.5) values are: - - * title - * role - - organizationId: Id (optional). The identifier of the organization in - which this title is held. - - "titles": { - "le9": { - "kind": "title", - "name": "Research Scientist" - }, - "k2": { - "kind": "role", - "name": "Project Leader", - "organizationId": "o2" - } - }, - "organizations": { - "o2": { - "name": "ABC, Inc." - } - } - - Figure 24: Example for the titles Property - -2.3. Contact Properties - - This section defines how properties contact the entity represented by - the Card. - -2.3.1. emails - - emails: Id[EmailAddress] (optional). The email addresses in which to - contact the entity represented by the Card. - - An EmailAddress object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "EmailAddress", if set. - - address: String (mandatory). The email address. This MUST be an - _addr-spec_ value as defined in Section 3.4.1 of [RFC5322]. - - contexts: String[Boolean] (optional). The contexts in which to use - this email address. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the email address in - relation to other email addresses. Also see Section 1.5.3. - - label: String (optional). A custom label for the value. Also see - Section 1.5.2. - - "emails": { - "e1": { - "contexts": { - "work": true - }, - "address": "jqpublic@xyz.example.com" - }, - "e2": { - "address": "jane_doe@example.com", - "pref": 1 - } - } - - Figure 25: Example for the emails Property - -2.3.2. onlineServices - - onlineServices: Id[OnlineService] (optional). The online services - that are associated with the entity represented by the Card. This - can be messaging services, social media profiles, and other. - - An OnlineService object has the following properties, of which at - least the uri or user property MUST be set: - - @type: String. The JSContact type of the object. The value MUST be - "OnlineService", if set. - - service: String (optional). The name of the online service or - protocol. The name MAY be capitalized the same as on the - service's website, app, or publishing material, but names MUST be - considered equal if they match case-insensitively. Examples are - "GitHub", "kakao", and "Mastodon". - - uri: String (optional). The identifier for the entity represented by - the Card at the online service. This MUST be a _URI_ as defined - in Section 3 of [RFC3986]. - - user: String (optional). The name the entity represented by the Card - at the online service. Any free-text value is allowed. The - service property SHOULD be set. - - contexts: String[Boolean] (optional). The contexts in which to use - the service. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the service in - relation to other services. Also see Section 1.5.3. - - label: String (optional). A custom label for the value. Also see - Section 1.5.2. - - "onlineServices": { - "x1": { - "uri": "xmpp:alice@example.com" - }, - "x2": { - "service": "Mastodon", - "user": "@alice@example2.com", - "uri": "https://example2.com/@alice" - } - } - - Figure 26: Example for the onlineServices Property - -2.3.3. phones - - phones: Id[Phone] (optional). The phone numbers by which to contact - the entity represented by the Card. - - Phone object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Phone", if set. - - number: String (mandatory). The phone number as either a URI or free - text. Typical URI schemes are "tel" [RFC3966] or "sip" [RFC3261], - but any URI scheme is allowed. - - features: String[Boolean] (optional). The set of contact features - that the phone number may be used for. The set is represented as - an object, with each key being a method type. The boolean value - MUST be "true". The enumerated (Section 1.7.5) method type values - are: - - * mobile: this number is for a mobile phone. - * voice: this number supports calling by voice. - * text: this number supports text messages (SMS). - * video: this number supports video conferencing. - * main-number: this number is a main phone number such as the - number of the front desk at a company, as opposed to a direct- - dial number of an individual employee. - * textphone: this number is for a device for people with hearing - or speech difficulties. - * fax: this number supports sending faxes. - * pager: this number is for a pager or beeper. - - contexts: String[Boolean] (optional). The contexts in which to use - the number. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the number in - relation to other numbers. Also see Section 1.5.3. - - label: String (optional). A custom label for the value. Also see - Section 1.5.2. - - "phones": { - "tel0": { - "contexts": { - "private": true - }, - "features": { - "voice": true - }, - "number": "tel:+1-555-555-5555;ext=5555", - "pref": 1 - }, - "tel3": { - "contexts": { - "work": true - }, - "number": "tel:+1-201-555-0123" - } - } - - Figure 27: Example for the phones Property - -2.3.4. preferredLanguages - - preferredLanguages : Id[LanguagePref] (optional). The preferred - languages for contacting the entity associated with the Card. - - A LanguagePref object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "LanguagePref", if set. - - language: String (mandatory). The preferred language. This MUST be - a language tag as defined in [RFC5646] . - - contexts: String[Boolean] (optional). The contexts in which to use - the language. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the language in - relation to other languages of the same contexts. Also see - Section 1.5.3. - - "preferredLanguages": { - "l1": { - "language": "en", - "contexts": { - "work": true - }, - "pref": 1 - }, - "l2": { - "language": "fr", - "contexts": { - "work": true - }, - "pref": 2 - }, - "l3": { - "language": "fr", - "contexts": { - "private": true - } - } - } - - Figure 28: Example for the preferredLanguages Property - -2.4. Calendaring and Scheduling Properties - - This section defines properties for scheduling calendar events with - the entity represented by the Card. - -2.4.1. calendars - - calendars: Id[Calendar] (optional). The calendaring resources of the - entity represented by the Card, such as to look up free-busy - information. - - A Calendar object has all properties of the Resource (Section 1.4.4) - data type, with the following additional definitions: - - * The @type property value MUST be "Calendar", if set. - - * The kind property is mandatory. Its enumerated (Section 1.7.5) - values are: - - - calendar: The resource is a calendar that contains entries such - as calendar events or tasks. - - - freeBusy: The resource allows for free-busy lookups, for - example, to schedule group events. - - "calendars": { - "calA": { - "kind": "calendar", - "uri": "webcal://calendar.example.com/calA.ics" - }, - "project-a": { - "kind": "freeBusy", - "uri": "https://calendar.example.com/busy/project-a" - } - } - - Figure 29: Example for the calendars Property - -2.4.2. schedulingAddresses - - schedulingAddresses: Id[SchedulingAddress] (optional). The - scheduling addresses by which the entity may receive calendar - scheduling invitations. - - A SchedulingAddress object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "SchedulingAddress", if set. - - uri: String (mandatory). The address to use for calendar scheduling - with the contact. This MUST be a URI as defined in Section 3 of - [RFC3986]. - - contexts: String[Boolean] (optional). The contexts in which to use - the scheduling address. Also see Section 1.5.1. - - pref: UnsignedInt (optional). The preference of the scheduling - address in relation to other scheduling addresses. Also see - Section 1.5.3. - - label: String (optional). A custom label for the scheduling address. - Also see Section 1.5.2. - - "schedulingAddresses": { - "sched1": { - "uri": "mailto:janedoe@example.com" - } - } - - Figure 30: Example for the schedulingAddresses Property - -2.5. Address and Location Properties - - This section defines properties for postal addresses and geographical - locations associated with the entity represented by the Card. - -2.5.1. addresses - - addresses: Id[Address] (optional). The addresses of the entity - represented by the Card, such as postal addresses or geographic - locations. - -2.5.1.1. Address Object - - An Address object has the following properties, of which at least one - of components, coordinates, countryCode, full or timeZone MUST be - set: - - @type: String. The JSContact type of the object. The value MUST be - "Address", if set. - - components: AddressComponent[] (optional). The components - (Section 2.5.1.2) that make up the address. The component list - MUST have at least one entry that has a kind property value other - than "separator". - - Address components SHOULD be ordered such that when their values - are joined as a String, a valid full address is produced. If so, - implementations MUST set the isOrdered property value to "true". - - If the address components are ordered, then the defaultSeparator - property and address components with the kind property value set - to "separator" give guidance on what characters to insert between - components, but implementations are free to choose any others. - When lacking a separator, inserting a single space character in - between address component values is a good choice. - - If, instead, the address components follow no particular order, - then the isOrdered property value MUST be "false", the components - property MUST NOT contain an AddressComponent with the kind - property value set to "separator", and the defaultSeparator - property MUST NOT be set. - - isOrdered: Boolean (optional; default: "false"). The indicator if - the address components in the components property are ordered. - - countryCode: String (optional). The Alpha-2 country code - [ISO.3166-1]. - - coordinates: String (optional). A "geo:" URI [RFC5870] for the - address. - - timeZone: String (optional). The time zone in which the address is - located. This MUST be a time zone name registered in the IANA - Time Zone Database [IANA-TZ]. - - contexts: String[Boolean] (optional). The contexts in which to use - this address. The boolean value MUST be "true". In addition to - the common contexts (Section 1.5.1), allowed key values are: - - * billing: an address to be used for billing. - * delivery: an address to be used for delivering physical items. - - full: String (optional). The full address, including street, region, - or country. The purpose of this property is to define an address, - even if the individual address components are not known. - - defaultSeparator: String (optional). The default separator to insert - between address component values when concatenating all address - component values to a single String. Also see the definition of - the kind property value "separator" for the AddressComponent - (Section 2.5.1.2) object. The defaultSeparator property MUST NOT - be set if the Address isOrdered property value is "false" or if - the components property is not set. - - pref: UnsignedInt (optional). The preference of the address in - relation to other addresses. Also see Section 1.5.3. - - phoneticScript: String (optional). The script used in the value of - the AddressComponent phonetic property. Also see Section 1.5.4. - - phoneticSystem: String (optional). The phonetic system used in the - AddressComponent phonetic property. Also see Section 1.5.4. - - The following example illustrates the use of the address property for - "54321 Oak St, Reston, CA 20190, USA". Additional examples are shown - in Section 2.5.1.3. - - "addresses": { - "k23": { - "contexts": { - "work": true - }, - "components": [ - { "kind": "number", "value": "54321" }, - { "kind": "separator", "value": " " }, - { "kind": "name", "value": "Oak St" }, - { "kind": "locality", "value": "Reston" }, - { "kind": "region", "value": "VA" }, - { "kind": "separator", "value": " " }, - { "kind": "postcode", "value": "20190" }, - { "kind": "country", "value": "USA" } - ], - "countryCode": "US", - "defaultSeparator": ", ", - "isOrdered": true - } - } - - Figure 31: Example of an Address in the USA - -2.5.1.2. AddressComponent Object - - An AddressComponent object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "AddressComponent", if set. - - value: String (mandatory). The value of the address component. - - kind: String (mandatory). The kind of the address component. The - enumerated (Section 1.7.5) values are: - - * room: the room, suite number, or identifier. - * apartment: the extension designation such as the apartment - number, unit, or box number. - * floor: the floor or level the address is located on. - * building: the building, tower, or condominium the address is - located in. - * number: the street number, e.g., "123". This value is not - restricted to numeric values and can include any value such as - number ranges ("112-10"), grid style ("39.2 RD"), alphanumerics - ("N6W23001"), or fractionals ("123 1/2"). - * name: the street name. - * block: the block name or number. - * subdistrict: the subdistrict, ward, or other subunit of a - district. - * district: the district name. - * locality: the municipality, city, town, village, post town, or - other locality. - * region: the administrative area such as province, state, - prefecture, county, or canton. - * postcode: the postal code, post code, ZIP code, or other short - code associated with the address by the relevant country's - postal system. - * country: the country name. - * direction: the cardinal direction or quadrant, e.g., "north". - * landmark: the publicly known prominent feature that can - substitute the street name and number, e.g., "White House" or - "Taj Mahal". - * postOfficeBox: the post office box number or identifier. - * separator: a formatting separator between two ordered address - non-separator components. The value property of the component - includes the verbatim separator, for example, a hyphen - character or even an empty string. This value has higher - precedence than the defaultSeparator property of the Address. - Implementations MUST NOT insert two consecutive separator - components; instead, they SHOULD insert a single separator - component with the combined value. This component kind MUST - NOT be set if the Address isOrdered property value is "false". - - phonetic: String (optional). The pronunciation of the name - component. If this property is set, then at least one of the - Address object phoneticSystem or phoneticScript properties MUST be - set. Also see Section 1.5.4. - -2.5.1.3. Additional Address Examples - - The following example illustrates the use of the address property for - "46, 1 Sukhumvit 51 Alley, Khlong Tan Nuea, Watthana, Bangkok 10110, - Thailand". - - "addresses": { - "k25": { - "components": [ - { "kind": "number", "value": "46" }, - { "kind": "name", "value": "1 Sukhumvit 51 Alley" }, - { "kind": "subdistrict", "value": "Khlong Tan Nuea" }, - { "kind": "district", "value": " Watthana" }, - { "kind": "locality", "value": "Bangkok" }, - { "kind": "country", "value": "Thailand" }, - { "kind": "postcode", "value": "10110" } - ], - "defaultSeparator": ", ", - "isOrdered": true - } - } - - Figure 32: Example of an Address in Thailand - - The following example illustrates the use of the address property for - "2-7-2 Marunouchi, Chiyoda-ku, Tokyo 100-8994" and its Japanese - localization (Section 2.7.1). - - "addresses": { - "k26": { - "components": [ - { "kind": "block", "value": "2-7" }, - { "kind": "separator", "value": "-" }, - { "kind": "number", "value": "2" }, - { "kind": "separator", "value": " " }, - { "kind": "district", "value": "Marunouchi" }, - { "kind": "locality", "value": "Chiyoda-ku" }, - { "kind": "region", "value": "Tokyo" }, - { "kind": "separator", "value": " " }, - { "kind": "postcode", "value": "100-8994" } - ], - "defaultSeparator": ", ", - "full": "2-7-2 Marunouchi, Chiyoda-ku, Tokyo 100-8994", - "isOrdered": true - } - }, - "localizations": { - "jp": { - "addresses/k26": { - "components": [ - { "kind": "region", "value": "æ±äº¬éƒ½" }, - { "kind": "locality", "value": "åƒä»£ç”°åŒº" }, - { "kind": "district", "value": "丸ノ内" }, - { "kind": "block", "value": "2-7" }, - { "kind": "separator", "value": "-" }, - { "kind": "number", "value": "2" }, - { "kind": "postcode", "value": "〒100-8994" } - ], - "defaultSeparator": "", - "full": "〒100-8994æ±äº¬éƒ½åƒä»£ç”°åŒºä¸¸ãƒŽå†…2-7-2", - "isOrdered": true - } - } - } - - Figure 33: Example of an Address in Tokyo and Its Localization in - Japanese - -2.6. Resource Properties - - This section defines properties for digital resources associated with - the entity represented by the Card. - -2.6.1. cryptoKeys - - cryptoKeys: Id[CryptoKey] (optional). The cryptographic resources - such as public keys and certificates associated with the entity - represented by the Card. - - A CryptoKey object has all properties of the Resource (Section 1.4.4) - data type, with the following additional definition: - - * The @type property value MUST be "CryptoKey", if set. - - The following example shows how to refer to an external cryptographic - resource. - - "cryptoKeys": { - "mykey1": { - "uri": "https://www.example.com/keys/jdoe.cer" - } - } - - Figure 34: Example of cryptoKeys with External Data - - The following example shows how to embed key data in the CryptoKey. - The key data is depicted in multiple lines only for demonstration - purposes. - - "cryptoKeys": { - "mykey2": { - "uri": "data:application/pgp-keys;base64,LS0tLS1CRUdJTiBSU0EgUFVC - TElDIEtFWS0tLS0tCk1JSUJDZ0tDQVFFQSt4R1ovd2N6OXVnRnBQMDdOc - 3BvNlUxN2wwWWhGaUZweHhVNHBUazNMaWZ6OVIzenNJc3UKRVJ3dGE3K2 - ZXSWZ4T28yMDhldHQvamhza2lWb2RTRXQzUUJHaDRYQmlweVdvcEt3Wjk - zSEhhRFZaQUFMaS8yQQoreFRCdFdkRW83WEdVdWpLRHZDMi9hWkt1a2Zq - cE9pVUk4QWhMQWZqbWxjRC9VWjFRUGgwbUhzZ2xSTkNtcEN3Cm13U1hBO - VZObWh6K1BpQitEbWw0V1duS1cvVkhvMnVqVFh4cTcrZWZNVTRIMmZueT - NTZTNLWU9zRlBGR1oxVE4KUVNZbEZ1U2hXckhQdGlMbVVkUG9QNkNWMm1 - NTDF0aytsN0RJSXFYclFoTFVLREFDZU01cm9NeDBrTGhVV0I4UAorMHVq - MUNObE5ONEpSWmxDN3hGZnFpTWJGUlU5WjRONll3SURBUUFCCi0tLS0tR - U5EIFJTQSBQVUJMSUMgS0VZLS0tLS0K" - } - } - - Figure 35: Example of cryptoKeys with Embedded Data - -2.6.2. directories - - directories: Id[Directory] (optional). The directories containing - information about the entity represented by the Card. - - A Directory object has all properties of the Resource (Section 1.4.4) - data type, with the following additional definitions: - - * The @type property value MUST be "Directory", if set. - - * The kind property is mandatory. Its enumerated (Section 1.7.5) - values are: - - - directory: the resource is a directory service that the entity - represented by the Card is a part of. This typically is an - organizational directory that also contains associated - entities, e.g., co-workers and management in a company - directory. - - - entry: the resource is a directory entry of the entity - represented by the Card. In contrast to the "directory" type, - this is the specific URI for the entity _within_ a directory. - - In addition, the Directory object has the following property: - - listAs: UnsignedInt (optional). The position of the directory - resource in the list of all Directory objects having the same kind - property value in the Card. If set, the listAs value MUST be - higher than zero. Multiple directory resources MAY have the same - listAs property value or none. Sorting such same-valued entries - is implementation-specific. - - "directories": { - "dir1": { - "kind": "entry", - "uri": "https://dir.example.com/addrbook/jdoe/Jean%20Dupont.vcf" - }, - "dir2": { - "kind": "directory", - "uri": "ldap://ldap.example/o=Example%20Tech,ou=Engineering", - "pref": 1 - } - - Figure 36: Example for the directories Property - -2.6.3. links - - links: Id[Link] (optional). The links to resources that do not fit - any of the other use-case-specific resource properties. - - A Link object has all properties of the Resource (Section 1.4.4) data - type, with the following additional definitions: - - * The @type property value MUST be "Link", if set. - - * The kind property is optional. Its enumerated (Section 1.7.5) - values are: - - - contact: the resource is a URI by which the entity represented - by the Card may be contacted; this includes web forms or other - media that require user interaction. - - "links": { - "link3": { - "kind": "contact", - "uri": "mailto:contact@example.com", - "pref": 1 - } - } - - Figure 37: Example for the links Property - -2.6.4. media - - media: Id[Media] (optional). The media resources such as - photographs, avatars, or sounds that are associated with the - entity represented by the Card. - - A Media object has all properties of the Resource (Section 1.4.4) - data type, with the following additional definitions: - - * The @type property value MUST be "Media", if set. - - * The kind property is mandatory. Its enumerated (Section 1.7.5) - values are: - - - photo: the resource is a photograph or avatar. - - - sound: the resource is audio media, e.g., to specify the proper - pronunciation of the name property contents. - - - logo: the resource is a graphic image or logo associated with - the entity represented by the Card. - - "media": { - "res45": { - "kind": "sound", - "uri": "CID:JOHNQ.part8.19960229T080000.xyzMail@example.com" - }, - "res47": { - "kind": "logo", - "uri": "https://www.example.com/pub/logos/abccorp.jpg" - }, - "res1": { - "kind": "photo", - "uri": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAASABIAAD/4..." - } - } - - Figure 38: Example for the media Property - -2.7. Multilingual Properties - - This section defines properties for localizing the content of the - Card in human languages. - -2.7.1. localizations - - localizations: String[PatchObject] (optional). The property values - localized to languages other than the main language - (Section 2.1.5) of the Card. Localizations provide language- - specific alternatives for existing property values and SHOULD NOT - add new properties. The keys in the localizations property value - are language tags [RFC5646]; the values are of type PatchObject - and localize the Card in that language tag. The paths in the - PatchObject are relative to the Card that includes the - localizations property. A patch MUST NOT target the localizations - property. - - Conceptually, a Card is localized as follows: - - * Determine the language tag in which the Card should be localized. - - * If the localizations property includes a key for that language, - obtain the PatchObject value. If there is no such key, stop. - - * Create a copy of the Card, but do not copy the localizations - property. - - * Apply all patches in the PatchObject to the copy of the Card. - - * Optionally, set the language property in the copy of the Card. - - * Use the patched copy of the Card as the localized variant of the - original Card. - - A patch in the PatchObject may contain any value type. Its value - MUST be a valid value according to the definition of the patched - property. - - Figure 39 localizes the name property by completely replacing its - contents in Ukrainian language with Cyrillic script. - - { - "name": { - "components": [ - { "kind": "title", "value": "Mr." }, - { "kind": "given", "value": "Ivan" }, - { "kind": "given2", "value": "Petrovich" }, - { "kind": "surname", "value": "Vasiliev" } - ] - }, - "localizations": { - "uk-Cyrl": { - "name": { - "components": [ - { "kind": "title", "value": "г-н" }, - { "kind": "given", "value": "Иван" }, - { "kind": "given2", "value": "Петрович" }, - { "kind": "surname", "value": "ВаÑильев" } - ] - } - } - } - } - - Figure 39: Example of Localizing a Top-Level Property - - Figure 40 localizes the title name by patching _inside_ the titles - property. All properties, except the name property in the Title - object, are left as is. - - "name": { - "full": "Gabriel García Márquez" - }, - "titles": { - "t1": { - "kind": "title", - "name": "novelist" - } - }, - "localizations": { - "es": { - "titles/t1/name": "escritor" - } - } - - Figure 40: Example of Localizing a Nested Property - -2.8. Additional Properties - - This section defines properties for which none of the previous - sections are appropriate. - -2.8.1. anniversaries - - anniversaries: Id[Anniversary] (optional). The memorable dates and - events for the entity represented by the Card. - - An Anniversary object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Anniversary", if set. - - kind: String (mandatory). The kind of anniversary. The enumerated - (Section 1.7.5) values are: - - * birth: a birthday anniversary - * death: a deathday anniversary - * wedding: a wedding day anniversary - - date: PartialDate|Timestamp (mandatory; defaultType: PartialDate). T - he date of the anniversary in the Gregorian calendar. This MUST - be either a whole or partial calendar date or a complete UTC - timestamp (see the definition of the Timestamp and PartialDate - object types below). - - place: Address (optional). An address associated with this - anniversary, e.g., the place of birth or death. - - A PartialDate object represents a complete or partial calendar date - in the Gregorian calendar. It represents a complete date, a year, a - month in a year, or a day in a month. It has the following - properties: - - @type: String. The JSContact type of the object. The value MUST be - "PartialDate", if set. - - year: UnsignedInt (optional). The calendar year. - - month: UnsignedInt (optional). The calendar month, represented as - the integers 1 <= month <= 12. If this property is set, then - either the year or the day property MUST be set. - - day: UnsignedInt (optional). The calendar month day, represented as - the integers 1 <= day <= 31, depending on the validity within the - month and year. If this property is set, then the month property - MUST be set. - - calendarScale: String (optional). The calendar system in which this - date occurs, in lowercase. This MUST be either a calendar system - name registered as a Common Locale Data Repository (CLDR) - [RFC7529] or a vendor-specific value. The year, month, and day - still MUST be represented in the Gregorian calendar. Note that - the year property might be required to convert the date between - the Gregorian calendar and the respective calendar system. - - A Timestamp object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Timestamp", if set. - - utc: UTCDateTime (mandatory). The point in time in UTC time. - - Figure 41 illustrates anniversaries with partial dates and a - timestamp. Note how the @type property is set for the Timestamp - object value according to the rules defined in Section 1.3.4. - - "anniversaries": { - "k8": { - "kind": "birth", - "date": { - "year": 1953, - "month": 4, - "day": 15 - } - }, - "k9": { - "kind": "death", - "date": { - "@type": "Timestamp", - "utc": "2019-10-15T23:10:00Z" - }, - "place": { - "full": "4445 Tree Street\nNew England, ND 58647\nUSA" - } - } - } - - Figure 41: Example for the anniversaries Property - -2.8.2. keywords - - keywords: String[Boolean] (optional). The set of free-text keywords, - also known as _tags_. Each key in the set is a keyword, and each - boolean value MUST be "true". - - "keywords": { - "internet": true, - "IETF": true - } - - Figure 42: Example for the keywords Property - -2.8.3. notes - - notes: Id[Note] (optional). The free-text notes that are associated - with the Card. - - A Note object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "Note", if set. - - note: String (mandatory). The free-text value of this note. - - created: UTCDateTime (optional). The date and time when this note - was created. - - author: Author (optional). The author of this note. - - An Author object has the following properties, of which at least one - property other than @type MUST be set: - - @type: String. The JSContact type of the object. The value MUST be - "Author", if set. - - name: String (optional). The name of this author. - - uri: String (optional). The URI value that identifies the author. - - "notes": { - "n1": { - "note": "Open office hours are 1600 to 1715 EST, Mon-Fri", - "created": "2022-11-23T15:01:32Z", - "author": { - "name": "John" - } - } - } - - Figure 43: Example for the notes Property - -2.8.4. personalInfo - - personalInfo: Id[PersonalInfo] (optional). The personal information - of the entity represented by the Card. - - A PersonalInfo object has the following properties: - - @type: String. The JSContact type of the object. The value MUST be - "PersonalInfo", if set. - - kind: String (mandatory). The kind of personal information. The - enumerated (Section 1.7.5) values are: - - * expertise: a field of expertise or a credential - - * hobby: a hobby - - * interest: an interest - - value: String (mandatory). The actual information. - - level: String (optional). The level of expertise or engagement in - hobby or interest. The enumerated (Section 1.7.5) values are: - - * high - - * medium - - * low - - listAs: UnsignedInt (optional). The position of the personal - information in the list of all PersonalInfo objects that have the - same kind property value in the Card. If set, the listAs value - MUST be higher than zero. Multiple personal information entries - MAY have the same listAs property value or none. Sorting such - same-valued entries is implementation-specific. - - label: String (optional). A custom label. See Section 1.5.2. - - "personalInfo": { - "pi2": { - "kind": "expertise", - "value": "chemistry", - "level": "high" - }, - "pi1": { - "kind": "hobby", - "value": "reading", - "level": "high" - }, - "pi6": { - "kind": "interest", - "value": "r&b music", - "level": "medium" - } - } - - Figure 44: Example for the personalInfo Property - -3. IANA Considerations - -3.1. Media Type Registration - - This document defines a media type for use with JSContact data - formatted in JSON. - - Type name: application - - Subtype name: jscontact+json - - Required parameters: None - - Optional parameters: version - - This parameter conveys the version of the JSContact data in the - body part. It MUST NOT occur more than once. If this parameter - is set, then the values of all JSContact version (Table 2) - properties in the body part MUST match the parameter value. - - Encoding considerations: This is the same as the encoding - considerations of application/json, as specified in Section 11 of - [RFC8259]. - - Security considerations: See Section 4 of RFC 9553. - - Interoperability considerations: While JSContact is designed to - avoid ambiguities as much as possible, when converting objects - from other contact formats to/from JSContact, it is possible that - differing representations for the same logical data or ambiguities - in interpretation might arise. The semantic equivalence of two - JSContact objects may be determined differently by different - applications, for example, where URL values differ in case between - the two objects. - - Published specification: RFC 9553 - - Applications that use this media type: Applications that currently - make use of the text/vcard media type can use this as an - alternative. - - Fragment identifier considerations: A JSON Pointer fragment - identifier may be used, as defined in [RFC6901], Section 6. - - Additional information: - - Magic number(s): N/A - File extensions(s): N/A - Macintosh file type code(s): N/A - - Person & email address to contact for further information: - calsify@ietf.org - - Intended usage: COMMON - - Restrictions on usage: N/A - - Author: See the "Authors' Addresses" section of RFC 9553. - - Change controller: IETF - -3.2. Creation of the JSContact Registry Group - - IANA has created the "JSContact" registry group. The new registry - definitions in the following sections all belong to that group. - -3.3. Registry Policy and Change Procedures - - Registry assignments that introduce backwards-incompatible - (Section 1.9) changes require the JSContact major version to change; - other changes only require a change to the minor version. The - registry policy for assignments that require the JSContact major - version to change is Standards Action ([RFC8126], Section 4.9). The - registry policy for other assignments is Specification Required - ([RFC8126], Section 4.6). - - The designated expert (DE) decides if a major or minor version change - is required and assigns the new version to the "JSContact Version" - registry (Section 3.4). Version numbers increment by one, and a - major version change resets the minor version to zero. An assignment - may apply multiple changes and to more than one registry at once, in - which case a single version change is sufficient. If the registry - policy is Specification Required, then the DE may decide that it is - enough to document the new assignment in the Description item of the - respective registry. - - A registration MUST have an intended usage of "common", "reserved", - or "obsolete". - - * A "common" usage denotes an item with shared semantics and syntax - across systems. Up-to-date systems MUST expect such items to - occur in JSContact data. - - * A "reserved" usage reserves an item in the registry without - assigning semantics to avoid name collisions with future - extensions or protocol use. Implementations MUST NOT expect or - add items with such names outside the protocols or extensions that - use them; otherwise, any such JSContact data is invalid. - - * An "obsolete" usage denotes an item that is no longer expected to - be added by up-to-date systems. A new assignment has probably - been defined, covering the obsolete item's semantics. - Implementations MUST expect such items to occur in JSContact data - up to the "Until Version" registry field, inclusively. They MUST - NOT add such items for any version after which the item was - obsoleted; otherwise, any such JSContact data is invalid. - - The intended usage of registry items may change between versions, but - the DE must carefully consider the impact on existing implementations - and standards before doing so. - - The registration procedure is not a formal standards process but - rather an administrative procedure intended to allow community - comments and to check whether it is coherent without excessive time - delay. It is designed to encourage vendors to document and register - new items they add for use cases not covered by the original - specification, leading to increased interoperability. - -3.3.1. Preliminary Community Review - - Notice of a potential new registration MUST be sent to the Calext WG - mailing list for review. This mailing list is - appropriate for soliciting community feedback on a proposed registry - assignment. - - The intent of the public posting to this list is to solicit comments - and feedback on the choice of the item name or value, the unambiguity - of its description, and a review of any interoperability or security - considerations. The submitter may submit a revised registration - proposal or abandon the registration completely at any time. - -3.3.2. Submit Request to IANA - - Registration requests can be sent to IANA . - -3.3.3. Designated Expert Review - - The primary concern of the DE is preventing name collisions and - encouraging the submitter to document security and privacy - considerations. - - A new type name, property name, or enumerated value MUST NOT differ - only in case from an already-registered name or value. - - For a common-use registration, the DE is expected to confirm that - suitable documentation is available to ensure interoperability. The - DE should also verify that the new assignment does not conflict with - work that is active or already published within the IETF. - - The DE will either approve or deny the registration request and - publish a notice of the decision to the Calext WG mailing list or its - successor, as well as inform IANA. A denial notice must be justified - by an explanation, and in the cases where it is possible, concrete - suggestions on how the request can be modified to become acceptable - should be provided. - -3.3.4. Change Procedures - - Once a JSContact registry group item has been published by IANA, the - Change Controller may request a change to its definition. The same - procedure that would be appropriate for the original registration - request is used to process a change request. - - JSContact registrations do not get deleted; instead, items that are - no longer believed appropriate for use are declared obsolete by a - change to their "Intended Usage" field; such items will be clearly - marked in the IANA registry. - - Significant changes to a JSContact registry item's definition should - be requested only when there are serious omissions or errors in the - published specification, as such changes may cause interoperability - issues. When review is required, a change request may be denied if - it renders entities that were valid under the previous definition - invalid under the new definition. - -3.4. Creation of the JSContact Version Registry - - IANA has created the "JSContact Version" registry. The purpose of - this new registry is to define the allowed value range of JSContact - major and minor version numbers. - - The registry entries sort numerically in ascending order by the - "Major Version" column, and entries with equal "Major Version" sort - numerically in ascending order by the "Minor Version" column. - - The registry process is outlined in Section 3.3. - -3.4.1. JSContact Version Registry Template - - Major Version: The numeric value of a JSContact major version - number. It MUST be a positive integer. - - Highest Minor Version: The maximum numeric value of a JSContact - minor version for the given major version. It MUST be zero or a - positive integer. All numbers less than or equal to this value - are valid minor version values for the given major version. - -3.4.2. Initial Contents of the JSContact Version Registry - - The following table lists the initial valid major and minor version - number ranges. - - +===============+=======================+===========+ - | Major Version | Highest Minor Version | Reference | - +===============+=======================+===========+ - | 1 | 0 | RFC 9553 | - +---------------+-----------------------+-----------+ - - Table 1: JSContact Version Registry - -3.5. Creation of the JSContact Properties Registry - - IANA has created the "JSContact Properties" registry. The purpose of - this new registry is to allow interoperability of extensions to - JSContact objects. - - The registry entries sort alphabetically in ascending order by the - following columns: "Property Name" first, "Property Context" second, - and "Since Version" third. Equal entries sort in any order. - - The registry process for a new property is outlined in Section 3.3. - -3.5.1. JSContact Properties Registry Template - - Property Name: The name of the property. The property name MUST NOT - already be registered for any of the object types listed in the - "Property Context" field of this registration. Other object types - MAY have already registered a different property with the same - name; however, the same name MUST only be used when the semantics - are analogous. - - Property Type: For properties with intended usage other than - "reserved", this is the type of this property, using type - signatures as specified in Section 1.3.2. The property type MUST - be registered in the "JSContact Types" registry. For reserved - property names, the value MUST be the verbatim string "not - applicable". - - Property Context: A comma-separated list of JSContact object types - (Section 3.6.2) that contain the property. For reserved property - names, the value MAY be the verbatim string "not applicable". - - Intended Usage: May be "common", "reserved", or "obsolete". - - Since Version: The JSContact version on which the property - definition is based. The version MUST be one of the allowed - values of the version property in the "JSContact Version" registry - (see Table 1). - - Until Version: The JSContact version after which the property was - obsoleted; therefore, it MUST NOT be used in later versions. The - Until Version value either MUST NOT be set or MUST be one of the - allowed values of the version property in the "JSContact Version" - registry (see Table 1). - - Change Controller: Person or entity responsible for requesting a - change to the entry's definition ("IETF" for RFCs from the IETF - stream). - - Reference or Description: A brief description or RFC number and - section reference where the property is specified. This must - include references to all RFC documents where this property is - introduced or updated. For reserved property names, the reference - or description MAY be omitted. - -3.5.2. Initial Contents of the JSContact Properties Registry - - The following table lists the initial "common" usage entries of the - "JSContact Properties" registry. For all properties, the Since - Version is "1.0", the Until Version is not set, the Change Controller - is "IETF", and RFC section references are for RFC 9553. - - +=====================+=======================+====================+ - | Property Name | Property Type | Property Context | - +=====================+=======================+====================+ - | @type | String | Address | - | | | (Section 2.5.1.1), | - | | | AddressComponent | - | | | (Section 2.5.1.2), | - | | | Anniversary | - | | | (Section 2.8.1), | - | | | Author | - | | | (Section 2.8.3), | - | | | Card | - | | | (Section 2.1.1), | - | | | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | EmailAddress | - | | | (Section 2.3.1), | - | | | LanguagePref | - | | | (Section 2.3.4), | - | | | Link | - | | | Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | Name | - | | | (Section 2.2.1.1), | - | | | NameComponent | - | | | (Section 2.2.1.2), | - | | | Nickname | - | | | (Section 2.2.2), | - | | | Note | - | | | (Section 2.8.3), | - | | | OnlineService | - | | | (Section 2.3.2), | - | | | Organization | - | | | (Section 2.2.3), | - | | | OrgUnit | - | | | (Section 2.2.3), | - | | | PartialDate | - | | | (Section 2.8.1), | - | | | PersonalInfo | - | | | (Section 2.8.4), | - | | | Phone | - | | | (Section 2.3.3), | - | | | Pronouns | - | | | (Section 2.2.4), | - | | | Relation | - | | | (Section 2.1.8), | - | | | SchedulingAddress | - | | | (Section 2.4.2), | - | | | SpeakToAs | - | | | (Section 2.2.4), | - | | | Timestamp | - | | | (Section 2.8.1), | - | | | Title | - | | | (Section 2.2.5) | - +---------------------+-----------------------+--------------------+ - | address | String | EmailAddress | - | | | (Section 2.3.1) | - +---------------------+-----------------------+--------------------+ - | addresses | Id[Address] | Card | - | | | (Section 2.5.1.1) | - +---------------------+-----------------------+--------------------+ - | anniversaries | Id[Anniversary] | Card | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | author | Author | Note | - | | | (Section 2.8.3) | - +---------------------+-----------------------+--------------------+ - | calendars | Id[Calendar] | Card | - | | | (Section 2.4.1) | - +---------------------+-----------------------+--------------------+ - | calendarScale | String | PartialDate | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | components | AddressComponent[] | Address | - | | | (Section 2.5.1.1) | - +---------------------+-----------------------+--------------------+ - | components | NameComponent[] | Name | - | | | (Section 2.2.1.2) | - +---------------------+-----------------------+--------------------+ - | contexts | String[Boolean] | Address | - | | | (Section 2.5.1.1), | - | | | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | EmailAddress | - | | | (Section 2.3.1), | - | | | LanguagePref | - | | | (Section 2.3.4), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | Nickname | - | | | (Section 2.2.2), | - | | | OnlineService | - | | | (Section 2.3.2), | - | | | Organization | - | | | (Section 2.2.3), | - | | | Phone | - | | | (Section 2.3.3), | - | | | Pronouns | - | | | (Section 2.2.4), | - | | | SchedulingAddress | - | | | (Section 2.4.2). | - | | | Also see Sections | - | | | 1.4.4 and 1.5.1. | - +---------------------+-----------------------+--------------------+ - | coordinates | String | Address | - | | | (Section 2.5.1.1) | - +---------------------+-----------------------+--------------------+ - | countryCode | String | Address | - | | | (Section 2.5.1.1) | - +---------------------+-----------------------+--------------------+ - | created | UTCDateTime | Card | - | | | (Section 2.1.3), | - | | | Note | - | | | (Section 2.8.3) | - +---------------------+-----------------------+--------------------+ - | date | PartialDate|Timestamp | Anniversary | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | day | UnsignedInt | PartialDate | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | defaultSeparator | String | Address | - | | | (Section 2.5.1.1), | - | | | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | directories | Id[Directory] | Card | - | | | (Section 2.6.2) | - +---------------------+-----------------------+--------------------+ - | emails | Id[EmailAddress] | Card | - | | | (Section 2.3.1) | - +---------------------+-----------------------+--------------------+ - | features | String[Boolean] | Phone | - | | | (Section 2.3.3) | - +---------------------+-----------------------+--------------------+ - | full | String | Address | - | | | (Section 2.5.1.1), | - | | | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | grammaticalGender | String | SpeakToAs | - | | | (Section 2.2.4) | - +---------------------+-----------------------+--------------------+ - | isOrdered | Boolean | Address | - | | | (Section 2.5.1.1), | - | | | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | keywords | String[Boolean] | Card | - | | | (Section 2.8.2) | - +---------------------+-----------------------+--------------------+ - | kind | String | AddressComponent | - | | | (Section 2.5.1.2), | - | | | Anniversary | - | | | (Section 2.8.1), | - | | | Calendar | - | | | (Section 2.4.1), | - | | | Card | - | | | (Section 2.1.4), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | NameComponent | - | | | (Section 2.2.1.2), | - | | | PersonalInfo | - | | | (Section 2.8.4), | - | | | Title | - | | | (Section 2.2.5) | - +---------------------+-----------------------+--------------------+ - | label | String | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | EmailAddress | - | | | (Section 2.3.1), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | OnlineService | - | | | (Section 2.3.2), | - | | | PersonalInfo | - | | | (Section 2.8.4), | - | | | Phone | - | | | (Section 2.3.3), | - | | | SchedulingAddress | - | | | (Section 2.4.2). | - | | | Also see Sections | - | | | 1.4.4 and 1.5.2. | - +---------------------+-----------------------+--------------------+ - | language | String | Card | - | | | (Section 2.1.5), | - | | | LanguagePref | - | | | (Section 2.3.4) | - +---------------------+-----------------------+--------------------+ - | level | String | PersonalInfo | - | | | (Section 2.8.4) | - +---------------------+-----------------------+--------------------+ - | links | Id[Link] | Card | - | | | (Section 2.6.3) | - +---------------------+-----------------------+--------------------+ - | listAs | UnsignedInt | Directory | - | | | (Section 2.6.2), | - | | | PersonalInfo | - | | | (Section 2.8.4) | - +---------------------+-----------------------+--------------------+ - | localizations | String[PatchObject] | Card | - | | | (Section 2.7.1) | - +---------------------+-----------------------+--------------------+ - | media | Id[Media] | Card | - | | | (Section 2.6.4) | - +---------------------+-----------------------+--------------------+ - | mediaType | String | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4). | - | | | Also see | - | | | Section 1.4.4. | - +---------------------+-----------------------+--------------------+ - | members | String[Boolean] | Card | - | | | (Section 2.1.6) | - +---------------------+-----------------------+--------------------+ - | month | UnsignedInt | PartialDate | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | name | Name | Card | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | name | String | Author | - | | | (Section 2.8.3), | - | | | Nickname | - | | | (Section 2.2.2), | - | | | Organization | - | | | (Section 2.2.3), | - | | | OrgUnit | - | | | (Section 2.2.3), | - | | | Title | - | | | (Section 2.2.5) | - +---------------------+-----------------------+--------------------+ - | nicknames | Id[Nickname] | Card | - | | | (Section 2.2.2) | - +---------------------+-----------------------+--------------------+ - | note | String | Note | - | | | (Section 2.8.3) | - +---------------------+-----------------------+--------------------+ - | notes | Id[Note] | Card | - | | | (Section 2.8.3) | - +---------------------+-----------------------+--------------------+ - | number | String | Phone | - | | | (Section 2.3.3) | - +---------------------+-----------------------+--------------------+ - | onlineServices | Id[OnlineService] | Card | - | | | (Section 2.3.2) | - +---------------------+-----------------------+--------------------+ - | organizationId | String | Title | - | | | (Section 2.2.5) | - +---------------------+-----------------------+--------------------+ - | organizations | Id[Organization] | Card | - | | | (Section 2.2.3) | - +---------------------+-----------------------+--------------------+ - | personalInfo | Id[PersonalInfo] | Card | - | | | (Section 2.8.4) | - +---------------------+-----------------------+--------------------+ - | phones | Id[Phone] | Card | - | | | (Section 2.3.3) | - +---------------------+-----------------------+--------------------+ - | phonetic | String | AddressComponent | - | | | (Section 2.5.1.2), | - | | | NameComponent | - | | | (Section 2.2.1.2) | - +---------------------+-----------------------+--------------------+ - | phoneticScript | String | Address | - | | | (Section 2.5.1.1), | - | | | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | phoneticSystem | String | Address (2.5.1.1), | - | | | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | place | Address | Anniversary | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | pref | UnsignedInt | Address | - | | | (Section 2.5.1.1), | - | | | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | EmailAddress | - | | | (Section 2.3.1), | - | | | LanguagePref | - | | | (Section 2.3.4), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | Nickname | - | | | (Section 2.2.2), | - | | | OnlineService | - | | | (Section 2.3.2), | - | | | Phone | - | | | (Section 2.3.3), | - | | | Pronouns | - | | | (Section 2.2.4), | - | | | SchedulingAddress | - | | | (Section 2.4.2). | - | | | Also see Sections | - | | | 1.4.4 and 1.5.3. | - +---------------------+-----------------------+--------------------+ - | preferredLanguages | String[LanguagePref] | Card | - | | | (Section 2.3.4) | - +---------------------+-----------------------+--------------------+ - | prodId | String | Card | - | | | (Section 2.1.7) | - +---------------------+-----------------------+--------------------+ - | pronouns | Id[Pronouns] | SpeakToAs | - | | | (Section 2.2.4) | - +---------------------+-----------------------+--------------------+ - | relatedTo | String[Relation] | Card | - | | | (Section 2.1.8) | - +---------------------+-----------------------+--------------------+ - | relation | String[Boolean] | Relation | - | | | (Section 2.1.8) | - +---------------------+-----------------------+--------------------+ - | schedulingAddresses | Id[SchedulingAddress] | Card | - | | | (Section 2.4.2) | - +---------------------+-----------------------+--------------------+ - | service | String | OnlineService | - | | | (Section 2.3.2) | - +---------------------+-----------------------+--------------------+ - | sortAs | String[String] | Name | - | | | (Section 2.2.1.1) | - +---------------------+-----------------------+--------------------+ - | sortAs | String | Organization | - | | | (Section 2.2.3), | - | | | OrgUnit | - | | | (Section 2.2.3) | - +---------------------+-----------------------+--------------------+ - | speakToAs | SpeakToAs | Card | - | | | (Section 2.2.4) | - +---------------------+-----------------------+--------------------+ - | timeZone | String | Address | - | | | (Section 2.5.1.1) | - +---------------------+-----------------------+--------------------+ - | titles | Id[Title] | Card | - | | | (Section 2.2.5) | - +---------------------+-----------------------+--------------------+ - | uid | String | Card | - | | | (Section 2.1.9) | - +---------------------+-----------------------+--------------------+ - | units | OrgUnit[] | Organization | - | | | (Section 2.2.3) | - +---------------------+-----------------------+--------------------+ - | updated | UTCDateTime | Card | - | | | (Section 2.1.10) | - +---------------------+-----------------------+--------------------+ - | uri | String | Author | - | | | (Section 2.8.3), | - | | | Calendar | - | | | (Section 2.4.1), | - | | | CryptoKey | - | | | (Section 2.6.1), | - | | | Directory | - | | | (Section 2.6.2), | - | | | Link | - | | | (Section 2.6.3), | - | | | Media | - | | | (Section 2.6.4), | - | | | OnlineService | - | | | (Section 2.3.2), | - | | | SchedulingAddress | - | | | (Section 2.4.2). | - | | | Also see | - | | | Section 1.4.4. | - +---------------------+-----------------------+--------------------+ - | user | String | OnlineService | - | | | (Section 2.3.2) | - +---------------------+-----------------------+--------------------+ - | utc | UTCDateTime | Timestamp | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - | value | String | AddressComponent | - | | | (Section 2.5.1.2), | - | | | NameComponent | - | | | (Section 2.2.1.2), | - | | | PersonalInfo | - | | | (Section 2.8.4) | - +---------------------+-----------------------+--------------------+ - | version | String | Card | - | | | (Section 2.1.2) | - +---------------------+-----------------------+--------------------+ - | year | UnsignedInt | PartialDate | - | | | (Section 2.8.1) | - +---------------------+-----------------------+--------------------+ - - Table 2: JSContact Properties with "common" Usage - - The following table lists the initial "reserved" usage entries of the - "JSContact Properties" registry. For this property, the Change - Controller is "IETF", and the RFC section reference is for RFC 9553. - - +===============+============+============+==========+=============+ - | Property Name | Property | Property | Intended | Reference/ | - | | Type | Context | Usage | Description | - +===============+============+============+==========+=============+ - | extra | not | not | reserved | Section | - | | applicable | applicable | | 1.7.3.1 | - +---------------+------------+------------+----------+-------------+ - - Table 3: JSContact Properties with "reserved" Usage - -3.6. Creation of the JSContact Types Registry - - IANA has created the "JSContact Types" registry. The purpose of this - new registry is to avoid name collisions for JSContact type names and - provide a complete reference for all data types used for JSContact - property values. - - The registry entries sort alphabetically in ascending order by the - "Type Name" column. Equal entries sort in any order. - - The registry process for a new type is outlined in Section 3.3. - -3.6.1. JSContact Types Registry Template - - Type Name: The name of the type. - - Intended Usage: May be "common", "reserved", or "obsolete". - - Since Version: The JSContact version on which this type definition - is based. The version MUST be one of the allowed values of the - version property in the "JSContact Version" registry (see - Table 1). - - Until Version: The JSContact version after which the type definition - was obsoleted; therefore, it MUST NOT be used in later versions. - The Until Version value either MUST NOT be set or MUST be one of - the allowed values of the version property in the "JSContact - Version" registry (see Table 1). - - Change Controller: Person or entity responsible for requesting a - change to the entry's definition ("IETF" for RFCs from the IETF - stream). - - Reference or Description: A brief description or RFC number and - section reference where the Type is specified. For reserved type - names, the reference or description MAY be omitted. - -3.6.2. Initial Contents of the JSContact Types Registry - - The following table lists the initial "common" usage entries in the - "JSContact Types" registry. For all of these types, the Since - Version is "1.0", the Until Version is not set, the Change Controller - is "IETF", and RFC section references are for RFC 9553. - - +===================+=======================+ - | Type Name | Reference/Description | - +===================+=======================+ - | Address | Section 2.5.1.1 | - +-------------------+-----------------------+ - | AddressComponent | Section 2.5.1.2 | - +-------------------+-----------------------+ - | Anniversary | Section 2.8.1 | - +-------------------+-----------------------+ - | Author | Section 2.8.3 | - +-------------------+-----------------------+ - | Boolean | Section 1.3.2 | - +-------------------+-----------------------+ - | Calendar | Section 2.4.1 | - +-------------------+-----------------------+ - | Card | Section 2 | - +-------------------+-----------------------+ - | CryptoKey | Section 2.6.1 | - +-------------------+-----------------------+ - | Directory | Section 2.6.2 | - +-------------------+-----------------------+ - | EmailAddress | Section 2.3.1 | - +-------------------+-----------------------+ - | Id | Section 1.4.1 | - +-------------------+-----------------------+ - | Int | Section 1.4.2 | - +-------------------+-----------------------+ - | LanguagePref | Section 2.3.4 | - +-------------------+-----------------------+ - | Link | Section 2.6.3 | - +-------------------+-----------------------+ - | Media | Section 2.6.4 | - +-------------------+-----------------------+ - | Name | Section 2.2.1.1 | - +-------------------+-----------------------+ - | NameComponent | Section 2.2.1.2 | - +-------------------+-----------------------+ - | Nickname | Section 2.2.2 | - +-------------------+-----------------------+ - | Note | Section 2.8.3 | - +-------------------+-----------------------+ - | Number | Section 1.3.2 | - +-------------------+-----------------------+ - | OnlineService | Section 2.3.2 | - +-------------------+-----------------------+ - | Organization | Section 2.2.3 | - +-------------------+-----------------------+ - | OrgUnit | Section 2.2.3 | - +-------------------+-----------------------+ - | PartialDate | Section 2.8.1 | - +-------------------+-----------------------+ - | PatchObject | Section 1.4.3 | - +-------------------+-----------------------+ - | PersonalInfo | Section 2.8.4 | - +-------------------+-----------------------+ - | Phone | Section 2.3.3 | - +-------------------+-----------------------+ - | Pronouns | Section 2.2.4 | - +-------------------+-----------------------+ - | Relation | Section 2.1.8 | - +-------------------+-----------------------+ - | SchedulingAddress | Section 2.4.2 | - +-------------------+-----------------------+ - | SpeakToAs | Section 2.2.4 | - +-------------------+-----------------------+ - | String | Section 1.3.2 | - +-------------------+-----------------------+ - | Timestamp | Section 2.8.1 | - +-------------------+-----------------------+ - | Title | Section 2.2.5 | - +-------------------+-----------------------+ - | UnsignedInt | Section 1.4.2 | - +-------------------+-----------------------+ - | UTCDateTime | Section 1.4.5 | - +-------------------+-----------------------+ - - Table 4: JSContact Types with "common" Usage - - The following table lists the initial "reserved" usage entry of the - "JSContact Types" registry. For this type, the version is "1.0", the - Change Controller is "IETF", and the RFC section reference is for RFC - 9553. - - +===========+=======================+ - | Type Name | Reference/Description | - +===========+=======================+ - | Resource | Section 1.4.4 | - +-----------+-----------------------+ - - Table 5: JSContact Types with - "reserved" Usage - -3.7. Creation of the JSContact Enum Values Registry - - IANA has created the "JSContact Enum Values" registry. The purpose - of the new registry is to allow interoperable extension of semantics - for JSContact properties with enumerable values. Each such property - will have a subregistry of allowed values. - - The registry entries sort alphabetically in ascending order by the - following columns: "Property Name" first, "Property Context" second, - and "Since Version" third. The enum values sort alphabetically in - ascending order. Equal entries sort in any order. - - The registry process for a new enum value or adding a new enumerable - property is outlined in Section 3.3. - -3.7.1. JSContact Enum Values Registry Property Template - - This template is for adding a subregistry for a new enumerable - property to the "JSContact Enum Values" registry. - - Property Name: The name(s) of the property or properties where these - values may be used. This MUST be registered in the "JSContact - Properties" registry. - - Context: The list of allowed object types where the property or - properties may appear, as registered in the "JSContact Properties" - registry. This disambiguates where there may be two distinct - properties with the same name in different contexts. - - Since Version: The JSContact version on which the enum value - definition is based. The version MUST be one of the allowed - values of the version property in the "JSContact Version" registry - (see Table 1). - - Until Version: The JSContact version after which the enum value - definition was obsoleted; therefore, the enum value definition - MUST NOT be used in later versions. The Until Version value - either MUST NOT be set or MUST be one of the allowed values of the - version property in the "JSContact Version" registry (see - Table 1). - - Change Controller: Person or entity responsible for requesting a - change to the entry's definition ("IETF" for RFCs from the IETF - stream). - - Reference or Description: A brief description or RFC number and - section reference for the semantics of the value. - - Note that the initial contents will be the initial list of defined - values for the enum, using the template defined in Section 3.7.2. A - subregistry will be created with these values for this property name/ - context tuple. - -3.7.2. JSContact Enum Values Registry Value Template - - This template is for adding a new enum value to a subregistry in the - "JSContact Enum Values" registry. - - Enum Value: The verbatim value of the enum. - - Since Version: The JSContact version on which the enum value - definition is based. The version MUST be one of the allowed - values of the version property in the "JSContact Version" registry - (see Table 1). - - Until Version: The JSContact version after which the enum value was - obsoleted; therefore, the enum value MUST NOT be used in later - versions. The Until Version value either MUST NOT be set or MUST - be one of the allowed values of the version property in the - "JSContact Version" registry (see Table 1). - - Change Controller: Person or entity responsible for requesting a - change to the entry's definition ("IETF" for RFCs from the IETF - stream). - - Reference or Description: A brief description or RFC number and - section reference for the semantics of the value. - -3.7.3. Initial Contents of the JSContact Enum Values Registry - - For all entries in each subregistry created in this section, the - Since Version is "1.0", the Until Version is not set, the Change - Controller is "IETF", and RFC section references are for RFC 9553. - - Property Name: contexts - Context: Address - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | billing | Section 2.5.1.1 | - +------------+-----------------------+ - | delivery | Section 2.5.1.1 | - +------------+-----------------------+ - | private | Section 1.5.1 | - +------------+-----------------------+ - | work | Section 1.5.1 | - +------------+-----------------------+ - - Table 6: JSContact Enum Values for - contexts (Context: Address) - - Property Name: contexts - Context: Calendar, CryptoKey, Directory, EmailAddress, - LanguagePref, Link, Media, Nickname, - OnlineService, Organization, Phone, Pronouns, - SchedulingAddress - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | private | Section 1.5.1 | - +------------+-----------------------+ - | work | Section 1.5.1 | - +------------+-----------------------+ - - Table 7: JSContact Enum Values for - contexts (Context: Calendar, - CryptoKey, Directory, - EmailAddress, LanguagePref, Link, - Media, Nickname, OnlineService, - Organization, Phone, Pronouns, - SchedulingAddress) - - Property Name: features - Context: Phone - - Initial Contents: - +=============+=======================+ - | Enum Value | Reference/Description | - +=============+=======================+ - | fax | Section 2.3.3 | - +-------------+-----------------------+ - | main-number | Section 2.3.3 | - +-------------+-----------------------+ - | mobile | Section 2.3.3 | - +-------------+-----------------------+ - | pager | Section 2.3.3 | - +-------------+-----------------------+ - | text | Section 2.3.3 | - +-------------+-----------------------+ - | textphone | Section 2.3.3 | - +-------------+-----------------------+ - | video | Section 2.3.3 | - +-------------+-----------------------+ - | voice | Section 2.3.3 | - +-------------+-----------------------+ - - Table 8: JSContact Enum Values for - features (Context: Phone) - - Property Name: grammaticalGender - Context: SpeakToAs - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | animate | Section 2.2.4 | - +------------+-----------------------+ - | common | Section 2.2.4 | - +------------+-----------------------+ - | feminine | Section 2.2.4 | - +------------+-----------------------+ - | inanimate | Section 2.2.4 | - +------------+-----------------------+ - | masculine | Section 2.2.4 | - +------------+-----------------------+ - | neuter | Section 2.2.4 | - +------------+-----------------------+ - - Table 9: JSContact Enum Values for - grammaticalGender (Context: - SpeakToAs) - - Property Name: kind - Context: AddressComponent - - Initial Contents: - +===============+=======================+ - | Enum Value | Reference/Description | - +===============+=======================+ - | apartment | Section 2.5.1.2 | - +---------------+-----------------------+ - | block | Section 2.5.1.2 | - +---------------+-----------------------+ - | building | Section 2.5.1.2 | - +---------------+-----------------------+ - | country | Section 2.5.1.2 | - +---------------+-----------------------+ - | direction | Section 2.5.1.2 | - +---------------+-----------------------+ - | district | Section 2.5.1.2 | - +---------------+-----------------------+ - | floor | Section 2.5.1.2 | - +---------------+-----------------------+ - | landmark | Section 2.5.1.2 | - +---------------+-----------------------+ - | locality | Section 2.5.1.2 | - +---------------+-----------------------+ - | name | Section 2.5.1.2 | - +---------------+-----------------------+ - | number | Section 2.5.1.2 | - +---------------+-----------------------+ - | postcode | Section 2.5.1.2 | - +---------------+-----------------------+ - | postOfficeBox | Section 2.5.1.2 | - +---------------+-----------------------+ - | region | Section 2.5.1.2 | - +---------------+-----------------------+ - | room | Section 2.5.1.2 | - +---------------+-----------------------+ - | separator | Section 2.5.1.2 | - +---------------+-----------------------+ - | subdistrict | Section 2.5.1.2 | - +---------------+-----------------------+ - - Table 10: JSContact Enum Values for - kind (Context: AddressComponent) - - Property Name: kind - Context: Anniversary - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | birth | Section 2.8.1 | - +------------+-----------------------+ - | death | Section 2.8.1 | - +------------+-----------------------+ - | wedding | Section 2.8.1 | - +------------+-----------------------+ - - Table 11: JSContact Enum Values - for kind (Context: Anniversary) - - Property Name: kind - Context: Calendar - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | calendar | Section 2.4.1 | - +------------+-----------------------+ - | freeBusy | Section 2.4.1 | - +------------+-----------------------+ - - Table 12: JSContact Enum Values - for kind (Context: Calendar) - - Property Name: kind - Context: Card - - Initial Contents: - +=============+=======================+ - | Enum Value | Reference/Description | - +=============+=======================+ - | application | Section 2.1.4 | - +-------------+-----------------------+ - | device | Section 2.1.4 | - +-------------+-----------------------+ - | group | Section 2.1.4 | - +-------------+-----------------------+ - | individual | Section 2.1.4 | - +-------------+-----------------------+ - | location | Section 2.1.4 | - +-------------+-----------------------+ - | org | Section 2.1.4 | - +-------------+-----------------------+ - - Table 13: JSContact Enum Values for - kind (Context: Card) - - Property Name: kind - Context: Directory - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | directory | Section 2.6.2 | - +------------+-----------------------+ - | entry | Section 2.6.2 | - +------------+-----------------------+ - - Table 14: JSContact Enum Values - for kind (Context: Directory) - - Property Name: kind - Context: Link - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | contact | Section 2.6.3 | - +------------+-----------------------+ - - Table 15: JSContact Enum Values - for kind (Context: Link) - - Property Name: kind - Context: Media - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | logo | Section 2.6.4 | - +------------+-----------------------+ - | photo | Section 2.6.4 | - +------------+-----------------------+ - | sound | Section 2.6.4 | - +------------+-----------------------+ - - Table 16: JSContact Enum Values - for kind (Context: Media) - - Property Name: kind - Context: NameComponent - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | credential | Section 2.2.1.2 | - +------------+-----------------------+ - | generation | Section 2.2.1.2 | - +------------+-----------------------+ - | given | Section 2.2.1.2 | - +------------+-----------------------+ - | given2 | Section 2.2.1.2 | - +------------+-----------------------+ - | separator | Section 2.2.1.2 | - +------------+-----------------------+ - | surname | Section 2.2.1.2 | - +------------+-----------------------+ - | surname2 | Section 2.2.1.2 | - +------------+-----------------------+ - | title | Section 2.2.1.2 | - +------------+-----------------------+ - - Table 17: JSContact Enum Values - for kind (Context: NameComponent) - - Property Name: kind - Context: PersonalInfo - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | expertise | Section 2.8.4 | - +------------+-----------------------+ - | hobby | Section 2.8.4 | - +------------+-----------------------+ - | interest | Section 2.8.4 | - +------------+-----------------------+ - - Table 18: JSContact Enum Values - for kind (Context: PersonalInfo) - - Property Name: kind - Context: Title - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | role | Section 2.2.5 | - +------------+-----------------------+ - | title | Section 2.2.5 | - +------------+-----------------------+ - - Table 19: JSContact Enum Values - for kind (Context: Title) - - Property Name: level - Context: PersonalInfo - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | high | Section 2.8.4 | - +------------+-----------------------+ - | low | Section 2.8.4 | - +------------+-----------------------+ - | medium | Section 2.8.4 | - +------------+-----------------------+ - - Table 20: JSContact Enum Values - for level (Context: PersonalInfo) - - Property Name: phoneticSystem - Context: Address, Name - - Initial Contents: - +============+=======================+ - | Enum Value | Reference/Description | - +============+=======================+ - | ipa | Section 1.5.4 | - +------------+-----------------------+ - | jyut | Section 1.5.4 | - +------------+-----------------------+ - | piny | Section 1.5.4 | - +------------+-----------------------+ - - Table 21: JSContact Enum Values - for phoneticSystem (Context: - Address, Name) - - Property Name: relation - Context: Relation - - Initial Contents: - +==============+=======================+ - | Enum Value | Reference/Description | - +==============+=======================+ - | acquaintance | Section 2.1.8 | - +--------------+-----------------------+ - | agent | Section 2.1.8 | - +--------------+-----------------------+ - | child | Section 2.1.8 | - +--------------+-----------------------+ - | colleague | Section 2.1.8 | - +--------------+-----------------------+ - | contact | Section 2.1.8 | - +--------------+-----------------------+ - | co-resident | Section 2.1.8 | - +--------------+-----------------------+ - | co-worker | Section 2.1.8 | - +--------------+-----------------------+ - | crush | Section 2.1.8 | - +--------------+-----------------------+ - | date | Section 2.1.8 | - +--------------+-----------------------+ - | emergency | Section 2.1.8 | - +--------------+-----------------------+ - | friend | Section 2.1.8 | - +--------------+-----------------------+ - | kin | Section 2.1.8 | - +--------------+-----------------------+ - | me | Section 2.1.8 | - +--------------+-----------------------+ - | met | Section 2.1.8 | - +--------------+-----------------------+ - | muse | Section 2.1.8 | - +--------------+-----------------------+ - | neighbor | Section 2.1.8 | - +--------------+-----------------------+ - | parent | Section 2.1.8 | - +--------------+-----------------------+ - | sibling | Section 2.1.8 | - +--------------+-----------------------+ - | spouse | Section 2.1.8 | - +--------------+-----------------------+ - | sweetheart | Section 2.1.8 | - +--------------+-----------------------+ - - Table 22: JSContact Enum Values for - relation (Context: Relation) - -4. Security Considerations - - Contact information is very privacy sensitive. It can reveal the - identity, location, credentials information, employment status, - interests and hobbies, and social network of a user. Its - transmission and storage must be done carefully to protect it from - possible threats such as eavesdropping, replay, message insertion, - deletion, modification, and on-path attacks. - - The data being stored and transmitted may be used in systems with - real-world consequences. For example, a malicious actor might - provide JSContact data that uses the name of another person but - insert their contact details to impersonate the unknown victim. Such - systems must be careful to authenticate all data they receive to - prevent them from being subverted and ensure the change comes from an - authorized entity. - - This document only defines the data format; such considerations are - primarily the concern of the API or method of storage and - transmission of such files. - -4.1. JSON Parsing - - The security considerations of [RFC8259] apply to the use of JSON as - the data interchange format. - - As for any serialization format, parsers need to thoroughly check the - syntax of the supplied data. JSON uses opening and closing brackets - for several types and structures, and it is possible that the end of - the supplied data will be reached when scanning for a matching - closing bracket; this is an error condition, and implementations need - to stop scanning at the end of the supplied data. - - JSON also uses a string encoding with some escape sequences to encode - special characters within a string. Care is needed when processing - these escape sequences to ensure that they are fully formed before - the special processing is triggered, with special care taken when the - escape sequences appear adjacent to other (non-escaped) special - characters or adjacent to the end of data (as in the previous - paragraph). - - If parsing JSON into a non-textual structured data format, - implementations may need to allocate storage to hold JSON string - elements. Since JSON does not use explicit string lengths, the risk - of denial of service due to resource exhaustion is small, but - implementations may still wish to place limits on the size of - allocations they are willing to make in any given context, to avoid - untrusted data causing excessive memory allocation. - -4.2. URI Values - - Several JSContact properties contain URIs as values, and processing - these properties requires extra care. Section 7 of [RFC3986] - discusses security risks related to URIs. - - Fetching remote resources carries inherent risks. Connections must - only be allowed on well-known ports, using allowed protocols - (generally, just HTTP/HTTPS on their default ports). The URL must be - resolved externally and not allowed to access internal resources. - Connecting to an external source reveals IP (and therefore often - location) information. - - A maliciously constructed JSContact object may contain a very large - number of URIs. In the case of published address books with a large - number of subscribers, such objects could be widely distributed. - Implementations should be careful to limit the automatic fetching of - linked resources to reduce the risk of this being an amplification - vector for a denial-of-service attack. - -5. References - -5.1. Normative References - - [IANA-TZ] IANA, "Time Zone Database", - . - - [IANA-vCard] - IANA, "vCard Elements", - . - - [ISO.3166-1] - International Organization for Standardization, "Codes for - the representation of names of countries and their - subdivisions -- Part 1: Country codes", ISO 3166-1:2020, - August 2020. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, - . - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, - November 1987, . - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, - DOI 10.17487/RFC2046, November 1996, - . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", - RFC 2426, DOI 10.17487/RFC2426, September 1998, - . - - [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: - Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, - . - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . - - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", STD 68, RFC 5234, - DOI 10.17487/RFC5234, January 2008, - . - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - DOI 10.17487/RFC5322, October 2008, - . - - [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying - Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, - September 2009, . - - [RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource - Identifier for Geographic Locations ('geo' URI)", - RFC 5870, DOI 10.17487/RFC5870, June 2010, - . - - [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, - DOI 10.17487/RFC6350, August 2011, - . - - [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., - "JavaScript Object Notation (JSON) Pointer", RFC 6901, - DOI 10.17487/RFC6901, April 2013, - . - - [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, - DOI 10.17487/RFC7493, March 2015, - . - - [RFC7529] Daboo, C. and G. Yakushev, "Non-Gregorian Recurrence Rules - in the Internet Calendaring and Scheduling Core Object - Specification (iCalendar)", RFC 7529, - DOI 10.17487/RFC7529, May 2015, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names - (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", STD 90, RFC 8259, - DOI 10.17487/RFC8259, December 2017, - . - -5.2. Informative References - - [IPA] IPA, "International Phonetic Alphabet", - . - - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, - A., Peterson, J., Sparks, R., Handley, M., and E. - Schooler, "SIP: Session Initiation Protocol", RFC 3261, - DOI 10.17487/RFC3261, June 2002, - . - - [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", - RFC 3966, DOI 10.17487/RFC3966, December 2004, - . - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, DOI 10.17487/RFC3986, January 2005, - . - - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, - January 2005, . - - [RFC6351] Perreault, S., "xCard: vCard XML Representation", - RFC 6351, DOI 10.17487/RFC6351, August 2011, - . - - [RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473, - DOI 10.17487/RFC6473, December 2011, - . - - [RFC6474] Li, K. and B. Leiba, "vCard Format Extensions: Place of - Birth, Place and Date of Death", RFC 6474, - DOI 10.17487/RFC6474, December 2011, - . - - [RFC6715] Cauchie, D., Leiba, B., and K. Li, "vCard Format - Extensions: Representing vCard Extensions Defined by the - Open Mobile Alliance (OMA) Converged Address Book (CAB) - Group", RFC 6715, DOI 10.17487/RFC6715, August 2012, - . - - [RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard - KIND:device", RFC 6869, DOI 10.17487/RFC6869, February - 2013, . - - [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, - DOI 10.17487/RFC7095, January 2014, - . - - [RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: - ICANN Extensions for the Registration Data Access Protocol - (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, - . - - [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, - RFC 9499, DOI 10.17487/RFC9499, March 2024, - . - - [RFC9554] Stepanek, R. and M. Loffredo, "vCard Format Extensions for - JSContact", RFC 9554, DOI 10.17487/RFC9554, May 2024, - . - - [RFC9555] Stepanek, R. and M. Loffredo, "JSContact: Converting from - and to vCard", RFC 9555, DOI 10.17487/RFC9555, May 2024, - . - - [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique - IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May - 2024, . - - [UBiDi] The Unicode Consortium, "Unicode Standard Annex #9: - Unicode Bidirectional Algorithm", Revision 48, - Unicode 15.1.0, August 2023, - . - - [WHATWG-URL] - WHATWG, "URL Living Standard", January 2024, - . - -Authors' Addresses - - Robert Stepanek - Fastmail - PO Box 234 - Collins St. West - Melbourne VIC 8007 - Australia - Email: rsto@fastmailteam.com - - - Mario Loffredo - IIT-CNR - Via Moruzzi, 1 - 56124 Pisa - Italy - Email: mario.loffredo@iit.cnr.it diff --git a/specifications/contacts/rfc9610.pdf b/specifications/contacts/rfc9610.pdf deleted file mode 100644 index f1d6e3ab..00000000 Binary files a/specifications/contacts/rfc9610.pdf and /dev/null differ diff --git a/specifications/contacts/rfc9610.txt b/specifications/contacts/rfc9610.txt deleted file mode 100644 index 8975e5ba..00000000 --- a/specifications/contacts/rfc9610.txt +++ /dev/null @@ -1,844 +0,0 @@ - - - - -Internet Engineering Task Force (IETF) N. Jenkins, Ed. -Request for Comments: 9610 Fastmail -Category: Standards Track December 2024 -ISSN: 2070-1721 - - - JSON Meta Application Protocol (JMAP) for Contacts - -Abstract - - This document specifies a data model for synchronising contact data - with a server using the JSON Meta Application Protocol (JMAP). - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc9610. - -Copyright Notice - - Copyright (c) 2024 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Revised BSD License text as described in Section 4.e of the - Trust Legal Provisions and are provided without warranty as described - in the Revised BSD License. - -Table of Contents - - 1. Introduction - 1.1. Notational Conventions - 1.2. Terminology - 1.3. Data Model Overview - 1.4. Addition to the Capabilities Object - 1.4.1. urn:ietf:params:jmap:contacts - 2. AddressBooks - 2.1. AddressBook/get - 2.2. AddressBook/changes - 2.3. AddressBook/set - 3. ContactCards - 3.1. ContactCard/get - 3.2. ContactCard/changes - 3.3. ContactCard/query - 3.3.1. Filtering - 3.3.2. Sorting - 3.4. ContactCard/queryChanges - 3.5. ContactCard/set - 3.6. ContactCard/copy - 4. Examples - 4.1. Fetching Initial Data - 4.2. Changing the Default Address Book - 5. Internationalisation Considerations - 6. Security Considerations - 7. IANA Considerations - 7.1. JMAP Capability Registration for "contacts" - 7.2. JMAP Data Type Registration for "AddressBook" - 7.3. JMAP Data Type Registration for "ContactCard" - 7.4. JMAP Error Codes Registry - 7.4.1. addressBookHasContents - 7.5. JSContact Property Registrations - 7.5.1. id - 7.5.2. addressBookIds - 7.5.3. blobId - 8. References - 8.1. Normative References - 8.2. Informative References - Author's Address - -1. Introduction - - The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic - protocol for synchronising data, such as mail, calendars, or - contacts, between a client and a server. It is optimised for mobile - and web environments and aims to provide a consistent interface to - different data types. - - This specification defines a data model for synchronising contacts - between a client and a server using JMAP. - -1.1. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - Type signatures, examples, and property descriptions in this document - follow the conventions established in Section 1.1 of [RFC8620]. The - Id, UnsignedInt, and UTCDate data types defined in Sections 1.2, 1.3, - and 1.4 of [RFC8620] are also used in this document. - -1.2. Terminology - - The same terminology used in the core JMAP specification (see - Section 1.6 of [RFC8620]) is also used in this document. - - The terms AddressBook and ContactCard (with these specific - capitalizations) are used to refer to the data types defined in this - document and instances of those data types. - -1.3. Data Model Overview - - An Account (see Section 1.6.2 of [RFC8620]) with support for the - contact data model contains zero or more AddressBook objects, which - is a named collection of zero or more ContactCards. A ContactCard is - a representation of a person, company, entity, or a group of such - entities in JSContact Card format, as defined in Section 2 of - [RFC9553]. Each ContactCard belongs to one or more AddressBooks. - - In servers with support for JMAP Sharing [RFC9670], users may see and - configure sharing of contact data with others. Sharing permissions - are managed per AddressBook. - -1.4. Addition to the Capabilities Object - - The capabilities object is returned as part of the JMAP Session - object; see Section 2 of [RFC8620]. This document defines one - additional capability URI. - -1.4.1. urn:ietf:params:jmap:contacts - - This represents support for the AddressBook and ContactCard data - types and associated API methods. The value of this property in the - JMAP Session "capabilities" property is an empty object. - - The value of this property in an account's "accountCapabilities" - property is an object that MUST contain the following information on - server capabilities and permissions for that account: - - *maxAddressBooksPerCard*: UnsignedInt|null - The maximum number of AddressBooks (see Section 2) that can be - assigned to a single ContactCard object (see Section 3). This - MUST be an integer >= 1, or null for no limit (or rather, the - limit is always the number of AddressBooks in the account). - - *mayCreateAddressBook*: Boolean - The user may create an AddressBook in this account if, and only - if, this is true. - -2. AddressBooks - - An AddressBook is a named collection of ContactCards. All - ContactCards are associated with one or more AddressBooks. - - An *AddressBook* object has the following properties: - - *id*: Id (immutable; server-set) - The id of the AddressBook. - - *name*: String - The user-visible name of the AddressBook. This MUST NOT be the - empty string and MUST NOT be greater than 255 octets in size when - encoded as UTF-8. - - *description*: String|null (default: null) - An optional long-form description of the AddressBook that provides - context in shared environments where users need more than just the - name. - - *sortOrder*: UnsignedInt (default: 0) - Defines the sort order of AddressBooks when presented in the - client's UI so it is consistent between devices. The number MUST - be an integer in the range 0 <= sortOrder < 2^31. - - An AddressBook with a lower order is to be displayed before a - AddressBook with a higher order in any list of AddressBooks in the - client's UI. AddressBooks with equal order should be sorted in - alphabetical order by name. The sorting should take into account - locale-specific character order convention. - - *isDefault*: Boolean (server-set) - This SHOULD be true for exactly one AddressBook in any account and - MUST NOT be true for more than one AddressBook within an account. - The default AddressBook should be used by clients whenever they - need to choose an AddressBook for the user within this account and - they do not have any other information on which to make a choice. - For example, if the user creates a new contact card, the client - may automatically set the card as belonging to the default - AddressBook from the user's primary account. - - *isSubscribed*: Boolean - True if the user has indicated they wish to see this AddressBook - in their client. This SHOULD default to false for AddressBooks in - shared accounts that the user has access to and true for any new - AddressBooks created by the user themself. - - If false, the AddressBook and its contents SHOULD only be - displayed when the user explicitly requests it. The UI may offer - to the user the option of subscribing to it. - - *shareWith*: Id[AddressBookRights]|null (default: null) - A map of the Principal id (Section 2 of [RFC9670]) to rights for - Principals this AddressBook is shared with. The Principal to - which this AddressBook belongs MUST NOT be in this set. This is - null if the AddressBook is not shared with anyone or if the server - does not support [RFC9670]. The value may be modified only if the - user has the "mayShare" right. The account id for the Principals - may be found in the urn:ietf:params:jmap:principals:owner - capability of the Account to which the AddressBook belongs. - - *myRights*: AddressBookRights (server-set) - The set of access rights the user has in relation to this - AddressBook. - - An *AddressBookRights* object has the following properties: - - *mayRead*: Boolean - The user may fetch the ContactCards in this AddressBook. - - *mayWrite*: Boolean - The user may create, modify, or destroy all ContactCards in this - AddressBook, or move them to or from this AddressBook. - - *mayShare*: Boolean - The user may modify the "shareWith" property for this AddressBook. - - *mayDelete*: Boolean - The user may delete the AddressBook itself. - -2.1. AddressBook/get - - This is a standard "/get" method as described in Section 5.1 of - [RFC8620]. The "ids" argument may be null to fetch all at once. - -2.2. AddressBook/changes - - This is a standard "/changes" method as described in Section 5.2 of - [RFC8620]. - -2.3. AddressBook/set - - This is a standard "/set" method as described in Section 5.3 of - [RFC8620], but with the following additional request arguments: - - *onDestroyRemoveContents*: Boolean (default: false) - If false, any attempt to destroy an AddressBook that still has a - ContactCard in it will be rejected with an - "addressBookHasContents" SetError. If true, any ContactCard that - is in the AddressBook will be removed from it, and if such a - ContactCard does not belong to any other AddressBook, it will be - destroyed. - - *onSuccessSetIsDefault*: Id|null - If an id is given, and all creates, updates, and destroys (if any) - succeed without error, the server will try to set this AddressBook - as the default. (For references to AddressBook creations, this is - equivalent to a creation-reference, so the id will be the creation - id prefixed with a "#".) - - If the id is not found or if the change is not permitted by the - server for policy reasons, it MUST be ignored and the current default - AddressBook (if any) will remain as such. No error is returned to - the client in this case. - - As per Section 5.3 of [RFC8620], if the default AddressBook is - successfully changed, any changed objects MUST be reported in either - the "created" or "updated" argument in the response as appropriate, - with the server-set value included. - - The "shareWith" property may only be set by users that have the - "mayShare" right. When modifying the "shareWith" property, the user - cannot give a right to a Principal if the Principal did not already - have that right and the user making the change also does not have - that right. Any attempt to do so MUST be rejected with a "forbidden" - SetError. - - Users can subscribe or unsubscribe to an AddressBook by setting the - "isSubscribed" property. The server MAY forbid users from - subscribing to certain AddressBooks even though they have permission - to see them, rejecting the update with a "forbidden" SetError. - - The following extra SetError type is defined for "destroy": - - *addressBookHasContents*: The AddressBook has at least one - ContactCard assigned to it and the "onDestroyRemoveContents" - argument was false. - -3. ContactCards - - A *ContactCard* object contains information about a person, company, - or other entity, or represents a group of such entities. It is a - JSContact Card object as defined in Section 2 of [RFC9553] with the - following additional properties: - - *id*: Id (immutable; server-set) - The id of the ContactCard. The "id" property MAY be different to - the ContactCard's "uid" property (as defined in Section 2.1.9 of - [RFC9553]). However, there MUST NOT be more than one ContactCard - with the same uid in an Account. - - *addressBookIds*: Id[Boolean] - The set of AddressBook ids that this ContactCard belongs to. A - card MUST belong to at least one AddressBook at all times (until - it is destroyed). The set is represented as an object, with each - key being an AddressBook id. The value for each key in the object - MUST be true. - - For any Media object in the card (see Section 2.6.4 of [RFC9553]), a - new property is defined: - - *blobId*: Id - An id for the Blob representing the binary contents of the - resource. - - When returning ContactCards, any Media with a URI that uses the - "data:" URL scheme [RFC2397] SHOULD return a "blobId" property and - omit the "uri" property, as this lets clients load the (potentially - large) image file only when needed and avoids the overhead of Base64 - encoding. The "mediaType" property MUST also be set. Similarly, - when creating or updating a ContactCard, clients MAY send a "blobId" - instead of the "uri" property for a Media object. - - A contact card with a "kind" property equal to "group" represents a - group of contacts. Clients often present these separately from other - contact cards. The "members" property, as defined in Section 2.1.6 - of [RFC9553], contains a set of uids (as defined in Section 2.1.9 of - [RFC9553]) for other contacts that are the members of this group. - Clients should consider the group to contain any ContactCard with a - matching uid from any account they have access to that has support - for the urn:ietf:params:jmap:contacts capability. Any uid that - cannot be found SHOULD be ignored but preserved. For example, - suppose a user adds contacts from a shared address book to their - private group, then temporarily loses access to this address book. - The uids cannot be resolved, so the contacts will disappear from the - group. However, if they are given permission to access the data - again, the uids will be found and the contacts will reappear. - -3.1. ContactCard/get - - This is a standard "/get" method as described in Section 5.1 of - [RFC8620]. - -3.2. ContactCard/changes - - This is a standard "/changes" method as described in Section 5.2 of - [RFC8620]. - -3.3. ContactCard/query - - This is a standard "/query" method as described in Section 5.5 of - [RFC8620]. - -3.3.1. Filtering - - A *FilterCondition* object has the following properties, any of which - may be omitted: - - *inAddressBook*: Id - An AddressBook id. A card must be in this address book to match - the condition. - - *uid*: String - A card must have this string exactly as its uid (as defined in - Section 2.1.9 of [RFC9553]) to match. - - *hasMember*: String - A card must have a "members" property (as defined in Section 2.1.6 - of [RFC9553]) that contains this string as one of the uids in the - set to match. - - *kind*: String - A card must have a "kind" property (as defined in Section 2.1.4 of - [RFC9553]) that equals this string exactly to match. - - *createdBefore*: UTCDate - The "created" date-time of the ContactCard (as defined in - Section 2.1.3 of [RFC9553]) must be before this date-time to match - the condition. - - *createdAfter*: UTCDate - The "created" date-time of the ContactCard (as defined in - Section 2.1.3 of [RFC9553]) must be the same or after this date- - time to match the condition. - - *updatedBefore*: UTCDate - The "updated" date-time of the ContactCard (as defined in - Section 2.1.10 of [RFC9553]) must be before this date-time to - match the condition. - - *updatedAfter*: UTCDate - The "updated" date-time of the ContactCard (as defined in - Section 2.1.10 of [RFC9553]) must be the same or after this date- - time to match the condition. - - *text*: String - A card matches this condition if the text matches with text in the - card. - - *name*: String - A card matches this condition if the value of any NameComponent in - the "name" property or the "full" property in the "name" property - of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches - the value. - - *name/given*: String - A card matches this condition if the value of a NameComponent with - kind "given" inside the "name" property of the card (as defined in - Section 2.2.1.2 of [RFC9553]) matches the value. - - *name/surname*: String - A card matches this condition if the value of a NameComponent with - kind "surname" inside the "name" property of the card (as defined - in Section 2.2.1.2 of [RFC9553]) matches the value. - - *name/surname2*: String - A card matches this condition if the value of a NameComponent with - kind "surname2" inside the "name" property of the card (as defined - in Section 2.2.1.2 of [RFC9553]) matches the value. - - *nickname*: String - A card matches this condition if the "name" of any Nickname in the - "nicknames" property of the card (as defined in Section 2.2.2 of - [RFC9553]) matches the value. - - *organization*: String - A card matches this condition if the "name" of any Organization in - the "organizations" property of the card (as defined in - Section 2.2.3 of [RFC9553]) matches the value. - - *email*: String - A card matches this condition if the "address" or "label" of any - EmailAddress in the "emails" property of the card (as defined in - Section 2.3.1 of [RFC9553]) matches the value. - - *phone*: String - A card matches this condition if the "number" or "label" of any - Phone in the "phones" property of the card (as defined in - Section 2.3.3 of [RFC9553]) matches the value. - - *onlineService*: String - A card matches this condition if the "service", "uri", "user", or - "label" of any OnlineService in the "onlineServices" property of - the card (as defined in Section 2.3.2 of [RFC9553]) matches the - value. - - *address*: String - A card matches this condition if the value of any AddressComponent - in the "addresses" property or the "full" property in the - "addresses" property of the card (as defined in Section 2.5.1 of - [RFC9553]) matches the value. - - *note*: String - A card matches this condition if the "note" of any Note in the - "notes" property of the card (as defined in Section 2.8.3 of - [RFC9553]) matches the value. - - If zero properties are specified on the FilterCondition, the - condition MUST always evaluate to true. If multiple properties are - specified, ALL must apply for the condition to be true (it is - equivalent to splitting the object into one-property conditions and - making them all the child of an AND filter operator). - - The exact semantics for matching String fields is deliberately not - defined to allow for flexibility in indexing implementation, subject - to the following: - - * Text SHOULD be matched in a case-insensitive manner. - - * Text contained in either (but matched) single or double quotes - SHOULD be treated as a phrase search. That is, a match is - required for that exact sequence of words, excluding the - surrounding quotation marks. Use \", \', and \\ to match a - literal ", ', and \ respectively in a phrase. - - * Outside of a phrase, whitespace SHOULD be treated as dividing - separate tokens that may be searched for separately in the - contact, but MUST all be present for the contact to match the - filter. - - * Tokens MAY be matched on a whole-word basis using stemming (e.g., - a text search for bus would match "buses", but not "business"). - -3.3.2. Sorting - - The following values for the "property" field on the Comparator - object MUST be supported for sorting: - - * "created" - The "created" date on the ContactCard. - - * "updated" - The "updated" date on the ContactCard. - - The following values for the "property" field on the Comparator - object SHOULD be supported for sorting: - - * "name/given" - The value of the first NameComponent in the "name" - property whose "kind" is "given". - - * "name/surname" - The value of the first NameComponent in the - "name" property whose "kind" is "surname". - - * "name/surname2" - The value of the first NameComponent in the - "name" property whose "kind" is "surname2". - -3.4. ContactCard/queryChanges - - This is a standard "/queryChanges" method as described in Section 5.6 - of [RFC8620]. - -3.5. ContactCard/set - - This is a standard "/set" method as described in Section 5.3 of - [RFC8620]. - - To set a new photo, the file must first be uploaded using the upload - mechanism as described in Section 6.1 of [RFC8620]. This will give - the client a valid blobId, size, and type to use. The server MUST - reject attempts to set a file that is not a recognised image type as - the photo for a card. - -3.6. ContactCard/copy - - This is a standard "/copy" method as described in Section 5.4 of - [RFC8620]. - -4. Examples - - For brevity, only the "methodCalls" property of the Request object - and the "methodResponses" property of the Response object is shown in - the following examples. - -4.1. Fetching Initial Data - - A user has authenticated and the client has fetched the JMAP Session - object. It finds a single Account with the - "urn:ietf:params:jmap:contacts" capability with id "a0x9" and wants - to fetch all the address books and contacts. It might make the - following request: - - [ - ["AddressBook/get", { - "accountId": "a0x9" - }, "0"], - ["ContactCard/get", { - "accountId": "a0x9" - }, "1"] - ] - - Figure 1: "methodCalls" Property of a JMAP Request - - The server might respond with something like: - - [ - ["AddressBook/get", { - "accountId": "a0x9", - "list": [{ - "id": "062adcfa-105d-455c-bc60-6db68b69c3f3", - "name": "Personal", - "description": null, - "sortOrder": 0, - "isDefault": true, - "isSubscribed": true, - "shareWith": { - "3f1502e0-63fe-4335-9ff3-e739c188f5dd": { - "mayRead": true, - "mayWrite": false, - "mayShare": false, - "mayDelete": false - } - }, - "myRights": { - "mayRead": true, - "mayWrite": true, - "mayShare": true, - "mayDelete": false - } - }, { - "id": "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe", - "name": "Autosaved", - "description": null, - "sortOrder": 1, - "isDefault": false, - "isSubscribed": true, - "shareWith": null, - "myRights": { - "mayRead": true, - "mayWrite": true, - "mayShare": true, - "mayDelete": false - } - }], - "notFound": [], - "state": "~4144" - }, "0"], - ["ContactCard/get", { - "accountId": "a0x9", - "list": [{ - "id": "3", - "addressBookIds": { - "062adcfa-105d-455c-bc60-6db68b69c3f3": true - }, - "name": { - "components": [ - { "kind": "given", "value": "Joe" }, - { "kind": "surname", "value": "Bloggs" } - ], - "isOrdered": true - }, - "emails": { - "0": { - "contexts": { - "private": true - }, - "address": "joe.bloggs@example.com" - } - } - }], - "notFound": [], - "state": "ewarbckaqJ::112" - }, "1"] - ] - - Figure 2: "methodResponses" Property of a JMAP Response - -4.2. Changing the Default Address Book - - The client tries to change the default address book from "Personal" - to "Autosaved" (and makes no other change): - - [ - ["AddressBook/set", { - "accountId": "a0x9", - "onSuccessSetIsDefault": "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe" - }, "0"] - ] - - Figure 3: "methodCalls" Property of a JMAP Request - - The server allows the change, returning the following response: - - [ - ["AddressBook/set", { - "accountId": "a0x9", - "updated": { - "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe": { - "isDefault": true - }, - "062adcfa-105d-455c-bc60-6db68b69c3f3": { - "isDefault": false - }, - "oldState": "~4144", - "newState": "~4148" - } - }, "0"] - ] - - Figure 4: "methodResponses" Property of a JMAP Response - -5. Internationalisation Considerations - - Experience has shown that unrestricted use of Unicode can lead to - problems such as inconsistent rendering, users reading text and - interpreting it differently than intended, and unexpected results - when copying text from one location to another. Servers MAY choose - to mitigate this by restricting the set of characters allowed in - otherwise unconstrained String fields. The FreeformClass, as - documented in Section 4.3 of [RFC8264], might be a good starting - point for this. - - Attempts to set a value containing code points outside of the - permissible set can be handled in a few ways by the server. The - server could choose to strip the forbidden characters or replace them - with U+FFFD (the Unicode replacement character) and store the - resulting string. This is likely to be appropriate for non-printable - characters -- such as the "Control Codes" defined in Section 23.1 - (https://www.unicode.org/versions/latest/core-spec/chapter- - 23/#G20365) of [UNICODE], excluding newline (U+000A), carriage return - (U+000D), and tab (U+0009) -- that can end up in data accidentally - due to copy-and-paste issues but are invisible to the end user. JMAP - allows the server to transform data on create/update as long as any - changed properties are returned to the client in the "/set" response - so it knows what has changed, as per Section 5.3 of [RFC8620]. - Alternatively, the server MAY just reject the create/update with an - "invalidProperties" SetError. - -6. Security Considerations - - All security considerations of JMAP [RFC8620] apply to this - specification. Additional considerations specific to the data types - and functionality introduced by this document are described in the - following subsection. - - Contacts consist almost entirely of private, personally identifiable - information, and represent the social connections of users. Privacy - leaks can have real world consequences, and contact servers and - clients MUST be mindful of the need to keep all data secure. - - Servers MUST enforce the Access Control Lists (ACLs) set on address - books to ensure only authorised data is shared. - -7. IANA Considerations - -7.1. JMAP Capability Registration for "contacts" - - IANA has registered "contacts" in the "JMAP Capabilities" registry as - follows: - - Capability Name: urn:ietf:params:jmap:contacts - Intended Use: common - Change Controller: IETF - Security and Privacy Considerations: this document, Section 6 - Reference: this document - -7.2. JMAP Data Type Registration for "AddressBook" - - IANA has registered "AddressBook" in the "JMAP Data Types" registry - as follows: - - Type Name: AddressBook - Can Reference Blobs: No - Can Use for State Change: Yes - Capability: urn:ietf:params:jmap:contacts - Reference: this document - -7.3. JMAP Data Type Registration for "ContactCard" - - IANA has registered "ContactCard" in the "JMAP Data Types" registry - as follows: - - Type Name: ContactCard - Can Reference Blobs: Yes - Can Use for State Change: Yes - Capability: urn:ietf:params:jmap:contacts - Reference: this document - -7.4. JMAP Error Codes Registry - - The following subsection has registered a new error code in the "JMAP - Error Codes" registry, as defined in Section 9 of [RFC8620]. - -7.4.1. addressBookHasContents - - JMAP Error Code: addressBookHasContents - Intended Use: common - Change Controller: IETF - Description: The AddressBook has at least one ContactCard assigned - to it, and the "onDestroyRemoveContents" argument was false. - Reference: This document, Section 2.3 - -7.5. JSContact Property Registrations - - IANA has registered the following additional properties in the - "JSContact Properties" registry, as defined in Section 3 of - [RFC9553]. - -7.5.1. id - - Property Name: id - Property Type: not applicable - Property Context: Card - Intended Usage: reserved - Since Version: 1.0 - Change Controller: IETF - Reference: this document - -7.5.2. addressBookIds - - Property Name: addressBookIds - Property Type: not applicable - Property Context: Card - Intended Usage: reserved - Since Version: 1.0 - Change Controller: IETF - Reference: this document - -7.5.3. blobId - - Property Name: blobId - Property Type: not applicable - Property Context: Media - Intended Usage: reserved - Since Version: 1.0 - Change Controller: IETF - Reference: this document - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, - DOI 10.17487/RFC2397, August 1998, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application - Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July - 2019, . - - [RFC9553] Stepanek, R. and M. Loffredo, "JSContact: A JSON - Representation of Contact Data", RFC 9553, - DOI 10.17487/RFC9553, May 2024, - . - - [RFC9670] Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP) - Sharing", RFC 9670, DOI 10.17487/RFC9670, November 2024, - . - -8.2. Informative References - - [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: - Preparation, Enforcement, and Comparison of - Internationalized Strings in Application Protocols", - RFC 8264, DOI 10.17487/RFC8264, October 2017, - . - - [UNICODE] The Unicode Consortium, "The Unicode Standard", - . - -Author's Address - - Neil Jenkins (editor) - Fastmail - PO Box 234, Collins St West - Melbourne VIC 8007 - Australia - Email: neilj@fastmailteam.com - URI: https://www.fastmail.com diff --git a/specifications/core/rfc8620.pdf b/specifications/core/rfc8620.pdf deleted file mode 100644 index 8b036313..00000000 Binary files a/specifications/core/rfc8620.pdf and /dev/null differ diff --git a/specifications/core/rfc8620.txt b/specifications/core/rfc8620.txt deleted file mode 100644 index 935ba474..00000000 --- a/specifications/core/rfc8620.txt +++ /dev/null @@ -1,5043 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) N. Jenkins -Request for Comments: 8620 Fastmail -Category: Standards Track C. Newman -ISSN: 2070-1721 Oracle - July 2019 - - - The JSON Meta Application Protocol (JMAP) - -Abstract - - This document specifies a protocol for clients to efficiently query, - fetch, and modify JSON-based data objects, with support for push - notification of changes and fast resynchronisation and for out-of- - band binary data upload/download. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc8620. - -Copyright Notice - - Copyright (c) 2019 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - - - - -Jenkins & Newman Standards Track [Page 1] - -RFC 8620 JMAP July 2019 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 - 1.2. The Id Data Type . . . . . . . . . . . . . . . . . . . . 6 - 1.3. The Int and UnsignedInt Data Types . . . . . . . . . . . 6 - 1.4. The Date and UTCDate Data Types . . . . . . . . . . . . . 7 - 1.5. JSON as the Data Encoding Format . . . . . . . . . . . . 7 - 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.6.1. User . . . . . . . . . . . . . . . . . . . . . . . . 7 - 1.6.2. Accounts . . . . . . . . . . . . . . . . . . . . . . 7 - 1.6.3. Data Types and Records . . . . . . . . . . . . . . . 8 - 1.7. The JMAP API Model . . . . . . . . . . . . . . . . . . . 8 - 1.8. Vendor-Specific Extensions . . . . . . . . . . . . . . . 9 - 2. The JMAP Session Resource . . . . . . . . . . . . . . . . . . 9 - 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.2. Service Autodiscovery . . . . . . . . . . . . . . . . . . 15 - 3. Structured Data Exchange . . . . . . . . . . . . . . . . . . 16 - 3.1. Making an API Request . . . . . . . . . . . . . . . . . . 16 - 3.2. The Invocation Data Type . . . . . . . . . . . . . . . . 16 - 3.3. The Request Object . . . . . . . . . . . . . . . . . . . 16 - 3.3.1. Example Request . . . . . . . . . . . . . . . . . . . 18 - 3.4. The Response Object . . . . . . . . . . . . . . . . . . . 18 - 3.4.1. Example Response . . . . . . . . . . . . . . . . . . 19 - 3.5. Omitting Arguments . . . . . . . . . . . . . . . . . . . 19 - 3.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.6.1. Request-Level Errors . . . . . . . . . . . . . . . . 20 - 3.6.2. Method-Level Errors . . . . . . . . . . . . . . . . . 21 - 3.7. References to Previous Method Results . . . . . . . . . . 22 - 3.8. Localisation of User-Visible Strings . . . . . . . . . . 27 - 3.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 28 - 3.10. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 28 - 4. The Core/echo Method . . . . . . . . . . . . . . . . . . . . 28 - 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 5. Standard Methods and Naming Convention . . . . . . . . . . . 29 - 5.1. /get . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 5.2. /changes . . . . . . . . . . . . . . . . . . . . . . . . 30 - 5.3. /set . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 5.4. /copy . . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 5.5. /query . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 5.6. /queryChanges . . . . . . . . . . . . . . . . . . . . . . 48 - 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 51 - 5.8. Proxy Considerations . . . . . . . . . . . . . . . . . . 58 - 6. Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . 58 - 6.1. Uploading Binary Data . . . . . . . . . . . . . . . . . . 59 - 6.2. Downloading Binary Data . . . . . . . . . . . . . . . . . 60 - 6.3. Blob/copy . . . . . . . . . . . . . . . . . . . . . . . . 61 - - - - -Jenkins & Newman Standards Track [Page 2] - -RFC 8620 JMAP July 2019 - - - 7. Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 - 7.1. The StateChange Object . . . . . . . . . . . . . . . . . 63 - 7.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 64 - 7.2. PushSubscription . . . . . . . . . . . . . . . . . . . . 64 - 7.2.1. PushSubscription/get . . . . . . . . . . . . . . . . 67 - 7.2.2. PushSubscription/set . . . . . . . . . . . . . . . . 68 - 7.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 69 - 7.3. Event Source . . . . . . . . . . . . . . . . . . . . . . 71 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 73 - 8.1. Transport Confidentiality . . . . . . . . . . . . . . . . 73 - 8.2. Authentication Scheme . . . . . . . . . . . . . . . . . . 73 - 8.3. Service Autodiscovery . . . . . . . . . . . . . . . . . . 73 - 8.4. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 74 - 8.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 74 - 8.6. Connection to Unknown Push Server . . . . . . . . . . . . 74 - 8.7. Push Encryption . . . . . . . . . . . . . . . . . . . . . 75 - 8.8. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 76 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 - 9.1. Assignment of jmap Service Name . . . . . . . . . . . . . 76 - 9.2. Registration of Well-Known URI Suffix for JMAP . . . . . 76 - 9.3. Registration of the jmap URN Sub-namespace . . . . . . . 77 - 9.4. Creation of "JMAP Capabilities" Registry . . . . . . . . 77 - 9.4.1. Preliminary Community Review . . . . . . . . . . . . 77 - 9.4.2. Submit Request to IANA . . . . . . . . . . . . . . . 78 - 9.4.3. Designated Expert Review . . . . . . . . . . . . . . 78 - 9.4.4. Change Procedures . . . . . . . . . . . . . . . . . . 78 - 9.4.5. JMAP Capabilities Registry Template . . . . . . . . . 79 - 9.4.6. Initial Registration for JMAP Core . . . . . . . . . 79 - 9.4.7. Registration for JMAP Error Placeholder in JMAP - Capabilities Registry . . . . . . . . . . . . . . . . 80 - 9.5. Creation of "JMAP Error Codes" Registry . . . . . . . . . 80 - 9.5.1. Expert Review . . . . . . . . . . . . . . . . . . . . 80 - 9.5.2. JMAP Error Codes Registry Template . . . . . . . . . 81 - 9.5.3. Initial Contents for the JMAP Error Codes Registry . 81 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 86 - 10.2. Informative References . . . . . . . . . . . . . . . . . 89 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 3] - -RFC 8620 JMAP July 2019 - - -1. Introduction - - The JSON Meta Application Protocol (JMAP) is used for synchronising - data, such as mail, calendars, or contacts, between a client and a - server. It is optimised for mobile and web environments and aims to - provide a consistent interface to different data types. - - This specification is for the generic mechanism of data - synchronisation. Further specifications define the data models for - different data types that may be synchronised via JMAP. - - JMAP is designed to make efficient use of limited network resources. - Multiple API calls may be batched in a single request to the server, - reducing round trips and improving battery life on mobile devices. - Push connections remove the need for polling, and an efficient delta - update mechanism ensures a minimum amount of data is transferred. - - JMAP is designed to be horizontally scalable to a very large number - of users. This is facilitated by separate endpoints for users after - login, the separation of binary and structured data, and a data model - for sharing that does not allow data dependencies between accounts. - -1.1. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - The underlying format used for this specification is JSON. - Consequently, the terms "object" and "array" as well as the four - primitive types (strings, numbers, booleans, and null) are to be - interpreted as described in Section 1 of [RFC8259]. Unless otherwise - noted, all the property names and values are case sensitive. - - Some examples in this document contain "partial" JSON documents used - for illustrative purposes. In these examples, three periods "..." - are used to indicate a portion of the document that has been removed - for compactness. - - For compatibility with publishing requirements, line breaks have been - inserted inside long JSON strings, with the following continuation - lines indented. To form the valid JSON example, any line breaks - inside a string must be replaced with a space and any other white - space after the line break removed. - - - - - -Jenkins & Newman Standards Track [Page 4] - -RFC 8620 JMAP July 2019 - - - Unless otherwise specified, examples of API exchanges only show the - methodCalls array of the Request object or the methodResponses array - of the Response object. For compactness, the rest of the Request/ - Response object is omitted. - - Type signatures are given for all JSON values in this document. The - following conventions are used: - - o "*" - The type is undefined (the value could be any type, although - permitted values may be constrained by the context of this value). - - o "String" - The JSON string type. - - o "Number" - The JSON number type. - - o "Boolean" - The JSON boolean type. - - o "A[B]" - A JSON object where the keys are all of type "A", and the - values are all of type "B". - - o "A[]" - An array of values of type "A". - - o "A|B" - The value is either of type "A" or of type "B". - - Other types may also be given, with their representation defined - elsewhere in this document. - - Object properties may also have a set of attributes defined along - with the type signature. These have the following meanings: - - o "server-set" -- Only the server can set the value for this - property. The client MUST NOT send this property when creating a - new object of this type. - - o "immutable" -- The value MUST NOT change after the object is - created. - - o "default" -- (This is followed by a JSON value). The value that - will be used for this property if it is omitted in an argument or - when creating a new object of this type. - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 5] - -RFC 8620 JMAP July 2019 - - -1.2. The Id Data Type - - All record ids are assigned by the server and are immutable. - - Where "Id" is given as a data type, it means a "String" of at least 1 - and a maximum of 255 octets in size, and it MUST only contain - characters from the "URL and Filename Safe" base64 alphabet, as - defined in Section 5 of [RFC4648], excluding the pad character ("="). - This means the allowed characters are the ASCII alphanumeric - characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_"). - - These characters are safe to use in almost any context (e.g., - filesystems, URIs, and IMAP atoms). For maximum safety, servers - SHOULD also follow defensive allocation strategies to avoid creating - risks where glob completion or data type detection may be present - (e.g., on filesystems or in spreadsheets). In particular, it is wise - to avoid: - - o Ids starting with a dash - - o Ids starting with digits - - o Ids that contain only digits - - o Ids that differ only by ASCII case (for example, A vs. a) - - o the specific sequence of three characters "NIL" (because this - sequence can be confused with the IMAP protocol expression of the - null value) - - A good solution to these issues is to prefix every id with a single - alphabetical character. - -1.3. The Int and UnsignedInt Data Types - - Where "Int" is given as a data type, it means an integer in the range - -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a - floating-point double, represented as a JSON "Number". - - Where "UnsignedInt" is given as a data type, it means an "Int" where - the value MUST be in the range 0 <= value <= 2^53-1. - - - - - - - - - - -Jenkins & Newman Standards Track [Page 6] - -RFC 8620 JMAP July 2019 - - -1.4. The Date and UTCDate Data Types - - Where "Date" is given as a type, it means a string in "date-time" - format [RFC3339]. To ensure a normalised form, the "time-secfrac" - MUST always be omitted if zero, and any letters in the string (e.g., - "T" and "Z") MUST be uppercase. For example, - "2014-10-30T14:12:00+08:00". - - Where "UTCDate" is given as a type, it means a "Date" where the - "time-offset" component MUST be "Z" (i.e., it must be in UTC time). - For example, "2014-10-30T06:12:00Z". - -1.5. JSON as the Data Encoding Format - - JSON is a text-based data interchange format as specified in - [RFC8259]. The Internet JSON (I-JSON) format defined in [RFC7493] is - a strict subset of this, adding restrictions to avoid potentially - confusing scenarios (for example, it mandates that an object MUST NOT - have two members with the same name). - - All data sent from the client to the server or from the server to the - client (except binary file upload/download) MUST be valid I-JSON - according to the RFC and is therefore case sensitive and encoded in - UTF-8 [RFC3629]. - -1.6. Terminology - -1.6.1. User - - A user is a person accessing data via JMAP. A user has a set of - permissions determining the data that they can see. - -1.6.2. Accounts - - An account is a collection of data. A single account may contain an - arbitrary set of data types, for example, a collection of mail, - contacts, and calendars. Most JMAP methods take a mandatory - "accountId" argument that specifies on which account the operations - are to take place. - - An account is not the same as a user, although it is common for a - primary account to directly belong to the user. For example, you may - have an account that contains data for a group or business, to which - multiple users have access. - - - - - - - -Jenkins & Newman Standards Track [Page 7] - -RFC 8620 JMAP July 2019 - - - A single set of credentials may provide access to multiple accounts, - for example, if another user is sharing their work calendar with the - authenticated user or if there is a group mailbox for a support-desk - inbox. - - In the event of a severe internal error, a server may have to - reallocate ids or do something else that violates standard JMAP data - constraints for an account. In this situation, the data on the - server is no longer compatible with cached data the client may have - from before. The server MUST treat this as though the account has - been deleted and then recreated with a new account id. Clients will - then be forced to throw away any data with the old account id and - refetch all data from scratch. - -1.6.3. Data Types and Records - - JMAP provides a uniform interface for creating, retrieving, updating, - and deleting various types of objects. A "data type" is a collection - of named, typed properties, just like the schema for a database - table. Each instance of a data type is called a "record". - - The id of a record is immutable and assigned by the server. The id - MUST be unique among all records of the *same type* within the *same - account*. Ids may clash across accounts or for two records of - different types within the same account. - -1.7. The JMAP API Model - - JMAP uses HTTP [RFC7230] to expose API, push, upload, and download - resources. All HTTP requests MUST use the "https://" scheme (HTTP - over TLS [RFC2818]). All HTTP requests MUST be authenticated. - - An authenticated client can fetch the user's Session object with - details about the data and capabilities the server can provide as - shown in Section 2. The client may then exchange data with the - server in the following ways: - - 1. The client may make an API request to the server to get or set - structured data. This request consists of an ordered series of - method calls. These are processed by the server, which then - returns an ordered series of responses. This is described in - Sections 3, 4, and 5. - - 2. The client may download or upload binary files from/to the - server. This is detailed in Section 6. - - 3. The client may connect to a push channel on the server, to be - notified when data has changed. This is explained in Section 7. - - - -Jenkins & Newman Standards Track [Page 8] - -RFC 8620 JMAP July 2019 - - -1.8. Vendor-Specific Extensions - - Individual services will have custom features they wish to expose - over JMAP. This may take the form of extra data types and/or methods - not in the spec, extra arguments to JMAP methods, or extra properties - on existing data types (which may also appear in arguments to methods - that take property names). - - The server can advertise custom extensions it supports by including - the identifiers in the capabilities object. Identifiers for vendor - extensions MUST be a URL belonging to a domain owned by the vendor, - to avoid conflict. The URL SHOULD resolve to documentation for the - changes the extension makes. - - The client MUST opt in to use an extension by passing the appropriate - capability identifier in the "using" array of the Request object, as - described in Section 3.3. The server MUST only follow the - specifications that are opted into and behave as though it does not - implement anything else when processing a request. This is to ensure - compatibility with clients that don't know about a specific custom - extension and for compatibility with future versions of JMAP. - -2. The JMAP Session Resource - - You need two things to connect to a JMAP server: - - 1. The URL for the JMAP Session resource. This may be requested - directly from the user or discovered automatically based on a - username domain (see Section 2.2 below). - - 2. Credentials to authenticate with. How to obtain credentials is - out of scope for this document. - - A successful authenticated GET request to the JMAP Session resource - MUST return a JSON-encoded *Session* object, giving details about the - data and capabilities the server can provide to the client given - those credentials. It has the following properties: - - o capabilities: "String[Object]" - - An object specifying the capabilities of this server. Each key is - a URI for a capability supported by the server. The value for - each of these keys is an object with further information about the - server's capabilities in relation to that capability. - - The client MUST ignore any properties it does not understand. - - - - - -Jenkins & Newman Standards Track [Page 9] - -RFC 8620 JMAP July 2019 - - - The capabilities object MUST include a property called - "urn:ietf:params:jmap:core". The value of this property is an - object that MUST contain the following information on server - capabilities (suggested minimum values for limits are supplied - that allow clients to make efficient use of the network): - - * maxSizeUpload: "UnsignedInt" - - The maximum file size, in octets, that the server will accept - for a single file upload (for any purpose). Suggested minimum: - 50,000,000. - - * maxConcurrentUpload: "UnsignedInt" - - The maximum number of concurrent requests the server will - accept to the upload endpoint. Suggested minimum: 4. - - * maxSizeRequest: "UnsignedInt" - - The maximum size, in octets, that the server will accept for a - single request to the API endpoint. Suggested minimum: - 10,000,000. - - * maxConcurrentRequests: "UnsignedInt" - - The maximum number of concurrent requests the server will - accept to the API endpoint. Suggested minimum: 4. - - * maxCallsInRequest: "UnsignedInt" - - The maximum number of method calls the server will accept in a - single request to the API endpoint. Suggested minimum: 16. - - * maxObjectsInGet: "UnsignedInt" - - The maximum number of objects that the client may request in a - single /get type method call. Suggested minimum: 500. - - * maxObjectsInSet: "UnsignedInt" - - The maximum number of objects the client may send to create, - update, or destroy in a single /set type method call. This is - the combined total, e.g., if the maximum is 10, you could not - create 7 objects and destroy 6, as this would be 13 actions, - which exceeds the limit. Suggested minimum: 500. - - - - - - -Jenkins & Newman Standards Track [Page 10] - -RFC 8620 JMAP July 2019 - - - * collationAlgorithms: "String[]" - - A list of identifiers for algorithms registered in the - collation registry, as defined in [RFC4790], that the server - supports for sorting when querying records. - - Specifications for future capabilities will define their own - properties on the capabilities object. - - Servers MAY advertise vendor-specific JMAP extensions, as - described in Section 1.8. To avoid conflict, an identifier for a - vendor-specific extension MUST be a URL with a domain owned by the - vendor. Clients MUST opt in to any capability it wishes to use - (see Section 3.3). - - o accounts: "Id[Account]" - - A map of an account id to an Account object for each account (see - Section 1.6.2) the user has access to. An *Account* object has - the following properties: - - * name: "String" - - A user-friendly string to show when presenting content from - this account, e.g., the email address representing the owner of - the account. - - * isPersonal: "Boolean" - - This is true if the account belongs to the authenticated user - rather than a group account or a personal account of another - user that has been shared with them. - - * isReadOnly: "Boolean" - - This is true if the entire account is read-only. - - * accountCapabilities: "String[Object]" - - The set of capability URIs for the methods supported in this - account. Each key is a URI for a capability that has methods - you can use with this account. The value for each of these - keys is an object with further information about the account's - permissions and restrictions with respect to this capability, - as defined in the capability's specification. - - The client MUST ignore any properties it does not understand. - - - - -Jenkins & Newman Standards Track [Page 11] - -RFC 8620 JMAP July 2019 - - - The server advertises the full list of capabilities it supports - in the capabilities object, as defined above. If the - capability defines new methods, the server MUST include it in - the accountCapabilities object if the user may use those - methods with this account. It MUST NOT include it in the - accountCapabilities object if the user cannot use those methods - with this account. - - For example, you may have access to your own account with mail, - calendars, and contacts data and also a shared account that - only has contacts data (a business address book, for example). - In this case, the accountCapabilities property on the first - account would include something like - "urn:ietf:params:jmap:mail", "urn:ietf:params:jmap:calendars", - and "urn:ietf:params:jmap:contacts", while the second account - would just have the last of these. - - Attempts to use the methods defined in a capability with one of - the accounts that does not support that capability are rejected - with an "accountNotSupportedByMethod" error (see "Method-Level - Errors", Section 3.6.2). - - o primaryAccounts: "String[Id]" - - A map of capability URIs (as found in accountCapabilities) to the - account id that is considered to be the user's main or default - account for data pertaining to that capability. If no account - being returned belongs to the user, or in any other way there is - no appropriate way to determine a default account, there MAY be no - entry for a particular URI, even though that capability is - supported by the server (and in the capabilities object). - "urn:ietf:params:jmap:core" SHOULD NOT be present. - - o username: "String" - - The username associated with the given credentials, or the empty - string if none. - - o apiUrl: "String" - - The URL to use for JMAP API requests. - - - - - - - - - - -Jenkins & Newman Standards Track [Page 12] - -RFC 8620 JMAP July 2019 - - - o downloadUrl: "String" - - The URL endpoint to use when downloading files, in URI Template - (level 1) format [RFC6570]. The URL MUST contain variables called - "accountId", "blobId", "type", and "name". The use of these - variables is described in Section 6.2. Due to potential encoding - issues with slashes in content types, it is RECOMMENDED to put the - "type" variable in the query section of the URL. - - o uploadUrl: "String" - - The URL endpoint to use when uploading files, in URI Template - (level 1) format [RFC6570]. The URL MUST contain a variable - called "accountId". The use of this variable is described in - Section 6.1. - - o eventSourceUrl: "String" - - The URL to connect to for push events, as described in - Section 7.3, in URI Template (level 1) format [RFC6570]. The URL - MUST contain variables called "types", "closeafter", and "ping". - The use of these variables is described in Section 7.3. - - o state: "String" - - A (preferably short) string representing the state of this object - on the server. If the value of any other property on the Session - object changes, this string will change. The current value is - also returned on the API Response object (see Section 3.4), - allowing clients to quickly determine if the session information - has changed (e.g., an account has been added or removed), so they - need to refetch the object. - - To ensure future compatibility, other properties MAY be included on - the Session object. Clients MUST ignore any properties they are not - expecting. - - Implementors must take care to avoid inappropriate caching of the - Session object at the HTTP layer. Since the client should only - refetch when it detects there is a change (via the sessionState - property of an API response), it is RECOMMENDED to disable HTTP - caching altogether, for example, by setting "Cache-Control: no-cache, - no-store, must-revalidate" on the response. - - - - - - - - -Jenkins & Newman Standards Track [Page 13] - -RFC 8620 JMAP July 2019 - - -2.1. Example - - In the following example Session object, the user has access to their - own mail and contacts via JMAP, as well as read-only access to shared - mail from another user. The server is advertising a custom - "https://example.com/apis/foobar" capability. - - { - "capabilities": { - "urn:ietf:params:jmap:core": { - "maxSizeUpload": 50000000, - "maxConcurrentUpload": 8, - "maxSizeRequest": 10000000, - "maxConcurrentRequest": 8, - "maxCallsInRequest": 32, - "maxObjectsInGet": 256, - "maxObjectsInSet": 128, - "collationAlgorithms": [ - "i;ascii-numeric", - "i;ascii-casemap", - "i;unicode-casemap" - ] - }, - "urn:ietf:params:jmap:mail": {} - "urn:ietf:params:jmap:contacts": {}, - "https://example.com/apis/foobar": { - "maxFoosFinangled": 42 - } - }, - "accounts": { - "A13824": { - "name": "john@example.com", - "isPersonal": true, - "isReadOnly": false, - "accountCapabilities": { - "urn:ietf:params:jmap:mail": { - "maxMailboxesPerEmail": null, - "maxMailboxDepth": 10, - ... - }, - "urn:ietf:params:jmap:contacts": { - ... - } - } - }, - - - - - - -Jenkins & Newman Standards Track [Page 14] - -RFC 8620 JMAP July 2019 - - - "A97813": { - "name": "jane@example.com", - "isPersonal": false, - "isReadOnly": true, - "accountCapabilities": { - "urn:ietf:params:jmap:mail": { - "maxMailboxesPerEmail": 1, - "maxMailboxDepth": 10, - ... - } - } - } - }, - "primaryAccounts": { - "urn:ietf:params:jmap:mail": "A13824", - "urn:ietf:params:jmap:contacts": "A13824" - }, - "username": "john@example.com", - "apiUrl": "https://jmap.example.com/api/", - "downloadUrl": "https://jmap.example.com - /download/{accountId}/{blobId}/{name}?accept={type}", - "uploadUrl": "https://jmap.example.com/upload/{accountId}/", - "eventSourceUrl": "https://jmap.example.com - /eventsource/?types={types}&closeafter={closeafter}&ping={ping}", - "state": "75128aab4b1b" - } - -2.2. Service Autodiscovery - - There are two standardised autodiscovery methods in use for Internet - protocols: - - o DNS SRV (see [RFC2782], [RFC6186], and [RFC6764]) - - o .well-known/servicename (see [RFC8615]) - - A JMAP-supporting host for the domain "example.com" SHOULD publish a - SRV record "_jmap._tcp.example.com" that gives a hostname and port - (usually port "443"). The JMAP Session resource is then - "https://${hostname}[:${port}]/.well-known/jmap" (following any - redirects). - - If the client has a username in the form of an email address, it MAY - use the domain portion of this to attempt autodiscovery of the JMAP - server. - - - - - - -Jenkins & Newman Standards Track [Page 15] - -RFC 8620 JMAP July 2019 - - -3. Structured Data Exchange - - The client may make an API request to the server to get or set - structured data. This request consists of an ordered series of - method calls. These are processed by the server, which then returns - an ordered series of responses. - -3.1. Making an API Request - - To make an API request, the client makes an authenticated POST - request to the API resource, which is defined by the "apiUrl" - property in the Session object (see Section 2). - - The request MUST be of type "application/json" and consist of a - single JSON-encoded "Request" object, as defined in Section 3.3. If - successful, the response MUST also be of type "application/json" and - consist of a single "Response" object, as defined in Section 3.4. - -3.2. The Invocation Data Type - - Method calls and responses are represented by the *Invocation* data - type. This is a tuple, represented as a JSON array containing three - elements: - - 1. A "String" *name* of the method to call or of the response. - - 2. A "String[*]" object containing named *arguments* for that method - or response. - - 3. A "String" *method call id*: an arbitrary string from the client - to be echoed back with the responses emitted by that method call - (a method may return 1 or more responses, as it may make implicit - calls to other methods; all responses initiated by this method - call get the same method call id in the response). - -3.3. The Request Object - - A *Request* object has the following properties: - - o using: "String[]" - - The set of capabilities the client wishes to use. The client MAY - include capability identifiers even if the method calls it makes - do not utilise those capabilities. The server advertises the set - of specifications it supports in the Session object (see - Section 2), as keys on the "capabilities" property. - - - - - -Jenkins & Newman Standards Track [Page 16] - -RFC 8620 JMAP July 2019 - - - o methodCalls: "Invocation[]" - - An array of method calls to process on the server. The method - calls MUST be processed sequentially, in order. - - o createdIds: "Id[Id]" (optional) - - A map of a (client-specified) creation id to the id the server - assigned when a record was successfully created. - - As described later in this specification, some records may have a - property that contains the id of another record. To allow more - efficient network usage, you can set this property to reference a - record created earlier in the same API request. Since the real id - is unknown when the request is created, the client can instead - specify the creation id it assigned, prefixed with a "#" (see - Section 5.3 for more details). - - As the server processes API requests, any time it successfully - creates a new record, it adds the creation id to this map (see the - "create" argument to /set in Section 5.3), with the server- - assigned real id as the value. If it comes across a reference to - a creation id in a create/update, it looks it up in the map and - replaces the reference with the real id, if found. - - The client can pass an initial value for this map as the - "createdIds" property of the Request object. This may be an empty - object. If given in the request, the response will also include a - createdIds property. This allows proxy servers to easily split a - JMAP request into multiple JMAP requests to send to different - servers. For example, it could send the first two method calls to - server A, then the third to server B, before sending the fourth to - server A again. By passing the createdIds of the previous - response to the next request, it can ensure all of these still - resolve. See Section 5.8 for further discussion of proxy - considerations. - - Future specifications MAY add further properties to the Request - object to extend the semantics. To ensure forwards compatibility, a - server MUST ignore any other properties it does not understand on the - JMAP Request object. - - - - - - - - - - -Jenkins & Newman Standards Track [Page 17] - -RFC 8620 JMAP July 2019 - - -3.3.1. Example Request - -{ - "using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ], - "methodCalls": [ - [ "method1", { - "arg1": "arg1data", - "arg2": "arg2data" - }, "c1" ], - [ "method2", { - "arg1": "arg1data" - }, "c2" ], - [ "method3", {}, "c3" ] - ] -} - -3.4. The Response Object - - A *Response* object has the following properties: - - o methodResponses: "Invocation[]" - - An array of responses, in the same format as the "methodCalls" on - the Request object. The output of the methods MUST be added to - the "methodResponses" array in the same order that the methods are - processed. - - o createdIds: "Id[Id]" (optional; only returned if given in the - request) - - A map of a (client-specified) creation id to the id the server - assigned when a record was successfully created. This MUST - include all creation ids passed in the original createdIds - parameter of the Request object, as well as any additional ones - added for newly created records. - - o sessionState: "String" - - The current value of the "state" string on the Session object, as - described in Section 2. Clients may use this to detect if this - object has changed and needs to be refetched. - - Unless otherwise specified, if the method call completed - successfully, its response name is the same as the method name in the - request. - - - - - - -Jenkins & Newman Standards Track [Page 18] - -RFC 8620 JMAP July 2019 - - -3.4.1. Example Response - - { - "methodResponses": [ - [ "method1", { - "arg1": 3, - "arg2": "foo" - }, "c1" ], - [ "method2", { - "isBlah": true - }, "c2" ], - [ "anotherResponseFromMethod2", { - "data": 10, - "yetmoredata": "Hello" - }, "c2"], - [ "error", { - "type":"unknownMethod" - }, "c3" ] - ], - "sessionState": "75128aab4b1b" - } - -3.5. Omitting Arguments - - An argument to a method may be specified to have a default value. If - omitted by the client, the server MUST treat the method call the same - as if the default value had been specified. Similarly, the server - MAY omit any argument in a response that has the default value. - - Unless otherwise specified in a method description, null is the - default value for any argument in a request or response where this is - allowed by the type signature. Other arguments may only be omitted - if an explicit default value is defined in the method description. - -3.6. Errors - - There are three different levels of granularity at which an error may - be returned in JMAP. - - When an API request is made, the request as a whole may be rejected - due to rate limiting, malformed JSON, request for an unknown - capability, etc. In this case, the entire request is rejected with - an appropriate HTTP error response code and an additional JSON body - with more detail for the client. - - Provided the request itself is syntactically valid (the JSON is valid - and when decoded, it matches the type signature of a Request object), - the methods within it are executed sequentially by the server. Each - - - -Jenkins & Newman Standards Track [Page 19] - -RFC 8620 JMAP July 2019 - - - method may individually fail, for example, if invalid arguments are - given or an unknown method name is called. - - Finally, methods that make changes to the server state often act upon - a number of different records within a single call. Each record - change may be separately rejected with a SetError, as described in - Section 5.3. - -3.6.1. Request-Level Errors - - When an HTTP error response is returned to the client, the server - SHOULD return a JSON "problem details" object as the response body, - as per [RFC7807]. - - The following problem types are defined: - - o "urn:ietf:params:jmap:error:unknownCapability" - The client included a capability in the "using" property of the - request that the server does not support. - - o "urn:ietf:params:jmap:error:notJSON" - The content type of the request was not "application/json" or the - request did not parse as I-JSON. - - o "urn:ietf:params:jmap:error:notRequest" - The request parsed as JSON but did not match the type signature of - the Request object. - - o "urn:ietf:params:jmap:error:limit" - The request was not processed as it would have exceeded one of the - request limits defined on the capability object, such as - maxSizeRequest, maxCallsInRequest, or maxConcurrentRequests. A - "limit" property MUST also be present on the "problem details" - object, containing the name of the limit being applied. - -3.6.1.1. Example - - { - "type": "urn:ietf:params:jmap:error:unknownCapability", - "status": 400, - "detail": "The Request object used capability - 'https://example.com/apis/foobar', which is not supported - by this server." - } - - - - - - - -Jenkins & Newman Standards Track [Page 20] - -RFC 8620 JMAP July 2019 - - - Another example: - - { - "type": "urn:ietf:params:jmap:error:limit", - "limit": "maxSizeRequest", - "status": 400, - "detail": "The request is larger than the server is willing to - process." - } - -3.6.2. Method-Level Errors - - If a method encounters an error, the appropriate "error" response - MUST be inserted at the current point in the "methodResponses" array - and, unless otherwise specified, further processing MUST NOT happen - within that method call. - - Any further method calls in the request MUST then be processed as - normal. Errors at the method level MUST NOT generate an HTTP-level - error. - - An "error" response looks like this: - - [ "error", { - "type": "unknownMethod" - }, "call-id" ] - - The response name is "error", and it MUST have a type property. - Other properties may be present with further information; these are - detailed in the error type descriptions where appropriate. - - With the exception of when the "serverPartialFail" error is returned, - the externally visible state of the server MUST NOT have changed if - an error is returned at the method level. - - The following error types are defined, which may be returned for any - method call where appropriate: - - "serverUnavailable": Some internal server resource was temporarily - unavailable. Attempting the same operation later (perhaps after a - backoff with a random factor) may succeed. - - "serverFail": An unexpected or unknown error occurred during the - processing of the call. A "description" property should provide more - details about the error. The method call made no changes to the - server's state. Attempting the same operation again is expected to - fail again. Contacting the service administrator is likely necessary - to resolve this problem if it is persistent. - - - -Jenkins & Newman Standards Track [Page 21] - -RFC 8620 JMAP July 2019 - - - "serverPartialFail": Some, but not all, expected changes described by - the method occurred. The client MUST resynchronise impacted data to - determine server state. Use of this error is strongly discouraged. - - "unknownMethod": The server does not recognise this method name. - - "invalidArguments": One of the arguments is of the wrong type or is - otherwise invalid, or a required argument is missing. A - "description" property MAY be present to help debug with an - explanation of what the problem was. This is a non-localised string, - and it is not intended to be shown directly to end users. - - "invalidResultReference": The method used a result reference for one - of its arguments (see Section 3.7), but this failed to resolve. - - "forbidden": The method and arguments are valid, but executing the - method would violate an Access Control List (ACL) or other - permissions policy. - - "accountNotFound": The accountId does not correspond to a valid - account. - - "accountNotSupportedByMethod": The accountId given corresponds to a - valid account, but the account does not support this method or data - type. - - "accountReadOnly": This method modifies state, but the account is - read-only (as returned on the corresponding Account object in the - JMAP Session resource). - - Further possible errors for a particular method are specified in the - method descriptions. - - Further general errors MAY be defined in future RFCs. Should a - client receive an error type it does not understand, it MUST treat it - the same as the "serverFail" type. - -3.7. References to Previous Method Results - - To allow clients to make more efficient use of the network and avoid - round trips, an argument to one method can be taken from the result - of a previous method call in the same request. - - To do this, the client prefixes the argument name with "#" (an - octothorpe). The value is a ResultReference object as described - below. When processing a method call, the server MUST first check - the arguments object for any names beginning with "#". If found, the - result reference should be resolved and the value used as the "real" - - - -Jenkins & Newman Standards Track [Page 22] - -RFC 8620 JMAP July 2019 - - - argument. The method is then processed as normal. If any result - reference fails to resolve, the whole method MUST be rejected with an - "invalidResultReference" error. If an arguments object contains the - same argument name in normal and referenced form (e.g., "foo" and - "#foo"), the method MUST return an "invalidArguments" error. - - A *ResultReference* object has the following properties: - - o resultOf: "String" - - The method call id (see Section 3.2) of a previous method call in - the current request. - - o name: "String" - - The required name of a response to that method call. - - o path: "String" - - A pointer into the arguments of the response selected via the name - and resultOf properties. This is a JSON Pointer [RFC6901], except - it also allows the use of "*" to map through an array (see the - description below). - - To resolve: - - 1. Find the first response with a method call id identical to the - "resultOf" property of the ResultReference in the - "methodResponses" array from previously processed method calls in - the same request. If none, evaluation fails. - - 2. If the response name is not identical to the "name" property of - the ResultReference, evaluation fails. - - 3. Apply the "path" to the arguments object of the response (the - second item in the response array) following the JSON Pointer - algorithm [RFC6901], except with the following addition in - "Evaluation" (see Section 4): - - If the currently referenced value is a JSON array, the reference - token may be exactly the single character "*", making the new - referenced value the result of applying the rest of the JSON - Pointer tokens to every item in the array and returning the - results in the same order in a new array. If the result of - applying the rest of the pointer tokens to each item was itself - an array, the contents of this array are added to the output - rather than the array itself (i.e., the result is flattened from - an array of arrays to a single array). If the result of applying - - - -Jenkins & Newman Standards Track [Page 23] - -RFC 8620 JMAP July 2019 - - - the rest of the pointer tokens to a value was itself an array, - its items should be included individually in the output rather - than including the array itself (i.e., the result is flattened - from an array of arrays to a single array). - - As a simple example, suppose we have the following API request - "methodCalls": - - [[ "Foo/changes", { - "accountId": "A1", - "sinceState": "abcdef" - }, "t0" ], - [ "Foo/get", { - "accountId": "A1", - "#ids": { - "resultOf": "t0", - "name": "Foo/changes", - "path": "/created" - } - }, "t1" ]] - - After executing the first method call, the "methodResponses" array - is: - - [[ "Foo/changes", { - "accountId": "A1", - "oldState": "abcdef", - "newState": "123456", - "hasMoreChanges": false, - "created": [ "f1", "f4" ], - "updated": [], - "destroyed": [] - }, "t0" ]] - - To execute the "Foo/get" call, we look through the arguments and find - there is one with a "#" prefix. To resolve this, we apply the - algorithm above: - - 1. Find the first response with method call id "t0". The "Foo/ - changes" response fulfils this criterion. - - 2. Check that the response name is the same as in the result - reference. It is, so this is fine. - - 3. Apply the "path" as a JSON Pointer to the arguments object. This - simply selects the "created" property, so the result of - evaluating is: [ "f1", "f4" ]. - - - - -Jenkins & Newman Standards Track [Page 24] - -RFC 8620 JMAP July 2019 - - - The JMAP server now continues to process the "Foo/get" call as though - the arguments were: - - { - "accountId": "A1", - "ids": [ "f1", "f4" ] - } - - Now, a more complicated example using the JMAP Mail data model: fetch - the "from"/"date"/"subject" for every Email in the first 10 Threads - in the inbox (sorted newest first): - - [[ "Email/query", { - "accountId": "A1", - "filter": { "inMailbox": "id_of_inbox" }, - "sort": [{ "property": "receivedAt", "isAscending": false }], - "collapseThreads": true, - "position": 0, - "limit": 10, - "calculateTotal": true - }, "t0" ], - [ "Email/get", { - "accountId": "A1", - "#ids": { - "resultOf": "t0", - "name": "Email/query", - "path": "/ids" - }, - "properties": [ "threadId" ] - }, "t1" ], - [ "Thread/get", { - "accountId": "A1", - "#ids": { - "resultOf": "t1", - "name": "Email/get", - "path": "/list/*/threadId" - } - }, "t2" ], - [ "Email/get", { - "accountId": "A1", - "#ids": { - "resultOf": "t2", - "name": "Thread/get", - "path": "/list/*/emailIds" - }, - "properties": [ "from", "receivedAt", "subject" ] - }, "t3" ]] - - - - -Jenkins & Newman Standards Track [Page 25] - -RFC 8620 JMAP July 2019 - - - After executing the first 3 method calls, the "methodResponses" array - might be: - - [[ "Email/query", { - "accountId": "A1", - "queryState": "abcdefg", - "canCalculateChanges": true, - "position": 0, - "total": 101, - "ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91", - "msg38", "msg36", "msg33", "msg11", "msg1" ] - }, "t0" ], - [ "Email/get", { - "accountId": "A1", - "state": "123456", - "list": [{ - "id": "msg1023", - "threadId": "trd194" - }, { - "id": "msg223", - "threadId": "trd114" - }, - ... - ], - "notFound": [] - }, "t1" ], - [ "Thread/get", { - "accountId": "A1", - "state": "123456", - "list": [{ - "id": "trd194", - "emailIds": [ "msg1020", "msg1021", "msg1023" ] - }, { - "id": "trd114", - "emailIds": [ "msg201", "msg223" ] - }, - ... - ], - "notFound": [] - }, "t2" ]] - - To execute the final "Email/get" call, we look through the arguments - and find there is one with a "#" prefix. To resolve this, we apply - the algorithm: - - 1. Find the first response with method call id "t2". The "Thread/ - get" response fulfils this criterion. - - - - -Jenkins & Newman Standards Track [Page 26] - -RFC 8620 JMAP July 2019 - - - 2. "Thread/get" is the name specified in the result reference, so - this is fine. - - 3. Apply the "path" as a JSON Pointer to the arguments object. - Token by token: - - 1. "list": get the array of thread objects - - 2. "*": for each of the items in the array: - - a. "emailIds": get the array of Email ids - - b. Concatenate these into a single array of all the ids in - the result. - - The JMAP server now continues to process the "Email/get" call as - though the arguments were: - -{ - "accountId": "A1", - "ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", ... ], - "properties": [ "from", "receivedAt", "subject" ] -} - - The ResultReference performs a similar role to that of the creation - id, in that it allows a chained method call to refer to information - not available when the request is generated. However, they are - different things and not interchangeable; the only commonality is the - octothorpe used to indicate them. - -3.8. Localisation of User-Visible Strings - - If returning a custom string to be displayed to the user, for - example, an error message, the server SHOULD use information from the - Accept-Language header of the request (as defined in Section 5.3.5 of - [RFC7231]) to choose the best available localisation. The Content- - Language header of the response (see Section 3.1.3.2 of [RFC7231]) - SHOULD indicate the language being used for user-visible strings. - - For example, suppose a request was made with the following header: - - Accept-Language: fr-CH, fr;q=0.9, de;q=0.8, en;q=0.7, *;q=0.5 - - and a method generated an error to display to the user. The server - has translations of the error message in English and German. Looking - at the Accept-Language header, the user's preferred language is - French. Since we don't have a translation for this, we look at the - - - - -Jenkins & Newman Standards Track [Page 27] - -RFC 8620 JMAP July 2019 - - - next most preferred, which is German. We have a German translation, - so the server returns this and indicates the language chosen in a - Content-Language header like so: - - Content-Language: de - -3.9. Security - - As always, the server must be strict about data received from the - client. Arguments need to be checked for validity; a malicious user - could attempt to find an exploit through the API. In case of invalid - arguments (unknown/insufficient/wrong type for data, etc.), the - method MUST return an "invalidArguments" error and terminate. - -3.10. Concurrency - - Method calls within a single request MUST be executed in order. - However, method calls from different concurrent API requests may be - interleaved. This means that the data on the server may change - between two method calls within a single API request. - -4. The Core/echo Method - - The "Core/echo" method returns exactly the same arguments as it is - given. It is useful for testing if you have a valid authenticated - connection to a JMAP API endpoint. - -4.1. Example - - Request: - - [[ "Core/echo", { - "hello": true, - "high": 5 - }, "b3ff" ]] - - Response: - - [[ "Core/echo", { - "hello": true, - "high": 5 - }, "b3ff" ]] - - - - - - - - - -Jenkins & Newman Standards Track [Page 28] - -RFC 8620 JMAP July 2019 - - -5. Standard Methods and Naming Convention - - JMAP provides a uniform interface for creating, retrieving, updating, - and deleting objects of a particular type. For a "Foo" data type, - records of that type would be fetched via a "Foo/get" call and - modified via a "Foo/set" call. Delta updates may be fetched via a - "Foo/changes" call. These methods all follow a standard format as - described below. - - Some types may not have all these methods. Specifications defining - types MUST specify which methods are available for the type. - -5.1. /get - - Objects of type Foo are fetched via a call to "Foo/get". - - It takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o ids: "Id[]|null" - - The ids of the Foo objects to return. If null, then *all* records - of the data type are returned, if this is supported for that data - type and the number of records does not exceed the - "maxObjectsInGet" limit. - - o properties: "String[]|null" - - If supplied, only the properties listed in the array are returned - for each Foo object. If null, all properties of the object are - returned. The id property of the object is *always* returned, - even if not explicitly requested. If an invalid property is - requested, the call MUST be rejected with an "invalidArguments" - error. - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - - - - - - - -Jenkins & Newman Standards Track [Page 29] - -RFC 8620 JMAP July 2019 - - - o state: "String" - - A (preferably short) string representing the state on the server - for *all* the data of this type in the account (not just the - objects returned in this call). If the data changes, this string - MUST change. If the Foo data is unchanged, servers SHOULD return - the same state string on subsequent requests for this data type. - When a client receives a response with a different state string to - a previous call, it MUST either throw away all currently cached - objects for the type or call "Foo/changes" to get the exact - changes. - - o list: "Foo[]" - - An array of the Foo objects requested. This is the *empty array* - if no objects were found or if the "ids" argument passed in was - also an empty array. The results MAY be in a different order to - the "ids" in the request arguments. If an identical id is - included more than once in the request, the server MUST only - include it once in either the "list" or the "notFound" argument of - the response. - - o notFound: "Id[]" - - This array contains the ids passed to the method for records that - do not exist. The array is empty if all requested ids were found - or if the "ids" argument passed in was either null or an empty - array. - - The following additional error may be returned instead of the "Foo/ - get" response: - - "requestTooLarge": The number of ids requested by the client exceeds - the maximum number the server is willing to process in a single - method call. - -5.2. /changes - - When the state of the set of Foo records in an account changes on the - server (whether due to creation, updates, or deletion), the "state" - property of the "Foo/get" response will change. The "Foo/changes" - method allows a client to efficiently update the state of its Foo - cache to match the new state on the server. It takes the following - arguments: - - o accountId: "Id" - - The id of the account to use. - - - -Jenkins & Newman Standards Track [Page 30] - -RFC 8620 JMAP July 2019 - - - o sinceState: "String" - - The current state of the client. This is the string that was - returned as the "state" argument in the "Foo/get" response. The - server will return the changes that have occurred since this - state. - - o maxChanges: "UnsignedInt|null" - - The maximum number of ids to return in the response. The server - MAY choose to return fewer than this value but MUST NOT return - more. If not given by the client, the server may choose how many - to return. If supplied by the client, the value MUST be a - positive integer greater than 0. If a value outside of this range - is given, the server MUST reject the call with an - "invalidArguments" error. - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - o oldState: "String" - - This is the "sinceState" argument echoed back; it's the state from - which the server is returning changes. - - o newState: "String" - - This is the state the client will be in after applying the set of - changes to the old state. - - o hasMoreChanges: "Boolean" - - If true, the client may call "Foo/changes" again with the - "newState" returned to get further updates. If false, "newState" - is the current server state. - - o created: "Id[]" - - An array of ids for records that have been created since the old - state. - - o updated: "Id[]" - - An array of ids for records that have been updated since the old - state. - - - -Jenkins & Newman Standards Track [Page 31] - -RFC 8620 JMAP July 2019 - - - o destroyed: "Id[]" - - An array of ids for records that have been destroyed since the old - state. - - If a record has been created AND updated since the old state, the - server SHOULD just return the id in the "created" list but MAY return - it in the "updated" list as well. - - If a record has been updated AND destroyed since the old state, the - server SHOULD just return the id in the "destroyed" list but MAY - return it in the "updated" list as well. - - If a record has been created AND destroyed since the old state, the - server SHOULD remove the id from the response entirely. However, it - MAY include it in just the "destroyed" list or in both the - "destroyed" and "created" lists. - - If a "maxChanges" is supplied, or set automatically by the server, - the server MUST ensure the number of ids returned across "created", - "updated", and "destroyed" does not exceed this limit. If there are - more changes than this between the client's state and the current - server state, the server SHOULD generate an update to take the client - to an intermediate state, from which the client can continue to call - "Foo/changes" until it is fully up to date. If it is unable to - calculate an intermediate state, it MUST return a - "cannotCalculateChanges" error response instead. - - When generating intermediate states, the server may choose how to - divide up the changes. For many types, it will provide a better user - experience to return the more recent changes first, as this is more - likely to be what the user is most interested in. The client can - then continue to page in the older changes while the user is viewing - the newer data. For example, suppose a server went through the - following states: - - A -> B -> C -> D -> E - - And a client asks for changes from state "B". The server might first - get the ids of records created, updated, or destroyed between states - D and E, returning them with: - - state: "B-D-E" - hasMoreChanges: true - - - - - - - -Jenkins & Newman Standards Track [Page 32] - -RFC 8620 JMAP July 2019 - - - The client will then ask for the change from state "B-D-E", and the - server can return the changes between states C and D, returning: - - state: "B-C-E" - hasMoreChanges: true - - Finally, the client will request the changes from "B-C-E", and the - server can return the changes between states B and C, returning: - - state: "E" - hasMoreChanges: false - - Should the state on the server be modified in the middle of all this - (to "F"), the server still does the same, but now when the update to - state "E" is returned, it would indicate that it still has more - changes for the client to fetch. - - Where multiple changes to a record are split across different - intermediate states, the server MUST NOT return a record as created - after a response that deems it as updated or destroyed, and it MUST - NOT return a record as destroyed before a response that deems it as - created or updated. The server may have to coalesce multiple changes - to a record to satisfy this requirement. - - The following additional errors may be returned instead of the "Foo/ - changes" response: - - "cannotCalculateChanges": The server cannot calculate the changes - from the state string given by the client. Usually, this is due to - the client's state being too old or the server being unable to - produce an update to an intermediate state when there are too many - updates. The client MUST invalidate its Foo cache. - - Maintaining state to allow calculation of "Foo/changes" can be - expensive for the server, but always returning - "cannotCalculateChanges" severely increases network traffic and - resource usage for the client. To allow efficient sync, servers - SHOULD be able to calculate changes from any state string that was - given to a client within the last 30 days (but of course may support - calculating updates from states older than this). - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 33] - -RFC 8620 JMAP July 2019 - - -5.3. /set - - Modifying the state of Foo objects on the server is done via the - "Foo/set" method. This encompasses creating, updating, and - destroying Foo records. This allows the server to sort out ordering - and dependencies that may exist if doing multiple operations at once - (for example, to ensure there is always a minimum number of a certain - record type). - - The "Foo/set" method takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o ifInState: "String|null" - - This is a state string as returned by the "Foo/get" method - (representing the state of all objects of this type in the - account). If supplied, the string must match the current state; - otherwise, the method will be aborted and a "stateMismatch" error - returned. If null, any changes will be applied to the current - state. - - o create: "Id[Foo]|null" - - A map of a *creation id* (a temporary id set by the client) to Foo - objects, or null if no objects are to be created. - - The Foo object type definition may define default values for - properties. Any such property may be omitted by the client. - - The client MUST omit any properties that may only be set by the - server (for example, the "id" property on most object types). - - o update: "Id[PatchObject]|null" - - A map of an id to a Patch object to apply to the current Foo - object with that id, or null if no objects are to be updated. - - A *PatchObject* is of type "String[*]" and represents an unordered - set of patches. The keys are a path in JSON Pointer format - [RFC6901], with an implicit leading "/" (i.e., prefix each key - with "/" before applying the JSON Pointer evaluation algorithm). - - All paths MUST also conform to the following restrictions; if - there is any violation, the update MUST be rejected with an - "invalidPatch" error: - - - -Jenkins & Newman Standards Track [Page 34] - -RFC 8620 JMAP July 2019 - - - * The pointer MUST NOT reference inside an array (i.e., you MUST - NOT insert/delete from an array; the array MUST be replaced in - its entirety instead). - - * All parts prior to the last (i.e., the value after the final - slash) MUST already exist on the object being patched. - - * There MUST NOT be two patches in the PatchObject where the - pointer of one is the prefix of the pointer of the other, e.g., - "alerts/1/offset" and "alerts". - - The value associated with each pointer determines how to apply - that patch: - - * If null, set to the default value if specified for this - property; otherwise, remove the property from the patched - object. If the key is not present in the parent, this a no-op. - - * Anything else: The value to set for this property (this may be - a replacement or addition to the object being patched). - - Any server-set properties MAY be included in the patch if their - value is identical to the current server value (before applying - the patches to the object). Otherwise, the update MUST be - rejected with an "invalidProperties" SetError. - - This patch definition is designed such that an entire Foo object - is also a valid PatchObject. The client may choose to optimise - network usage by just sending the diff or may send the whole - object; the server processes it the same either way. - - o destroy: "Id[]|null" - - A list of ids for Foo objects to permanently delete, or null if no - objects are to be destroyed. - - Each creation, modification, or destruction of an object is - considered an atomic unit. It is permissible for the server to - commit changes to some objects but not others; however, it MUST NOT - only commit part of an update to a single record (e.g., update a - "name" property but not a "count" property, if both are supplied in - the update object). - - The final state MUST be valid after the "Foo/set" is finished; - however, the server may have to transition through invalid - intermediate states (not exposed to the client) while processing the - individual create/update/destroy requests. For example, suppose - there is a "name" property that must be unique. A single method call - - - -Jenkins & Newman Standards Track [Page 35] - -RFC 8620 JMAP July 2019 - - - could rename an object A => B and simultaneously rename another - object B => A. If the final state is valid, this is allowed. - Otherwise, each creation, modification, or destruction of an object - should be processed sequentially and accepted/rejected based on the - current server state. - - If a create, update, or destroy is rejected, the appropriate error - MUST be added to the notCreated/notUpdated/notDestroyed property of - the response, and the server MUST continue to the next create/update/ - destroy. It does not terminate the method. - - If an id given cannot be found, the update or destroy MUST be - rejected with a "notFound" set error. - - The server MAY skip an update (rejecting it with a "willDestroy" - SetError) if that object is destroyed in the same /set request. - - Some records may hold references to other records (foreign keys). - That reference may be set (via create or update) in the same request - as the referenced record is created. To do this, the client refers - to the new record using its creation id prefixed with a "#". The - order of the method calls in the request by the client MUST be such - that the record being referenced is created in the same or an earlier - call. Thus, the server never has to look ahead. Instead, while - processing a request, the server MUST keep a simple map for the - duration of the request of creation id to record id for each newly - created record, so it can substitute in the correct value if - necessary in later method calls. In the case of records with - references to the same type, the server MUST order the creates and - updates within a single method call so that creates happen before - their creation ids are referenced by another create/update/destroy in - the same call. - - Creation ids are not scoped by type but are a single map for all - types. A client SHOULD NOT reuse a creation id anywhere in the same - API request. If a creation id is reused, the server MUST map the - creation id to the most recently created item with that id. To allow - easy proxying of API requests, an initial set of creation id to real - id values may be passed with a request (see "The Request Object", - Section 3.3) and the final state of the map passed out with the - response (see "The Response Object", Section 3.4). - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - - - -Jenkins & Newman Standards Track [Page 36] - -RFC 8620 JMAP July 2019 - - - o oldState: "String|null" - - The state string that would have been returned by "Foo/get" before - making the requested changes, or null if the server doesn't know - what the previous state string was. - - o newState: "String" - - The state string that will now be returned by "Foo/get". - - o created: "Id[Foo]|null" - - A map of the creation id to an object containing any properties of - the created Foo object that were not sent by the client. This - includes all server-set properties (such as the "id" in most - object types) and any properties that were omitted by the client - and thus set to a default by the server. - - This argument is null if no Foo objects were successfully created. - - o updated: "Id[Foo|null]|null" - - The keys in this map are the ids of all Foos that were - successfully updated. - - The value for each id is a Foo object containing any property that - changed in a way *not* explicitly requested by the PatchObject - sent to the server, or null if none. This lets the client know of - any changes to server-set or computed properties. - - This argument is null if no Foo objects were successfully updated. - - o destroyed: "Id[]|null" - - A list of Foo ids for records that were successfully destroyed, or - null if none. - - o notCreated: "Id[SetError]|null" - - A map of the creation id to a SetError object for each record that - failed to be created, or null if all successful. - - o notUpdated: "Id[SetError]|null" - - A map of the Foo id to a SetError object for each record that - failed to be updated, or null if all successful. - - - - - -Jenkins & Newman Standards Track [Page 37] - -RFC 8620 JMAP July 2019 - - - o notDestroyed: "Id[SetError]|null" - - A map of the Foo id to a SetError object for each record that - failed to be destroyed, or null if all successful. - - A *SetError* object has the following properties: - - o type: "String" - - The type of error. - - o description: "String|null" - - A description of the error to help with debugging that includes an - explanation of what the problem was. This is a non-localised - string and is not intended to be shown directly to end users. - - The following SetError types are defined and may be returned for set - operations on any record type where appropriate: - - o "forbidden": (create; update; destroy). The create/update/destroy - would violate an ACL or other permissions policy. - - o "overQuota": (create; update). The create would exceed a server- - defined limit on the number or total size of objects of this type. - - o "tooLarge": (create; update). The create/update would result in - an object that exceeds a server-defined limit for the maximum size - of a single object of this type. - - o "rateLimit": (create). Too many objects of this type have been - created recently, and a server-defined rate limit has been - reached. It may work if tried again later. - - o "notFound": (update; destroy). The id given to update/destroy - cannot be found. - - o "invalidPatch": (update). The PatchObject given to update the - record was not a valid patch (see the patch description). - - o "willDestroy": (update). The client requested that an object be - both updated and destroyed in the same /set request, and the - server has decided to therefore ignore the update. - - - - - - - - -Jenkins & Newman Standards Track [Page 38] - -RFC 8620 JMAP July 2019 - - - o "invalidProperties": (create; update). The record given is - invalid in some way. For example: - - * It contains properties that are invalid according to the type - specification of this record type. - - * It contains a property that may only be set by the server - (e.g., "id") and is different to the current value. Note, to - allow clients to pass whole objects back, it is not an error to - include a server-set property in an update as long as the value - is identical to the current value on the server. - - * There is a reference to another record (foreign key), and the - given id does not correspond to a valid record. - - The SetError object SHOULD also have a property called - "properties" of type "String[]" that lists *all* the properties - that were invalid. - - Individual methods MAY specify more specific errors for certain - conditions that would otherwise result in an invalidProperties - error. If the condition of one of these is met, it MUST be - returned instead of the invalidProperties error. - - o "singleton": (create; destroy). This is a singleton type, so you - cannot create another one or destroy the existing one. - - Other possible SetError types MAY be given in specific method - descriptions. Other properties MAY also be present on the SetError - object, as described in the relevant methods. - - The following additional errors may be returned instead of the "Foo/ - set" response: - - "requestTooLarge": The total number of objects to create, update, or - destroy exceeds the maximum number the server is willing to process - in a single method call. - - "stateMismatch": An "ifInState" argument was supplied, and it does - not match the current state. - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 39] - -RFC 8620 JMAP July 2019 - - -5.4. /copy - - The only way to move Foo records *between* two different accounts is - to copy them using the "Foo/copy" method; once the copy has - succeeded, delete the original. The "onSuccessDestroyOriginal" - argument allows you to try to do this in one method call; however, - note that the two different actions are not atomic, so it is possible - for the copy to succeed but the original not to be destroyed for some - reason. - - The copy is conceptually in three phases: - - 1. Reading the current values from the "from" account. - - 2. Writing the new copies to the other account. - - 3. Destroying the originals in the "from" account, if requested. - - Data may change in between phases due to concurrent requests. - - The "Foo/copy" method takes the following arguments: - - o fromAccountId: "Id" - - The id of the account to copy records from. - - o ifFromInState: "String|null" - - This is a state string as returned by the "Foo/get" method. If - supplied, the string must match the current state of the account - referenced by the fromAccountId when reading the data to be - copied; otherwise, the method will be aborted and a - "stateMismatch" error returned. If null, the data will be read - from the current state. - - o accountId: "Id" - - The id of the account to copy records to. This MUST be different - to the "fromAccountId". - - o ifInState: "String|null" - - This is a state string as returned by the "Foo/get" method. If - supplied, the string must match the current state of the account - referenced by the accountId; otherwise, the method will be aborted - and a "stateMismatch" error returned. If null, any changes will - be applied to the current state. - - - - -Jenkins & Newman Standards Track [Page 40] - -RFC 8620 JMAP July 2019 - - - o create: "Id[Foo]" - - A map of the *creation id* to a Foo object. The Foo object MUST - contain an "id" property, which is the id (in the fromAccount) of - the record to be copied. When creating the copy, any other - properties included are used instead of the current value for that - property on the original. - - o onSuccessDestroyOriginal: "Boolean" (default: false) - - If true, an attempt will be made to destroy the original records - that were successfully copied: after emitting the "Foo/copy" - response, but before processing the next method, the server MUST - make a single call to "Foo/set" to destroy the original of each - successfully copied record; the output of this is added to the - responses as normal, to be returned to the client. - - o destroyFromIfInState: "String|null" - - This argument is passed on as the "ifInState" argument to the - implicit "Foo/set" call, if made at the end of this request to - destroy the originals that were successfully copied. - - Each record copy is considered an atomic unit that may succeed or - fail individually. - - The response has the following arguments: - - o fromAccountId: "Id" - - The id of the account records were copied from. - - o accountId: "Id" - - The id of the account records were copied to. - - o oldState: "String|null" - - The state string that would have been returned by "Foo/get" on the - account records that were copied to before making the requested - changes, or null if the server doesn't know what the previous - state string was. - - o newState: "String" - - The state string that will now be returned by "Foo/get" on the - account records were copied to. - - - - -Jenkins & Newman Standards Track [Page 41] - -RFC 8620 JMAP July 2019 - - - o created: "Id[Foo]|null" - - A map of the creation id to an object containing any properties of - the copied Foo object that are set by the server (such as the "id" - in most object types; note, the id is likely to be different to - the id of the object in the account it was copied from). - - This argument is null if no Foo objects were successfully copied. - - o notCreated: "Id[SetError]|null" - - A map of the creation id to a SetError object for each record that - failed to be copied, or null if none. - - The SetError may be any of the standard set errors returned for a - create or update. In addition, the following SetError is defined: - - "alreadyExists": The server forbids duplicates, and the record - already exists in the target account. An "existingId" property of - type "Id" MUST be included on the SetError object with the id of the - existing record. - - The following additional errors may be returned instead of the "Foo/ - copy" response: - - "fromAccountNotFound": The "fromAccountId" does not correspond to a - valid account. - - "fromAccountNotSupportedByMethod": The "fromAccountId" given - corresponds to a valid account, but the account does not support this - data type. - - "stateMismatch": An "ifInState" argument was supplied and it does not - match the current state, or an "ifFromInState" argument was supplied - and it does not match the current state in the from account. - -5.5. /query - - For data sets where the total amount of data is expected to be very - small, clients can just fetch the complete set of data and then do - any sorting/filtering locally. However, for large data sets (e.g., - multi-gigabyte mailboxes), the client needs to be able to - search/sort/window the data type on the server. - - A query on the set of Foos in an account is made by calling "Foo/ - query". This takes a number of arguments to determine which records - to include, how they should be sorted, and which part of the result - - - - -Jenkins & Newman Standards Track [Page 42] - -RFC 8620 JMAP July 2019 - - - should be returned (the full list may be *very* long). The result is - returned as a list of Foo ids. - - A call to "Foo/query" takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o filter: "FilterOperator|FilterCondition|null" - - Determines the set of Foos returned in the results. If null, all - objects in the account of this type are included in the results. - A *FilterOperator* object has the following properties: - - * operator: "String" - - This MUST be one of the following strings: - - + "AND": All of the conditions must match for the filter to - match. - - + "OR": At least one of the conditions must match for the - filter to match. - - + "NOT": None of the conditions must match for the filter to - match. - - * conditions: "(FilterOperator|FilterCondition)[]" - - The conditions to evaluate against each record. - - A *FilterCondition* is an "object" whose allowed properties and - semantics depend on the data type and is defined in the /query - method specification for that type. It MUST NOT have an - "operator" property. - - o sort: "Comparator[]|null" - - Lists the names of properties to compare between two Foo records, - and how to compare them, to determine which comes first in the - sort. If two Foo records have an identical value for the first - comparator, the next comparator will be considered, and so on. If - all comparators are the same (this includes the case where an - empty array or null is given as the "sort" argument), the sort - order is server dependent, but it MUST be stable between calls to - "Foo/query". A *Comparator* has the following properties: - - - - -Jenkins & Newman Standards Track [Page 43] - -RFC 8620 JMAP July 2019 - - - * property: "String" - - The name of the property on the Foo objects to compare. - - * isAscending: "Boolean" (optional; default: true) - - If true, sort in ascending order. If false, reverse the - comparator's results to sort in descending order. - - * collation: "String" (optional; default is server-dependent) - - The identifier, as registered in the collation registry defined - in [RFC4790], for the algorithm to use when comparing the order - of strings. The algorithms the server supports are advertised - in the capabilities object returned with the Session object - (see Section 2). - - If omitted, the default algorithm is server dependent, but: - - 1. It MUST be unicode-aware. - - 2. It MAY be selected based on an Accept-Language header in - the request (as defined in [RFC7231], Section 5.3.5) or - out-of-band information about the user's language/locale. - - 3. It SHOULD be case insensitive where such a concept makes - sense for a language/locale. Where the user's language is - unknown, it is RECOMMENDED to follow the advice in - Section 5.2.3 of [RFC8264]. - - The "i;unicode-casemap" collation [RFC5051] and the Unicode - Collation Algorithm () - are two examples that fulfil these criterion and provide - reasonable behaviour for a large number of languages. - - When the property being compared is not a string, the - "collation" property is ignored, and the following comparison - rules apply based on the type. In ascending order: - - + "Boolean": false comes before true. - - + "Number": A lower number comes before a higher number. - - + "Date"/"UTCDate": The earlier date comes first. - - The Comparator object may also have additional properties as - required for specific sort operations defined in a type's /query - method. - - - -Jenkins & Newman Standards Track [Page 44] - -RFC 8620 JMAP July 2019 - - - o position: "Int" (default: 0) - - The zero-based index of the first id in the full list of results - to return. - - If a negative value is given, it is an offset from the end of the - list. Specifically, the negative value MUST be added to the total - number of results given the filter, and if still negative, it's - clamped to "0". This is now the zero-based index of the first id - to return. - - If the index is greater than or equal to the total number of - objects in the results list, then the "ids" array in the response - will be empty, but this is not an error. - - o anchor: "Id|null" - - A Foo id. If supplied, the "position" argument is ignored. The - index of this id in the results will be used in combination with - the "anchorOffset" argument to determine the index of the first - result to return (see below for more details). - - o anchorOffset: "Int" (default: 0) - - The index of the first result to return relative to the index of - the anchor, if an anchor is given. This MAY be negative. For - example, "-1" means the Foo immediately preceding the anchor is - the first result in the list returned (see below for more - details). - - o limit: "UnsignedInt|null" - - The maximum number of results to return. If null, no limit - presumed. The server MAY choose to enforce a maximum "limit" - argument. In this case, if a greater value is given (or if it is - null), the limit is clamped to the maximum; the new limit is - returned with the response so the client is aware. If a negative - value is given, the call MUST be rejected with an - "invalidArguments" error. - - o calculateTotal: "Boolean" (default: false) - - Does the client wish to know the total number of results in the - query? This may be slow and expensive for servers to calculate, - particularly with complex filters, so clients should take care to - only request the total when needed. - - - - - -Jenkins & Newman Standards Track [Page 45] - -RFC 8620 JMAP July 2019 - - - If an "anchor" argument is given, the anchor is looked for in the - results after filtering and sorting. If found, the "anchorOffset" is - then added to its index. If the resulting index is now negative, it - is clamped to 0. This index is now used exactly as though it were - supplied as the "position" argument. If the anchor is not found, the - call is rejected with an "anchorNotFound" error. - - If an "anchor" is specified, any position argument supplied by the - client MUST be ignored. If no "anchor" is supplied, any - "anchorOffset" argument MUST be ignored. - - A client can use "anchor" instead of "position" to find the index of - an id within a large set of results. - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - o queryState: "String" - - A string encoding the current state of the query on the server. - This string MUST change if the results of the query (i.e., the - matching ids and their sort order) have changed. The queryState - string MAY change if something has changed on the server, which - means the results may have changed but the server doesn't know for - sure. - - The queryState string only represents the ordered list of ids that - match the particular query (including its sort/filter). There is - no requirement for it to change if a property on an object - matching the query changes but the query results are unaffected - (indeed, it is more efficient if the queryState string does not - change in this case). The queryState string only has meaning when - compared to future responses to a query with the same type/sort/ - filter or when used with /queryChanges to fetch changes. - - Should a client receive back a response with a different - queryState string to a previous call, it MUST either throw away - the currently cached query and fetch it again (note, this does not - require fetching the records again, just the list of ids) or call - "Foo/queryChanges" to get the difference. - - - - - - - - -Jenkins & Newman Standards Track [Page 46] - -RFC 8620 JMAP July 2019 - - - o canCalculateChanges: "Boolean" - - This is true if the server supports calling "Foo/queryChanges" - with these "filter"/"sort" parameters. Note, this does not - guarantee that the "Foo/queryChanges" call will succeed, as it may - only be possible for a limited time afterwards due to server - internal implementation details. - - o position: "UnsignedInt" - - The zero-based index of the first result in the "ids" array within - the complete list of query results. - - o ids: "Id[]" - - The list of ids for each Foo in the query results, starting at the - index given by the "position" argument of this response and - continuing until it hits the end of the results or reaches the - "limit" number of ids. If "position" is >= "total", this MUST be - the empty list. - - o total: "UnsignedInt" (only if requested) - - The total number of Foos in the results (given the "filter"). - This argument MUST be omitted if the "calculateTotal" request - argument is not true. - - o limit: "UnsignedInt" (if set by the server) - - The limit enforced by the server on the maximum number of results - to return. This is only returned if the server set a limit or - used a different limit than that given in the request. - - The following additional errors may be returned instead of the "Foo/ - query" response: - - "anchorNotFound": An anchor argument was supplied, but it cannot be - found in the results of the query. - - "unsupportedSort": The "sort" is syntactically valid, but it includes - a property the server does not support sorting on or a collation - method it does not recognise. - - "unsupportedFilter": The "filter" is syntactically valid, but the - server cannot process it. If the filter was the result of a user's - search input, the client SHOULD suggest that the user simplify their - search. - - - - -Jenkins & Newman Standards Track [Page 47] - -RFC 8620 JMAP July 2019 - - -5.6. /queryChanges - - The "Foo/queryChanges" method allows a client to efficiently update - the state of a cached query to match the new state on the server. It - takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o filter: "FilterOperator|FilterCondition|null" - - The filter argument that was used with "Foo/query". - - o sort: "Comparator[]|null" - - The sort argument that was used with "Foo/query". - - o sinceQueryState: "String" - - The current state of the query in the client. This is the string - that was returned as the "queryState" argument in the "Foo/query" - response with the same sort/filter. The server will return the - changes made to the query since this state. - - o maxChanges: "UnsignedInt|null" - - The maximum number of changes to return in the response. See - error descriptions below for more details. - - o upToId: "Id|null" - - The last (highest-index) id the client currently has cached from - the query results. When there are a large number of results, in a - common case, the client may have only downloaded and cached a - small subset from the beginning of the results. If the sort and - filter are both only on immutable properties, this allows the - server to omit changes after this point in the results, which can - significantly increase efficiency. If they are not immutable, - this argument is ignored. - - o calculateTotal: "Boolean" (default: false) - - Does the client wish to know the total number of results now in - the query? This may be slow and expensive for servers to - calculate, particularly with complex filters, so clients should - take care to only request the total when needed. - - - - -Jenkins & Newman Standards Track [Page 48] - -RFC 8620 JMAP July 2019 - - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - o oldQueryState: "String" - - This is the "sinceQueryState" argument echoed back; that is, the - state from which the server is returning changes. - - o newQueryState: "String" - - This is the state the query will be in after applying the set of - changes to the old state. - - o total: "UnsignedInt" (only if requested) - - The total number of Foos in the results (given the "filter"). - This argument MUST be omitted if the "calculateTotal" request - argument is not true. - - o removed: "Id[]" - - The "id" for every Foo that was in the query results in the old - state and that is not in the results in the new state. - - If the server cannot calculate this exactly, the server MAY return - the ids of extra Foos in addition that may have been in the old - results but are not in the new results. - - If the sort and filter are both only on immutable properties and - an "upToId" is supplied and exists in the results, any ids that - were removed but have a higher index than "upToId" SHOULD be - omitted. - - If the "filter" or "sort" includes a mutable property, the server - MUST include all Foos in the current results for which this - property may have changed. The position of these may have moved - in the results, so they must be reinserted by the client to ensure - its query cache is correct. - - - - - - - - - - -Jenkins & Newman Standards Track [Page 49] - -RFC 8620 JMAP July 2019 - - - o added: "AddedItem[]" - - The id and index in the query results (in the new state) for every - Foo that has been added to the results since the old state AND - every Foo in the current results that was included in the - "removed" array (due to a filter or sort based upon a mutable - property). - - If the sort and filter are both only on immutable properties and - an "upToId" is supplied and exists in the results, any ids that - were added but have a higher index than "upToId" SHOULD be - omitted. - - The array MUST be sorted in order of index, with the lowest index - first. - - An *AddedItem* object has the following properties: - - * id: "Id" - - * index: "UnsignedInt" - - The result of this is that if the client has a cached sparse array of - Foo ids corresponding to the results in the old state, then: - - fooIds = [ "id1", "id2", null, null, "id3", "id4", null, null, null ] - - If it *splices out* all ids in the removed array that it has in its - cached results, then: - - removed = [ "id2", "id31", ... ]; - fooIds => [ "id1", null, null, "id3", "id4", null, null, null ] - - and *splices in* (one by one in order, starting with the lowest - index) all of the ids in the added array: - - added = [{ id: "id5", index: 0, ... }]; - fooIds => [ "id5", "id1", null, null, "id3", "id4", null, null, null ] - - and *truncates* or *extends* to the new total length, then the - results will now be in the new state. - - Note: splicing in adds the item at the given index, incrementing the - index of all items previously at that or a higher index. Splicing - out is the inverse, removing the item and decrementing the index of - every item after it in the array. - - - - - -Jenkins & Newman Standards Track [Page 50] - -RFC 8620 JMAP July 2019 - - - The following additional errors may be returned instead of the "Foo/ - queryChanges" response: - - "tooManyChanges": There are more changes than the client's - "maxChanges" argument. Each item in the removed or added array is - considered to be one change. The client may retry with higher max - changes or invalidate its cache of the query results. - - "cannotCalculateChanges": The server cannot calculate the changes - from the queryState string given by the client, usually due to the - client's state being too old. The client MUST invalidate its cache - of the query results. - -5.7. Examples - - Suppose we have a type *Todo* with the following properties: - - o id: "Id" (immutable; server-set) - - The id of the object. - - o title: "String" - - A brief summary of what is to be done. - - o keywords: "String[Boolean]" (default: {}) - - A set of keywords that apply to the Todo. The set is represented - as an object, with the keys being the "keywords". The value for - each key in the object MUST be true. (This format allows you to - update an individual key using patch syntax rather than having to - update the whole set of keywords as one, which a "String[]" - representation would require.) - - o neuralNetworkTimeEstimation: "Number" (server-set) - - The title and keywords are fed into the server's state-of-the-art - neural network to get an estimation of how long this Todo will - take, in seconds. - - o subTodoIds: "Id[]|null" - - The ids of a list of other Todos to complete as part of this Todo. - - Suppose also that all the standard methods are defined for this type - and the FilterCondition object supports a "hasKeyword" property to - match Todos with the given keyword. - - - - -Jenkins & Newman Standards Track [Page 51] - -RFC 8620 JMAP July 2019 - - - A client might want to display the list of Todos with either a - "music" keyword or a "video" keyword, so it makes the following - method call: - - [[ "Todo/query", { - "accountId": "x", - "filter": { - "operator": "OR", - "conditions": [ - { "hasKeyword": "music" }, - { "hasKeyword": "video" } - ] - }, - "sort": [{ "property": "title" }], - "position": 0, - "limit": 10 - }, "0" ], - [ "Todo/get", { - "accountId": "x", - "#ids": { - "resultOf": "0", - "name": "Todo/query", - "path": "/ids" - } - }, "1" ]] - - - - - - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 52] - -RFC 8620 JMAP July 2019 - - - This would query the server for the set of Todos with a keyword of - either "music" or "video", sorted by title, and limited to the first - 10 results. It fetches the full object for each of these Todos using - back-references to reference the result of the query. The response - might look something like: - - [[ "Todo/query", { - "accountId": "x", - "queryState": "y13213", - "canCalculateChanges": true, - "position": 0, - "ids": [ "a", "b", "c", "d", "e", "f", "g", "h", "i", "j" ] - }, "0" ], - [ "Todo/get", { - "accountId": "x", - "state": "10324", - "list": [{ - "id": "a", - "title": "Practise Piano", - "keywords": { - "music": true, - "beethoven": true, - "mozart": true, - "liszt": true, - "rachmaninov": true - }, - "neuralNetworkTimeEstimation": 3600 - }, { - "id": "b", - "title": "Watch Daft Punk music video", - "keywords": { - "music": true, - "video": true, - "trance": true - }, - "neuralNetworkTimeEstimation": 18000 - }, - ... - ] - }, "1" ]] - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 53] - -RFC 8620 JMAP July 2019 - - - Now, suppose the user adds a keyword "chopin" and removes the keyword - "mozart" from the "Practise Piano" task. The client may send the - whole object to the server, as this is a valid PatchObject: - - [[ "Todo/set", { - "accountId": "x", - "ifInState": "10324", - "update": { - "a": { - "id": "a", - "title": "Practise Piano", - "keywords": { - "music": true, - "beethoven": true, - "chopin": true, - "liszt": true, - "rachmaninov": true - }, - "neuralNetworkTimeEstimation": 360 - } - } - }, "0" ]] - - or it may send a minimal patch: - - [[ "Todo/set", { - "accountId": "x", - "ifInState": "10324", - "update": { - "a": { - "keywords/chopin": true, - "keywords/mozart": null - } - } - }, "0" ]] - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 54] - -RFC 8620 JMAP July 2019 - - - The effect is exactly the same on the server in either case, and - presuming the server is still in state "10324", it will probably - return success: - - [[ "Todo/set", { - "accountId": "x", - "oldState": "10324", - "newState": "10329", - "updated": { - "a": { - "neuralNetworkTimeEstimation": 5400 - } - } - }, "0" ]] - - The server changed the "neuralNetworkTimeEstimation" property on the - object as part of this change; as this changed in a way *not* - explicitly requested by the PatchObject sent to the server, it is - returned with the "updated" confirmation. - - Let us now add a sub-Todo to our new "Practise Piano" Todo. In this - example, we can see the use of a reference to a creation id to allow - us to set a foreign key reference to a record created in the same - request: - - [[ "Todo/set", { - "accountId": "x", - "create": { - "k15": { - "title": "Warm up with scales" - } - }, - "update": { - "a": { - "subTodoIds": [ "#k15" ] - } - } - }, "0" ]] - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 55] - -RFC 8620 JMAP July 2019 - - - Now, suppose another user deleted the "Listen to Daft Punk" Todo. - The first user will receive a push notification (see Section 7) with - the changed state string for the "Todo" type. Since the new string - does not match its current state, it knows it needs to check for - updates. It may make a request like: - - [[ "Todo/changes", { - "accountId": "x", - "sinceState": "10324", - "maxChanges": 50 - }, "0" ], - [ "Todo/queryChanges", { - "accountId": "x", - "filter": { - "operator": "OR", - "conditions": [ - { "hasKeyword": "music" }, - { "hasKeyword": "video" } - ] - }, - "sort": [{ "property": "title" }], - "sinceQueryState": "y13213", - "maxChanges": 50 - }, "1" ]] - - and receive in response: - - [[ "Todo/changes", { - "accountId": "x", - "oldState": "10324", - "newState": "871903", - "hasMoreChanges": false, - "created": [], - "updated": [], - "destroyed": ["b"] - }, "0" ], - [ "Todo/queryChanges", { - "accountId": "x", - "oldQueryState": "y13213", - "newQueryState": "y13218", - "removed": ["b"], - "added": null - }, "1" ]] - - - - - - - - -Jenkins & Newman Standards Track [Page 56] - -RFC 8620 JMAP July 2019 - - - Suppose the user has access to another account "y", for example, a - team account shared between multiple users. To move an existing Todo - from account "x", the client would call: - - [[ "Todo/copy", { - "fromAccountId": "x", - "accountId": "y", - "create": { - "k5122": { - "id": "a" - } - }, - "onSuccessDestroyOriginal": true - }, "0" ]] - - The server successfully copies the Todo to a new account (where it - receives a new id) and deletes the original. Due to the implicit - call to "Todo/set", there are two responses to the single method - call, both with the same method call id: - - [[ "Todo/copy", { - "fromAccountId": "x", - "accountId": "y", - "created": { - "k5122": { - "id": "DAf97" - } - }, - "oldState": "c1d64ecb038c", - "newState": "33844835152b" - }, "0" ], - [ "Todo/set", { - "accountId": "x", - "oldState": "871903", - "newState": "871909", - "destroyed": [ "a" ], - ... - }, "0" ]] - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 57] - -RFC 8620 JMAP July 2019 - - -5.8. Proxy Considerations - - JMAP has been designed to allow an API endpoint to easily proxy - through to one or more JMAP servers. This may be useful for load - balancing, augmenting capabilities, or presenting a single endpoint - to accounts hosted on different JMAP servers (splitting the request - based on each method's "accountId" argument). The proxy need only - understand the general structure of a JMAP Request object; it does - not need to know anything specifically about the methods and - arguments it will pass through to other servers. - - If splitting up the methods in a request to call them on different - backend servers, the proxy must do two things to ensure back- - references and creation-id references resolve the same as if the - entire request were processed on a single server: - - 1. It must pass a "createdIds" property with each subrequest. If - this is not given by the client, an empty object should be used - for the first subrequest. The "createdIds" property of each - subresponse should be passed on in the next subrequest. - - 2. It must resolve back-references to previous method results that - were processed on a different server. This is a relatively - simple syntactic substitution, described in Section 3.7. - - When splitting a request based on accountId, proxy implementors do - need to be aware of "/copy" methods that copy between accounts. If - the accounts are on different servers, the proxy will have to - implement this functionality directly. - -6. Binary Data - - Binary data is referenced by a *blobId* in JMAP and uploaded/ - downloaded separately to the core API. The blobId solely represents - the raw bytes of data, not any associated metadata such as a file - name or content type. Such metadata is stored alongside the blobId - in the object referencing it. The data represented by a blobId is - immutable. - - Any blobId that exists within an account may be used when creating/ - updating another object in that account. For example, an Email type - may have a blobId that represents the object in Internet Message - Format [RFC5322]. A client could create a new Email object with an - attachment and use this blobId, in effect attaching the old message - to the new one. Similarly, it could attach any existing attachment - of an old message without having to download and upload it again. - - - - - -Jenkins & Newman Standards Track [Page 58] - -RFC 8620 JMAP July 2019 - - - When the client uses a blobId in a create/update, the server MAY - assign a new blobId to refer to the same binary data within the new/ - updated object. If it does so, it MUST return any properties that - contain a changed blobId in the created/updated response, so the - client gets the new ids. - - A blob that is not referenced by a JMAP object (e.g., as a message - attachment) MAY be deleted by the server to free up resources. - Uploads (see below) are initially unreferenced blobs. To ensure - interoperability: - - o The server SHOULD use a separate quota for unreferenced blobs to - the account's usual quota. In the case of shared accounts, this - quota SHOULD be separate per user. - - o This quota SHOULD be at least the maximum total size that a single - object can reference on this server. For example, if supporting - JMAP Mail, this should be at least the maximum total attachments - size for a message. - - o When an upload would take the user over quota, the server MUST - delete unreferenced blobs in date order, oldest first, until there - is room for the new blob. - - o Except where quota restrictions force early deletion, an - unreferenced blob MUST NOT be deleted for at least 1 hour from the - time of upload; if reuploaded, the same blobId MAY be returned, - but this SHOULD reset the expiry time. - - o A blob MUST NOT be deleted during the method call that removed the - last reference, so that a client can issue a create and a destroy - that both reference the blob within the same method call. - -6.1. Uploading Binary Data - - There is a single endpoint that handles all file uploads for an - account, regardless of what they are to be used for. The Session - object (see Section 2) has an "uploadUrl" property in URI Template - (level 1) format [RFC6570], which MUST contain a variable called - "accountId". The client may use this template in combination with an - "accountId" to get the URL of the file upload resource. - - To upload a file, the client submits an authenticated POST request to - the file upload resource. - - - - - - - -Jenkins & Newman Standards Track [Page 59] - -RFC 8620 JMAP July 2019 - - - A successful request MUST return a single JSON object with the - following properties as the response: - - o accountId: "Id" - - The id of the account used for the call. - - o blobId: "Id" - - The id representing the binary data uploaded. The data for this - id is immutable. The id *only* refers to the binary data, not any - metadata. - - o type: "String" - - The media type of the file (as specified in [RFC6838], - Section 4.2) as set in the Content-Type header of the upload HTTP - request. - - o size: "UnsignedInt" - - The size of the file in octets. - - If identical binary content to an existing blob in the account is - uploaded, the existing blobId MAY be returned. - - Clients should use the blobId returned in a timely manner. Under - rare circumstances, the server may have deleted the blob before the - client uses it; the client should keep a reference to the local file - so it can upload it again in such a situation. - - When an HTTP error response is returned to the client, the server - SHOULD return a JSON "problem details" object as the response body, - as per [RFC7807]. - - As access controls are often determined by the object holding the - reference to a blob, unreferenced blobs MUST only be accessible to - the uploader, even in shared accounts. - -6.2. Downloading Binary Data - - The Session object (see Section 2) has a "downloadUrl" property, - which is in URI Template (level 1) format [RFC6570]. The URL MUST - contain variables called "accountId", "blobId", "type", and "name". - - - - - - - -Jenkins & Newman Standards Track [Page 60] - -RFC 8620 JMAP July 2019 - - - To download a file, the client makes an authenticated GET request to - the download URL with the appropriate variables substituted in: - - o "accountId": The id of the account to which the record with the - blobId belongs. - - o "blobId": The blobId representing the data of the file to - download. - - o "type": The type for the server to set in the "Content-Type" - header of the response; the blobId only represents the binary data - and does not have a content-type innately associated with it. - - o "name": The name for the file; the server MUST return this as the - filename if it sets a "Content-Disposition" header. - - As the data for a particular blobId is immutable, and thus the - response in the generated download URL is too, implementors are - recommended to set long cache times and use the "immutable" Cache- - Control extension [RFC8246] for successful responses, for example, - "Cache-Control: private, immutable, max-age=31536000". - - When an HTTP error response is returned to the client, the server - SHOULD return a JSON "problem details" object as the response body, - as per [RFC7807]. - -6.3. Blob/copy - - Binary data may be copied *between* two different accounts using the - "Blob/copy" method rather than having to download and then reupload - on the client. - - The "Blob/copy" method takes the following arguments: - - o fromAccountId: "Id" - - The id of the account to copy blobs from. - - o accountId: "Id" - - The id of the account to copy blobs to. - - o blobIds: "Id[]" - - A list of ids of blobs to copy to the other account. - - - - - - -Jenkins & Newman Standards Track [Page 61] - -RFC 8620 JMAP July 2019 - - - The response has the following arguments: - - o fromAccountId: "Id" - - The id of the account blobs were copied from. - - o accountId: "Id" - - The id of the account blobs were copied to. - - o copied: "Id[Id]|null" - - A map of the blobId in the fromAccount to the id for the blob in - the account it was copied to, or null if none were successfully - copied. - - o notCopied: "Id[SetError]|null" - - A map of blobId to a SetError object for each blob that failed to - be copied, or null if none. - - The SetError may be any of the standard set errors that may be - returned for a create, as defined in Section 5.3. In addition, the - "notFound" SetError error may be returned if the blobId to be copied - cannot be found. - - The following additional method-level error may be returned instead - of the "Blob/copy" response: - - "fromAccountNotFound": The "fromAccountId" included with the request - does not correspond to a valid account. - -7. Push - - Push notifications allow clients to efficiently update (almost) - instantly to stay in sync with data changes on the server. The - general model for push is simple and sends minimal data over the push - channel: just enough for the client to know whether it needs to - resync. The format allows multiple changes to be coalesced into a - single push update and the frequency of pushes to be rate limited by - the server. It doesn't matter if some push events are dropped before - they reach the client; the next time it gets/sets any records of a - changed type, it will discover the data has changed and still sync - all changes. - - - - - - - -Jenkins & Newman Standards Track [Page 62] - -RFC 8620 JMAP July 2019 - - - There are two different mechanisms by which a client can receive push - notifications, to allow for the different environments in which a - client may exist. An event source resource (see Section 7.3) allows - clients that can hold transport connections open to receive push - notifications directly from the JMAP server. This is simple and - avoids third parties, but it is often not feasible on constrained - platforms such as mobile devices. Alternatively, clients can make - use of any push service supported by their environment. A URL for - the push service is registered with the JMAP server (see - Section 7.2); the server then POSTs each notification to that URL. - The push service is then responsible for routing these to the client. - -7.1. The StateChange Object - - When something changes on the server, the server pushes a StateChange - object to the client. A *StateChange* object has the following - properties: - - o @type: "String" - - This MUST be the string "StateChange". - - o changed: "Id[TypeState]" - - A map of an "account id" to an object encoding the state of data - types that have changed for that account since the last - StateChange object was pushed, for each of the accounts to which - the user has access and for which something has changed. - - A *TypeState* object is a map. The keys are the type name "Foo" - (e.g., "Mailbox" or "Email"), and the value is the "state" - property that would currently be returned by a call to "Foo/get". - - The client can compare the new state strings with its current - values to see whether it has the current data for these types. If - not, the changes can then be efficiently fetched in a single - standard API request (using the /changes type methods). - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 63] - -RFC 8620 JMAP July 2019 - - -7.1.1. Example - - In this example, the server has amalgamated a few changes together - across two different accounts the user has access to, before pushing - the following StateChange object to the client: - - { - "@type": "StateChange", - "changed": { - "a3123": { - "Email": "d35ecb040aab", - "EmailDelivery": "428d565f2440", - "CalendarEvent": "87accfac587a" - }, - "a43461d": { - "Mailbox": "0af7a512ce70", - "CalendarEvent": "7a4297cecd76" - } - } - } - - The client can compare the state strings with its current state for - the Email, CalendarEvent, etc., object types in the appropriate - accounts to see if it needs to fetch changes. - - If the client is itself making changes, it may receive a StateChange - object while the /set API call is in flight. It can wait until the - call completes and then compare if the new state string after the - /set is the same as was pushed in the StateChange object; if so, and - the old state of the /set response matches the client's previous - state, it does not need to waste a request asking for changes it - already knows. - -7.2. PushSubscription - - Clients may create a PushSubscription to register a URL with the JMAP - server. The JMAP server will then make an HTTP POST request to this - URL for each push notification it wishes to send to the client. - - As a push subscription causes the JMAP server to make a number of - requests to a previously unknown endpoint, it can be used as a vector - for launching a denial-of-service attack. To prevent this, when a - subscription is created, the JMAP server immediately sends a - PushVerification object to that URL (see Section 7.2.2). The JMAP - server MUST NOT make any further requests to the URL until the client - receives the push and updates the subscription with the correct - verification code. - - - - -Jenkins & Newman Standards Track [Page 64] - -RFC 8620 JMAP July 2019 - - - A *PushSubscription* object has the following properties: - - o id: "Id" (immutable; server-set) - - The id of the push subscription. - - o deviceClientId: "String" (immutable) - - An id that uniquely identifies the client + device it is running - on. The purpose of this is to allow clients to identify which - PushSubscription objects they created even if they lose their - local state, so they can revoke or update them. This string MUST - be different on different devices and be different from apps from - other vendors. It SHOULD be easy to regenerate and not depend on - persisted state. It is RECOMMENDED to use a secure hash of a - string that contains: - - 1. A unique identifier associated with the device where the JMAP - client is running, normally supplied by the device's operating - system. - - 2. A custom vendor/app id, including a domain controlled by the - vendor of the JMAP client. - - To protect the privacy of the user, the deviceClientId id MUST NOT - contain an unobfuscated device id. - - o url: "String" (immutable) - - An absolute URL where the JMAP server will POST the data for the - push message. This MUST begin with "https://". - - o keys: "Object|null" (immutable) - - Client-generated encryption keys. If supplied, the server MUST - use them as specified in [RFC8291] to encrypt all data sent to the - push subscription. The object MUST have the following properties: - - * p256dh: "String" - - The P-256 Elliptic Curve Diffie-Hellman (ECDH) public key as - described in [RFC8291], encoded in URL-safe base64 - representation as defined in [RFC4648]. - - * auth: "String" - - The authentication secret as described in [RFC8291], encoded in - URL-safe base64 representation as defined in [RFC4648]. - - - -Jenkins & Newman Standards Track [Page 65] - -RFC 8620 JMAP July 2019 - - - o verificationCode: "String|null" - - This MUST be null (or omitted) when the subscription is created. - The JMAP server then generates a verification code and sends it in - a push message, and the client updates the PushSubscription object - with the code; see Section 7.2.2 for details. - - o expires: "UTCDate|null" - - The time this push subscription expires. If specified, the JMAP - server MUST NOT make further requests to this resource after this - time. It MAY automatically destroy the push subscription at or - after this time. - - The server MAY choose to set an expiry if none is given by the - client or modify the expiry time given by the client to a shorter - duration. - - o types: "String[]|null" - - A list of types the client is interested in (using the same names - as the keys in the TypeState object defined in the previous - section). A StateChange notification will only be sent if the - data for one of these types changes. Other types are omitted from - the TypeState object. If null, changes will be pushed for all - types. - - The POST request MUST have a content type of "application/json" and - contain the UTF-8 JSON-encoded object as the body. The request MUST - have a "TTL" header and MAY have "Urgency" and/or "Topic" headers, as - specified in Section 5 of [RFC8030]. The JMAP server is expected to - understand and handle HTTP status responses in a reasonable manner. - A "429" (Too Many Requests) response MUST cause the JMAP server to - reduce the frequency of pushes; the JMAP push structure allows - multiple changes to be coalesced into a single minimal StateChange - object. See the security considerations in Section 8.6 for a - discussion of the risks in connecting to unknown servers. - - The JMAP server acts as an application server as defined in - [RFC8030]. A client MAY use the rest of [RFC8030] in combination - with its own push service to form a complete end-to-end solution, or - it MAY rely on alternative mechanisms to ensure the delivery of the - pushed data after it leaves the JMAP server. - - The push subscription is tied to the credentials used to authenticate - the API request that created it. Should these credentials expire or - be revoked, the push subscription MUST be destroyed by the JMAP - - - - -Jenkins & Newman Standards Track [Page 66] - -RFC 8620 JMAP July 2019 - - - server. Only subscriptions created by these credentials are returned - when the client fetches existing subscriptions. - - When these credentials have their own expiry (i.e., it is a session - with a timeout), the server SHOULD NOT set or bound the expiry time - for the push subscription given by the client but MUST expire it when - the session expires. - - When these credentials are not time bounded (e.g., Basic - authentication [RFC7617]), the server SHOULD set an expiry time for - the push subscription if none is given and limit the expiry time if - set too far in the future. This maximum expiry time MUST be at least - 48 hours in the future and SHOULD be at least 7 days in the future. - An app running on a mobile device may only be able to refresh the - push subscription lifetime when it is in the foreground, so this - gives a reasonable time frame to allow this to happen. - - In the case of separate access and refresh credentials, as in Oauth - 2.0 [RFC6749], the server SHOULD tie the push subscription to the - validity of the refresh token rather than the access token and behave - according to whether this is time-limited or not. - - When a push subscription is destroyed, the server MUST securely erase - the URL and encryption keys from memory and storage as soon as - possible. - -7.2.1. PushSubscription/get - - Standard /get method as described in Section 5.1, except it does - *not* take or return an "accountId" argument, as push subscriptions - are not tied to specific accounts. It also does *not* return a - "state" argument. The "ids" argument may be null to fetch all at - once. - - The server MUST only return push subscriptions that were created - using the same authentication credentials as for this - "PushSubscription/get" request. - - As the "url" and "keys" properties may contain data that is private - to a particular device, the values for these properties MUST NOT be - returned. If the "properties" argument is null or omitted, the - server MUST default to all properties excluding these two. If one of - them is explicitly requested, the method call MUST be rejected with a - "forbidden" error. - - - - - - - -Jenkins & Newman Standards Track [Page 67] - -RFC 8620 JMAP July 2019 - - -7.2.2. PushSubscription/set - - Standard /set method as described in Section 5.3, except it does - *not* take or return an "accountId" argument, as push subscriptions - are not tied to specific accounts. It also does *not* take an - "ifInState" argument or return "oldState" or "newState" arguments. - - The "url" and "keys" properties are immutable; if the client wishes - to change these, it must destroy the current push subscription and - create a new one. - - When a PushSubscription is created, the server MUST immediately push - a *PushVerification* object to the URL. It has the following - properties: - - o @type: "String" - - This MUST be the string "PushVerification". - - o pushSubscriptionId: "String" - - The id of the push subscription that was created. - - o verificationCode: "String" - - The verification code to add to the push subscription. This MUST - contain sufficient entropy to avoid the client being able to guess - the code via brute force. - - The client MUST update the push subscription with the correct - verification code before the server makes any further requests to the - subscription's URL. Attempts to update the subscription with an - invalid verification code MUST be rejected by the server with an - "invalidProperties" SetError. - - The client may update the "expires" property to extend (or, less - commonly, shorten) the lifetime of a push subscription. The server - MAY modify the proposed new expiry time to enforce server-defined - limits. Extending the lifetime does not require the subscription to - be verified again. - - Clients SHOULD NOT update or destroy a push subscription that they - did not create (i.e., has a "deviceClientId" that they do not - recognise). - - - - - - - -Jenkins & Newman Standards Track [Page 68] - -RFC 8620 JMAP July 2019 - - -7.2.3. Example - - At "2018-07-06T02:14:29Z", a client with deviceClientId "a889-ffea- - 910" fetches the set of push subscriptions currently on the server, - making an API request with: - - [[ "PushSubscription/get", { - "ids": null - }, "0" ]] - - Which returns: - - [[ "PushSubscription/get", { - "list": [{ - "id": "e50b2c1d-9553-41a3-b0a7-a7d26b599ee1", - "deviceClientId": "b37ff8001ca0", - "verificationCode": "b210ef734fe5f439c1ca386421359f7b", - "expires": "2018-07-31T00:13:21Z", - "types": [ "Todo" ] - }, { - "id": "f2d0aab5-e976-4e8b-ad4b-b380a5b987e4", - "deviceClientId": "X8980fc", - "verificationCode": "f3d4618a9ae15c8b7f5582533786d531", - "expires": "2018-07-12T05:55:00Z", - "types": [ "Mailbox", "Email", "EmailDelivery" ] - }], - "notFound": [] - }, "0" ]] - - Since neither of the returned push subscription objects have the - client's deviceClientId, it knows it does not have a current push - subscription active on the server. So it creates one, sending this - request: - -[[ "PushSubscription/set", { - "create": { - "4f29": { - "deviceClientId": "a889-ffea-910", - "url": "https://example.com/push/?device=X8980fc&client=12c6d086", - "types": null - } - } -}, "0" ]] - - - - - - - - -Jenkins & Newman Standards Track [Page 69] - -RFC 8620 JMAP July 2019 - - - The server creates the push subscription but limits the expiry time - to 7 days in the future, returning this response: - - [[ "PushSubscription/set", { - "created": { - "4f29": { - "id": "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60", - "keys": null, - "expires": "2018-07-13T02:14:29Z" - } - } - }, "0" ]] - - The server also immediately makes a POST request to - "https://example.com/push/?device=X8980fc&client=12c6d086" with the - data: - - { - "@type": "PushVerification", - "pushSubscriptionId": "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60", - "verificationCode": "da1f097b11ca17f06424e30bf02bfa67" - } - - The client receives this and updates the subscription with the - verification code (note there is a potential race condition here; the - client MUST be able to handle receiving the push while the request - creating the subscription is still in progress): - - [[ "PushSubscription/set", { - "update": { - "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": { - "verificationCode": "da1f097b11ca17f06424e30bf02bfa67" - } - } - }, "0" ]] - - The server confirms the update was successful and will now make - requests to the registered URL when the state changes. - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 70] - -RFC 8620 JMAP July 2019 - - - Two days later, the client updates the subscription to extend its - lifetime, sending this request: - - [[ "PushSubscription/set", { - "update": { - "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": { - "expires": "2018-08-13T00:00:00Z" - } - } - }, "0" ]] - - The server extends the expiry time, but only again to its maximum - limit of 7 days in the future, returning this response: - - [[ "PushSubscription/set", { - "updated": { - "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": { - "expires": "2018-07-15T02:22:50Z" - } - } - }, "0" ]] - -7.3. Event Source - - Clients that can hold transport connections open can connect directly - to the JMAP server to receive push notifications via a "text/event- - stream" resource, as described in [EventSource]. This is a long - running HTTP request, where the server can push data to the client by - appending data without ending the response. - - When a change occurs in the data on the server, it pushes an event - called "state" to any connected clients, with the StateChange object - as the data. - - The server SHOULD also send a new event id that encodes the entire - server state visible to the user immediately after sending a "state" - event. When a new connection is made to the event-source endpoint, a - client following the server-sent events specification will send a - Last-Event-ID HTTP header field with the last id it saw, which the - server can use to work out whether the client has missed some - changes. If so, it SHOULD send these changes immediately on - connection. - - The Session object (see Section 2) has an "eventSourceUrl" property, - which is in URI Template (level 1) format [RFC6570]. The URL MUST - contain variables called "types", "closeafter", and "ping". - - - - - -Jenkins & Newman Standards Track [Page 71] - -RFC 8620 JMAP July 2019 - - - To connect to the resource, the client makes an authenticated GET - request to the event-source URL with the appropriate variables - substituted in: - - o "types": This MUST be either: - - * A comma-separated list of type names, e.g., - "Email,CalendarEvent". The server MUST only push changes for - the types in this list. - - * The single character: "*". Changes to all types are pushed. - - o "closeafter": This MUST be one of the following values: - - * "state": The server MUST end the HTTP response after pushing a - state event. This can be used by clients in environments where - buffering proxies prevent the pushed data from arriving - immediately, or indeed at all, when operating in the usual - mode. - - * "no": The connection is persisted by the server as a standard - event-source resource. - - o "ping": A positive integer value representing a length of time in - seconds, e.g., "300". If non-zero, the server MUST send an event - called "ping" whenever this time elapses since the previous event - was sent. This MUST NOT set a new event id. If the value is "0", - the server MUST NOT send ping events. - - The server MAY modify a requested ping interval to be subject to a - minimum and/or maximum value. For interoperability, servers MUST - NOT have a minimum allowed value higher than 30 or a maximum - allowed value less than 300. - - The data for the ping event MUST be a JSON object containing an - "interval" property, the value (type "UnsignedInt") being the - interval in seconds the server is using to send pings (this may be - different to the requested value if the server clamped it to be - within a min/max value). - - Clients can monitor for the ping event to help determine when the - closeafter mode may be required. - - A client MAY hold open multiple connections to the event-source - resource, although it SHOULD try to use a single connection for - efficiency. - - - - - -Jenkins & Newman Standards Track [Page 72] - -RFC 8620 JMAP July 2019 - - -8. Security Considerations - -8.1. Transport Confidentiality - - To ensure the confidentiality and integrity of data sent and received - via JMAP, all requests MUST use TLS 1.2 [RFC5246] [RFC8446] or later, - following the recommendations in [RFC7525]. Servers SHOULD support - TLS 1.3 [RFC8446] or later. - - Clients MUST validate TLS certificate chains to protect against - man-in-the-middle attacks [RFC5280]. - -8.2. Authentication Scheme - - A number of HTTP authentication schemes have been standardised (see - ). Servers - should take care to assess the security characteristics of different - schemes in relation to their needs when deciding what to implement. - - Use of the Basic authentication scheme is NOT RECOMMENDED. Services - that choose to use it are strongly recommended to require generation - of a unique "app password" via some external mechanism for each - client they wish to connect. This allows connections from different - devices to be differentiated by the server and access to be - individually revoked. - -8.3. Service Autodiscovery - - Unless secured by something like DNSSEC, autodiscovery of server - details using SRV DNS records is vulnerable to a DNS poisoning - attack, which can lead to the client talking to an attacker's server - instead of the real JMAP server. The attacker may then intercept - requests to execute man-in-the-middle attacks and, depending on the - authentication scheme, steal credentials to generate its own - requests. - - Clients that do not support SRV lookups are likely to try just using - the "/.well-known/jmap" path directly against the domain of the - username over HTTPS. Servers SHOULD ensure this path resolves or - redirects to the correct JMAP Session resource to allow this to work. - If this is not feasible, servers MUST ensure this path cannot be - controlled by an attacker, as again it may be used to steal - credentials. - - - - - - - - -Jenkins & Newman Standards Track [Page 73] - -RFC 8620 JMAP July 2019 - - -8.4. JSON Parsing - - The Security Considerations of [RFC8259] apply to the use of JSON as - the data interchange format. - - As for any serialization format, parsers need to thoroughly check the - syntax of the supplied data. JSON uses opening and closing tags for - several types and structures, and it is possible that the end of the - supplied data will be reached when scanning for a matching closing - tag; this is an error condition, and implementations need to stop - scanning at the end of the supplied data. - - JSON also uses a string encoding with some escape sequences to encode - special characters within a string. Care is needed when processing - these escape sequences to ensure that they are fully formed before - the special processing is triggered, with special care taken when the - escape sequences appear adjacent to other (non-escaped) special - characters or adjacent to the end of data (as in the previous - paragraph). - - If parsing JSON into a non-textual structured data format, - implementations may need to allocate storage to hold JSON string - elements. Since JSON does not use explicit string lengths, the risk - of denial of service due to resource exhaustion is small, but - implementations may still wish to place limits on the size of - allocations they are willing to make in any given context, to avoid - untrusted data causing excessive memory allocation. - -8.5. Denial of Service - - A small request may result in a very large response and require - considerable work on the server if resource limits are not enforced. - JMAP provides mechanisms for advertising and enforcing a wide variety - of limits for mitigating this threat, including limits on the number - of objects fetched in a single method call, number of methods in a - single request, number of concurrent requests, etc. - - JMAP servers MUST implement sensible limits to mitigate against - resource exhaustion attacks. - -8.6. Connection to Unknown Push Server - - When a push subscription is registered, the application server will - make POST requests to the given URL. There are a number of security - considerations that MUST be considered when implementing this. - - - - - - -Jenkins & Newman Standards Track [Page 74] - -RFC 8620 JMAP July 2019 - - - The server MUST ensure the URL is externally resolvable to avoid - server-side request forgery, where the server makes a request to a - resource on its internal network. - - A malicious client may use the push subscription to attempt to flood - a third party server with requests, creating a denial-of-service - attack and masking the attacker's true identity. There is no - guarantee that the URL given to the JMAP server is actually a valid - push server. Upon creation of a push subscription, the JMAP server - sends a PushVerification object to the URL and MUST NOT send any - further requests until the client verifies it has received the - initial push. The verification code MUST contain sufficient entropy - to prevent the client from being able to verify the subscription via - brute force. - - The verification code does not guarantee the URL is a valid push - server, only that the client is able to access the data submitted to - it. While the verification step significantly reduces the set of - potential targets, there is still a risk that the server is unrelated - to the client and being targeted for a denial-of-service attack. - - The server MUST limit the number of push subscriptions any one user - may have to ensure the user cannot cause the server to send a large - number of push notifications at once, which could again be used as - part of a denial-of-service attack. The rate of creation MUST also - be limited to minimise the ability to abuse the verification request - as an attack vector. - -8.7. Push Encryption - - When data changes, a small object is pushed with the new state - strings for the types that have changed. While the data here is - minimal, a passive man-in-the-middle attacker may be able to gain - useful information. To ensure confidentiality and integrity, if the - push is sent via a third party outside of the control of the client - and JMAP server, the client MUST specify encryption keys when - establishing the PushSubscription and ignore any push notification - received that is not encrypted with those keys. - - The privacy and security considerations of [RFC8030] and [RFC8291] - also apply to the use of the PushSubscription mechanism. - - As there is no crypto algorithm agility in Web Push Encryption - [RFC8291], a new specification will be needed to provide this if new - algorithms are required in the future. - - - - - - -Jenkins & Newman Standards Track [Page 75] - -RFC 8620 JMAP July 2019 - - -8.8. Traffic Analysis - - While the data is encrypted, a passive observer with the ability to - monitor network traffic may be able to glean information from the - timing of API requests and push notifications. For example, suppose - an email or calendar invitation is sent from User A (hosted on Server - X) to User B (hosted on Server Y). If Server X hosts data for many - users, a passive observer can see that the two servers connected but - does not know who the data was for. However, if a push notification - is immediately sent to User B and the attacker can observe this as - well, they may reasonably conclude that someone on Server X is - connecting to User B. - -9. IANA Considerations - -9.1. Assignment of jmap Service Name - - IANA has assigned the 'jmap' service name in the "Service Name and - Transport Protocol Port Number Registry" [RFC6335]. - - Service Name: jmap - - Transport Protocol(s): tcp - - Assignee: IESG - - Contact: IETF Chair - - Description: JSON Meta Application Protocol - - Reference: RFC 8620 - - Assignment Notes: This service name was previously assigned under the - name "JSON Mail Access Protocol". This has been de-assigned and - re-assigned with the approval of the previous assignee. - -9.2. Registration of Well-Known URI Suffix for JMAP - - IANA has registered the following suffix in the "Well-Known URIs" - registry for JMAP, as described in [RFC8615]: - - URI Suffix: jmap - - Change Controller: IETF - - Specification Document: RFC 8620, Section 2.2. - - - - - -Jenkins & Newman Standards Track [Page 76] - -RFC 8620 JMAP July 2019 - - -9.3. Registration of the jmap URN Sub-namespace - - IANA has registered the following URN sub-namespace in the "IETF URN - Sub-namespace for Registered Protocol Parameter Identifiers" registry - within the "Uniform Resource Name (URN) Namespace for IETF Use" - registry as described in [RFC3553]. - - Registered Parameter Identifier: jmap - - Reference: RFC 8620, Section 9.4 - - IANA Registry Reference: http://www.iana.org/assignments/jmap - -9.4. Creation of "JMAP Capabilities" Registry - - IANA has created the "JMAP Capabilities" registry as described in - Section 2. JMAP capabilities are advertised in the "capabilities" - property of the JMAP Session resource. They are used to extend the - functionality of a JMAP server. A capability is referenced by a URI. - The JMAP capability URI can be a URN starting with - "urn:ietf:params:jmap:" plus a unique suffix that is the index value - in the jmap URN sub-namespace. Registration of a JMAP capability - with another form of URI has no impact on the jmap URN sub-namespace. - - This registry follows the expert review process unless the "intended - use" field is "common" or "placeholder", in which case registration - follows the specification required process. - - A JMAP capability registration can have an intended use of "common", - "placeholder", "limited", or "obsolete". IANA will list common-use - registrations prominently and separately from those with other - intended use values. - - The JMAP capability registration procedure is not a formal standards - process but rather an administrative procedure intended to allow - community comment and sanity checking without excessive time delay. - - A "placeholder" registration reserves part of the jmap URN namespace - for another purpose but is typically not included in the - "capabilities" property of the JMAP Session resource. - -9.4.1. Preliminary Community Review - - Notice of a potential JMAP common-use registration SHOULD be sent to - the JMAP mailing list for review. This mailing list - is appropriate to solicit community feedback on a proposed JMAP - - - - - -Jenkins & Newman Standards Track [Page 77] - -RFC 8620 JMAP July 2019 - - - capability. Registrations that are not intended for common use MAY - be sent to the list for review as well; doing so is entirely - OPTIONAL, but is encouraged. - - The intent of the public posting to this list is to solicit comments - and feedback on the choice of the capability name, the unambiguity of - the specification document, and a review of any interoperability or - security considerations. The submitter may submit a revised - registration proposal or abandon the registration completely at any - time. - -9.4.2. Submit Request to IANA - - Registration requests can be sent to . - -9.4.3. Designated Expert Review - - For a limited-use registration, the primary concern of the designated - expert (DE) is preventing name collisions and encouraging the - submitter to document security and privacy considerations; a - published specification is not required. For a common-use - registration, the DE is expected to confirm that suitable - documentation, as described in Section 4.6 of [RFC8126], is - available. The DE should also verify that the capability does not - conflict with work that is active or already published within the - IETF. - - Before a period of 30 days has passed, the DE will either approve or - deny the registration request and publish a notice of the decision to - the JMAP WG mailing list or its successor, as well as inform IANA. A - denial notice must be justified by an explanation, and, in the cases - where it is possible, concrete suggestions on how the request can be - modified so as to become acceptable should be provided. - - If the DE does not respond within 30 days, the registrant may request - the IESG take action to process the request in a timely manner. - -9.4.4. Change Procedures - - Once a JMAP capability has been published by the IANA, the change - controller may request a change to its definition. The same - procedure that would be appropriate for the original registration - request is used to process a change request. - - JMAP capability registrations may not be deleted; capabilities that - are no longer believed appropriate for use can be declared obsolete - by a change to their "intended use" field; such capabilities will be - clearly marked in the lists published by the IANA. - - - -Jenkins & Newman Standards Track [Page 78] - -RFC 8620 JMAP July 2019 - - - Significant changes to a capability's definition should be requested - only when there are serious omissions or errors in the published - specification. When review is required, a change request may be - denied if it renders entities that were valid under the previous - definition invalid under the new definition. - - The owner of a JMAP capability may pass responsibility to another - person or agency by informing the IANA; this can be done without - discussion or review. - - The IESG may reassign responsibility for a JMAP capability. The most - common case of this will be to enable changes to be made to - capabilities where the author of the registration has died, moved out - of contact, or is otherwise unable to make changes that are important - to the community. - -9.4.5. JMAP Capabilities Registry Template - - Capability name: (see capability property in Section 2) - - Specification document: - - Intended use: (one of common, limited, placeholder, or obsolete) - - Change controller: ("IETF" for Standards Track / BCP RFCs) - - Security and privacy considerations: - -9.4.6. Initial Registration for JMAP Core - - Capability Name: "urn:ietf:params:jmap:core" - - Specification document: RFC 8620, Section 2 - - Intended use: common - - Change Controller: IETF - - Security and privacy considerations: RFC 8620, Section 8. - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 79] - -RFC 8620 JMAP July 2019 - - -9.4.7. Registration for JMAP Error Placeholder in JMAP Capabilities - Registry - - Capability Name: "urn:ietf:params:jmap:error:" - - Specification document: RFC 8620, Section 9.5 - - Intended use: placeholder - - Change Controller: IETF - - Security and privacy considerations: RFC 8620, Section 8. - -9.5. Creation of "JMAP Error Codes" Registry - - IANA has created the "JMAP Error Codes" registry. JMAP error codes - appear in the "type" member of a JSON problem details object (as - described in Section 3.6.1), the "type" member in a JMAP error object - (as described in Section 3.6.2), or the "type" member of a JMAP - method-specific error object (such as SetError in Section 5.3). When - used in a problem details object, the prefix - "urn:ietf:params:jmap:error:" is always included; when used in JMAP - objects, the prefix is always omitted. - - This registry follows the expert review process. Preliminary - community review for this registry follows the same procedures as the - "JMAP Capabilities" registry, but it is optional. The change - procedures for this registry are the same as the change procedures - for the "JMAP Capabilities" registry. - -9.5.1. Expert Review - - The designated expert should review the following aspects of the - registration: - - 1. Verify the error code does not conflict with existing names. - - 2. Verify the error code follows the syntax limitations (does not - require URI encoding). - - 3. Encourage the submitter to follow the naming convention of - previously registered errors. - - 4. Encourage the submitter to describe client behaviours that are - recommended in response to the error code. These may distinguish - the error code from other error codes. - - - - - -Jenkins & Newman Standards Track [Page 80] - -RFC 8620 JMAP July 2019 - - - 5. Encourage the submitter to describe when the server should issue - the error as opposed to some other error code. - - 6. Encourage the submitter to note any security considerations - associated with the error, if any (e.g., an error code that might - disclose existence of data the authenticated user does not have - permission to know about). - - Steps 3-6 are meant to promote a higher-quality registry. However, - the expert is encouraged to approve any registration that would not - actively harm JMAP interoperability to make this a relatively - lightweight process. - -9.5.2. JMAP Error Codes Registry Template - - JMAP Error Code: - - Intended use: (one of "common", "limited", "obsolete") - - Change Controller: ("IETF" for Standards Track / BCP RFCs) - - Reference: (Optional. Only required if defined in an RFC.) - - Description: - -9.5.3. Initial Contents for the JMAP Error Codes Registry - - o JMAP Error Code: accountNotFound - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: The accountId does not correspond to a valid account. - - o JMAP Error Code: accountNotSupportedByMethod - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: The accountId given corresponds to a valid account, - but the account does not support this method or data type. - - o JMAP Error Code: accountReadOnly - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: This method modifies state, but the account is read- - only (as returned on the corresponding Account object in the JMAP - Session resource). - - - - -Jenkins & Newman Standards Track [Page 81] - -RFC 8620 JMAP July 2019 - - - o JMAP Error Code: anchorNotFound - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.5 - Description: An anchor argument was supplied, but it cannot be - found in the results of the query. - - o JMAP Error Code: alreadyExists - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.4 - Description: The server forbids duplicates, and the record already - exists in the target account. An existingId property of type Id - MUST be included on the SetError object with the id of the - existing record. - - o JMAP Error Code: cannotCalculateChanges - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Sections 5.2 and 5.6 - Description: The server cannot calculate the changes from the - state string given by the client. - - o JMAP Error Code: forbidden - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Sections 3.6.2, 5.3, and 7.2.1 - Description: The action would violate an ACL or other permissions - policy. - - o JMAP Error Code: fromAccountNotFound - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Sections 5.4 and 6.3 - Description: The fromAccountId does not correspond to a valid - account. - - o JMAP Error Code: fromAccountNotSupportedByMethod - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.4 - Description: The fromAccountId given corresponds to a valid - account, but the account does not support this data type. - - - - - - - - -Jenkins & Newman Standards Track [Page 82] - -RFC 8620 JMAP July 2019 - - - o JMAP Error Code: invalidArguments - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: One of the arguments is of the wrong type or - otherwise invalid, or a required argument is missing. - - o JMAP Error Code: invalidPatch - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The PatchObject given to update the record was not a - valid patch. - - o JMAP Error Code: invalidProperties - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The record given is invalid. - - o JMAP Error Code: notFound - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The id given cannot be found. - - o JMAP Error Code: notJSON - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.1 - Description: The content type of the request was not application/ - json, or the request did not parse as I-JSON. - - o JMAP Error Code: notRequest - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.1 - Description: The request parsed as JSON but did not match the type - signature of the Request object. - - o JMAP Error Code: overQuota - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The create would exceed a server-defined limit on the - number or total size of objects of this type. - - - - - -Jenkins & Newman Standards Track [Page 83] - -RFC 8620 JMAP July 2019 - - - o JMAP Error Code: rateLimit - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: Too many objects of this type have been created - recently, and a server-defined rate limit has been reached. It - may work if tried again later. - - o JMAP Error Code: requestTooLarge - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Sections 5.1 and 5.3 - Description: The total number of actions exceeds the maximum - number the server is willing to process in a single method call. - - o JMAP Error Code: invalidResultReference - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: The method used a result reference for one of its - arguments, but this failed to resolve. - - o JMAP Error Code: serverFail - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: An unexpected or unknown error occurred during the - processing of the call. The method call made no changes to the - server's state. - - o JMAP Error Code: serverPartialFail - Intended Use: Limited - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: Some, but not all, expected changes described by the - method occurred. The client MUST resynchronise impacted data to - determine the server state. Use of this error is strongly - discouraged. - - o JMAP Error Code: serverUnavailable - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: Some internal server resource was temporarily - unavailable. Attempting the same operation later (perhaps after a - backoff with a random factor) may succeed. - - - - - -Jenkins & Newman Standards Track [Page 84] - -RFC 8620 JMAP July 2019 - - - o JMAP Error Code: singleton - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: This is a singleton type, so you cannot create - another one or destroy the existing one. - - o JMAP Error Code: stateMismatch - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: An ifInState argument was supplied, and it does not - match the current state. - - o JMAP Error Code: tooLarge - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The action would result in an object that exceeds a - server-defined limit for the maximum size of a single object of - this type. - - o JMAP Error Code: tooManyChanges - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.6 - Description: There are more changes than the client's maxChanges - argument. - - o JMAP Error Code: unknownCapability - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.1 - Description: The client included a capability in the "using" - property of the request that the server does not support. - - o JMAP Error Code: unknownMethod - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 3.6.2 - Description: The server does not recognise this method name. - - o JMAP Error Code: unsupportedFilter - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.5 - Description: The filter is syntactically valid, but the server - cannot process it. - - - -Jenkins & Newman Standards Track [Page 85] - -RFC 8620 JMAP July 2019 - - - o JMAP Error Code: unsupportedSort - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.5 - Description: The sort is syntactically valid but includes a - property the server does not support sorting on or a collation - method it does not recognise. - - o JMAP Error Code: willDestroy - Intended Use: Common - Change Controller: IETF - Reference: RFC 8620, Section 5.3 - Description: The client requested an object be both updated and - destroyed in the same /set request, and the server has decided to - therefore ignore the update. - -10. References - -10.1. Normative References - - [EventSource] - Hickson, I., "Server-Sent Events", World Wide Web - Consortium Recommendation REC-eventsource-20150203, - February 2015, . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - DOI 10.17487/RFC2782, February 2000, - . - - [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, - DOI 10.17487/RFC2818, May 2000, - . - - [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: - Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, - . - - [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An - IETF URN Sub-namespace for Registered Protocol - Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June - 2003, . - - - - -Jenkins & Newman Standards Track [Page 86] - -RFC 8620 JMAP July 2019 - - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November - 2003, . - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, - . - - [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet - Application Protocol Collation Registry", RFC 4790, - DOI 10.17487/RFC4790, March 2007, - . - - [RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation - Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007, - . - - [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, - DOI 10.17487/RFC5246, August 2008, - . - - [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation List - (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, - . - - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - DOI 10.17487/RFC5322, October 2008, - . - - [RFC6186] Daboo, C., "Use of SRV Records for Locating Email - Submission/Access Services", RFC 6186, - DOI 10.17487/RFC6186, March 2011, - . - - [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. - Cheshire, "Internet Assigned Numbers Authority (IANA) - Procedures for the Management of the Service Name and - Transport Protocol Port Number Registry", BCP 165, - RFC 6335, DOI 10.17487/RFC6335, August 2011, - . - - [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., - and D. Orchard, "URI Template", RFC 6570, - DOI 10.17487/RFC6570, March 2012, - . - - - -Jenkins & Newman Standards Track [Page 87] - -RFC 8620 JMAP July 2019 - - - [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", - RFC 6749, DOI 10.17487/RFC6749, October 2012, - . - - [RFC6764] Daboo, C., "Locating Services for Calendaring Extensions - to WebDAV (CalDAV) and vCard Extensions to WebDAV - (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, - . - - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type - Specifications and Registration Procedures", BCP 13, - RFC 6838, DOI 10.17487/RFC6838, January 2013, - . - - [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., - "JavaScript Object Notation (JSON) Pointer", RFC 6901, - DOI 10.17487/RFC6901, April 2013, - . - - [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Message Syntax and Routing", - RFC 7230, DOI 10.17487/RFC7230, June 2014, - . - - [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Semantics and Content", RFC 7231, - DOI 10.17487/RFC7231, June 2014, - . - - [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, - DOI 10.17487/RFC7493, March 2015, - . - - [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, - "Recommendations for Secure Use of Transport Layer - Security (TLS) and Datagram Transport Layer Security - (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May - 2015, . - - [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", - RFC 7617, DOI 10.17487/RFC7617, September 2015, - . - - [RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP - APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, - . - - - - - -Jenkins & Newman Standards Track [Page 88] - -RFC 8620 JMAP July 2019 - - - [RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic - Event Delivery Using HTTP Push", RFC 8030, - DOI 10.17487/RFC8030, December 2016, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data - Interchange Format", STD 90, RFC 8259, - DOI 10.17487/RFC8259, December 2017, - . - - [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: - Preparation, Enforcement, and Comparison of - Internationalized Strings in Application Protocols", - RFC 8264, DOI 10.17487/RFC8264, October 2017, - . - - [RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, - DOI 10.17487/RFC8291, November 2017, - . - - [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, - . - - [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers - (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, - . - -10.2. Informative References - - [RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, - DOI 10.17487/RFC8246, September 2017, - . - - - - - - - - - -Jenkins & Newman Standards Track [Page 89] - -RFC 8620 JMAP July 2019 - - -Authors' Addresses - - Neil Jenkins - Fastmail - PO Box 234, Collins St. West - Melbourne, VIC 8007 - Australia - - Email: neilj@fastmailteam.com - URI: https://www.fastmail.com - - - Chris Newman - Oracle - 440 E. Huntington Dr., Suite 400 - Arcadia, CA 91006 - United States of America - - Email: chris.newman@oracle.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 90] - diff --git a/specifications/mail/rfc2369.pdf b/specifications/mail/rfc2369.pdf deleted file mode 100644 index 3cd84ffd..00000000 Binary files a/specifications/mail/rfc2369.pdf and /dev/null differ diff --git a/specifications/mail/rfc2369.txt b/specifications/mail/rfc2369.txt deleted file mode 100644 index 77a1f68f..00000000 --- a/specifications/mail/rfc2369.txt +++ /dev/null @@ -1,843 +0,0 @@ - - - - - - -Network Working Group G. Neufeld -Request for Comments: 2369 Nisto -Category: Standards Track J. Baer - SkyWeyr Technologies - July 1998 - - - The Use of URLs as Meta-Syntax for Core Mail List Commands - and their Transport through Message Header Fields - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1998). All Rights Reserved. - -Abstract - - The mailing list command specification header fields are a set of - structured fields to be added to email messages sent by email - distribution lists. Each field typically contains a URL (usually - mailto [RFC2368]) locating the relevant information or performing the - command directly. The three core header fields described in this - document are List-Help, List-Subscribe, and List-Unsubscribe. - - There are three other header fields described here which, although - not as widely applicable, will have utility for a sufficient number - of mailing lists to justify their formalization here. These are - List-Post, List-Owner and List-Archive. - - By including these header fields, list servers can make it possible - for mail clients to provide automated tools for users to perform list - functions. This could take the form of a menu item, push button, or - other user interface element. The intent is to simplify the user - experience, providing a common interface to the often cryptic and - varied mailing list manager commands. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - - - - - -Neufeld & Baer Standards Track [Page 1] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -1. Introduction - - This is a proposal for additional header fields to be added to email - messages sent by email distribution lists. The content of each new - field is typically a URL - usually mailto [RFC2368] - which locates - the relevant information or performs the command directly. MTAs - generating the header fields SHOULD usually include a mailto based - command, in addition to any other protocols used, in order to support - users who do not have access to non-mail-based protocols. - - Implementing these fields will be optional. Significant functionality - and convenience can be gained by including them, however. Many list - managers, especially as the proposal first gains acceptance, MAY - choose to implement only one or two of the fields. The List-Help - field is the most useful individual field since it provides an access - point to detailed user support information, and accommodates almost - all existing list managers command sets. The List-Subscribe and - List-Unsubscribe fields are also very useful, but cannot describe - some list manager syntaxes at this time (those which require variable - substitution). See appendix A.5 for an explanation. - - The description of command syntax provided by the fields can be used - by mail client applications to provide simplified and consistent user - access to email distribution list functions. This could take the form - of menu items, push buttons, or other user interface elements. The - intent is to simplify the user experience, providing a common - interface to the often cryptic and varied mailing list manager - commands. - - Consideration has been given to avoiding the creation of too many - fields, while at the same time avoiding the overloading of individual - fields and keeping the syntax clear and simple. - - The use of these fields does not remove the requirement to support - the -Request command address for mailing lists [RFC2142]. - -2. The Command Syntax - - The list header fields are subject to the encoding and character - restrictions for mail headers as described in [RFC822]. Additionally, - the URL content is further restricted to the set of URL safe - characters [RFC1738]. - - The contents of the list header fields mostly consist of angle- - bracket ('<', '>') enclosed URLs, with internal whitespace being - ignored. MTAs MUST NOT insert whitespace within the brackets, but - client applications should treat any whitespace, that might be - inserted by poorly behaved MTAs, as characters to ignore. - - - -Neufeld & Baer Standards Track [Page 2] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - A list of multiple, alternate, URLs MAY be specified by a comma- - separated list of angle-bracket enclosed URLs. The URLs have order of - preference from left to right. The client application should use the - left most protocol that it supports, or knows how to access by a - separate application. By this mechanism, protocols like http may be - specified while still providing the basic mailto support for those - clients who do not have access to non-mail protocols. The client - should only use one of the available URLs for a command, using - another only if the first one used failed. - - The use of URLs allows for the use of the syntax with existing URL - supporting applications. As the standard for URLs is extended, the - list header fields will gain the benefit of those extensions. - Additionally, the use of URLs provides access to multiple transport - protocols (such as ftp and http) although it is expected that the - "mailto" protocol [RFC2368] will be the focus of most use of the list - header fields. Use of non-mailto protocols should be considered in - light of those users who do not have access to the specified - mechanism (those who only have email - with no web access). - - Command syntaxes requiring variable fields to be set by the client - (such as including the user's email address within a command) are not - supported by this implementation. However, systems using such - syntaxes SHOULD still take advantage of the List-Help field to - provide the user with detailed instructions as needed or - perhaps - more usefully - provide access to some form of structured command - interface such as an HTML-based form. - - The additional complications of supporting variable fields within the - command syntax was determined to be too difficult to support by this - protocol and would compromise the likelihood of implementation by - software authors. - - To allow for future extension, client applications MUST follow the - following guidelines for handling the contents of the header fields - described in this document: - - 1) Except where noted for specific fields, if the content of the - field (following any leading whitespace, including comments) - begins with any character other than the opening angle bracket - '<', the field SHOULD be ignored. - - 2) Any characters following an angle bracket enclosed URL SHOULD be - ignored, unless a comma is the first non-whitespace/comment - character after the closing angle bracket. - - - - - - -Neufeld & Baer Standards Track [Page 3] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - 3) If a sub-item (comma-separated item) within the field is not an - angle-bracket enclosed URL, the remainder of the field (the - current, and all subsequent, sub-items) SHOULD be ignored. - -3. The List Header Fields - - This document presents header fields which will provide the - command syntax description for the 'core' and key secondary - functions of most email distribution lists. The fields implemented - on a given list SHOULD be included on all messages distributed by - the list (including command responses to individual users), and on - other messages where the message clearly applies to one distinct - list. There MUST be no more than one of each field present in any - given message. - - These fields MUST only be generated by mailing lists, not end - users. - -3.1. List-Help - - The List-Help field is the most important of the header fields - described in this document. It would be acceptable for a list - manager to include only this field, since by definition it SHOULD - direct the user to complete instructions for all other commands. - Typically, the URL specified would request the help file, perhaps - incorporating an HTML form for list commands, for the list, and - alternatively provide access to an instructive website. - - Examples: - - List-Help: (List Instructions) - List-Help: - List-Help: (Info about the list) - List-Help: , - List-Help: (FTP), - - -3.2. List-Unsubscribe - - The List-Unsubscribe field describes the command (preferably using - mail) to directly unsubscribe the user (removing them from the list). - - Examples: - - List-Unsubscribe: - List-Unsubscribe: (Use this command to get off the list) - - List-Unsubscribe: - - - -Neufeld & Baer Standards Track [Page 4] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - List-Unsubscribe: , - - -3.3. List-Subscribe - - The List-Subscribe field describes the command (preferably using - mail) to directly subscribe the user (request addition to the list). - - Examples: - - List-Subscribe: - List-Subscribe: - List-Subscribe: (Use this command to join the list) - - List-Subscribe: - List-Subscribe: , - - -3.4. List-Post - - The List-Post field describes the method for posting to the list. - This is typically the address of the list, but MAY be a moderator, or - potentially some other form of submission. For the special case of a - list that does not allow posting (e.g., an announcements list), the - List-Post field may contain the special value "NO". - - Examples: - - List-Post: - List-Post: (Postings are Moderated) - List-Post: - List-Post: NO (posting not allowed on this list) - -3.5. List-Owner - - The List-Owner field identifies the path to contact a human - administrator for the list. The URL MAY contain the address of a - administrator for the list, the mail system administrator, or any - other person who can handle user contact for the list. There is no - need to specify List-Owner if it is the same person as the mail - system administrator (postmaster). - - Examples: - - List-Owner: (Contact Person for Help) - List-Owner: (Grant Neufeld) - List-Owner: - - - - -Neufeld & Baer Standards Track [Page 5] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -3.6. List-Archive - - The List-Archive field describes how to access archives for the list. - - Examples: - - List-Archive: - List-Archive: - List-Archive: (Web Archive) - -4. Supporting Nested Lists - - A list that is a sublist for another list in a nested mailing list - hierarchy will need to modify some of the List- header fields, while - leaving others as the parent list set them. - - Sublists SHOULD remove the parent list's List-Help, List-Subscribe, - List-Unsubscribe and List-Owner fields, and SHOULD insert their own - versions of those fields. - - If the sublist provides its own archive, it SHOULD replace the List- - Archive with its own. Otherwise, it MUST leave the List-Archive field - untouched. - - Dependant on how postings to the list are handled, the sublist MAY - replace the List-Post field. The appropriateness of whether to - replace List-Post is left to the determination of the individual list - managers. If the intention is that postings should be distributed to - all members of the primary list, List-Post should not be changed by a - sublist in such a way that postings will be distributed only to - members of the sublist. - -5. Security Considerations - - There are very few new security concerns generated with this - proposal. Message headers are an existing standard, designed to - easily accommodate new types. There may be concern with multiple - fields being inserted or headers being forged, but these are problems - inherent in Internet email, not specific to the protocol described in - this document. Further, the implications are relatively harmless. - - Mail list processors should not allow any user-originated list header - fields to pass through to their lists, lest they confuse the user and - have the potential to create security problems. - - On the client side, there may be some concern with posts or commands - being sent in error. It is required that the user have a chance to - confirm any action before it is executed. In the case of mailto, it - - - -Neufeld & Baer Standards Track [Page 6] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - may be appropriate to create the correctly formatted message without - sending it, allowing the user to see exactly what is happening and - giving the user the opportunity to approve or discard the message - before it is sent. - - All security considerations for the use of URLs [RFC1738] apply - equally to this protocol. Mail client applications should not support - list header field URLs which could compromise the security of the - user's system. This includes the "file://" URL type which could - potentially be used to trigger the execution of a local application - on some user systems. - -6. Acknowledgements - - The numerous participants of the List-Header [5], ListMom-Talk [6], - List-Managers and MIDA-Mail mailing lists contributed much to the - formation and structure of this document. - - Keith Moore and Christopher Allen - provided guidance on the standards - process. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Neufeld & Baer Standards Track [Page 7] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -A. Background Discussion - - This proposal arose from discussions started on the ListMom-Talk - Discussion List [6]. When the discussion reached a sufficient level, - a separate list was formed for discussing this proposal, the List - Headers Mail List [5] for deeper discussion. We have included - summaries of key issues raised, in order to show some of the - alternatives examined and reasons for our decisions. - -A.1. Multiple header fields vs. a single header field - - Use of a single header field for transporting command meta-syntax was - rejected for a number of reasons. - - Such a field would require the creation of a new meta-syntax in order - to describe the list commands (as opposed to the use of the widely - deployed URL syntax which was chosen for this implementation). Every - additional layer of complexity and newness reduces the likelihood of - actual implementation because it will require additional work to - support. Also, by using the existing URL syntax, we can profit from - the end users' knowledge of that syntax and ability to use it even if - their client applications do not support the list header fields. - - Restricting the transport of meta-syntax to the use of a single - header field also introduces complications with header field size - limitations. Most individual commands can easily be described in a - single line, but describing a multitude of commands can take up many - lines in the field and runs a greater risk of being modified by an - existing server on route. - - The client implementation is also easier with multiple fields, since - each command can be supported and implemented individually, - completely independent of the others. Thus, some list managers or - mail clients can choose to implement a subset of the fields based on - the specific needs of their individual lists. - - Finally, the format described in this document is simple and well - recognized, which reduces the chances of errors in implementation and - parsing. - -A.2. URLs vs. parameter lists - - URLs are already an established syntax which is flexible, well- - defined, and in wide spread use. As its definition matures and - expands, the abilities of the list fields will grow as well, without - requiring modification of this proposal. URLs are well prepared to - handle future protocols and developments, and can easily describe the - different existing access protocols such as mailto, http and ftp. - - - -Neufeld & Baer Standards Track [Page 8] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - Many clients already have functionality for recognizing, parsing, and - evaluating URLs, either internally or by passing the request to a - helper application. This makes implementation easier and more - realistic. As an example, this existing support for URL parsing - allowed us to add prototype list header functionality to existing - mail clients (Eudora and Emailer for the Macintosh) without modifying - their source code. - -A.3. Why not just create a standard command language? - - A standard command language, supported by all email list services, - would go a long way to reducing the problems of list access that - currently plague existing services. It would reduce the amount of - learning required by end users and allow for a number of common - support tools to be developed. - - However, such standardization does pose problems in the areas of - multi-lingual support and the custom needs of individual mailing - lists. The development of such a standard is also expected to be met - with a slow adoption rate by software developers and list service - providers. - - These points do not preclude the development of such a standard (in - fact, it would suggest that we should start sooner rather than - later), but we do need a solution that can be widely supported by the - current list services. - - We can support most existing list manager command syntaxes without a - standard command language. By using URLs, we allow alternate access - methods a standard command language probably wouldn't enable, such as - web based control. - - Finally, client support for a standard command language is not at all - clear or necessarily simple to implement. The variety and large - number of commands existing today would require complicated user - interfaces which could be confusing and difficult to implement. By - restricting this proposal to the core functions, the client - - implementation is much simpler, which significantly increases the - likelihood of implementation (as evidenced by the support already - announced by a number of client and server application authors). - -A.4. Internationalization - - Multilingual support is up to the URL standard. If URLs support it, - then the List- header fields support it. This is another advantage of - using URLs as the building blocks for the list header fields. - - - - -Neufeld & Baer Standards Track [Page 9] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -A.5. Variable Substitution - - Variables would allow the List- header fields to accommodate nearly - every existing list manager. However, it would immeasurably increase - the complexity of the entire proposal, and possibly involve - redefining the URL standard, or force us to use something more - complicated (and hence more difficult to implement) than URLs to - describe the command syntax. - - Parameters would either have to be mandatory (i.e. the user agent - doesn't submit the message if it doesn't know what text to - substitute) or you need a way to say "if you know this parameter, add - its text here; otherwise, do this" where "this" is either: (a) - substitute a constant string, or (b) fail. - - The reason you would want a facility like this is because some list - server applications insist on having certain parameters like users' - names, which the user agent might or might not know. e.g. listserv - insists on having a first name and a last name if you supply either - one. - - Which could lead to something like the UNIX shell syntax, where - ${foo-bar} means substitute the value of parameter "foo" if "foo" is - defined, else substitute the string "bar". Perhaps $foo would mean - "substitute the value of parameter foo if it is defined, else - substitute the empty string" - - This all seems far too complicated for the gains involved, especially - since the use of variables can often be avoided. - - The use of variables in the command syntaxes of list services appears - to be lessening and does not, in any case, apply to all commands. - While the unsubscribe and subscribe command header fields may not be - usable by those systems which require the use of variables, the help - field will still provide end users with a consistent point of access - through which they can get support for their use of the list. - -A.6. Why not use a specialized MIME part instead of header fields? - - MIME parts were considered, but because most mail clients currently - either don't support MIME or are not equipped to handle such - specialized parts - such an implementation would result in problems - for end users. It is also not as easy for many list servers to - implement MIME as it is to implement new header fields. - - However, we are looking at the design of a MIME part to more fully - describe list command syntax, as well as trying to find ways to get - it supported by the applicable software. - - - -Neufeld & Baer Standards Track [Page 10] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -A.7. Why include a Subscribe command? - - Subscribe and Unsubscribe are the key commands needed by almost every - list. Other commands, such as digest mode, are not as widely - supported. - - Additionally, users who have unsubscribed (before going on vacation, - or for whatever other reason) may want to resubscribe to a list. Or, - a message may be forwarded/bounced from a subscriber to a non- - subscriber. Or, the user may change addresses and want to subscribe - from their new address. Having the List-Subscribe field available - could certainly help in all these cases. - -A.8. The Dangers of Header Bloat - - At what point are there just too many header fields? It really - varies on a list by list basis. On some lists, the majority of users - will never be aware of a field unless the client software provides - some alternative user interface to it (akin to the Reply-To field). - On others, the users will often see the header fields of messages and - would be able to recognize the function of the URLs contained within. - - The flexibility afforded by the protocol described in this document - (in that the header fields may be individually implemented as deemed - appropriate) provides list administrators with sufficient 'room to - maneuver' to meet their individual needs. - - - - - - - - - - - - - - - - - - - - - - - - - -Neufeld & Baer Standards Track [Page 11] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -B. Client Implementation - -B.1. Guidelines - - For 'mailto' URL based commands, mail client applications may choose - to provide specialized feedback (such as presenting a dialog or - alert), instead of the actual command email message, asking for - command confirmation from the user. The feedback should identify the - message destination and command within a more descriptive - explanation. For example: - - "Do you want to send the unsubscription command 'unsubscribe - somelist' to 'somelist-request@some.host.com'? Sending the command - will result in your removal from the associated list." - - If the user has multiple email addresses supported by the mail - client, the client application should prompt the user for which - address to use when subscribing or performing some other action where - the address to use cannot be specifically determined. When - unsubscribing or such, the address that is subscribed should be used, - unless that is not known by the application and cannot be determined - from the message headers. - -B.2. Implementation Options - - The following implementation possibilities are suggested here to give - some idea as to why these new header fields will be useful, and how - they could be supported. - - In most cases, it may be helpful to disable the interface for the - commands when not applicable to the currently selected message. - -B.2.1. Key combinations and command lines - - On text based systems which utilize command lines or key - combinations, each field could be implemented as a separate command. - Thus one combination would subscribe the user, another would - unsubscribe, a third request help, etc. The commands would only be - available on messages containing the list header fields. - -B.2.2. Menu items - - On graphical systems which have menus, these commands could take the - form of a menu or sub-menu of items. For example, a "Lists" menu - might appear when viewing messages containing the header fields, with - items named "Subscribe", "Unsubscribe", "Get Help", "Post Message to - - - - - -Neufeld & Baer Standards Track [Page 12] - -RFC 2369 URLs as Meta-Syntax July 1998 - - - List", "Contact List Owner" and "Access List Archive". This menu - could be disabled when not applicable to the current message or - disappear entirely. - -B.2.3. Push Buttons and Pallettes - - On graphical window systems, buttons could be placed in the window of - the message, a toolbar, or in a floating pallette of their own. Each - button could correspond to a command, with names "Subscribe", - "Unsubscribe", "Get Help", "Post to List", "List Owner" and - "Archive". These buttons or pallettes could be disabled when not - applicable to the current message or disappear entirely. - -B.2.4 Feedback to the User - - If using a dialog interface (or other feedback element) the client - application MUST include an option for the user to review (and - possibly modify) the message before it is sent. The application may - also find it useful to provide a link to more detailed context- - sensitive assistance about mail list access in general. - -References - - [RFC822] Crocker, D., "Standard for the Format of ARPA - Internet Text Messages", STD 11, RFC 822, August 1982. - - [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, - "Uniform Resource Locators (URL)" RFC 1738, December 1994. - - [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and - Functions", RFC 2142, May 1997. - - [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL - scheme", RFC 2368, July 1998. - - [5] "List-Header" Mail list. list-header@list.nisto.com - - - - [6] "ListMom-Talk" Mail list. listmom-talk@skyweyr.com - - - - - - - - - - - -Neufeld & Baer Standards Track [Page 13] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -Editors' Addresses - - Joshua D. Baer - Box 273 - 4902 Forbes Avenue - Pittsburgh, PA 15213-3799 - USA - - EMail: josh@skyweyr.com - - - Grant Neufeld - Calgary, Alberta - Canada - - EMail: grant@acm.org - Web: http://www.nisto.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Neufeld & Baer Standards Track [Page 14] - -RFC 2369 URLs as Meta-Syntax July 1998 - - -Full Copyright Statement - - Copyright (C) The Internet Society (1998). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - -Neufeld & Baer Standards Track [Page 15] - diff --git a/specifications/mail/rfc5322.pdf b/specifications/mail/rfc5322.pdf deleted file mode 100644 index 027b85fa..00000000 Binary files a/specifications/mail/rfc5322.pdf and /dev/null differ diff --git a/specifications/mail/rfc5322.txt b/specifications/mail/rfc5322.txt deleted file mode 100644 index f3306869..00000000 --- a/specifications/mail/rfc5322.txt +++ /dev/null @@ -1,3195 +0,0 @@ - - - - - - -Network Working Group P. Resnick, Ed. -Request for Comments: 5322 Qualcomm Incorporated -Obsoletes: 2822 October 2008 -Updates: 4021 -Category: Standards Track - - - Internet Message Format - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This document specifies the Internet Message Format (IMF), a syntax - for text messages that are sent between computer users, within the - framework of "electronic mail" messages. This specification is a - revision of Request For Comments (RFC) 2822, which itself superseded - Request For Comments (RFC) 822, "Standard for the Format of ARPA - Internet Text Messages", updating it to reflect current practice and - incorporating incremental changes that were specified in other RFCs. - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 1] - -RFC 5322 Internet Message Format October 2008 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5 - 1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5 - 1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 5 - 1.2.3. Structure of This Document . . . . . . . . . . . . . . 5 - 2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6 - 2.1. General Description . . . . . . . . . . . . . . . . . . . 6 - 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7 - 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8 - 2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8 - 2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . . 8 - 2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10 - 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10 - 3.2.2. Folding White Space and Comments . . . . . . . . . . . 11 - 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . . 13 - 3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14 - 3.3. Date and Time Specification . . . . . . . . . . . . . . . 14 - 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 - 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17 - 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . . 18 - 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19 - 3.6.1. The Origination Date Field . . . . . . . . . . . . . . 22 - 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22 - 3.6.3. Destination Address Fields . . . . . . . . . . . . . . 23 - 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25 - 3.6.5. Informational Fields . . . . . . . . . . . . . . . . . 27 - 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 28 - 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . . 30 - 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 30 - 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 - 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 32 - 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . . 33 - 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 - 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 35 - 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35 - 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 36 - 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . . 36 - 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 37 - 4.5.4. Obsolete Identification Fields . . . . . . . . . . . . 37 - 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 37 - - - -Resnick Standards Track [Page 2] - -RFC 5322 Internet Message Format October 2008 - - - 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . . 38 - 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 38 - 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 - Appendix A. Example Messages . . . . . . . . . . . . . . . . . 43 - Appendix A.1. Addressing Examples . . . . . . . . . . . . . . . 44 - Appendix A.1.1. A Message from One Person to Another with - Simple Addressing . . . . . . . . . . . . . . . . 44 - Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45 - Appendix A.1.3. Group Addresses . . . . . . . . . . . . . . . . . 45 - Appendix A.2. Reply Messages . . . . . . . . . . . . . . . . . . 46 - Appendix A.3. Resent Messages . . . . . . . . . . . . . . . . . 47 - Appendix A.4. Messages with Trace Fields . . . . . . . . . . . . 48 - Appendix A.5. White Space, Comments, and Other Oddities . . . . 49 - Appendix A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . 50 - Appendix A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . 50 - Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50 - Appendix A.6.3. Obsolete White Space and Comments . . . . . . . . 51 - Appendix B. Differences from Earlier Specifications . . . . . 52 - Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 55 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 55 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 3] - -RFC 5322 Internet Message Format October 2008 - - -1. Introduction - -1.1. Scope - - This document specifies the Internet Message Format (IMF), a syntax - for text messages that are sent between computer users, within the - framework of "electronic mail" messages. This specification is an - update to [RFC2822], which itself superseded [RFC0822], updating it - to reflect current practice and incorporating incremental changes - that were specified in other RFCs such as [RFC1123]. - - This document specifies a syntax only for text messages. In - particular, it makes no provision for the transmission of images, - audio, or other sorts of structured data in electronic mail messages. - There are several extensions published, such as the MIME document - series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms - for the transmission of such data through electronic mail, either by - extending the syntax provided here or by structuring such messages to - conform to this syntax. Those mechanisms are outside of the scope of - this specification. - - In the context of electronic mail, messages are viewed as having an - envelope and contents. The envelope contains whatever information is - needed to accomplish transmission and delivery. (See [RFC5321] for a - discussion of the envelope.) The contents comprise the object to be - delivered to the recipient. This specification applies only to the - format and some of the semantics of message contents. It contains no - specification of the information in the envelope. - - However, some message systems may use information from the contents - to create the envelope. It is intended that this specification - facilitate the acquisition of such information by programs. - - This specification is intended as a definition of what message - content format is to be passed between systems. Though some message - systems locally store messages in this format (which eliminates the - need for translation between formats) and others use formats that - differ from the one specified in this specification, local storage is - outside of the scope of this specification. - - Note: This specification is not intended to dictate the internal - formats used by sites, the specific message system features that - they are expected to support, or any of the characteristics of - user interface programs that create or read messages. In - addition, this document does not specify an encoding of the - characters for either transport or storage; that is, it does not - specify the number of bits used or how those bits are specifically - transferred over the wire or stored on disk. - - - -Resnick Standards Track [Page 4] - -RFC 5322 Internet Message Format October 2008 - - -1.2. Notational Conventions - -1.2.1. Requirements Notation - - This document occasionally uses terms that appear in capital letters. - When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD - NOT", and "MAY" appear capitalized, they are being used to indicate - particular requirements of this specification. A discussion of the - meanings of these terms appears in [RFC2119]. - -1.2.2. Syntactic Notation - - This specification uses the Augmented Backus-Naur Form (ABNF) - [RFC5234] notation for the formal definitions of the syntax of - messages. Characters will be specified either by a decimal value - (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by - a case-insensitive literal value enclosed in quotation marks (e.g., - "A" for either uppercase or lowercase A). - -1.2.3. Structure of This Document - - This document is divided into several sections. - - This section, section 1, is a short introduction to the document. - - Section 2 lays out the general description of a message and its - constituent parts. This is an overview to help the reader understand - some of the general principles used in the later portions of this - document. Any examples in this section MUST NOT be taken as - specification of the formal syntax of any part of a message. - - Section 3 specifies formal ABNF rules for the structure of each part - of a message (the syntax) and describes the relationship between - those parts and their meaning in the context of a message (the - semantics). That is, it lays out the actual rules for the structure - of each part of a message (the syntax) as well as a description of - the parts and instructions for their interpretation (the semantics). - This includes analysis of the syntax and semantics of subparts of - messages that have specific structure. The syntax included in - section 3 represents messages as they MUST be created. There are - also notes in section 3 to indicate if any of the options specified - in the syntax SHOULD be used over any of the others. - - Both sections 2 and 3 describe messages that are legal to generate - for purposes of this specification. - - - - - - -Resnick Standards Track [Page 5] - -RFC 5322 Internet Message Format October 2008 - - - Section 4 of this document specifies an "obsolete" syntax. There are - references in section 3 to these obsolete syntactic elements. The - rules of the obsolete syntax are elements that have appeared in - earlier versions of this specification or have previously been widely - used in Internet messages. As such, these elements MUST be - interpreted by parsers of messages in order to be conformant to this - specification. However, since items in this syntax have been - determined to be non-interoperable or to cause significant problems - for recipients of messages, they MUST NOT be generated by creators of - conformant messages. - - Section 5 details security considerations to take into account when - implementing this specification. - - Appendix A lists examples of different sorts of messages. These - examples are not exhaustive of the types of messages that appear on - the Internet, but give a broad overview of certain syntactic forms. - - Appendix B lists the differences between this specification and - earlier specifications for Internet messages. - - Appendix C contains acknowledgements. - -2. Lexical Analysis of Messages - -2.1. General Description - - At the most basic level, a message is a series of characters. A - message that is conformant with this specification is composed of - characters with values in the range of 1 through 127 and interpreted - as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document - sometimes refers to this range of characters as simply "US-ASCII - characters". - - Note: This document specifies that messages are made up of - characters in the US-ASCII range of 1 through 127. There are - other documents, specifically the MIME document series ([RFC2045], - [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that - extend this specification to allow for values outside of that - range. Discussion of those mechanisms is not within the scope of - this specification. - - Messages are divided into lines of characters. A line is a series of - characters that is delimited with the two characters carriage-return - and line-feed; that is, the carriage return (CR) character (ASCII - value 13) followed immediately by the line feed (LF) character (ASCII - value 10). (The carriage return/line feed pair is usually written in - this document as "CRLF".) - - - -Resnick Standards Track [Page 6] - -RFC 5322 Internet Message Format October 2008 - - - A message consists of header fields (collectively called "the header - section of the message") followed, optionally, by a body. The header - section is a sequence of lines of characters with special syntax as - defined in this specification. The body is simply a sequence of - characters that follows the header section and is separated from the - header section by an empty line (i.e., a line with nothing preceding - the CRLF). - - Note: Common parlance and earlier versions of this specification - use the term "header" to either refer to the entire header section - or to refer to an individual header field. To avoid ambiguity, - this document does not use the terms "header" or "headers" in - isolation, but instead always uses "header field" to refer to the - individual field and "header section" to refer to the entire - collection. - -2.1.1. Line Length Limits - - There are two limits that this specification places on the number of - characters in a line. Each line of characters MUST be no more than - 998 characters, and SHOULD be no more than 78 characters, excluding - the CRLF. - - The 998 character limit is due to limitations in many implementations - that send, receive, or store IMF messages which simply cannot handle - more than 998 characters on a line. Receiving implementations would - do well to handle an arbitrarily large number of characters in a line - for robustness sake. However, there are so many implementations that - (in compliance with the transport requirements of [RFC5321]) do not - accept messages containing more than 1000 characters including the CR - and LF per line, it is important for implementations not to create - such messages. - - The more conservative 78 character recommendation is to accommodate - the many implementations of user interfaces that display these - messages which may truncate, or disastrously wrap, the display of - more than 78 characters per line, in spite of the fact that such - implementations are non-conformant to the intent of this - specification (and that of [RFC5321] if they actually cause - information to be lost). Again, even though this limitation is put - on messages, it is incumbent upon implementations that display - messages to handle an arbitrarily large number of characters in a - line (certainly at least up to the 998 character limit) for the sake - of robustness. - - - - - - - -Resnick Standards Track [Page 7] - -RFC 5322 Internet Message Format October 2008 - - -2.2. Header Fields - - Header fields are lines beginning with a field name, followed by a - colon (":"), followed by a field body, and terminated by CRLF. A - field name MUST be composed of printable US-ASCII characters (i.e., - characters that have values between 33 and 126, inclusive), except - colon. A field body may be composed of printable US-ASCII characters - as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, - ASCII value 9) characters (together known as the white space - characters, WSP). A field body MUST NOT include CR and LF except - when used in "folding" and "unfolding", as described in section - 2.2.3. All field bodies MUST conform to the syntax described in - sections 3 and 4 of this specification. - -2.2.1. Unstructured Header Field Bodies - - Some field bodies in this specification are defined simply as - "unstructured" (which is specified in section 3.2.5 as any printable - US-ASCII characters plus white space characters) with no further - restrictions. These are referred to as unstructured field bodies. - Semantically, unstructured field bodies are simply to be treated as a - single line of characters with no further processing (except for - "folding" and "unfolding" as described in section 2.2.3). - -2.2.2. Structured Header Field Bodies - - Some field bodies in this specification have a syntax that is more - restrictive than the unstructured field bodies described above. - These are referred to as "structured" field bodies. Structured field - bodies are sequences of specific lexical tokens as described in - sections 3 and 4 of this specification. Many of these tokens are - allowed (according to their syntax) to be introduced or end with - comments (as described in section 3.2.2) as well as the white space - characters, and those white space characters are subject to "folding" - and "unfolding" as described in section 2.2.3. Semantic analysis of - structured field bodies is given along with their syntax. - -2.2.3. Long Header Fields - - Each header field is logically a single line of characters comprising - the field name, the colon, and the field body. For convenience - however, and to deal with the 998/78 character limitations per line, - the field body portion of a header field can be split into a - multiple-line representation; this is called "folding". The general - rule is that wherever this specification allows for folding white - space (not simply WSP characters), a CRLF may be inserted before any - WSP. - - - - -Resnick Standards Track [Page 8] - -RFC 5322 Internet Message Format October 2008 - - - For example, the header field: - - Subject: This is a test - - can be represented as: - - Subject: This - is a test - - Note: Though structured field bodies are defined in such a way - that folding can take place between many of the lexical tokens - (and even within some of the lexical tokens), folding SHOULD be - limited to placing the CRLF at higher-level syntactic breaks. For - instance, if a field body is defined as comma-separated values, it - is recommended that folding occur after the comma separating the - structured items in preference to other places where the field - could be folded, even if it is allowed elsewhere. - - The process of moving from this folded multiple-line representation - of a header field to its single line representation is called - "unfolding". Unfolding is accomplished by simply removing any CRLF - that is immediately followed by WSP. Each header field should be - treated in its unfolded form for further syntactic and semantic - evaluation. An unfolded header field has no length restriction and - therefore may be indeterminately long. - -2.3. Body - - The body of a message is simply lines of US-ASCII characters. The - only two limitations on the body are as follows: - - o CR and LF MUST only occur together as CRLF; they MUST NOT appear - independently in the body. - o Lines of characters in the body MUST be limited to 998 characters, - and SHOULD be limited to 78 characters, excluding the CRLF. - - Note: As was stated earlier, there are other documents, - specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049], - [RFC4288], [RFC4289]), that extend (and limit) this specification - to allow for different sorts of message bodies. Again, these - mechanisms are beyond the scope of this document. - - - - - - - - - - -Resnick Standards Track [Page 9] - -RFC 5322 Internet Message Format October 2008 - - -3. Syntax - -3.1. Introduction - - The syntax as given in this section defines the legal syntax of - Internet messages. Messages that are conformant to this - specification MUST conform to the syntax in this section. If there - are options in this section where one option SHOULD be generated, - that is indicated either in the prose or in a comment next to the - syntax. - - For the defined expressions, a short description of the syntax and - use is given, followed by the syntax in ABNF, followed by a semantic - analysis. The following primitive tokens that are used but otherwise - unspecified are taken from the "Core Rules" of [RFC5234], Appendix - B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR. - - In some of the definitions, there will be non-terminals whose names - start with "obs-". These "obs-" elements refer to tokens defined in - the obsolete syntax in section 4. In all cases, these productions - are to be ignored for the purposes of generating legal Internet - messages and MUST NOT be used as part of such a message. However, - when interpreting messages, these tokens MUST be honored as part of - the legal syntax. In this sense, section 3 defines a grammar for the - generation of messages, with "obs-" elements that are to be ignored, - while section 4 adds grammar for the interpretation of messages. - -3.2. Lexical Tokens - - The following rules are used to define an underlying lexical - analyzer, which feeds tokens to the higher-level parsers. This - section defines the tokens used in structured header field bodies. - - Note: Readers of this specification need to pay special attention - to how these lexical tokens are used in both the lower-level and - higher-level syntax later in the document. Particularly, the - white space tokens and the comment tokens defined in section 3.2.2 - get used in the lower-level tokens defined here, and those lower- - level tokens are in turn used as parts of the higher-level tokens - defined later. Therefore, white space and comments may be allowed - in the higher-level tokens even though they may not explicitly - appear in a particular definition. - -3.2.1. Quoted characters - - Some characters are reserved for special interpretation, such as - delimiting lexical tokens. To permit use of these characters as - uninterpreted data, a quoting mechanism is provided. - - - -Resnick Standards Track [Page 10] - -RFC 5322 Internet Message Format October 2008 - - - quoted-pair = ("\" (VCHAR / WSP)) / obs-qp - - Where any quoted-pair appears, it is to be interpreted as the - character alone. That is to say, the "\" character that appears as - part of a quoted-pair is semantically "invisible". - - Note: The "\" character may appear in a message where it is not - part of a quoted-pair. A "\" character that does not appear in a - quoted-pair is not semantically invisible. The only places in - this specification where quoted-pair currently appears are - ccontent, qcontent, and in obs-dtext in section 4. - -3.2.2. Folding White Space and Comments - - White space characters, including white space used in folding - (described in section 2.2.3), may appear between many elements in - header field bodies. Also, strings of characters that are treated as - comments may be included in structured field bodies as characters - enclosed in parentheses. The following defines the folding white - space (FWS) and comment constructs. - - Strings of characters enclosed in parentheses are considered comments - so long as they do not appear within a "quoted-string", as defined in - section 3.2.4. Comments may nest. - - There are several places in this specification where comments and FWS - may be freely inserted. To accommodate that syntax, an additional - token for "CFWS" is defined for places where comments and/or FWS can - occur. However, where CFWS occurs in this specification, it MUST NOT - be inserted in such a way that any line of a folded header field is - made up entirely of WSP characters and nothing else. - - FWS = ([*WSP CRLF] 1*WSP) / obs-FWS - ; Folding white space - - ctext = %d33-39 / ; Printable US-ASCII - %d42-91 / ; characters not including - %d93-126 / ; "(", ")", or "\" - obs-ctext - - ccontent = ctext / quoted-pair / comment - - comment = "(" *([FWS] ccontent) [FWS] ")" - - CFWS = (1*([FWS] comment) [FWS]) / FWS - - - - - - -Resnick Standards Track [Page 11] - -RFC 5322 Internet Message Format October 2008 - - - Throughout this specification, where FWS (the folding white space - token) appears, it indicates a place where folding, as discussed in - section 2.2.3, may take place. Wherever folding appears in a message - (that is, a header field body containing a CRLF followed by any WSP), - unfolding (removal of the CRLF) is performed before any further - semantic analysis is performed on that header field according to this - specification. That is to say, any CRLF that appears in FWS is - semantically "invisible". - - A comment is normally used in a structured field body to provide some - human-readable informational text. Since a comment is allowed to - contain FWS, folding is permitted within the comment. Also note that - since quoted-pair is allowed in a comment, the parentheses and - backslash characters may appear in a comment, so long as they appear - as a quoted-pair. Semantically, the enclosing parentheses are not - part of the comment; the comment is what is contained between the two - parentheses. As stated earlier, the "\" in any quoted-pair and the - CRLF in any FWS that appears within the comment are semantically - "invisible" and therefore not part of the comment either. - - Runs of FWS, comment, or CFWS that occur between lexical tokens in a - structured header field are semantically interpreted as a single - space character. - -3.2.3. Atom - - Several productions in structured header field bodies are simply - strings of certain basic characters. Such productions are called - atoms. - - Some of the structured header field bodies also allow the period - character (".", ASCII value 46) within runs of atext. An additional - "dot-atom" token is defined for those purposes. - - Note: The "specials" token does not appear anywhere else in this - specification. It is simply the visible (i.e., non-control, non- - white space) characters that do not appear in atext. It is - provided only because it is useful for implementers who use tools - that lexically analyze messages. Each of the characters in - specials can be used to indicate a tokenization point in lexical - analysis. - - - - - - - - - - -Resnick Standards Track [Page 12] - -RFC 5322 Internet Message Format October 2008 - - - atext = ALPHA / DIGIT / ; Printable US-ASCII - "!" / "#" / ; characters not including - "$" / "%" / ; specials. Used for atoms. - "&" / "'" / - "*" / "+" / - "-" / "/" / - "=" / "?" / - "^" / "_" / - "`" / "{" / - "|" / "}" / - "~" - - atom = [CFWS] 1*atext [CFWS] - - dot-atom-text = 1*atext *("." 1*atext) - - dot-atom = [CFWS] dot-atom-text [CFWS] - - specials = "(" / ")" / ; Special characters that do - "<" / ">" / ; not appear in atext - "[" / "]" / - ":" / ";" / - "@" / "\" / - "," / "." / - DQUOTE - - Both atom and dot-atom are interpreted as a single unit, comprising - the string of characters that make it up. Semantically, the optional - comments and FWS surrounding the rest of the characters are not part - of the atom; the atom is only the run of atext characters in an atom, - or the atext and "." characters in a dot-atom. - -3.2.4. Quoted Strings - - Strings of characters that include characters other than those - allowed in atoms can be represented in a quoted string format, where - the characters are surrounded by quote (DQUOTE, ASCII value 34) - characters. - - - - - - - - - - - - - -Resnick Standards Track [Page 13] - -RFC 5322 Internet Message Format October 2008 - - - qtext = %d33 / ; Printable US-ASCII - %d35-91 / ; characters not including - %d93-126 / ; "\" or the quote character - obs-qtext - - qcontent = qtext / quoted-pair - - quoted-string = [CFWS] - DQUOTE *([FWS] qcontent) [FWS] DQUOTE - [CFWS] - - A quoted-string is treated as a unit. That is, quoted-string is - identical to atom, semantically. Since a quoted-string is allowed to - contain FWS, folding is permitted. Also note that since quoted-pair - is allowed in a quoted-string, the quote and backslash characters may - appear in a quoted-string so long as they appear as a quoted-pair. - - Semantically, neither the optional CFWS outside of the quote - characters nor the quote characters themselves are part of the - quoted-string; the quoted-string is what is contained between the two - quote characters. As stated earlier, the "\" in any quoted-pair and - the CRLF in any FWS/CFWS that appears within the quoted-string are - semantically "invisible" and therefore not part of the quoted-string - either. - -3.2.5. Miscellaneous Tokens - - Three additional tokens are defined: word and phrase for combinations - of atoms and/or quoted-strings, and unstructured for use in - unstructured header fields and in some places within structured - header fields. - - word = atom / quoted-string - - phrase = 1*word / obs-phrase - - unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct - -3.3. Date and Time Specification - - Date and time values occur in several header fields. This section - specifies the syntax for a full date and time specification. Though - folding white space is permitted throughout the date-time - specification, it is RECOMMENDED that a single space be used in each - place that FWS appears (whether it is required or optional); some - older implementations will not interpret longer sequences of folding - white space correctly. - - - - -Resnick Standards Track [Page 14] - -RFC 5322 Internet Message Format October 2008 - - - date-time = [ day-of-week "," ] date time [CFWS] - - day-of-week = ([FWS] day-name) / obs-day-of-week - - day-name = "Mon" / "Tue" / "Wed" / "Thu" / - "Fri" / "Sat" / "Sun" - - date = day month year - - day = ([FWS] 1*2DIGIT FWS) / obs-day - - month = "Jan" / "Feb" / "Mar" / "Apr" / - "May" / "Jun" / "Jul" / "Aug" / - "Sep" / "Oct" / "Nov" / "Dec" - - year = (FWS 4*DIGIT FWS) / obs-year - - time = time-of-day zone - - time-of-day = hour ":" minute [ ":" second ] - - hour = 2DIGIT / obs-hour - - minute = 2DIGIT / obs-minute - - second = 2DIGIT / obs-second - - zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone - - The day is the numeric day of the month. The year is any numeric - year 1900 or later. - - The time-of-day specifies the number of hours, minutes, and - optionally seconds since midnight of the date indicated. - - The date and time-of-day SHOULD express local time. - - The zone specifies the offset from Coordinated Universal Time (UTC, - formerly referred to as "Greenwich Mean Time") that the date and - time-of-day represent. The "+" or "-" indicates whether the time-of- - day is ahead of (i.e., east of) or behind (i.e., west of) Universal - Time. The first two digits indicate the number of hours difference - from Universal Time, and the last two digits indicate the number of - additional minutes difference from Universal Time. (Hence, +hhmm - means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) - minutes). The form "+0000" SHOULD be used to indicate a time zone at - Universal Time. Though "-0000" also indicates Universal Time, it is - - - - -Resnick Standards Track [Page 15] - -RFC 5322 Internet Message Format October 2008 - - - used to indicate that the time was generated on a system that may be - in a local time zone other than Universal Time and that the date-time - contains no information about the local time zone. - - A date-time specification MUST be semantically valid. That is, the - day-of-week (if included) MUST be the day implied by the date, the - numeric day-of-month MUST be between 1 and the number of days allowed - for the specified month (in the specified year), the time-of-day MUST - be in the range 00:00:00 through 23:59:60 (the number of seconds - allowing for a leap second; see [RFC1305]), and the last two digits - of the zone MUST be within the range 00 through 59. - -3.4. Address Specification - - Addresses occur in several message header fields to indicate senders - and recipients of messages. An address may either be an individual - mailbox, or a group of mailboxes. - - address = mailbox / group - - mailbox = name-addr / addr-spec - - name-addr = [display-name] angle-addr - - angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / - obs-angle-addr - - group = display-name ":" [group-list] ";" [CFWS] - - display-name = phrase - - mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list - - address-list = (address *("," address)) / obs-addr-list - - group-list = mailbox-list / CFWS / obs-group-list - - A mailbox receives mail. It is a conceptual entity that does not - necessarily pertain to file storage. For example, some sites may - choose to print mail on a printer and deliver the output to the - addressee's desk. - - Normally, a mailbox is composed of two parts: (1) an optional display - name that indicates the name of the recipient (which can be a person - or a system) that could be displayed to the user of a mail - application, and (2) an addr-spec address enclosed in angle brackets - - - - - -Resnick Standards Track [Page 16] - -RFC 5322 Internet Message Format October 2008 - - - ("<" and ">"). There is an alternate simple form of a mailbox where - the addr-spec address appears alone, without the recipient's name or - the angle brackets. The Internet addr-spec address is described in - section 3.4.1. - - Note: Some legacy implementations used the simple form where the - addr-spec appears without the angle brackets, but included the - name of the recipient in parentheses as a comment following the - addr-spec. Since the meaning of the information in a comment is - unspecified, implementations SHOULD use the full name-addr form of - the mailbox, instead of the legacy form, to specify the display - name associated with a mailbox. Also, because some legacy - implementations interpret the comment, comments generally SHOULD - NOT be used in address fields to avoid confusing such - implementations. - - When it is desirable to treat several mailboxes as a single unit - (i.e., in a distribution list), the group construct can be used. The - group construct allows the sender to indicate a named group of - recipients. This is done by giving a display name for the group, - followed by a colon, followed by a comma-separated list of any number - of mailboxes (including zero and one), and ending with a semicolon. - Because the list of mailboxes can be empty, using the group construct - is also a simple way to communicate to recipients that the message - was sent to one or more named sets of recipients, without actually - providing the individual mailbox address for any of those recipients. - -3.4.1. Addr-Spec Specification - - An addr-spec is a specific Internet identifier that contains a - locally interpreted string followed by the at-sign character ("@", - ASCII value 64) followed by an Internet domain. The locally - interpreted string is either a quoted-string or a dot-atom. If the - string can be represented as a dot-atom (that is, it contains no - characters other than atext characters or "." surrounded by atext - characters), then the dot-atom form SHOULD be used and the quoted- - string form SHOULD NOT be used. Comments and folding white space - SHOULD NOT be used around the "@" in the addr-spec. - - Note: A liberal syntax for the domain portion of addr-spec is - given here. However, the domain portion contains addressing - information specified by and used in other protocols (e.g., - [RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore - incumbent upon implementations to conform to the syntax of - addresses for the context in which they are used. - - - - - - -Resnick Standards Track [Page 17] - -RFC 5322 Internet Message Format October 2008 - - - addr-spec = local-part "@" domain - - local-part = dot-atom / quoted-string / obs-local-part - - domain = dot-atom / domain-literal / obs-domain - - domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] - - dtext = %d33-90 / ; Printable US-ASCII - %d94-126 / ; characters not including - obs-dtext ; "[", "]", or "\" - - The domain portion identifies the point to which the mail is - delivered. In the dot-atom form, this is interpreted as an Internet - domain name (either a host name or a mail exchanger name) as - described in [RFC1034], [RFC1035], and [RFC1123]. In the domain- - literal form, the domain is interpreted as the literal Internet - address of the particular host. In both cases, how addressing is - used and how messages are transported to a particular host is covered - in separate documents, such as [RFC5321]. These mechanisms are - outside of the scope of this document. - - The local-part portion is a domain-dependent string. In addresses, - it is simply interpreted on the particular host as a name of a - particular mailbox. - -3.5. Overall Message Syntax - - A message consists of header fields, optionally followed by a message - body. Lines in a message MUST be a maximum of 998 characters - excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 - characters excluding the CRLF. (See section 2.1.1 for explanation.) - In a message body, though all of the characters listed in the text - rule MAY be used, the use of US-ASCII control characters (values 1 - through 8, 11, 12, and 14 through 31) is discouraged since their - interpretation by receivers for display is not guaranteed. - - message = (fields / obs-fields) - [CRLF body] - - body = (*(*998text CRLF) *998text) / obs-body - - text = %d1-9 / ; Characters excluding CR - %d11 / ; and LF - %d12 / - %d14-127 - - - - - -Resnick Standards Track [Page 18] - -RFC 5322 Internet Message Format October 2008 - - - The header fields carry most of the semantic information and are - defined in section 3.6. The body is simply a series of lines of text - that are uninterpreted for the purposes of this specification. - -3.6. Field Definitions - - The header fields of a message are defined here. All header fields - have the same general syntactic structure: a field name, followed by - a colon, followed by the field body. The specific syntax for each - header field is defined in the subsequent sections. - - Note: In the ABNF syntax for each field in subsequent sections, - each field name is followed by the required colon. However, for - brevity, sometimes the colon is not referred to in the textual - description of the syntax. It is, nonetheless, required. - - It is important to note that the header fields are not guaranteed to - be in a particular order. They may appear in any order, and they - have been known to be reordered occasionally when transported over - the Internet. However, for the purposes of this specification, - header fields SHOULD NOT be reordered when a message is transported - or transformed. More importantly, the trace header fields and resent - header fields MUST NOT be reordered, and SHOULD be kept in blocks - prepended to the message. See sections 3.6.6 and 3.6.7 for more - information. - - The only required header fields are the origination date field and - the originator address field(s). All other header fields are - syntactically optional. More information is contained in the table - following this definition. - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 19] - -RFC 5322 Internet Message Format October 2008 - - - fields = *(trace - *optional-field / - *(resent-date / - resent-from / - resent-sender / - resent-to / - resent-cc / - resent-bcc / - resent-msg-id)) - *(orig-date / - from / - sender / - reply-to / - to / - cc / - bcc / - message-id / - in-reply-to / - references / - subject / - comments / - keywords / - optional-field) - - The following table indicates limits on the number of times each - field may occur in the header section of a message as well as any - special limitations on the use of those fields. An asterisk ("*") - next to a value in the minimum or maximum column indicates that a - special restriction appears in the Notes column. - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 20] - -RFC 5322 Internet Message Format October 2008 - - - +----------------+--------+------------+----------------------------+ - | Field | Min | Max number | Notes | - | | number | | | - +----------------+--------+------------+----------------------------+ - | trace | 0 | unlimited | Block prepended - see | - | | | | 3.6.7 | - | resent-date | 0* | unlimited* | One per block, required if | - | | | | other resent fields are | - | | | | present - see 3.6.6 | - | resent-from | 0 | unlimited* | One per block - see 3.6.6 | - | resent-sender | 0* | unlimited* | One per block, MUST occur | - | | | | with multi-address | - | | | | resent-from - see 3.6.6 | - | resent-to | 0 | unlimited* | One per block - see 3.6.6 | - | resent-cc | 0 | unlimited* | One per block - see 3.6.6 | - | resent-bcc | 0 | unlimited* | One per block - see 3.6.6 | - | resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 | - | orig-date | 1 | 1 | | - | from | 1 | 1 | See sender and 3.6.2 | - | sender | 0* | 1 | MUST occur with | - | | | | multi-address from - see | - | | | | 3.6.2 | - | reply-to | 0 | 1 | | - | to | 0 | 1 | | - | cc | 0 | 1 | | - | bcc | 0 | 1 | | - | message-id | 0* | 1 | SHOULD be present - see | - | | | | 3.6.4 | - | in-reply-to | 0* | 1 | SHOULD occur in some | - | | | | replies - see 3.6.4 | - | references | 0* | 1 | SHOULD occur in some | - | | | | replies - see 3.6.4 | - | subject | 0 | 1 | | - | comments | 0 | unlimited | | - | keywords | 0 | unlimited | | - | optional-field | 0 | unlimited | | - +----------------+--------+------------+----------------------------+ - - The exact interpretation of each field is described in subsequent - sections. - - - - - - - - - - - -Resnick Standards Track [Page 21] - -RFC 5322 Internet Message Format October 2008 - - -3.6.1. The Origination Date Field - - The origination date field consists of the field name "Date" followed - by a date-time specification. - - orig-date = "Date:" date-time CRLF - - The origination date specifies the date and time at which the creator - of the message indicated that the message was complete and ready to - enter the mail delivery system. For instance, this might be the time - that a user pushes the "send" or "submit" button in an application - program. In any case, it is specifically not intended to convey the - time that the message is actually transported, but rather the time at - which the human or other creator of the message has put the message - into its final form, ready for transport. (For example, a portable - computer user who is not connected to a network might queue a message - for delivery. The origination date is intended to contain the date - and time that the user queued the message, not the time when the user - connected to the network to send the message.) - -3.6.2. Originator Fields - - The originator fields of a message consist of the from field, the - sender field (when applicable), and optionally the reply-to field. - The from field consists of the field name "From" and a comma- - separated list of one or more mailbox specifications. If the from - field contains more than one mailbox specification in the mailbox- - list, then the sender field, containing the field name "Sender" and a - single mailbox specification, MUST appear in the message. In either - case, an optional reply-to field MAY also be included, which contains - the field name "Reply-To" and a comma-separated list of one or more - addresses. - - from = "From:" mailbox-list CRLF - - sender = "Sender:" mailbox CRLF - - reply-to = "Reply-To:" address-list CRLF - - The originator fields indicate the mailbox(es) of the source of the - message. The "From:" field specifies the author(s) of the message, - that is, the mailbox(es) of the person(s) or system(s) responsible - for the writing of the message. The "Sender:" field specifies the - mailbox of the agent responsible for the actual transmission of the - message. For example, if a secretary were to send a message for - another person, the mailbox of the secretary would appear in the - "Sender:" field and the mailbox of the actual author would appear in - the "From:" field. If the originator of the message can be indicated - - - -Resnick Standards Track [Page 22] - -RFC 5322 Internet Message Format October 2008 - - - by a single mailbox and the author and transmitter are identical, the - "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD - appear. - - Note: The transmitter information is always present. The absence - of the "Sender:" field is sometimes mistakenly taken to mean that - the agent responsible for transmission of the message has not been - specified. This absence merely means that the transmitter is - identical to the author and is therefore not redundantly placed - into the "Sender:" field. - - The originator fields also provide the information required when - replying to a message. When the "Reply-To:" field is present, it - indicates the address(es) to which the author of the message suggests - that replies be sent. In the absence of the "Reply-To:" field, - replies SHOULD by default be sent to the mailbox(es) specified in the - "From:" field unless otherwise specified by the person composing the - reply. - - In all cases, the "From:" field SHOULD NOT contain any mailbox that - does not belong to the author(s) of the message. See also section - 3.6.3 for more information on forming the destination addresses for a - reply. - -3.6.3. Destination Address Fields - - The destination fields of a message consist of three possible fields, - each of the same form: the field name, which is either "To", "Cc", or - "Bcc", followed by a comma-separated list of one or more addresses - (either mailbox or group syntax). - - to = "To:" address-list CRLF - - cc = "Cc:" address-list CRLF - - bcc = "Bcc:" [address-list / CFWS] CRLF - - The destination fields specify the recipients of the message. Each - destination field may have one or more addresses, and the addresses - indicate the intended recipients of the message. The only difference - between the three fields is how each is used. - - The "To:" field contains the address(es) of the primary recipient(s) - of the message. - - - - - - - -Resnick Standards Track [Page 23] - -RFC 5322 Internet Message Format October 2008 - - - The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of - making a copy on a typewriter using carbon paper) contains the - addresses of others who are to receive the message, though the - content of the message may not be directed at them. - - The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains - addresses of recipients of the message whose addresses are not to be - revealed to other recipients of the message. There are three ways in - which the "Bcc:" field is used. In the first case, when a message - containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is - removed even though all of the recipients (including those specified - in the "Bcc:" field) are sent a copy of the message. In the second - case, recipients specified in the "To:" and "Cc:" lines each are sent - a copy of the message with the "Bcc:" line removed as above, but the - recipients on the "Bcc:" line get a separate copy of the message - containing a "Bcc:" line. (When there are multiple recipient - addresses in the "Bcc:" field, some implementations actually send a - separate copy of the message to each recipient with a "Bcc:" - containing only the address of that particular recipient.) Finally, - since a "Bcc:" field may contain no addresses, a "Bcc:" field can be - sent without any addresses indicating to the recipients that blind - copies were sent to someone. Which method to use with "Bcc:" fields - is implementation dependent, but refer to the "Security - Considerations" section of this document for a discussion of each. - - When a message is a reply to another message, the mailboxes of the - authors of the original message (the mailboxes in the "From:" field) - or mailboxes specified in the "Reply-To:" field (if it exists) MAY - appear in the "To:" field of the reply since these would normally be - the primary recipients of the reply. If a reply is sent to a message - that has destination fields, it is often desirable to send a copy of - the reply to all of the recipients of the message, in addition to the - author. When such a reply is formed, addresses in the "To:" and - "Cc:" fields of the original message MAY appear in the "Cc:" field of - the reply, since these are normally secondary recipients of the - reply. If a "Bcc:" field is present in the original message, - addresses in that field MAY appear in the "Bcc:" field of the reply, - but they SHOULD NOT appear in the "To:" or "Cc:" fields. - - Note: Some mail applications have automatic reply commands that - include the destination addresses of the original message in the - destination addresses of the reply. How those reply commands - behave is implementation dependent and is beyond the scope of this - document. In particular, whether or not to include the original - destination addresses when the original message had a "Reply-To:" - field is not addressed here. - - - - - -Resnick Standards Track [Page 24] - -RFC 5322 Internet Message Format October 2008 - - -3.6.4. Identification Fields - - Though listed as optional in the table in section 3.6, every message - SHOULD have a "Message-ID:" field. Furthermore, reply messages - SHOULD have "In-Reply-To:" and "References:" fields as appropriate - and as described below. - - The "Message-ID:" field contains a single unique message identifier. - The "References:" and "In-Reply-To:" fields each contain one or more - unique message identifiers, optionally separated by CFWS. - - The message identifier (msg-id) syntax is a limited version of the - addr-spec construct enclosed in the angle bracket characters, "<" and - ">". Unlike addr-spec, this syntax only permits the dot-atom-text - form on the left-hand side of the "@" and does not have internal CFWS - anywhere in the message identifier. - - Note: As with addr-spec, a liberal syntax is given for the right- - hand side of the "@" in a msg-id. However, later in this section, - the use of a domain for the right-hand side of the "@" is - RECOMMENDED. Again, the syntax of domain constructs is specified - by and used in other protocols (e.g., [RFC1034], [RFC1035], - [RFC1123], [RFC5321]). It is therefore incumbent upon - implementations to conform to the syntax of addresses for the - context in which they are used. - - message-id = "Message-ID:" msg-id CRLF - - in-reply-to = "In-Reply-To:" 1*msg-id CRLF - - references = "References:" 1*msg-id CRLF - - msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] - - id-left = dot-atom-text / obs-id-left - - id-right = dot-atom-text / no-fold-literal / obs-id-right - - no-fold-literal = "[" *dtext "]" - - The "Message-ID:" field provides a unique message identifier that - refers to a particular version of a particular message. The - uniqueness of the message identifier is guaranteed by the host that - generates it (see below). This message identifier is intended to be - machine readable and not necessarily meaningful to humans. A message - identifier pertains to exactly one version of a particular message; - subsequent revisions to the message each receive new message - identifiers. - - - -Resnick Standards Track [Page 25] - -RFC 5322 Internet Message Format October 2008 - - - Note: There are many instances when messages are "changed", but - those changes do not constitute a new instantiation of that - message, and therefore the message would not get a new message - identifier. For example, when messages are introduced into the - transport system, they are often prepended with additional header - fields such as trace fields (described in section 3.6.7) and - resent fields (described in section 3.6.6). The addition of such - header fields does not change the identity of the message and - therefore the original "Message-ID:" field is retained. In all - cases, it is the meaning that the sender of the message wishes to - convey (i.e., whether this is the same message or a different - message) that determines whether or not the "Message-ID:" field - changes, not any particular syntactic difference that appears (or - does not appear) in the message. - - The "In-Reply-To:" and "References:" fields are used when creating a - reply to a message. They hold the message identifier of the original - message and the message identifiers of other messages (for example, - in the case of a reply to a message that was itself a reply). The - "In-Reply-To:" field may be used to identify the message (or - messages) to which the new message is a reply, while the - "References:" field may be used to identify a "thread" of - conversation. - - When creating a reply to a message, the "In-Reply-To:" and - "References:" fields of the resultant message are constructed as - follows: - - The "In-Reply-To:" field will contain the contents of the - "Message-ID:" field of the message to which this one is a reply (the - "parent message"). If there is more than one parent message, then - the "In-Reply-To:" field will contain the contents of all of the - parents' "Message-ID:" fields. If there is no "Message-ID:" field in - any of the parent messages, then the new message will have no "In- - Reply-To:" field. - - The "References:" field will contain the contents of the parent's - "References:" field (if any) followed by the contents of the parent's - "Message-ID:" field (if any). If the parent message does not contain - a "References:" field but does have an "In-Reply-To:" field - containing a single message identifier, then the "References:" field - will contain the contents of the parent's "In-Reply-To:" field - followed by the contents of the parent's "Message-ID:" field (if - any). If the parent has none of the "References:", "In-Reply-To:", - or "Message-ID:" fields, then the new message will have no - "References:" field. - - - - - -Resnick Standards Track [Page 26] - -RFC 5322 Internet Message Format October 2008 - - - Note: Some implementations parse the "References:" field to - display the "thread of the discussion". These implementations - assume that each new message is a reply to a single parent and - hence that they can walk backwards through the "References:" field - to find the parent of each message listed there. Therefore, - trying to form a "References:" field for a reply that has multiple - parents is discouraged; how to do so is not defined in this - document. - - The message identifier (msg-id) itself MUST be a globally unique - identifier for a message. The generator of the message identifier - MUST guarantee that the msg-id is unique. There are several - algorithms that can be used to accomplish this. Since the msg-id has - a similar syntax to addr-spec (identical except that quoted strings, - comments, and folding white space are not allowed), a good method is - to put the domain name (or a domain literal IP address) of the host - on which the message identifier was created on the right-hand side of - the "@" (since domain names and IP addresses are normally unique), - and put a combination of the current absolute date and time along - with some other currently unique (perhaps sequential) identifier - available on the system (for example, a process id number) on the - left-hand side. Though other algorithms will work, it is RECOMMENDED - that the right-hand side contain some domain identifier (either of - the host itself or otherwise) such that the generator of the message - identifier can guarantee the uniqueness of the left-hand side within - the scope of that domain. - - Semantically, the angle bracket characters are not part of the - msg-id; the msg-id is what is contained between the two angle bracket - characters. - -3.6.5. Informational Fields - - The informational fields are all optional. The "Subject:" and - "Comments:" fields are unstructured fields as defined in section - 2.2.1, and therefore may contain text or folding white space. The - "Keywords:" field contains a comma-separated list of one or more - words or quoted-strings. - - subject = "Subject:" unstructured CRLF - - comments = "Comments:" unstructured CRLF - - keywords = "Keywords:" phrase *("," phrase) CRLF - - These three fields are intended to have only human-readable content - with information about the message. The "Subject:" field is the most - common and contains a short string identifying the topic of the - - - -Resnick Standards Track [Page 27] - -RFC 5322 Internet Message Format October 2008 - - - message. When used in a reply, the field body MAY start with the - string "Re: " (an abbreviation of the Latin "in re", meaning "in the - matter of") followed by the contents of the "Subject:" field body of - the original message. If this is done, only one instance of the - literal string "Re: " ought to be used since use of other strings or - more than one instance can lead to undesirable consequences. The - "Comments:" field contains any additional comments on the text of the - body of the message. The "Keywords:" field contains a comma- - separated list of important words and phrases that might be useful - for the recipient. - -3.6.6. Resent Fields - - Resent fields SHOULD be added to any message that is reintroduced by - a user into the transport system. A separate set of resent fields - SHOULD be added each time this is done. All of the resent fields - corresponding to a particular resending of the message SHOULD be - grouped together. Each new set of resent fields is prepended to the - message; that is, the most recent set of resent fields appears - earlier in the message. No other fields in the message are changed - when resent fields are added. - - Each of the resent fields corresponds to a particular field elsewhere - in the syntax. For instance, the "Resent-Date:" field corresponds to - the "Date:" field and the "Resent-To:" field corresponds to the "To:" - field. In each case, the syntax for the field body is identical to - the syntax given previously for the corresponding field. - - When resent fields are used, the "Resent-From:" and "Resent-Date:" - fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. - "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be - identical to "Resent-From:". - - resent-date = "Resent-Date:" date-time CRLF - - resent-from = "Resent-From:" mailbox-list CRLF - - resent-sender = "Resent-Sender:" mailbox CRLF - - resent-to = "Resent-To:" address-list CRLF - - resent-cc = "Resent-Cc:" address-list CRLF - - resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF - - resent-msg-id = "Resent-Message-ID:" msg-id CRLF - - - - - -Resnick Standards Track [Page 28] - -RFC 5322 Internet Message Format October 2008 - - - Resent fields are used to identify a message as having been - reintroduced into the transport system by a user. The purpose of - using resent fields is to have the message appear to the final - recipient as if it were sent directly by the original sender, with - all of the original fields remaining the same. Each set of resent - fields correspond to a particular resending event. That is, if a - message is resent multiple times, each set of resent fields gives - identifying information for each individual time. Resent fields are - strictly informational. They MUST NOT be used in the normal - processing of replies or other such automatic actions on messages. - - Note: Reintroducing a message into the transport system and using - resent fields is a different operation from "forwarding". - "Forwarding" has two meanings: One sense of forwarding is that a - mail reading program can be told by a user to forward a copy of a - message to another person, making the forwarded message the body - of the new message. A forwarded message in this sense does not - appear to have come from the original sender, but is an entirely - new message from the forwarder of the message. Forwarding may - also mean that a mail transport program gets a message and - forwards it on to a different destination for final delivery. - Resent header fields are not intended for use with either type of - forwarding. - - The resent originator fields indicate the mailbox of the person(s) or - system(s) that resent the message. As with the regular originator - fields, there are two forms: a simple "Resent-From:" form, which - contains the mailbox of the individual doing the resending, and the - more complex form, when one individual (identified in the "Resent- - Sender:" field) resends a message on behalf of one or more others - (identified in the "Resent-From:" field). - - Note: When replying to a resent message, replies behave just as - they would with any other message, using the original "From:", - "Reply-To:", "Message-ID:", and other fields. The resent fields - are only informational and MUST NOT be used in the normal - processing of replies. - - The "Resent-Date:" indicates the date and time at which the resent - message is dispatched by the resender of the message. Like the - "Date:" field, it is not the date and time that the message was - actually transported. - - The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function - identically to the "To:", "Cc:", and "Bcc:" fields, respectively, - except that they indicate the recipients of the resent message, not - the recipients of the original message. - - - - -Resnick Standards Track [Page 29] - -RFC 5322 Internet Message Format October 2008 - - - The "Resent-Message-ID:" field provides a unique identifier for the - resent message. - -3.6.7. Trace Fields - - The trace fields are a group of header fields consisting of an - optional "Return-Path:" field, and one or more "Received:" fields. - The "Return-Path:" header field contains a pair of angle brackets - that enclose an optional addr-spec. The "Received:" field contains a - (possibly empty) list of tokens followed by a semicolon and a date- - time specification. Each token must be a word, angle-addr, addr- - spec, or a domain. Further restrictions are applied to the syntax of - the trace fields by specifications that provide for their use, such - as [RFC5321]. - - trace = [return] - 1*received - - return = "Return-Path:" path CRLF - - path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) - - received = "Received:" *received-token ";" date-time CRLF - - received-token = word / angle-addr / addr-spec / domain - - A full discussion of the Internet mail use of trace fields is - contained in [RFC5321]. For the purposes of this specification, the - trace fields are strictly informational, and any formal - interpretation of them is outside of the scope of this document. - -3.6.8. Optional Fields - - Fields may appear in messages that are otherwise unspecified in this - document. They MUST conform to the syntax of an optional-field. - This is a field name, made up of the printable US-ASCII characters - except SP and colon, followed by a colon, followed by any text that - conforms to the unstructured syntax. - - The field names of any optional field MUST NOT be identical to any - field name specified elsewhere in this document. - - - - - - - - - - -Resnick Standards Track [Page 30] - -RFC 5322 Internet Message Format October 2008 - - - optional-field = field-name ":" unstructured CRLF - - field-name = 1*ftext - - ftext = %d33-57 / ; Printable US-ASCII - %d59-126 ; characters not including - ; ":". - - For the purposes of this specification, any optional field is - uninterpreted. - -4. Obsolete Syntax - - Earlier versions of this specification allowed for different (usually - more liberal) syntax than is allowed in this version. Also, there - have been syntactic elements used in messages on the Internet whose - interpretations have never been documented. Though these syntactic - forms MUST NOT be generated according to the grammar in section 3, - they MUST be accepted and parsed by a conformant receiver. This - section documents many of these syntactic elements. Taking the - grammar in section 3 and adding the definitions presented in this - section will result in the grammar to use for the interpretation of - messages. - - Note: This section identifies syntactic forms that any - implementation MUST reasonably interpret. However, there are - certainly Internet messages that do not conform to even the - additional syntax given in this section. The fact that a - particular form does not appear in any section of this document is - not justification for computer programs to crash or for malformed - data to be irretrievably lost by any implementation. It is up to - the implementation to deal with messages robustly. - - One important difference between the obsolete (interpreting) and the - current (generating) syntax is that in structured header field bodies - (i.e., between the colon and the CRLF of any structured header - field), white space characters, including folding white space, and - comments could be freely inserted between any syntactic tokens. This - allowed many complex forms that have proven difficult for some - implementations to parse. - - Another key difference between the obsolete and the current syntax is - that the rule in section 3.2.2 regarding lines composed entirely of - white space in comments and folding white space does not apply. See - the discussion of folding white space in section 4.2 below. - - Finally, certain characters that were formerly allowed in messages - appear in this section. The NUL character (ASCII value 0) was once - - - -Resnick Standards Track [Page 31] - -RFC 5322 Internet Message Format October 2008 - - - allowed, but is no longer for compatibility reasons. Similarly, US- - ASCII control characters other than CR, LF, SP, and HTAB (ASCII - values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to - appear in header field bodies. CR and LF were allowed to appear in - messages other than as CRLF; this use is also shown here. - - Other differences in syntax and semantics are noted in the following - sections. - -4.1. Miscellaneous Obsolete Tokens - - These syntactic elements are used elsewhere in the obsolete syntax or - in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp, - obs-body, and obs-unstruct. US-ASCII control characters are added to - obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character - is added to obs-phrase. The obs-phrase-list provides for a - (potentially empty) comma-separated list of phrases that may include - "null" elements. That is, there could be two or more commas in such - a list with nothing in between them, or commas at the beginning or - end of the list. - - Note: The "period" (or "full stop") character (".") in obs-phrase - is not a form that was allowed in earlier versions of this or any - other specification. Period (nor any other character from - specials) was not allowed in phrase because it introduced a - parsing difficulty distinguishing between phrases and portions of - an addr-spec (see section 4.4). It appears here because the - period character is currently used in many messages in the - display-name portion of addresses, especially for initials in - names, and therefore must be interpreted properly. - - obs-NO-WS-CTL = %d1-8 / ; US-ASCII control - %d11 / ; characters that do not - %d12 / ; include the carriage - %d14-31 / ; return, line feed, and - %d127 ; white space characters - - obs-ctext = obs-NO-WS-CTL - - obs-qtext = obs-NO-WS-CTL - - obs-utext = %d0 / obs-NO-WS-CTL / VCHAR - - obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR) - - obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) - - obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS) - - - -Resnick Standards Track [Page 32] - -RFC 5322 Internet Message Format October 2008 - - - obs-phrase = word *(word / "." / CFWS) - - obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS]) - - Bare CR and bare LF appear in messages with two different meanings. - In many cases, bare CR or bare LF are used improperly instead of CRLF - to indicate line separators. In other cases, bare CR and bare LF are - used simply as US-ASCII control characters with their traditional - ASCII meanings. - -4.2. Obsolete Folding White Space - - In the obsolete syntax, any amount of folding white space MAY be - inserted where the obs-FWS rule is allowed. This creates the - possibility of having two consecutive "folds" in a line, and - therefore the possibility that a line which makes up a folded header - field could be composed entirely of white space. - - obs-FWS = 1*WSP *(CRLF 1*WSP) - -4.3. Obsolete Date and Time - - The syntax for the obsolete date format allows a 2 digit year in the - date field and allows for a list of alphabetic time zone specifiers - that were used in earlier versions of this specification. It also - permits comments and folding white space between many of the tokens. - - obs-day-of-week = [CFWS] day-name [CFWS] - - obs-day = [CFWS] 1*2DIGIT [CFWS] - - obs-year = [CFWS] 2*DIGIT [CFWS] - - obs-hour = [CFWS] 2DIGIT [CFWS] - - obs-minute = [CFWS] 2DIGIT [CFWS] - - obs-second = [CFWS] 2DIGIT [CFWS] - - obs-zone = "UT" / "GMT" / ; Universal Time - ; North American UT - ; offsets - "EST" / "EDT" / ; Eastern: - 5/ - 4 - "CST" / "CDT" / ; Central: - 6/ - 5 - "MST" / "MDT" / ; Mountain: - 7/ - 6 - "PST" / "PDT" / ; Pacific: - 8/ - 7 - ; - - - - -Resnick Standards Track [Page 33] - -RFC 5322 Internet Message Format October 2008 - - - %d65-73 / ; Military zones - "A" - %d75-90 / ; through "I" and "K" - %d97-105 / ; through "Z", both - %d107-122 ; upper and lower case - - Where a two or three digit year occurs in a date, the year is to be - interpreted as follows: If a two digit year is encountered whose - value is between 00 and 49, the year is interpreted by adding 2000, - ending up with a value between 2000 and 2049. If a two digit year is - encountered with a value between 50 and 99, or any three digit year - is encountered, the year is interpreted by adding 1900. - - In the obsolete time zone, "UT" and "GMT" are indications of - "Universal Time" and "Greenwich Mean Time", respectively, and are - both semantically identical to "+0000". - - The remaining three character zones are the US time zones. The first - letter, "E", "C", "M", or "P" stands for "Eastern", "Central", - "Mountain", and "Pacific". The second letter is either "S" for - "Standard" time, or "D" for "Daylight Savings" (or summer) time. - Their interpretations are as follows: - - EDT is semantically equivalent to -0400 - EST is semantically equivalent to -0500 - CDT is semantically equivalent to -0500 - CST is semantically equivalent to -0600 - MDT is semantically equivalent to -0600 - MST is semantically equivalent to -0700 - PDT is semantically equivalent to -0700 - PST is semantically equivalent to -0800 - - The 1 character military time zones were defined in a non-standard - way in [RFC0822] and are therefore unpredictable in their meaning. - The original definitions of the military zones "A" through "I" are - equivalent to "+0100" through "+0900", respectively; "K", "L", and - "M" are equivalent to "+1000", "+1100", and "+1200", respectively; - "N" through "Y" are equivalent to "-0100" through "-1200". - respectively; and "Z" is equivalent to "+0000". However, because of - the error in [RFC0822], they SHOULD all be considered equivalent to - "-0000" unless there is out-of-band information confirming their - meaning. - - Other multi-character (usually between 3 and 5) alphabetic time zones - have been used in Internet messages. Any such time zone whose - meaning is not known SHOULD be considered equivalent to "-0000" - unless there is out-of-band information confirming their meaning. - - - - - -Resnick Standards Track [Page 34] - -RFC 5322 Internet Message Format October 2008 - - -4.4. Obsolete Addressing - - There are four primary differences in addressing. First, mailbox - addresses were allowed to have a route portion before the addr-spec - when enclosed in "<" and ">". The route is simply a comma-separated - list of domain names, each preceded by "@", and the list terminated - by a colon. Second, CFWS were allowed between the period-separated - elements of local-part and domain (i.e., dot-atom was not used). In - addition, local-part is allowed to contain quoted-string in addition - to just atom. Third, mailbox-list and address-list were allowed to - have "null" members. That is, there could be two or more commas in - such a list with nothing in between them, or commas at the beginning - or end of the list. Finally, US-ASCII control characters and quoted- - pairs were allowed in domain literals and are added here. - - obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS] - - obs-route = obs-domain-list ":" - - obs-domain-list = *(CFWS / ",") "@" domain - *("," [CFWS] ["@" domain]) - - obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS]) - - obs-addr-list = *([CFWS] ",") address *("," [address / CFWS]) - - obs-group-list = 1*([CFWS] ",") [CFWS] - - obs-local-part = word *("." word) - - obs-domain = atom *("." atom) - - obs-dtext = obs-NO-WS-CTL / quoted-pair - - When interpreting addresses, the route portion SHOULD be ignored. - -4.5. Obsolete Header Fields - - Syntactically, the primary difference in the obsolete field syntax is - that it allows multiple occurrences of any of the fields and they may - occur in any order. Also, any amount of white space is allowed - before the ":" at the end of the field name. - - - - - - - - - -Resnick Standards Track [Page 35] - -RFC 5322 Internet Message Format October 2008 - - - obs-fields = *(obs-return / - obs-received / - obs-orig-date / - obs-from / - obs-sender / - obs-reply-to / - obs-to / - obs-cc / - obs-bcc / - obs-message-id / - obs-in-reply-to / - obs-references / - obs-subject / - obs-comments / - obs-keywords / - obs-resent-date / - obs-resent-from / - obs-resent-send / - obs-resent-rply / - obs-resent-to / - obs-resent-cc / - obs-resent-bcc / - obs-resent-mid / - obs-optional) - - Except for destination address fields (described in section 4.5.3), - the interpretation of multiple occurrences of fields is unspecified. - Also, the interpretation of trace fields and resent fields that do - not occur in blocks prepended to the message is unspecified as well. - Unless otherwise noted in the following sections, interpretation of - other fields is identical to the interpretation of their non-obsolete - counterparts in section 3. - -4.5.1. Obsolete Origination Date Field - - obs-orig-date = "Date" *WSP ":" date-time CRLF - -4.5.2. Obsolete Originator Fields - - obs-from = "From" *WSP ":" mailbox-list CRLF - - obs-sender = "Sender" *WSP ":" mailbox CRLF - - obs-reply-to = "Reply-To" *WSP ":" address-list CRLF - - - - - - - -Resnick Standards Track [Page 36] - -RFC 5322 Internet Message Format October 2008 - - -4.5.3. Obsolete Destination Address Fields - - obs-to = "To" *WSP ":" address-list CRLF - - obs-cc = "Cc" *WSP ":" address-list CRLF - - obs-bcc = "Bcc" *WSP ":" - (address-list / (*([CFWS] ",") [CFWS])) CRLF - - When multiple occurrences of destination address fields occur in a - message, they SHOULD be treated as if the address list in the first - occurrence of the field is combined with the address lists of the - subsequent occurrences by adding a comma and concatenating. - -4.5.4. Obsolete Identification Fields - - The obsolete "In-Reply-To:" and "References:" fields differ from the - current syntax in that they allow phrase (words or quoted strings) to - appear. The obsolete forms of the left and right sides of msg-id - allow interspersed CFWS, making them syntactically identical to - local-part and domain, respectively. - - obs-message-id = "Message-ID" *WSP ":" msg-id CRLF - - obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF - - obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF - - obs-id-left = local-part - - obs-id-right = domain - - For purposes of interpretation, the phrases in the "In-Reply-To:" and - "References:" fields are ignored. - - Semantically, none of the optional CFWS in the local-part and the - domain is part of the obs-id-left and obs-id-right, respectively. - -4.5.5. Obsolete Informational Fields - - obs-subject = "Subject" *WSP ":" unstructured CRLF - - obs-comments = "Comments" *WSP ":" unstructured CRLF - - obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF - - - - - - -Resnick Standards Track [Page 37] - -RFC 5322 Internet Message Format October 2008 - - -4.5.6. Obsolete Resent Fields - - The obsolete syntax adds a "Resent-Reply-To:" field, which consists - of the field name, the optional comments and folding white space, the - colon, and a comma separated list of addresses. - - obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF - - obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF - - obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF - - obs-resent-to = "Resent-To" *WSP ":" address-list CRLF - - obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF - - obs-resent-bcc = "Resent-Bcc" *WSP ":" - (address-list / (*([CFWS] ",") [CFWS])) CRLF - - obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF - - obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF - - As with other resent fields, the "Resent-Reply-To:" field is to be - treated as trace information only. - -4.5.7. Obsolete Trace Fields - - The obs-return and obs-received are again given here as template - definitions, just as return and received are in section 3. Their - full syntax is given in [RFC5321]. - - obs-return = "Return-Path" *WSP ":" path CRLF - - obs-received = "Received" *WSP ":" *received-token CRLF - -4.5.8. Obsolete optional fields - - obs-optional = field-name *WSP ":" unstructured CRLF - -5. Security Considerations - - Care needs to be taken when displaying messages on a terminal or - terminal emulator. Powerful terminals may act on escape sequences - and other combinations of US-ASCII control characters with a variety - of consequences. They can remap the keyboard or permit other - modifications to the terminal that could lead to denial of service or - even damaged data. They can trigger (sometimes programmable) - - - -Resnick Standards Track [Page 38] - -RFC 5322 Internet Message Format October 2008 - - - answerback messages that can allow a message to cause commands to be - issued on the recipient's behalf. They can also affect the operation - of terminal attached devices such as printers. Message viewers may - wish to strip potentially dangerous terminal escape sequences from - the message prior to display. However, other escape sequences appear - in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045], - [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore - should not be stripped indiscriminately. - - Transmission of non-text objects in messages raises additional - security issues. These issues are discussed in [RFC2045], [RFC2046], - [RFC2047], [RFC2049], [RFC4288], and [RFC4289]. - - Many implementations use the "Bcc:" (blind carbon copy) field, - described in section 3.6.3, to facilitate sending messages to - recipients without revealing the addresses of one or more of the - addressees to the other recipients. Mishandling this use of "Bcc:" - may disclose confidential information that could eventually lead to - security problems through knowledge of even the existence of a - particular mail address. For example, if using the first method - described in section 3.6.3, where the "Bcc:" line is removed from the - message, blind recipients have no explicit indication that they have - been sent a blind copy, except insofar as their address does not - appear in the header section of a message. Because of this, one of - the blind addressees could potentially send a reply to all of the - shown recipients and accidentally reveal that the message went to the - blind recipient. When the second method from section 3.6.3 is used, - the blind recipient's address appears in the "Bcc:" field of a - separate copy of the message. If the "Bcc:" field sent contains all - of the blind addressees, all of the "Bcc:" recipients will be seen by - each "Bcc:" recipient. Even if a separate message is sent to each - "Bcc:" recipient with only the individual's address, implementations - still need to be careful to process replies to the message as per - section 3.6.3 so as not to accidentally reveal the blind recipient to - other recipients. - -6. IANA Considerations - - This document updates the registrations that appeared in [RFC4021] - that referred to the definitions in [RFC2822]. IANA has updated the - Permanent Message Header Field Repository with the following header - fields, in accordance with the procedures set out in [RFC3864]. - - Header field name: Date - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.1) - - - -Resnick Standards Track [Page 39] - -RFC 5322 Internet Message Format October 2008 - - - Header field name: From - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.2) - - Header field name: Sender - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.2) - - Header field name: Reply-To - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.2) - - Header field name: To - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.3) - - Header field name: Cc - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.3) - - Header field name: Bcc - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.3) - - Header field name: Message-ID - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.4) - - Header field name: In-Reply-To - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.4) - - - - -Resnick Standards Track [Page 40] - -RFC 5322 Internet Message Format October 2008 - - - Header field name: References - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.4) - - Header field name: Subject - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.5) - - Header field name: Comments - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.5) - - Header field name: Keywords - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.5) - - Header field name: Resent-Date - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Resent-From - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Resent-Sender - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Resent-To - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - - - -Resnick Standards Track [Page 41] - -RFC 5322 Internet Message Format October 2008 - - - Header field name: Resent-Cc - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Resent-Bcc - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Resent-Reply-To - Applicable protocol: Mail - Status: obsolete - Author/Change controller: IETF - Specification document(s): This document (section 4.5.6) - - Header field name: Resent-Message-ID - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.6) - - Header field name: Return-Path - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.7) - - Header field name: Received - Applicable protocol: Mail - Status: standard - Author/Change controller: IETF - Specification document(s): This document (section 3.6.7) - Related information: [RFC5321] - - - - - - - - - - - - - - - -Resnick Standards Track [Page 42] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A. Example Messages - - This section presents a selection of messages. These are intended to - assist in the implementation of this specification, but should not be - taken as normative; that is to say, although the examples in this - section were carefully reviewed, if there happens to be a conflict - between these examples and the syntax described in sections 3 and 4 - of this document, the syntax in those sections is to be taken as - correct. - - In the text version of this document, messages in this section are - delimited between lines of "----". The "----" lines are not part of - the message itself. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 43] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.1. Addressing Examples - - The following are examples of messages that might be sent between two - individuals. - -Appendix A.1.1. A Message from One Person to Another with Simple - Addressing - - This could be called a canonical message. It has a single author, - John Doe, a single recipient, Mary Smith, a subject, the date, a - message identifier, and a textual message in the body. - - ---- - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - If John's secretary Michael actually sent the message, even though - John was the author and replies to this message should go back to - him, the sender field would be used: - - ---- - From: John Doe - Sender: Michael Jones - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - - - - - - - - - - - - -Resnick Standards Track [Page 44] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.1.2. Different Types of Mailboxes - - This message includes multiple addresses in the destination fields - and also uses several different forms of addresses. - - ---- - From: "Joe Q. Public" - To: Mary Smith , jdoe@example.org, Who? - Cc: , "Giant; \"Big\" Box" - Date: Tue, 1 Jul 2003 10:52:37 +0200 - Message-ID: <5678.21-Nov-1997@example.com> - - Hi everyone. - ---- - - Note that the display names for Joe Q. Public and Giant; "Big" Box - needed to be enclosed in double-quotes because the former contains - the period and the latter contains both semicolon and double-quote - characters (the double-quote characters appearing as quoted-pair - constructs). Conversely, the display name for Who? could appear - without them because the question mark is legal in an atom. Notice - also that jdoe@example.org and boss@nil.test have no display names - associated with them at all, and jdoe@example.org uses the simpler - address form without the angle brackets. - -Appendix A.1.3. Group Addresses - - ---- - From: Pete - To: A Group:Ed Jones ,joe@where.test,John ; - Cc: Undisclosed recipients:; - Date: Thu, 13 Feb 1969 23:32:54 -0330 - Message-ID: - - Testing. - ---- - - In this message, the "To:" field has a single group recipient named - "A Group", which contains 3 addresses, and a "Cc:" field with an - empty group recipient named Undisclosed recipients. - - - - - - - - - - - -Resnick Standards Track [Page 45] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.2. Reply Messages - - The following is a series of three messages that make up a - conversation thread between John and Mary. John first sends a - message to Mary, Mary then replies to John's message, and then John - replies to Mary's reply message. - - Note especially the "Message-ID:", "References:", and "In-Reply-To:" - fields in each message. - - ---- - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - When sending replies, the Subject field is often retained, though - prepended with "Re: " as described in section 3.6.5. - - ---- - From: Mary Smith - To: John Doe - Reply-To: "Mary Smith: Personal Account" - Subject: Re: Saying Hello - Date: Fri, 21 Nov 1997 10:01:10 -0600 - Message-ID: <3456@example.net> - In-Reply-To: <1234@local.machine.example> - References: <1234@local.machine.example> - - This is a reply to your hello. - ---- - - Note the "Reply-To:" field in the above message. When John replies - to Mary's message above, the reply should go to the address in the - "Reply-To:" field instead of the address in the "From:" field. - - - - - - - - - - - -Resnick Standards Track [Page 46] - -RFC 5322 Internet Message Format October 2008 - - - ---- - To: "Mary Smith: Personal Account" - From: John Doe - Subject: Re: Saying Hello - Date: Fri, 21 Nov 1997 11:00:00 -0600 - Message-ID: - In-Reply-To: <3456@example.net> - References: <1234@local.machine.example> <3456@example.net> - - This is a reply to your reply. - ---- - -Appendix A.3. Resent Messages - - Start with the message that has been used as an example several - times: - - ---- - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - Say that Mary, upon receiving this message, wishes to send a copy of - the message to Jane such that (a) the message would appear to have - come straight from John; (b) if Jane replies to the message, the - reply should go back to John; and (c) all of the original - information, like the date the message was originally sent to Mary, - the message identifier, and the original addressee, is preserved. In - this case, resent fields are prepended to the message: - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 47] - -RFC 5322 Internet Message Format October 2008 - - - ---- - Resent-From: Mary Smith - Resent-To: Jane Brown - Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 - Resent-Message-ID: <78910@example.net> - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - If Jane, in turn, wished to resend this message to another person, - she would prepend her own set of resent header fields to the above - and send that. (Note that for brevity, trace fields are not shown.) - -Appendix A.4. Messages with Trace Fields - - As messages are sent through the transport system as described in - [RFC5321], trace fields are prepended to the message. The following - is an example of what those trace fields might look like. Note that - there is some folding white space in the first one since these lines - can be long. - - ---- - Received: from x.y.test - by example.net - via TCP - with ESMTP - id ABC12345 - for ; 21 Nov 1997 10:05:43 -0600 - Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600 - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: Fri, 21 Nov 1997 09:55:06 -0600 - Message-ID: <1234@local.node.example> - - This is a message just to say hello. - So, "Hello". - ---- - - - - - - - -Resnick Standards Track [Page 48] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.5. White Space, Comments, and Other Oddities - - White space, including folding white space, and comments can be - inserted between many of the tokens of fields. Taking the example - from A.1.3, white space and comments can be inserted into all of the - fields. - - ---- - From: Pete(A nice \) chap) - To:A Group(Some people) - :Chris Jones , - joe@example.org, - John (my dear friend); (the end of the group) - Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ; - Date: Thu, - 13 - Feb - 1969 - 23:32 - -0330 (Newfoundland Time) - Message-ID: - - Testing. - ---- - - The above example is aesthetically displeasing, but perfectly legal. - Note particularly (1) the comments in the "From:" field (including - one that has a ")" character appearing as part of a quoted-pair); (2) - the white space absent after the ":" in the "To:" field as well as - the comment and folding white space after the group name, the special - character (".") in the comment in Chris Jones's address, and the - folding white space before and after "joe@example.org,"; (3) the - multiple and nested comments in the "Cc:" field as well as the - comment immediately following the ":" after "Cc"; (4) the folding - white space (but no comments except at the end) and the missing - seconds in the time of the date field; and (5) the white space before - (but not within) the identifier in the "Message-ID:" field. - - - - - - - - - - - - - - -Resnick Standards Track [Page 49] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.6. Obsoleted Forms - - The following are examples of obsolete (that is, the "MUST NOT - generate") syntactic elements described in section 4 of this - document. - -Appendix A.6.1. Obsolete Addressing - - Note in the example below the lack of quotes around Joe Q. Public, - the route that appears in the address for Mary Smith, the two commas - that appear in the "To:" field, and the spaces that appear around the - "." in the jdoe address. - - ---- - From: Joe Q. Public - To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example - Date: Tue, 1 Jul 2003 10:52:37 +0200 - Message-ID: <5678.21-Nov-1997@example.com> - - Hi everyone. - ---- - -Appendix A.6.2. Obsolete Dates - - The following message uses an obsolete date format, including a non- - numeric time zone and a two digit year. Note that although the day- - of-week is missing, that is not specific to the obsolete syntax; it - is optional in the current syntax as well. - - ---- - From: John Doe - To: Mary Smith - Subject: Saying Hello - Date: 21 Nov 97 09:55:06 GMT - Message-ID: <1234@local.machine.example> - - This is a message just to say hello. - So, "Hello". - ---- - - - - - - - - - - - - -Resnick Standards Track [Page 50] - -RFC 5322 Internet Message Format October 2008 - - -Appendix A.6.3. Obsolete White Space and Comments - - White space and comments can appear between many more elements than - in the current syntax. Also, folding lines that are made up entirely - of white space are legal. - - ---- - From : John Doe - To : Mary Smith - __ - - Subject : Saying Hello - Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 - Message-ID : <1234 @ local(blah) .machine .example> - - This is a message just to say hello. - So, "Hello". - ---- - - Note especially the second line of the "To:" field. It starts with - two space characters. (Note that "__" represent blank spaces.) - Therefore, it is considered part of the folding, as described in - section 4.2. Also, the comments and white space throughout - addresses, dates, and message identifiers are all part of the - obsolete syntax. - - - - - - - - - - - - - - - - - - - - - - - - - - -Resnick Standards Track [Page 51] - -RFC 5322 Internet Message Format October 2008 - - -Appendix B. Differences from Earlier Specifications - - This appendix contains a list of changes that have been made in the - Internet Message Format from earlier specifications, specifically - [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk - (*) below are items which appear in section 4 of this document and - therefore can no longer be generated. - - The following are the changes made from [RFC0822] and [RFC1123] to - [RFC2822] that remain in this document: - - 1. Period allowed in obsolete form of phrase. - 2. ABNF moved out of document, now in [RFC5234]. - 3. Four or more digits allowed for year. - 4. Header field ordering (and lack thereof) made explicit. - 5. Encrypted header field removed. - 6. Specifically allow and give meaning to "-0000" time zone. - 7. Folding white space is not allowed between every token. - 8. Requirement for destinations removed. - 9. Forwarding and resending redefined. - 10. Extension header fields no longer specifically called out. - 11. ASCII 0 (null) removed.* - 12. Folding continuation lines cannot contain only white space.* - 13. Free insertion of comments not allowed in date.* - 14. Non-numeric time zones not allowed.* - 15. Two digit years not allowed.* - 16. Three digit years interpreted, but not allowed for generation.* - 17. Routes in addresses not allowed.* - 18. CFWS within local-parts and domains not allowed.* - 19. Empty members of address lists not allowed.* - 20. Folding white space between field name and colon not allowed.* - 21. Comments between field name and colon not allowed. - 22. Tightened syntax of in-reply-to and references.* - 23. CFWS within msg-id not allowed.* - 24. Tightened semantics of resent fields as informational only. - 25. Resent-Reply-To not allowed.* - 26. No multiple occurrences of fields (except resent and received).* - 27. Free CR and LF not allowed.* - 28. Line length limits specified. - 29. Bcc more clearly specified. - - - - - - - - - - - -Resnick Standards Track [Page 52] - -RFC 5322 Internet Message Format October 2008 - - - The following are changes from [RFC2822]. - 1. Assorted typographical/grammatical errors fixed and - clarifications made. - 2. Changed "standard" to "document" or "specification" throughout. - 3. Made distinction between "header field" and "header section". - 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.* - 5. Moved discussion of specials to the "Atom" section. Moved text - to "Overall message syntax" section. - 6. Simplified CFWS syntax. - 7. Fixed unstructured syntax. - 8. Changed date and time syntax to deal with white space in - obsolete date syntax. - 9. Removed quoted-pair from domain literals and message - identifiers.* - 10. Clarified that other specifications limit domain syntax. - 11. Simplified "Bcc:" and "Resent-Bcc:" syntax. - 12. Allowed optional-field to appear within trace information. - 13. Removed no-fold-quote from msg-id. Clarified syntax - limitations. - 14. Generalized "Received:" syntax to fix bugs and move definition - out of this document. - 15. Simplified obs-qp. Fixed and simplified obs-utext (which now - only appears in the obsolete syntax). Removed obs-text and obs- - char, adding obs-body. - 16. Fixed obsolete date syntax to allow for more (or less) comments - and white space. - 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list, - obs-addr-list, obs-phrase-list, and the newly added obs-group- - list). - 18. Fixed obs-reply-to syntax. - 19. Fixed obs-bcc and obs-resent-bcc to allow empty lists. - 20. Removed obs-path. - -Appendix C. Acknowledgements - - Many people contributed to this document. They included folks who - participated in the Detailed Revision and Update of Messaging - Standards (DRUMS) Working Group of the Internet Engineering Task - Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and - people who simply sent their comments in via email. The editor is - deeply indebted to them all and thanks them sincerely. The below - list includes everyone who sent email concerning both this document - and [RFC2822]. Hopefully, everyone who contributed is named here: - - +--------------------+----------------------+---------------------+ - | Matti Aarnio | Tanaka Akira | Russ Allbery | - | Eric Allman | Harald Alvestrand | Ran Atkinson | - | Jos Backus | Bruce Balden | Dave Barr | - - - -Resnick Standards Track [Page 53] - -RFC 5322 Internet Message Format October 2008 - - - | Alan Barrett | John Beck | J Robert von Behren | - | Jos den Bekker | D J Bernstein | James Berriman | - | Oliver Block | Norbert Bollow | Raj Bose | - | Antony Bowesman | Scott Bradner | Randy Bush | - | Tom Byrer | Bruce Campbell | Larry Campbell | - | W J Carpenter | Michael Chapman | Richard Clayton | - | Maurizio Codogno | Jim Conklin | R Kelley Cook | - | Nathan Coulter | Steve Coya | Mark Crispin | - | Dave Crocker | Matt Curtin | Michael D'Errico | - | Cyrus Daboo | Michael D Dean | Jutta Degener | - | Mark Delany | Steve Dorner | Harold A Driscoll | - | Michael Elkins | Frank Ellerman | Robert Elz | - | Johnny Eriksson | Erik E Fair | Roger Fajman | - | Patrik Faltstrom | Claus Andre Faerber | Barry Finkel | - | Erik Forsberg | Chuck Foster | Paul Fox | - | Klaus M Frank | Ned Freed | Jochen Friedrich | - | Randall C Gellens | Sukvinder Singh Gill | Tim Goodwin | - | Philip Guenther | Arnt Gulbrandsen | Eric A Hall | - | Tony Hansen | John Hawkinson | Philip Hazel | - | Kai Henningsen | Robert Herriot | Paul Hethmon | - | Jim Hill | Alfred Hoenes | Paul E Hoffman | - | Steve Hole | Kari Hurtta | Marco S Hyman | - | Ofer Inbar | Olle Jarnefors | Kevin Johnson | - | Sudish Joseph | Maynard Kang | Prabhat Keni | - | John C Klensin | Graham Klyne | Brad Knowles | - | Shuhei Kobayashi | Peter Koch | Dan Kohn | - | Christian Kuhtz | Anand Kumria | Steen Larsen | - | Eliot Lear | Barry Leiba | Jay Levitt | - | Bruce Lilly | Lars-Johan Liman | Charles Lindsey | - | Pete Loshin | Simon Lyall | Bill Manning | - | John Martin | Mark Martinec | Larry Masinter | - | Denis McKeon | William P McQuillan | Alexey Melnikov | - | Perry E Metzger | Steven Miller | S Moonesamy | - | Keith Moore | John Gardiner Myers | Chris Newman | - | John W Noerenberg | Eric Norman | Mike O'Dell | - | Larry Osterman | Paul Overell | Jacob Palme | - | Michael A Patton | Uzi Paz | Michael A Quinlan | - | Robert Rapplean | Eric S Raymond | Sam Roberts | - | Hugh Sasse | Bart Schaefer | Tom Scola | - | Wolfgang Segmuller | Nick Shelness | John Stanley | - | Einar Stefferud | Jeff Stephenson | Bernard Stern | - | Peter Sylvester | Mark Symons | Eric Thomas | - | Lee Thompson | Karel De Vriendt | Matthew Wall | - | Rolf Weber | Brent B Welch | Dan Wing | - | Jack De Winter | Gregory J Woodhouse | Greg A Woods | - | Kazu Yamamoto | Alain Zahm | Jamie Zawinski | - | Timothy S Zurcher | | | - +--------------------+----------------------+---------------------+ - - - -Resnick Standards Track [Page 54] - -RFC 5322 Internet Message Format October 2008 - - -7. References - -7.1. Normative References - - [ANSI.X3-4.1986] American National Standards Institute, "Coded - Character Set - 7-bit American Standard Code for - Information Interchange", ANSI X3.4, 1986. - - [RFC1034] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - - Application and Support", STD 3, RFC 1123, - October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", STD 68, RFC 5234, - January 2008. - -7.2. Informative References - - [RFC0822] Crocker, D., "Standard for the format of ARPA - Internet text messages", STD 11, RFC 822, - August 1982. - - [RFC1305] Mills, D., "Network Time Protocol (Version 3) - Specification, Implementation", RFC 1305, - March 1992. - - [ISO.2022.1994] International Organization for Standardization, - "Information technology - Character code structure - and extension techniques", ISO Standard 2022, 1994. - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) Part One: Format of Internet - Message Bodies", RFC 2045, November 1996. - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) Part Two: Media Types", - RFC 2046, November 1996. - - - - - -Resnick Standards Track [Page 55] - -RFC 5322 Internet Message Format October 2008 - - - [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail - Extensions) Part Three: Message Header Extensions - for Non-ASCII Text", RFC 2047, November 1996. - - [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet - Mail Extensions (MIME) Part Five: Conformance - Criteria and Examples", RFC 2049, November 1996. - - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, - April 2001. - - [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, - "Registration Procedures for Message Header - Fields", BCP 90, RFC 3864, September 2004. - - [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and - MIME Header Fields", RFC 4021, March 2005. - - [RFC4288] Freed, N. and J. Klensin, "Media Type - Specifications and Registration Procedures", - BCP 13, RFC 4288, December 2005. - - [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet - Mail Extensions (MIME) Part Four: Registration - Procedures", BCP 13, RFC 4289, December 2005. - - [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", - RFC 5321, October 2008. - -Author's Address - - Peter W. Resnick (editor) - Qualcomm Incorporated - 5775 Morehouse Drive - San Diego, CA 92121-1714 - US - - Phone: +1 858 651 4478 - EMail: presnick@qualcomm.com - URI: http://www.qualcomm.com/~presnick/ - - - - - - - - - - - -Resnick Standards Track [Page 56] - -RFC 5322 Internet Message Format October 2008 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - -Resnick Standards Track [Page 57] - diff --git a/specifications/mail/rfc5652.txt b/specifications/mail/rfc5652.txt deleted file mode 100644 index 71f61de7..00000000 --- a/specifications/mail/rfc5652.txt +++ /dev/null @@ -1,3139 +0,0 @@ - - - - - - -Network Working Group R. Housley -Request for Comments: 5652 Vigil Security -Obsoletes: 3852 September 2009 -Category: Standards Track - - - Cryptographic Message Syntax (CMS) - -Abstract - - This document describes the Cryptographic Message Syntax (CMS). This - syntax is used to digitally sign, digest, authenticate, or encrypt - arbitrary message content. - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright and License Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - - - -Housley Standards Track [Page 1] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -Table of Contents - - 1. Introduction ....................................................3 - 1.1. Evolution of the CMS .......................................4 - 1.1.1. Changes Since PKCS #7 Version 1.5 ...................4 - 1.1.2. Changes Since RFC 2630 ..............................4 - 1.1.3. Changes Since RFC 3369 ..............................5 - 1.1.4. Changes Since RFC 3852 ..............................5 - 1.2. Terminology ................................................5 - 1.3. Version Numbers ............................................6 - 2. General Overview ................................................6 - 3. General Syntax ..................................................7 - 4. Data Content Type ...............................................7 - 5. Signed-data Content Type ........................................8 - 5.1. SignedData Type ............................................9 - 5.2. EncapsulatedContentInfo Type ..............................11 - 5.2.1. Compatibility with PKCS #7 .........................12 - 5.3. SignerInfo Type ...........................................13 - 5.4. Message Digest Calculation Process ........................16 - 5.5. Signature Generation Process ..............................16 - 5.6. Signature Verification Process ............................17 - 6. Enveloped-Data Content Type ....................................17 - 6.1. EnvelopedData Type ........................................18 - 6.2. RecipientInfo Type ........................................21 - 6.2.1. KeyTransRecipientInfo Type .........................22 - 6.2.2. KeyAgreeRecipientInfo Type .........................23 - 6.2.3. KEKRecipientInfo Type ..............................25 - 6.2.4. PasswordRecipientInfo Type .........................26 - 6.2.5. OtherRecipientInfo Type ............................27 - 6.3. Content-encryption Process ................................27 - 6.4. Key-Encryption Process ....................................28 - 7. Digested-Data Content Type .....................................28 - 8. Encrypted-Data Content Type ....................................29 - 9. Authenticated-Data Content Type ................................30 - 9.1. AuthenticatedData Type ....................................31 - 9.2. MAC Generation ............................................33 - 9.3. MAC Verification ..........................................34 - 10. Useful Types ..................................................34 - 10.1. Algorithm Identifier Types ...............................35 - 10.1.1. DigestAlgorithmIdentifier .........................35 - 10.1.2. SignatureAlgorithmIdentifier ......................35 - 10.1.3. KeyEncryptionAlgorithmIdentifier ..................35 - 10.1.4. ContentEncryptionAlgorithmIdentifier ..............36 - 10.1.5. MessageAuthenticationCodeAlgorithm ................36 - 10.1.6. KeyDerivationAlgorithmIdentifier ..................36 - 10.2. Other Useful Types .......................................36 - 10.2.1. RevocationInfoChoices .............................36 - 10.2.2. CertificateChoices ................................37 - - - -Housley Standards Track [Page 2] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - 10.2.3. CertificateSet ....................................38 - 10.2.4. IssuerAndSerialNumber .............................38 - 10.2.5. CMSVersion ........................................39 - 10.2.6. UserKeyingMaterial ................................39 - 10.2.7. OtherKeyAttribute .................................39 - 11. Useful Attributes .............................................39 - 11.1. Content Type .............................................40 - 11.2. Message Digest ...........................................40 - 11.3. Signing Time .............................................41 - 11.4. Countersignature .........................................42 - 12. ASN.1 Modules .................................................43 - 12.1. CMS ASN.1 Module .........................................44 - 12.2. Version 1 Attribute Certificate ASN.1 Module .............51 - 13. References ....................................................52 - 13.1. Normative References .....................................52 - 13.2. Informative References ...................................53 - 14. Security Considerations .......................................54 - 15. Acknowledgments ...............................................56 - -1. Introduction - - This document describes the Cryptographic Message Syntax (CMS). This - syntax is used to digitally sign, digest, authenticate, or encrypt - arbitrary message content. - - The CMS describes an encapsulation syntax for data protection. It - supports digital signatures and encryption. The syntax allows - multiple encapsulations; one encapsulation envelope can be nested - inside another. Likewise, one party can digitally sign some - previously encapsulated data. It also allows arbitrary attributes, - such as signing time, to be signed along with the message content, - and it provides for other attributes such as countersignatures to be - associated with a signature. - - The CMS can support a variety of architectures for certificate-based - key management, such as the one defined by the PKIX (Public Key - Infrastructure using X.509) working group [PROFILE]. - - The CMS values are generated using ASN.1 [X.208-88], using BER- - encoding (Basic Encoding Rules) [X.209-88]. Values are typically - represented as octet strings. While many systems are capable of - transmitting arbitrary octet strings reliably, it is well known that - many electronic mail systems are not. This document does not address - mechanisms for encoding octet strings for reliable transmission in - such environments. - - - - - - -Housley Standards Track [Page 3] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -1.1. Evolution of the CMS - - The CMS is derived from PKCS #7 version 1.5, which is documented in - RFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the - IETF; it was originally published as an RSA Laboratories Technical - Note in November 1993. Since that time, the IETF has taken - responsibility for the development and maintenance of the CMS. - Today, several important IETF Standards-Track protocols make use of - the CMS. - - This section describes that changes that the IETF has made to the CMS - in each of the published versions. - -1.1.1. Changes Since PKCS #7 Version 1.5 - - RFC 2630 [CMS1] was the first version of the CMS on the IETF - Standards Track. Wherever possible, backward compatibility with PKCS - #7 version 1.5 is preserved; however, changes were made to - accommodate version 1 attribute certificate transfer and to support - algorithm-independent key management. PKCS #7 version 1.5 included - support only for key transport. RFC 2630 adds support for key - agreement and previously distributed symmetric key-encryption key - techniques. - -1.1.2. Changes Since RFC 2630 - - RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI]. - Password-based key management is included in the CMS specification, - and an extension mechanism to support new key management schemes - without further changes to the CMS is specified. Backward - compatibility with RFC 2630 and RFC 3211 is preserved; however, - version 2 attribute certificate transfer is added, and the use of - version 1 attribute certificates is deprecated. - - Secure/Multipurpose Internet Mail Extensions (S/MIME) v2 signatures - [MSG2], which are based on PKCS #7 version 1.5, are compatible with - S/MIME v3 signatures [MSG3]and S/MIME v3.1 signatures [MSG3.1]. - However, there are some subtle compatibility issues with signatures - based on PKCS #7 version 1.5. These issues are discussed in Section - 5.2.1. These issues remain with the current version of the CMS. - - Specific cryptographic algorithms are not discussed in this document, - but they were discussed in RFC 2630. The discussion of specific - cryptographic algorithms has been moved to a separate document - [CMSALG]. Separation of the protocol and algorithm specifications - allows the IETF to update each document independently. This - specification does not require the implementation of any particular - - - - -Housley Standards Track [Page 4] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - algorithms. Rather, protocols that rely on the CMS are expected to - choose appropriate algorithms for their environment. The algorithms - may be selected from [CMSALG] or elsewhere. - -1.1.3. Changes Since RFC 3369 - - RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in the - previous section, RFC 3369 introduced an extension mechanism to - support new key management schemes without further changes to the - CMS. RFC 3852 introduces a similar extension mechanism to support - additional certificate formats and revocation status information - formats without further changes to the CMS. These extensions are - primarily documented in Sections 10.2.1 and 10.2.2. Backward - compatibility with earlier versions of the CMS is preserved. - - The use of version numbers is described in Section 1.3. - - Since the publication of RFC 3369, a few errata have been noted. - These errata are posted on the RFC Editor web site. These errors - have been corrected in this document. - - The text in Section 11.4 that describes the counter signature - unsigned attribute is clarified. Hopefully, the revised text is - clearer about the portion of the SignerInfo signature that is covered - by a countersignature. - -1.1.4. Changes Since RFC 3852 - - This document obsoletes RFC 3852 [CMS3]. The primary reason for the - publication of this document is to advance the CMS along the - standards maturity ladder. - - This document includes the clarifications that were originally - published in RFC 4853 [CMSMSIG] regarding the proper handling of the - SignedData protected content type when more than one digital - signature is present. - - Since the publication of RFC 3852, a few errata have been noted. - These errata are posted on the RFC Editor web site. These errors - have been corrected in this document. - -1.2. Terminology - - In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as - described in [STDWORDS]. - - - - - -Housley Standards Track [Page 5] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -1.3. Version Numbers - - Each of the major data structures includes a version number as the - first item in the data structure. The version numbers are intended - to avoid ASN.1 decode errors. Some implementations do not check the - version number prior to attempting a decode, and if a decode error - occurs, then the version number is checked as part of the error - handling routine. This is a reasonable approach; it places error - processing outside of the fast path. This approach is also forgiving - when an incorrect version number is used by the sender. - - Most of the initial version numbers were assigned in PKCS #7 version - 1.5. Others were assigned when the structure was initially created. - Whenever a structure is updated, a higher version number is assigned. - However, to ensure maximum interoperability, the higher version - number is only used when the new syntax feature is employed. That - is, the lowest version number that supports the generated syntax is - used. - -2. General Overview - - The CMS is general enough to support many different content types. - This document defines one protection content, ContentInfo. - ContentInfo encapsulates a single identified content type, and the - identified type may provide further encapsulation. This document - defines six content types: data, signed-data, enveloped-data, - digested-data, encrypted-data, and authenticated-data. Additional - content types can be defined outside this document. - - An implementation that conforms to this specification MUST implement - the protection content, ContentInfo, and MUST implement the data, - signed-data, and enveloped-data content types. The other content - types MAY be implemented. - - As a general design philosophy, each content type permits single pass - processing using indefinite-length Basic Encoding Rules (BER) - encoding. Single-pass operation is especially helpful if content is - large, stored on tapes, or is "piped" from another process. Single- - pass operation has one significant drawback: it is difficult to - perform encode operations using the Distinguished Encoding Rules - (DER) [X.509-88] encoding in a single pass since the lengths of the - various components may not be known in advance. However, signed - attributes within the signed-data content type and authenticated - attributes within the authenticated-data content type need to be - transmitted in DER form to ensure that recipients can verify a - content that contains one or more unrecognized attributes. Signed - attributes and authenticated attributes are the only data types used - in the CMS that require DER encoding. - - - -Housley Standards Track [Page 6] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -3. General Syntax - - The following object identifier identifies the content information - type: - - id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } - - The CMS associates a content type identifier with a content. The - syntax MUST have ASN.1 type ContentInfo: - - ContentInfo ::= SEQUENCE { - contentType ContentType, - content [0] EXPLICIT ANY DEFINED BY contentType } - - ContentType ::= OBJECT IDENTIFIER - - The fields of ContentInfo have the following meanings: - - contentType indicates the type of the associated content. It is - an object identifier; it is a unique string of integers assigned - by an authority that defines the content type. - - content is the associated content. The type of content can be - determined uniquely by contentType. Content types for data, - signed-data, enveloped-data, digested-data, encrypted-data, and - authenticated-data are defined in this document. If additional - content types are defined in other documents, the ASN.1 type - defined SHOULD NOT be a CHOICE type. - -4. Data Content Type - - The following object identifier identifies the data content type: - - id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } - - The data content type is intended to refer to arbitrary octet - strings, such as ASCII text files; the interpretation is left to the - application. Such strings need not have any internal structure - (although they could have their own ASN.1 definition or other - structure). - - S/MIME uses id-data to identify MIME-encoded content. The use of - this content identifier is specified in RFC 2311 for S/MIME v2 - [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 - [MSG3.1]. - - - - -Housley Standards Track [Page 7] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The data content type is generally encapsulated in the signed-data, - enveloped-data, digested-data, encrypted-data, or authenticated-data - content type. - -5. Signed-data Content Type - - The signed-data content type consists of a content of any type and - zero or more signature values. Any number of signers in parallel can - sign any type of content. - - The typical application of the signed-data content type represents - one signer's digital signature on content of the data content type. - Another typical application disseminates certificates and certificate - revocation lists (CRLs). - - The process by which signed-data is constructed involves the - following steps: - - 1. For each signer, a message digest, or hash value, is computed on - the content with a signer-specific message-digest algorithm. If - the signer is signing any information other than the content, the - message digest of the content and the other information are - digested with the signer's message digest algorithm (see Section - 5.4), and the result becomes the "message digest." - - 2. For each signer, the message digest is digitally signed using the - signer's private key. - - 3. For each signer, the signature value and other signer-specific - information are collected into a SignerInfo value, as defined in - Section 5.3. Certificates and CRLs for each signer, and those - not corresponding to any signer, are collected in this step. - - 4. The message digest algorithms for all the signers and the - SignerInfo values for all the signers are collected together with - the content into a SignedData value, as defined in Section 5.1. - - A recipient independently computes the message digest. This message - digest and the signer's public key are used to verify the signature - value. The signer's public key is referenced in one of two ways. It - can be referenced by an issuer distinguished name along with an - issuer-specific serial number to uniquely identify the certificate - that contains the public key. Alternatively, it can be referenced by - a subject key identifier, which accommodates both certified and - uncertified public keys. While not required, the signer's - certificate can be included in the SignedData certificates field. - - - - - -Housley Standards Track [Page 8] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - When more than one signature is present, the successful validation of - one signature associated with a given signer is usually treated as a - successful signature by that signer. However, there are some - application environments where other rules are needed. An - application that employs a rule other than one valid signature for - each signer must specify those rules. Also, where simple matching of - the signer identifier is not sufficient to determine whether the - signatures were generated by the same signer, the application - specification must describe how to determine which signatures were - generated by the same signer. Support of different communities of - recipients is the primary reason that signers choose to include more - than one signature. For example, the signed-data content type might - include signatures generated with the RSA signature algorithm and - with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature - algorithm. This allows recipients to verify the signature associated - with one algorithm or the other. - - This section is divided into six parts. The first part describes the - top-level type SignedData, the second part describes - EncapsulatedContentInfo, the third part describes the per-signer - information type SignerInfo, and the fourth, fifth, and sixth parts - describe the message digest calculation, signature generation, and - signature verification processes, respectively. - -5.1. SignedData Type - - The following object identifier identifies the signed-data content - type: - - id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } - - The signed-data content type shall have ASN.1 type SignedData: - - SignedData ::= SEQUENCE { - version CMSVersion, - digestAlgorithms DigestAlgorithmIdentifiers, - encapContentInfo EncapsulatedContentInfo, - certificates [0] IMPLICIT CertificateSet OPTIONAL, - crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, - signerInfos SignerInfos } - - DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier - - SignerInfos ::= SET OF SignerInfo - - - - - - -Housley Standards Track [Page 9] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The fields of type SignedData have the following meanings: - - version is the syntax version number. The appropriate value - depends on certificates, eContentType, and SignerInfo. The - version MUST be assigned as follows: - - IF ((certificates is present) AND - (any certificates with a type of other are present)) OR - ((crls is present) AND - (any crls with a type of other are present)) - THEN version MUST be 5 - ELSE - IF (certificates is present) AND - (any version 2 attribute certificates are present) - THEN version MUST be 4 - ELSE - IF ((certificates is present) AND - (any version 1 attribute certificates are present)) OR - (any SignerInfo structures are version 3) OR - (encapContentInfo eContentType is other than id-data) - THEN version MUST be 3 - ELSE version MUST be 1 - - digestAlgorithms is a collection of message digest algorithm - identifiers. There MAY be any number of elements in the - collection, including zero. Each element identifies the message - digest algorithm, along with any associated parameters, used by - one or more signer. The collection is intended to list the - message digest algorithms employed by all of the signers, in any - order, to facilitate one-pass signature verification. - Implementations MAY fail to validate signatures that use a digest - algorithm that is not included in this set. The message digesting - process is described in Section 5.4. - - encapContentInfo is the signed content, consisting of a content - type identifier and the content itself. Details of the - EncapsulatedContentInfo type are discussed in Section 5.2. - - certificates is a collection of certificates. It is intended that - the set of certificates be sufficient to contain certification - paths from a recognized "root" or "top-level certification - authority" to all of the signers in the signerInfos field. There - may be more certificates than necessary, and there may be - certificates sufficient to contain certification paths from two or - more independent top-level certification authorities. There may - also be fewer certificates than necessary, if it is expected that - recipients have an alternate means of obtaining necessary - - - - -Housley Standards Track [Page 10] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - certificates (e.g., from a previous set of certificates). The - signer's certificate MAY be included. The use of version 1 - attribute certificates is strongly discouraged. - - crls is a collection of revocation status information. It is - intended that the collection contain information sufficient to - determine whether the certificates in the certificates field are - valid, but such correspondence is not necessary. Certificate - revocation lists (CRLs) are the primary source of revocation - status information. There MAY be more CRLs than necessary, and - there MAY also be fewer CRLs than necessary. - - signerInfos is a collection of per-signer information. There MAY - be any number of elements in the collection, including zero. When - the collection represents more than one signature, the successful - validation of one of signature from a given signer ought to be - treated as a successful signature by that signer. However, there - are some application environments where other rules are needed. - The details of the SignerInfo type are discussed in Section 5.3. - Since each signer can employ a different digital signature - technique, and future specifications could update the syntax, all - implementations MUST gracefully handle unimplemented versions of - SignerInfo. Further, since all implementations will not support - every possible signature algorithm, all implementations MUST - gracefully handle unimplemented signature algorithms when they are - encountered. - -5.2. EncapsulatedContentInfo Type - - The content is represented in the type EncapsulatedContentInfo: - - EncapsulatedContentInfo ::= SEQUENCE { - eContentType ContentType, - eContent [0] EXPLICIT OCTET STRING OPTIONAL } - - ContentType ::= OBJECT IDENTIFIER - - The fields of type EncapsulatedContentInfo have the following - meanings: - - eContentType is an object identifier. The object identifier - uniquely specifies the content type. - - eContent is the content itself, carried as an octet string. The - eContent need not be DER encoded. - - - - - - -Housley Standards Track [Page 11] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The optional omission of the eContent within the - EncapsulatedContentInfo field makes it possible to construct - "external signatures". In the case of external signatures, the - content being signed is absent from the EncapsulatedContentInfo value - included in the signed-data content type. If the eContent value - within EncapsulatedContentInfo is absent, then the signatureValue is - calculated and the eContentType is assigned as though the eContent - value was present. - - In the degenerate case where there are no signers, the - EncapsulatedContentInfo value being "signed" is irrelevant. In this - case, the content type within the EncapsulatedContentInfo value being - "signed" MUST be id-data (as defined in Section 4), and the content - field of the EncapsulatedContentInfo value MUST be omitted. - -5.2.1. Compatibility with PKCS #7 - - This section contains a word of warning to implementers that wish to - support both the CMS and PKCS #7 [PKCS#7] SignedData content types. - Both the CMS and PKCS #7 identify the type of the encapsulated - content with an object identifier, but the ASN.1 type of the content - itself is variable in PKCS #7 SignedData content type. - - PKCS #7 defines content as: - - content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL - - The CMS defines eContent as: - - eContent [0] EXPLICIT OCTET STRING OPTIONAL - - The CMS definition is much easier to use in most applications, and it - is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed - messages using the CMS and PKCS #7 are compatible because identical - signed message formats are specified in RFC 2311 for S/MIME v2 - [MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1 - [MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type - (that is, an OCTET STRING) carried in the SignedData contentInfo - content ANY field, and S/MIME v3 carries the MIME content in the - SignedData encapContentInfo eContent OCTET STRING. Therefore, in - S/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in - an OCTET STRING and the message digest is computed over the identical - portions of the content. That is, the message digest is computed - over the octets comprising the value of the OCTET STRING, neither the - tag nor length octets are included. - - - - - - -Housley Standards Track [Page 12] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - There are incompatibilities between the CMS and PKCS #7 SignedData - types when the encapsulated content is not formatted using the Data - type. For example, when an RFC 2634 signed receipt [ESS] is - encapsulated in the CMS SignedData type, then the Receipt SEQUENCE is - encoded in the SignedData encapContentInfo eContent OCTET STRING and - the message digest is computed using the entire Receipt SEQUENCE - encoding (including tag, length and value octets). However, if an - RFC 2634 signed receipt is encapsulated in the PKCS #7 SignedData - type, then the Receipt SEQUENCE is DER encoded [X.509-88] in the - SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET - STRING). Therefore, the message digest is computed using only the - value octets of the Receipt SEQUENCE encoding. - - The following strategy can be used to achieve backward compatibility - with PKCS #7 when processing SignedData content types. If the - implementation is unable to ASN.1 decode the SignedData type using - the CMS SignedData encapContentInfo eContent OCTET STRING syntax, - then the implementation MAY attempt to decode the SignedData type - using the PKCS #7 SignedData contentInfo content ANY syntax and - compute the message digest accordingly. - - The following strategy can be used to achieve backward compatibility - with PKCS #7 when creating a SignedData content type in which the - encapsulated content is not formatted using the Data type. - Implementations MAY examine the value of the eContentType, and then - adjust the expected DER encoding of eContent based on the object - identifier value. For example, to support Microsoft Authenticode - [MSAC], the following information MAY be included: - - eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } - - eContent contains DER-encoded Authenticode signing information - -5.3. SignerInfo Type - - Per-signer information is represented in the type SignerInfo: - - SignerInfo ::= SEQUENCE { - version CMSVersion, - sid SignerIdentifier, - digestAlgorithm DigestAlgorithmIdentifier, - signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, - signatureAlgorithm SignatureAlgorithmIdentifier, - signature SignatureValue, - unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } - - - - - - -Housley Standards Track [Page 13] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - SignerIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier } - - SignedAttributes ::= SET SIZE (1..MAX) OF Attribute - - UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute - - Attribute ::= SEQUENCE { - attrType OBJECT IDENTIFIER, - attrValues SET OF AttributeValue } - - AttributeValue ::= ANY - - SignatureValue ::= OCTET STRING - - The fields of type SignerInfo have the following meanings: - - version is the syntax version number. If the SignerIdentifier is - the CHOICE issuerAndSerialNumber, then the version MUST be 1. If - the SignerIdentifier is subjectKeyIdentifier, then the version - MUST be 3. - - sid specifies the signer's certificate (and thereby the signer's - public key). The signer's public key is needed by the recipient - to verify the signature. SignerIdentifier provides two - alternatives for specifying the signer's public key. The - issuerAndSerialNumber alternative identifies the signer's - certificate by the issuer's distinguished name and the certificate - serial number; the subjectKeyIdentifier identifies the signer's - certificate by a key identifier. When an X.509 certificate is - referenced, the key identifier matches the X.509 - subjectKeyIdentifier extension value. When other certificate - formats are referenced, the documents that specify the certificate - format and their use with the CMS must include details on matching - the key identifier to the appropriate certificate field. - Implementations MUST support the reception of the - issuerAndSerialNumber and subjectKeyIdentifier forms of - SignerIdentifier. When generating a SignerIdentifier, - implementations MAY support one of the forms (either - issuerAndSerialNumber or subjectKeyIdentifier) and always use it, - or implementations MAY arbitrarily mix the two forms. However, - subjectKeyIdentifier MUST be used to refer to a public key - contained in a non-X.509 certificate. - - digestAlgorithm identifies the message digest algorithm, and any - associated parameters, used by the signer. The message digest is - computed on either the content being signed or the content - - - -Housley Standards Track [Page 14] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - together with the signed attributes using the process described in - Section 5.4. The message digest algorithm SHOULD be among those - listed in the digestAlgorithms field of the associated SignerData. - Implementations MAY fail to validate signatures that use a digest - algorithm that is not included in the SignedData digestAlgorithms - set. - - signedAttrs is a collection of attributes that are signed. The - field is optional, but it MUST be present if the content type of - the EncapsulatedContentInfo value being signed is not id-data. - SignedAttributes MUST be DER encoded, even if the rest of the - structure is BER encoded. Useful attribute types, such as signing - time, are defined in Section 11. If the field is present, it MUST - contain, at a minimum, the following two attributes: - - A content-type attribute having as its value the content type - of the EncapsulatedContentInfo value being signed. Section - 11.1 defines the content-type attribute. However, the - content-type attribute MUST NOT be used as part of a - countersignature unsigned attribute as defined in Section 11.4. - - A message-digest attribute, having as its value the message - digest of the content. Section 11.2 defines the message-digest - attribute. - - signatureAlgorithm identifies the signature algorithm, and any - associated parameters, used by the signer to generate the digital - signature. - - signature is the result of digital signature generation, using the - message digest and the signer's private key. The details of the - signature depend on the signature algorithm employed. - - unsignedAttrs is a collection of attributes that are not signed. - The field is optional. Useful attribute types, such as - countersignatures, are defined in Section 11. - - The fields of type SignedAttribute and UnsignedAttribute have the - following meanings: - - attrType indicates the type of attribute. It is an object - identifier. - - attrValues is a set of values that comprise the attribute. The - type of each value in the set can be determined uniquely by - attrType. The attrType can impose restrictions on the number of - items in the set. - - - - -Housley Standards Track [Page 15] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -5.4. Message Digest Calculation Process - - The message digest calculation process computes a message digest on - either the content being signed or the content together with the - signed attributes. In either case, the initial input to the message - digest calculation process is the "value" of the encapsulated content - being signed. Specifically, the initial input is the - encapContentInfo eContent OCTET STRING to which the signing process - is applied. Only the octets comprising the value of the eContent - OCTET STRING are input to the message digest algorithm, not the tag - or the length octets. - - The result of the message digest calculation process depends on - whether the signedAttrs field is present. When the field is absent, - the result is just the message digest of the content as described - above. When the field is present, however, the result is the message - digest of the complete DER encoding of the SignedAttrs value - contained in the signedAttrs field. Since the SignedAttrs value, - when present, must contain the content-type and the message-digest - attributes, those values are indirectly included in the result. The - content-type attribute MUST NOT be included in a countersignature - unsigned attribute as defined in Section 11.4. A separate encoding - of the signedAttrs field is performed for message digest calculation. - The IMPLICIT [0] tag in the signedAttrs is not used for the DER - encoding, rather an EXPLICIT SET OF tag is used. That is, the DER - encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0] - tag, MUST be included in the message digest calculation along with - the length and content octets of the SignedAttributes value. - - When the signedAttrs field is absent, only the octets comprising the - value of the SignedData encapContentInfo eContent OCTET STRING (e.g., - the contents of a file) are input to the message digest calculation. - This has the advantage that the length of the content being signed - need not be known in advance of the signature generation process. - - Although the encapContentInfo eContent OCTET STRING tag and length - octets are not included in the message digest calculation, they are - protected by other means. The length octets are protected by the - nature of the message digest algorithm since it is computationally - infeasible to find any two distinct message contents of any length - that have the same message digest. - -5.5. Signature Generation Process - - The input to the signature generation process includes the result of - the message digest calculation process and the signer's private key. - The details of the signature generation depend on the signature - algorithm employed. The object identifier, along with any - - - -Housley Standards Track [Page 16] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - parameters, that specifies the signature algorithm employed by the - signer is carried in the signatureAlgorithm field. The signature - value generated by the signer MUST be encoded as an OCTET STRING and - carried in the signature field. - -5.6. Signature Verification Process - - The input to the signature verification process includes the result - of the message digest calculation process and the signer's public - key. The recipient MAY obtain the correct public key for the signer - by any means, but the preferred method is from a certificate obtained - from the SignedData certificates field. The selection and validation - of the signer's public key MAY be based on certification path - validation (see [PROFILE]) as well as other external context, but is - beyond the scope of this document. The details of the signature - verification depend on the signature algorithm employed. - - The recipient MUST NOT rely on any message digest values computed by - the originator. If the SignedData signerInfo includes - signedAttributes, then the content message digest MUST be calculated - as described in Section 5.4. For the signature to be valid, the - message digest value calculated by the recipient MUST be the same as - the value of the messageDigest attribute included in the - signedAttributes of the SignedData signerInfo. - - If the SignedData signerInfo includes signedAttributes, then the - content-type attribute value MUST match the SignedData - encapContentInfo eContentType value. - -6. Enveloped-data Content Type - - The enveloped-data content type consists of an encrypted content of - any type and encrypted content-encryption keys for one or more - recipients. The combination of the encrypted content and one - encrypted content-encryption key for a recipient is a "digital - envelope" for that recipient. Any type of content can be enveloped - for an arbitrary number of recipients using any of the supported key - management techniques for each recipient. - - The typical application of the enveloped-data content type will - represent one or more recipients' digital envelopes on content of the - data or signed-data content types. - - Enveloped-data is constructed by the following steps: - - 1. A content-encryption key for a particular content-encryption - algorithm is generated at random. - - - - -Housley Standards Track [Page 17] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - 2. The content-encryption key is encrypted for each recipient. The - details of this encryption depend on the key management algorithm - used, but four general techniques are supported: - - key transport: the content-encryption key is encrypted in the - recipient's public key; - - key agreement: the recipient's public key and the sender's - private key are used to generate a pairwise symmetric key, then - the content-encryption key is encrypted in the pairwise - symmetric key; - - symmetric key-encryption keys: the content-encryption key is - encrypted in a previously distributed symmetric key-encryption - key; and - - passwords: the content-encryption key is encrypted in a key- - encryption key that is derived from a password or other shared - secret value. - - 3. For each recipient, the encrypted content-encryption key and - other recipient-specific information are collected into a - RecipientInfo value, defined in Section 6.2. - - 4. The content is encrypted with the content-encryption key. - Content encryption may require that the content be padded to a - multiple of some block size; see Section 6.3. - - 5. The RecipientInfo values for all the recipients are collected - together with the encrypted content to form an EnvelopedData - value as defined in Section 6.1. - - A recipient opens the digital envelope by decrypting one of the - encrypted content-encryption keys and then decrypting the encrypted - content with the recovered content-encryption key. - - This section is divided into four parts. The first part describes - the top-level type EnvelopedData, the second part describes the per- - recipient information type RecipientInfo, and the third and fourth - parts describe the content-encryption and key-encryption processes. - -6.1. EnvelopedData Type - - The following object identifier identifies the enveloped-data content - type: - - id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } - - - -Housley Standards Track [Page 18] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The enveloped-data content type shall have ASN.1 type EnvelopedData: - - EnvelopedData ::= SEQUENCE { - version CMSVersion, - originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, - recipientInfos RecipientInfos, - encryptedContentInfo EncryptedContentInfo, - unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } - - OriginatorInfo ::= SEQUENCE { - certs [0] IMPLICIT CertificateSet OPTIONAL, - crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } - - RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo - - EncryptedContentInfo ::= SEQUENCE { - contentType ContentType, - contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, - encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } - - EncryptedContent ::= OCTET STRING - - UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute - - The fields of type EnvelopedData have the following meanings: - - version is the syntax version number. The appropriate value - depends on originatorInfo, RecipientInfo, and unprotectedAttrs. - The version MUST be assigned as follows: - - IF (originatorInfo is present) AND - ((any certificates with a type of other are present) OR - (any crls with a type of other are present)) - THEN version is 4 - ELSE - IF ((originatorInfo is present) AND - (any version 2 attribute certificates are present)) OR - (any RecipientInfo structures include pwri) OR - (any RecipientInfo structures include ori) - THEN version is 3 - ELSE - IF (originatorInfo is absent) AND - (unprotectedAttrs is absent) AND - (all RecipientInfo structures are version 0) - THEN version is 0 - ELSE version is 2 - - - - - -Housley Standards Track [Page 19] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - originatorInfo optionally provides information about the - originator. It is present only if required by the key management - algorithm. It may contain certificates and CRLs: - - certs is a collection of certificates. certs may contain - originator certificates associated with several different key - management algorithms. certs may also contain attribute - certificates associated with the originator. The certificates - contained in certs are intended to be sufficient for all - recipients to build certification paths from a recognized - "root" or "top-level certification authority". However, certs - may contain more certificates than necessary, and there may be - certificates sufficient to make certification paths from two or - more independent top-level certification authorities. - Alternatively, certs may contain fewer certificates than - necessary, if it is expected that recipients have an alternate - means of obtaining necessary certificates (e.g., from a - previous set of certificates). - - crls is a collection of CRLs. It is intended that the set - contain information sufficient to determine whether or not the - certificates in the certs field are valid, but such - correspondence is not necessary. There MAY be more CRLs than - necessary, and there MAY also be fewer CRLs than necessary. - - recipientInfos is a collection of per-recipient information. - There MUST be at least one element in the collection. - - encryptedContentInfo is the encrypted content information. - - unprotectedAttrs is a collection of attributes that are not - encrypted. The field is optional. Useful attribute types are - defined in Section 11. - - The fields of type EncryptedContentInfo have the following meanings: - - contentType indicates the type of content. - - contentEncryptionAlgorithm identifies the content-encryption - algorithm, and any associated parameters, used to encrypt the - content. The content-encryption process is described in Section - 6.3. The same content-encryption algorithm and content-encryption - key are used for all recipients. - - encryptedContent is the result of encrypting the content. The - field is optional, and if the field is not present, its intended - value must be supplied by other means. - - - - -Housley Standards Track [Page 20] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The recipientInfos field comes before the encryptedContentInfo field - so that an EnvelopedData value may be processed in a single pass. - -6.2. RecipientInfo Type - - Per-recipient information is represented in the type RecipientInfo. - RecipientInfo has a different format for each of the supported key - management techniques. Any of the key management techniques can be - used for each recipient of the same encrypted content. In all cases, - the encrypted content-encryption key is transferred to one or more - recipients. - - Since all implementations will not support every possible key - management algorithm, all implementations MUST gracefully handle - unimplemented algorithms when they are encountered. For example, if - a recipient receives a content-encryption key encrypted in their RSA - public key using RSA-OAEP (Optimal Asymmetric Encryption Padding) and - the implementation only supports RSA PKCS #1 v1.5, then a graceful - failure must be implemented. - - Implementations MUST support key transport, key agreement, and - previously distributed symmetric key-encryption keys, as represented - by ktri, kari, and kekri, respectively. Implementations MAY support - the password-based key management as represented by pwri. - Implementations MAY support any other key management technique as - represented by ori. Since each recipient can employ a different key - management technique and future specifications could define - additional key management techniques, all implementations MUST - gracefully handle unimplemented alternatives within the RecipientInfo - CHOICE, all implementations MUST gracefully handle unimplemented - versions of otherwise supported alternatives within the RecipientInfo - CHOICE, and all implementations MUST gracefully handle unimplemented - or unknown ori alternatives. - - RecipientInfo ::= CHOICE { - ktri KeyTransRecipientInfo, - kari [1] KeyAgreeRecipientInfo, - kekri [2] KEKRecipientInfo, - pwri [3] PasswordRecipientinfo, - ori [4] OtherRecipientInfo } - - EncryptedKey ::= OCTET STRING - - - - - - - - - -Housley Standards Track [Page 21] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -6.2.1. KeyTransRecipientInfo Type - - Per-recipient information using key transport is represented in the - type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo - transfers the content-encryption key to one recipient. - - KeyTransRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 0 or 2 - rid RecipientIdentifier, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - RecipientIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier } - - The fields of type KeyTransRecipientInfo have the following meanings: - - version is the syntax version number. If the RecipientIdentifier - is the CHOICE issuerAndSerialNumber, then the version MUST be 0. - If the RecipientIdentifier is subjectKeyIdentifier, then the - version MUST be 2. - - rid specifies the recipient's certificate or key that was used by - the sender to protect the content-encryption key. The content- - encryption key is encrypted with the recipient's public key. The - RecipientIdentifier provides two alternatives for specifying the - recipient's certificate, and thereby the recipient's public key. - The recipient's certificate must contain a key transport public - key. Therefore, a recipient X.509 version 3 certificate that - contains a key usage extension MUST assert the keyEncipherment - bit. The issuerAndSerialNumber alternative identifies the - recipient's certificate by the issuer's distinguished name and the - certificate serial number; the subjectKeyIdentifier identifies the - recipient's certificate by a key identifier. When an X.509 - certificate is referenced, the key identifier matches the X.509 - subjectKeyIdentifier extension value. When other certificate - formats are referenced, the documents that specify the certificate - format and their use with the CMS must include details on matching - the key identifier to the appropriate certificate field. For - recipient processing, implementations MUST support both of these - alternatives for specifying the recipient's certificate. For - sender processing, implementations MUST support at least one of - these alternatives. - - - - - - - -Housley Standards Track [Page 22] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - keyEncryptionAlgorithm identifies the key-encryption algorithm, - and any associated parameters, used to encrypt the content- - encryption key for the recipient. The key-encryption process is - described in Section 6.4. - - encryptedKey is the result of encrypting the content-encryption - key for the recipient. - -6.2.2. KeyAgreeRecipientInfo Type - - Recipient information using key agreement is represented in the type - KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will - transfer the content-encryption key to one or more recipients that - use the same key agreement algorithm and domain parameters for that - algorithm. - - KeyAgreeRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 3 - originator [0] EXPLICIT OriginatorIdentifierOrKey, - ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - recipientEncryptedKeys RecipientEncryptedKeys } - - OriginatorIdentifierOrKey ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier, - originatorKey [1] OriginatorPublicKey } - - OriginatorPublicKey ::= SEQUENCE { - algorithm AlgorithmIdentifier, - publicKey BIT STRING } - - RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey - - RecipientEncryptedKey ::= SEQUENCE { - rid KeyAgreeRecipientIdentifier, - encryptedKey EncryptedKey } - - KeyAgreeRecipientIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - rKeyId [0] IMPLICIT RecipientKeyIdentifier } - - RecipientKeyIdentifier ::= SEQUENCE { - subjectKeyIdentifier SubjectKeyIdentifier, - date GeneralizedTime OPTIONAL, - other OtherKeyAttribute OPTIONAL } - - SubjectKeyIdentifier ::= OCTET STRING - - - -Housley Standards Track [Page 23] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The fields of type KeyAgreeRecipientInfo have the following meanings: - - version is the syntax version number. It MUST always be 3. - - originator is a CHOICE with three alternatives specifying the - sender's key agreement public key. The sender uses the - corresponding private key and the recipient's public key to - generate a pairwise key. The content-encryption key is encrypted - in the pairwise key. The issuerAndSerialNumber alternative - identifies the sender's certificate, and thereby the sender's - public key, by the issuer's distinguished name and the certificate - serial number. The subjectKeyIdentifier alternative identifies - the sender's certificate, and thereby the sender's public key, by - a key identifier. When an X.509 certificate is referenced, the - key identifier matches the X.509 subjectKeyIdentifier extension - value. When other certificate formats are referenced, the - documents that specify the certificate format and their use with - the CMS must include details on matching the key identifier to the - appropriate certificate field. The originatorKey alternative - includes the algorithm identifier and sender's key agreement - public key. This alternative permits originator anonymity since - the public key is not certified. Implementations MUST support all - three alternatives for specifying the sender's public key. - - ukm is optional. With some key agreement algorithms, the sender - provides a User Keying Material (UKM) to ensure that a different - key is generated each time the same two parties generate a - pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo - SEQUENCE that includes a ukm field. Implementations that do not - support key agreement algorithms that make use of UKMs MUST - gracefully handle the presence of UKMs. - - keyEncryptionAlgorithm identifies the key-encryption algorithm, - and any associated parameters, used to encrypt the content- - encryption key with the key-encryption key. The key-encryption - process is described in Section 6.4. - - recipientEncryptedKeys includes a recipient identifier and - encrypted key for one or more recipients. The - KeyAgreeRecipientIdentifier is a CHOICE with two alternatives - specifying the recipient's certificate, and thereby the - recipient's public key, that was used by the sender to generate a - pairwise key-encryption key. The recipient's certificate must - contain a key agreement public key. Therefore, a recipient X.509 - version 3 certificate that contains a key usage extension MUST - assert the keyAgreement bit. The content-encryption key is - encrypted in the pairwise key-encryption key. The - issuerAndSerialNumber alternative identifies the recipient's - - - -Housley Standards Track [Page 24] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - certificate by the issuer's distinguished name and the certificate - serial number; the RecipientKeyIdentifier is described below. The - encryptedKey is the result of encrypting the content-encryption - key in the pairwise key-encryption key generated using the key - agreement algorithm. Implementations MUST support both - alternatives for specifying the recipient's certificate. - - The fields of type RecipientKeyIdentifier have the following - meanings: - - subjectKeyIdentifier identifies the recipient's certificate by a - key identifier. When an X.509 certificate is referenced, the key - identifier matches the X.509 subjectKeyIdentifier extension value. - When other certificate formats are referenced, the documents that - specify the certificate format and their use with the CMS must - include details on matching the key identifier to the appropriate - certificate field. - - date is optional. When present, the date specifies which of the - recipient's previously distributed UKMs was used by the sender. - - other is optional. When present, this field contains additional - information used by the recipient to locate the public keying - material used by the sender. - -6.2.3. KEKRecipientInfo Type - - Recipient information using previously distributed symmetric keys is - represented in the type KEKRecipientInfo. Each instance of - KEKRecipientInfo will transfer the content-encryption key to one or - more recipients who have the previously distributed key-encryption - key. - - KEKRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 4 - kekid KEKIdentifier, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - KEKIdentifier ::= SEQUENCE { - keyIdentifier OCTET STRING, - date GeneralizedTime OPTIONAL, - other OtherKeyAttribute OPTIONAL } - - - - - - - - -Housley Standards Track [Page 25] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The fields of type KEKRecipientInfo have the following meanings: - - version is the syntax version number. It MUST always be 4. - - kekid specifies a symmetric key-encryption key that was previously - distributed to the sender and one or more recipients. - - keyEncryptionAlgorithm identifies the key-encryption algorithm, - and any associated parameters, used to encrypt the content- - encryption key with the key-encryption key. The key-encryption - process is described in Section 6.4. - - encryptedKey is the result of encrypting the content-encryption - key in the key-encryption key. - - The fields of type KEKIdentifier have the following meanings: - - keyIdentifier identifies the key-encryption key that was - previously distributed to the sender and one or more recipients. - - date is optional. When present, the date specifies a single key- - encryption key from a set that was previously distributed. - - other is optional. When present, this field contains additional - information used by the recipient to determine the key-encryption - key used by the sender. - -6.2.4. PasswordRecipientInfo Type - - Recipient information using a password or shared secret value is - represented in the type PasswordRecipientInfo. Each instance of - PasswordRecipientInfo will transfer the content-encryption key to one - or more recipients who possess the password or shared secret value. - - The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. The - PasswordRecipientInfo structure is repeated here for completeness. - - PasswordRecipientInfo ::= SEQUENCE { - version CMSVersion, -- Always set to 0 - keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier - OPTIONAL, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - - - - - - - -Housley Standards Track [Page 26] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The fields of type PasswordRecipientInfo have the following meanings: - - version is the syntax version number. It MUST always be 0. - - keyDerivationAlgorithm identifies the key-derivation algorithm, - and any associated parameters, used to derive the key-encryption - key from the password or shared secret value. If this field is - absent, the key-encryption key is supplied from an external - source, for example a hardware crypto token such as a smart card. - - keyEncryptionAlgorithm identifies the encryption algorithm, and - any associated parameters, used to encrypt the content-encryption - key with the key-encryption key. - - encryptedKey is the result of encrypting the content-encryption - key with the key-encryption key. - -6.2.5. OtherRecipientInfo Type - - Recipient information for additional key management techniques are - represented in the type OtherRecipientInfo. The OtherRecipientInfo - type allows key management techniques beyond key transport, key - agreement, previously distributed symmetric key-encryption keys, and - password-based key management to be specified in future documents. - An object identifier uniquely identifies such key management - techniques. - - OtherRecipientInfo ::= SEQUENCE { - oriType OBJECT IDENTIFIER, - oriValue ANY DEFINED BY oriType } - - The fields of type OtherRecipientInfo have the following meanings: - - oriType identifies the key management technique. - - oriValue contains the protocol data elements needed by a recipient - using the identified key management technique. - -6.3. Content-encryption Process - - The content-encryption key for the desired content-encryption - algorithm is randomly generated. The data to be protected is padded - as described below, then the padded data is encrypted using the - content-encryption key. The encryption operation maps an arbitrary - string of octets (the data) to another string of octets (the - ciphertext) under control of a content-encryption key. The encrypted - data is included in the EnvelopedData encryptedContentInfo - encryptedContent OCTET STRING. - - - -Housley Standards Track [Page 27] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - Some content-encryption algorithms assume the input length is a - multiple of k octets, where k is greater than one. For such - algorithms, the input shall be padded at the trailing end with - k-(lth mod k) octets all having value k-(lth mod k), where lth is - the length of the input. In other words, the input is padded at - the trailing end with one of the following strings: - - 01 -- if lth mod k = k-1 - 02 02 -- if lth mod k = k-2 - . - . - . - k k ... k k -- if lth mod k = 0 - - The padding can be removed unambiguously since all input is padded, - including input values that are already a multiple of the block size, - and no padding string is a suffix of another. This padding method is - well defined if and only if k is less than 256. - -6.4. Key-encryption Process - - The input to the key-encryption process -- the value supplied to the - recipient's key-encryption algorithm -- is just the "value" of the - content-encryption key. - - Any of the aforementioned key management techniques can be used for - each recipient of the same encrypted content. - -7. Digested-data Content Type - - The digested-data content type consists of content of any type and a - message digest of the content. - - Typically, the digested-data content type is used to provide content - integrity, and the result generally becomes an input to the - enveloped-data content type. - - The following steps construct digested-data: - - 1. A message digest is computed on the content with a message-digest - algorithm. - - 2. The message-digest algorithm and the message digest are collected - together with the content into a DigestedData value. - - A recipient verifies the message digest by comparing the message - digest to an independently computed message digest. - - - - -Housley Standards Track [Page 28] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The following object identifier identifies the digested-data content - type: - - id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } - - The digested-data content type shall have ASN.1 type DigestedData: - - DigestedData ::= SEQUENCE { - version CMSVersion, - digestAlgorithm DigestAlgorithmIdentifier, - encapContentInfo EncapsulatedContentInfo, - digest Digest } - - Digest ::= OCTET STRING - - The fields of type DigestedData have the following meanings: - - version is the syntax version number. If the encapsulated content - type is id-data, then the value of version MUST be 0; however, if - the encapsulated content type is other than id-data, then the - value of version MUST be 2. - - digestAlgorithm identifies the message digest algorithm, and any - associated parameters, under which the content is digested. The - message-digesting process is the same as in Section 5.4 in the - case when there are no signed attributes. - - encapContentInfo is the content that is digested, as defined in - Section 5.2. - - digest is the result of the message-digesting process. - - The ordering of the digestAlgorithm field, the encapContentInfo - field, and the digest field makes it possible to process a - DigestedData value in a single pass. - -8. Encrypted-data Content Type - - The encrypted-data content type consists of encrypted content of any - type. Unlike the enveloped-data content type, the encrypted-data - content type has neither recipients nor encrypted content-encryption - keys. Keys MUST be managed by other means. - - The typical application of the encrypted-data content type will be to - encrypt the content of the data content type for local storage, - perhaps where the encryption key is derived from a password. - - - - -Housley Standards Track [Page 29] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The following object identifier identifies the encrypted-data content - type: - - id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } - - The encrypted-data content type shall have ASN.1 type EncryptedData: - - EncryptedData ::= SEQUENCE { - version CMSVersion, - encryptedContentInfo EncryptedContentInfo, - unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } - - The fields of type EncryptedData have the following meanings: - - version is the syntax version number. If unprotectedAttrs is - present, then the version MUST be 2. If unprotectedAttrs is - absent, then version MUST be 0. - - encryptedContentInfo is the encrypted content information, as - defined in Section 6.1. - - unprotectedAttrs is a collection of attributes that are not - encrypted. The field is optional. Useful attribute types are - defined in Section 11. - -9. Authenticated-data Content Type - - The authenticated-data content type consists of content of any type, - a message authentication code (MAC), and encrypted authentication - keys for one or more recipients. The combination of the MAC and one - encrypted authentication key for a recipient is necessary for that - recipient to verify the integrity of the content. Any type of - content can be integrity protected for an arbitrary number of - recipients. - - The process by which authenticated-data is constructed involves the - following steps: - - 1. A message-authentication key for a particular message- - authentication algorithm is generated at random. - - 2. The message-authentication key is encrypted for each recipient. - The details of this encryption depend on the key management - algorithm used. - - - - - - -Housley Standards Track [Page 30] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - 3. For each recipient, the encrypted message-authentication key and - other recipient-specific information are collected into a - RecipientInfo value, defined in Section 6.2. - - 4. Using the message-authentication key, the originator computes a - MAC value on the content. If the originator is authenticating - any information in addition to the content (see Section 9.2), a - message digest is calculated on the content, the message digest - of the content and the other information are authenticated using - the message-authentication key, and the result becomes the "MAC - value". - -9.1. AuthenticatedData Type - - The following object identifier identifies the authenticated-data - content type: - - id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) - ct(1) 2 } - - The authenticated-data content type shall have ASN.1 type - AuthenticatedData: - - AuthenticatedData ::= SEQUENCE { - version CMSVersion, - originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, - recipientInfos RecipientInfos, - macAlgorithm MessageAuthenticationCodeAlgorithm, - digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, - encapContentInfo EncapsulatedContentInfo, - authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, - mac MessageAuthenticationCode, - unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } - - AuthAttributes ::= SET SIZE (1..MAX) OF Attribute - - UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute - - MessageAuthenticationCode ::= OCTET STRING - - The fields of type AuthenticatedData have the following meanings: - - version is the syntax version number. The version MUST be - assigned as follows: - - - - - - -Housley Standards Track [Page 31] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - IF (originatorInfo is present) AND - ((any certificates with a type of other are present) OR - (any crls with a type of other are present)) - THEN version is 3 - ELSE - IF ((originatorInfo is present) AND - (any version 2 attribute certificates are present)) - THEN version is 1 - ELSE version is 0 - - originatorInfo optionally provides information about the - originator. It is present only if required by the key management - algorithm. It MAY contain certificates, attribute certificates, - and CRLs, as defined in Section 6.1. - - recipientInfos is a collection of per-recipient information, as - defined in Section 6.1. There MUST be at least one element in the - collection. - - macAlgorithm is a message authentication code (MAC) algorithm - identifier. It identifies the MAC algorithm, along with any - associated parameters, used by the originator. Placement of the - macAlgorithm field facilitates one-pass processing by the - recipient. - - digestAlgorithm identifies the message digest algorithm, and any - associated parameters, used to compute a message digest on the - encapsulated content if authenticated attributes are present. The - message digesting process is described in Section 9.2. Placement - of the digestAlgorithm field facilitates one-pass processing by - the recipient. If the digestAlgorithm field is present, then the - authAttrs field MUST also be present. - - encapContentInfo is the content that is authenticated, as defined - in Section 5.2. - - authAttrs is a collection of authenticated attributes. The - authAttrs structure is optional, but it MUST be present if the - content type of the EncapsulatedContentInfo value being - authenticated is not id-data. If the authAttrs field is present, - then the digestAlgorithm field MUST also be present. The - AuthAttributes structure MUST be DER encoded, even if the rest of - the structure is BER encoded. Useful attribute types are defined - in Section 11. If the authAttrs field is present, it MUST - contain, at a minimum, the following two attributes: - - - - - - -Housley Standards Track [Page 32] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - A content-type attribute having as its value the content type - of the EncapsulatedContentInfo value being authenticated. - Section 11.1 defines the content-type attribute. - - A message-digest attribute, having as its value the message - digest of the content. Section 11.2 defines the message-digest - attribute. - - mac is the message authentication code. - - unauthAttrs is a collection of attributes that are not - authenticated. The field is optional. To date, no attributes - have been defined for use as unauthenticated attributes, but other - useful attribute types are defined in Section 11. - -9.2. MAC Generation - - The MAC calculation process computes a message authentication code - (MAC) on either the content being authenticated or a message digest - of content being authenticated together with the originator's - authenticated attributes. - - If the authAttrs field is absent, the input to the MAC calculation - process is the value of the encapContentInfo eContent OCTET STRING. - Only the octets comprising the value of the eContent OCTET STRING are - input to the MAC algorithm; the tag and the length octets are - omitted. This has the advantage that the length of the content being - authenticated need not be known in advance of the MAC generation - process. - - If the authAttrs field is present, the content-type attribute (as - described in Section 11.1) and the message-digest attribute (as - described in Section 11.2) MUST be included, and the input to the MAC - calculation process is the DER encoding of authAttrs. A separate - encoding of the authAttrs field is performed for message digest - calculation. The IMPLICIT [2] tag in the authAttrs field is not used - for the DER encoding, rather an EXPLICIT SET OF tag is used. That - is, the DER encoding of the SET OF tag, rather than of the IMPLICIT - [2] tag, is to be included in the message digest calculation along - with the length and content octets of the authAttrs value. - - The message digest calculation process computes a message digest on - the content being authenticated. The initial input to the message - digest calculation process is the "value" of the encapsulated content - being authenticated. Specifically, the input is the encapContentInfo - eContent OCTET STRING to which the authentication process is applied. - Only the octets comprising the value of the encapContentInfo eContent - OCTET STRING are input to the message digest algorithm, not the tag - - - -Housley Standards Track [Page 33] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - or the length octets. This has the advantage that the length of the - content being authenticated need not be known in advance. Although - the encapContentInfo eContent OCTET STRING tag and length octets are - not included in the message digest calculation, they are still - protected by other means. The length octets are protected by the - nature of the message digest algorithm since it is computationally - infeasible to find any two distinct contents of any length that have - the same message digest. - - The input to the MAC calculation process includes the MAC input data, - defined above, and an authentication key conveyed in a recipientInfo - structure. The details of MAC calculation depend on the MAC - algorithm employed (e.g., Hashed Message Authentication Code (HMAC)). - The object identifier, along with any parameters, that specifies the - MAC algorithm employed by the originator is carried in the - macAlgorithm field. The MAC value generated by the originator is - encoded as an OCTET STRING and carried in the mac field. - -9.3. MAC Verification - - The input to the MAC verification process includes the input data - (determined based on the presence or absence of the authAttrs field, - as defined in 9.2), and the authentication key conveyed in - recipientInfo. The details of the MAC verification process depend on - the MAC algorithm employed. - - The recipient MUST NOT rely on any MAC values or message digest - values computed by the originator. The content is authenticated as - described in Section 9.2. If the originator includes authenticated - attributes, then the content of the authAttrs is authenticated as - described in Section 9.2. For authentication to succeed, the MAC - value calculated by the recipient MUST be the same as the value of - the mac field. Similarly, for authentication to succeed when the - authAttrs field is present, the content message digest value - calculated by the recipient MUST be the same as the message digest - value included in the authAttrs message-digest attribute. - - If the AuthenticatedData includes authAttrs, then the content-type - attribute value MUST match the AuthenticatedData encapContentInfo - eContentType value. - -10. Useful Types - - This section is divided into two parts. The first part defines - algorithm identifiers, and the second part defines other useful - types. - - - - - -Housley Standards Track [Page 34] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -10.1. Algorithm Identifier Types - - All of the algorithm identifiers have the same type: - AlgorithmIdentifier. The definition of AlgorithmIdentifier is taken - from X.509 [X.509-88]. - - There are many alternatives for each algorithm type. - -10.1.1. DigestAlgorithmIdentifier - - The DigestAlgorithmIdentifier type identifies a message-digest - algorithm. Examples include SHA-1, MD2, and MD5. A message-digest - algorithm maps an octet string (the content) to another octet string - (the message digest). - - DigestAlgorithmIdentifier ::= AlgorithmIdentifier - -10.1.2. SignatureAlgorithmIdentifier - - The SignatureAlgorithmIdentifier type identifies a signature - algorithm, and it can also identify a message digest algorithm. - Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with - SHA-256. A signature algorithm supports signature generation and - verification operations. The signature generation operation uses the - message digest and the signer's private key to generate a signature - value. The signature verification operation uses the message digest - and the signer's public key to determine whether or not a signature - value is valid. Context determines which operation is intended. - - SignatureAlgorithmIdentifier ::= AlgorithmIdentifier - -10.1.3. KeyEncryptionAlgorithmIdentifier - - The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption - algorithm used to encrypt a content-encryption key. The encryption - operation maps an octet string (the key) to another octet string (the - encrypted key) under control of a key-encryption key. The decryption - operation is the inverse of the encryption operation. Context - determines which operation is intended. - - The details of encryption and decryption depend on the key management - algorithm used. Key transport, key agreement, previously distributed - symmetric key-encrypting keys, and symmetric key-encrypting keys - derived from passwords are supported. - - KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier - - - - - -Housley Standards Track [Page 35] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -10.1.4. ContentEncryptionAlgorithmIdentifier - - The ContentEncryptionAlgorithmIdentifier type identifies a content- - encryption algorithm. Examples include Triple-DES and RC2. A - content-encryption algorithm supports encryption and decryption - operations. The encryption operation maps an octet string (the - plaintext) to another octet string (the ciphertext) under control of - a content-encryption key. The decryption operation is the inverse of - the encryption operation. Context determines which operation is - intended. - - ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier - -10.1.5. MessageAuthenticationCodeAlgorithm - - The MessageAuthenticationCodeAlgorithm type identifies a message - authentication code (MAC) algorithm. Examples include DES-MAC and - HMAC-SHA-1. A MAC algorithm supports generation and verification - operations. The MAC generation and verification operations use the - same symmetric key. Context determines which operation is intended. - - MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier - -10.1.6. KeyDerivationAlgorithmIdentifier - - The KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 - [PWRI]. The KeyDerivationAlgorithmIdentifier definition is repeated - here for completeness. - - Key derivation algorithms convert a password or shared secret value - into a key-encryption key. - - KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier - -10.2. Other Useful Types - - This section defines types that are used other places in the - document. The types are not listed in any particular order. - -10.2.1. RevocationInfoChoices - - The RevocationInfoChoices type gives a set of revocation status - information alternatives. It is intended that the set contain - information sufficient to determine whether the certificates and - attribute certificates with which the set is associated are revoked. - However, there MAY be more revocation status information than - necessary or there MAY be less revocation status information than - necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are - - - -Housley Standards Track [Page 36] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - the primary source of revocation status information, but any other - revocation information format can be supported. The - OtherRevocationInfoFormat alternative is provided to support any - other revocation information format without further modifications to - the CMS. For example, Online Certificate Status Protocol (OCSP) - Responses [OCSP] can be supported using the - OtherRevocationInfoFormat. - - The CertificateList may contain a CRL, an Authority Revocation List - (ARL), a Delta CRL, or an Attribute Certificate Revocation List. All - of these lists share a common syntax. - - The CertificateList type gives a certificate revocation list (CRL). - CRLs are specified in X.509 [X.509-97], and they are profiled for use - in the Internet in RFC 5280 [PROFILE]. - - The definition of CertificateList is taken from X.509. - - RevocationInfoChoices ::= SET OF RevocationInfoChoice - - RevocationInfoChoice ::= CHOICE { - crl CertificateList, - other [1] IMPLICIT OtherRevocationInfoFormat } - - OtherRevocationInfoFormat ::= SEQUENCE { - otherRevInfoFormat OBJECT IDENTIFIER, - otherRevInfo ANY DEFINED BY otherRevInfoFormat } - -10.2.2. CertificateChoices - - The CertificateChoices type gives either a PKCS #6 extended - certificate [PKCS#6], an X.509 certificate, a version 1 X.509 - attribute certificate (ACv1) [X.509-97], a version 2 X.509 attribute - certificate (ACv2) [X.509-00], or any other certificate format. The - PKCS #6 extended certificate is obsolete. The PKCS #6 certificate is - included for backward compatibility, and PKCS #6 certificates SHOULD - NOT be used. The ACv1 is also obsolete. ACv1 is included for - backward compatibility, and ACv1 SHOULD NOT be used. The Internet - profile of X.509 certificates is specified in the "Internet X.509 - Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. - The Internet profile of ACv2 is specified in the "An Internet - Attribute Certificate Profile for Authorization" [ACPROFILE]. The - OtherCertificateFormat alternative is provided to support any other - certificate format without further modifications to the CMS. - - The definition of Certificate is taken from X.509. - - - - - -Housley Standards Track [Page 37] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The definitions of AttributeCertificate are taken from X.509-1997 and - X.509-2000. The definition from X.509-1997 is assigned to - AttributeCertificateV1 (see Section 12.2), and the definition from - X.509-2000 is assigned to AttributeCertificateV2. - - CertificateChoices ::= CHOICE { - certificate Certificate, - extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete - v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete - v2AttrCert [2] IMPLICIT AttributeCertificateV2, - other [3] IMPLICIT OtherCertificateFormat } - - OtherCertificateFormat ::= SEQUENCE { - otherCertFormat OBJECT IDENTIFIER, - otherCert ANY DEFINED BY otherCertFormat } - -10.2.3. CertificateSet - - The CertificateSet type provides a set of certificates. It is - intended that the set be sufficient to contain certification paths - from a recognized "root" or "top-level certification authority" to - all of the sender certificates with which the set is associated. - However, there may be more certificates than necessary, or there MAY - be fewer than necessary. - - The precise meaning of a "certification path" is outside the scope of - this document. However, [PROFILE] provides a definition for X.509 - certificates. Some applications may impose upper limits on the - length of a certification path; others may enforce certain - relationships between the subjects and issuers of certificates within - a certification path. - - CertificateSet ::= SET OF CertificateChoices - -10.2.4. IssuerAndSerialNumber - - The IssuerAndSerialNumber type identifies a certificate, and thereby - an entity and a public key, by the distinguished name of the - certificate issuer and an issuer-specific certificate serial number. - - The definition of Name is taken from X.501 [X.501-88], and the - definition of CertificateSerialNumber is taken from X.509 [X.509-97]. - - IssuerAndSerialNumber ::= SEQUENCE { - issuer Name, - serialNumber CertificateSerialNumber } - - CertificateSerialNumber ::= INTEGER - - - -Housley Standards Track [Page 38] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -10.2.5. CMSVersion - - The CMSVersion type gives a syntax version number, for compatibility - with future revisions of this specification. - - CMSVersion ::= INTEGER - { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } - -10.2.6. UserKeyingMaterial - - The UserKeyingMaterial type gives a syntax for user keying material - (UKM). Some key agreement algorithms require UKMs to ensure that a - different key is generated each time the same two parties generate a - pairwise key. The sender provides a UKM for use with a specific key - agreement algorithm. - - UserKeyingMaterial ::= OCTET STRING - -10.2.7. OtherKeyAttribute - - The OtherKeyAttribute type gives a syntax for the inclusion of other - key attributes that permit the recipient to select the key used by - the sender. The attribute object identifier must be registered along - with the syntax of the attribute itself. Use of this structure - should be avoided since it might impede interoperability. - - OtherKeyAttribute ::= SEQUENCE { - keyAttrId OBJECT IDENTIFIER, - keyAttr ANY DEFINED BY keyAttrId OPTIONAL } - -11. Useful Attributes - - This section defines attributes that may be used with signed-data, - enveloped-data, encrypted-data, or authenticated-data. The syntax of - Attribute is compatible with X.501 [X.501-88] and RFC 5280 [PROFILE]. - Some of the attributes defined in this section were originally - defined in PKCS #9 [PKCS#9]; others were originally defined in a - previous version of this specification [CMS1]. The attributes are - not listed in any particular order. - - Additional attributes are defined in many places, notably the S/MIME - Version 3.1 Message Specification [MSG3.1] and the Enhanced Security - Services for S/MIME [ESS], which also include recommendations on the - placement of these attributes. - - - - - - - -Housley Standards Track [Page 39] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -11.1. Content Type - - The content-type attribute type specifies the content type of the - ContentInfo within signed-data or authenticated-data. The content- - type attribute type MUST be present whenever signed attributes are - present in signed-data or authenticated attributes present in - authenticated-data. The content-type attribute value MUST match the - encapContentInfo eContentType value in the signed-data or - authenticated-data. - - The content-type attribute MUST be a signed attribute or an - authenticated attribute; it MUST NOT be an unsigned attribute, - unauthenticated attribute, or unprotected attribute. - - The following object identifier identifies the content-type - attribute: - - id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } - - Content-type attribute values have ASN.1 type ContentType: - - ContentType ::= OBJECT IDENTIFIER - - Even though the syntax is defined as a SET OF AttributeValue, a - content-type attribute MUST have a single attribute value; zero or - multiple instances of AttributeValue are not permitted. - - The SignedAttributes and AuthAttributes syntaxes are each defined as - a SET OF Attributes. The SignedAttributes in a signerInfo MUST NOT - include multiple instances of the content-type attribute. Similarly, - the AuthAttributes in an AuthenticatedData MUST NOT include multiple - instances of the content-type attribute. - -11.2. Message Digest - - The message-digest attribute type specifies the message digest of the - encapContentInfo eContent OCTET STRING being signed in signed-data - (see Section 5.4) or authenticated in authenticated-data (see Section - 9.2). For signed-data, the message digest is computed using the - signer's message digest algorithm. For authenticated-data, the - message digest is computed using the originator's message digest - algorithm. - - Within signed-data, the message-digest signed attribute type MUST be - present when there are any signed attributes present. Within - authenticated-data, the message-digest authenticated attribute type - MUST be present when there are any authenticated attributes present. - - - -Housley Standards Track [Page 40] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The message-digest attribute MUST be a signed attribute or an - authenticated attribute; it MUST NOT be an unsigned attribute, - unauthenticated attribute, or unprotected attribute. - - The following object identifier identifies the message-digest - attribute: - - id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } - - Message-digest attribute values have ASN.1 type MessageDigest: - - MessageDigest ::= OCTET STRING - - A message-digest attribute MUST have a single attribute value, even - though the syntax is defined as a SET OF AttributeValue. There MUST - NOT be zero or multiple instances of AttributeValue present. - - The SignedAttributes syntax and AuthAttributes syntax are each - defined as a SET OF Attributes. The SignedAttributes in a signerInfo - MUST include only one instance of the message-digest attribute. - Similarly, the AuthAttributes in an AuthenticatedData MUST include - only one instance of the message-digest attribute. - -11.3. Signing Time - - The signing-time attribute type specifies the time at which the - signer (purportedly) performed the signing process. The signing-time - attribute type is intended for use in signed-data. - - The signing-time attribute MUST be a signed attribute or an - authenticated attribute; it MUST NOT be an unsigned attribute, - unauthenticated attribute, or unprotected attribute. - - The following object identifier identifies the signing-time - attribute: - - id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } - - Signing-time attribute values have ASN.1 type SigningTime: - - SigningTime ::= Time - - Time ::= CHOICE { - utcTime UTCTime, - generalizedTime GeneralizedTime } - - - - -Housley Standards Track [Page 41] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - Note: The definition of Time matches the one specified in the 1997 - version of X.509 [X.509-97]. - - Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be - encoded as UTCTime. Any dates with year values before 1950 or after - 2049 MUST be encoded as GeneralizedTime. - - UTCTime values MUST be expressed in Coordinated Universal Time - (formerly known as Greenwich Mean Time (GMT) and Zulu clock time) and - MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the - number of seconds is zero. Midnight MUST be represented as - "YYMMDD000000Z". Century information is implicit, and the century - MUST be determined as follows: - - Where YY is greater than or equal to 50, the year MUST be - interpreted as 19YY; and - - Where YY is less than 50, the year MUST be interpreted as 20YY. - - GeneralizedTime values MUST be expressed in Coordinated Universal - Time and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even - where the number of seconds is zero. GeneralizedTime values MUST NOT - include fractional seconds. - - A signing-time attribute MUST have a single attribute value, even - though the syntax is defined as a SET OF AttributeValue. There MUST - NOT be zero or multiple instances of AttributeValue present. - - The SignedAttributes syntax and the AuthAttributes syntax are each - defined as a SET OF Attributes. The SignedAttributes in a signerInfo - MUST NOT include multiple instances of the signing-time attribute. - Similarly, the AuthAttributes in an AuthenticatedData MUST NOT - include multiple instances of the signing-time attribute. - - No requirement is imposed concerning the correctness of the signing - time, and acceptance of a purported signing time is a matter of a - recipient's discretion. It is expected, however, that some signers, - such as time-stamp servers, will be trusted implicitly. - -11.4. Countersignature - - The countersignature attribute type specifies one or more signatures - on the contents octets of the signature OCTET STRING in a SignerInfo - value of the signed-data. That is, the message digest is computed - over the octets comprising the value of the OCTET STRING, neither the - tag nor length octets are included. Thus, the countersignature - attribute type countersigns (signs in serial) another signature. - - - - -Housley Standards Track [Page 42] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The countersignature attribute MUST be an unsigned attribute; it MUST - NOT be a signed attribute, an authenticated attribute, an - unauthenticated attribute, or an unprotected attribute. - - The following object identifier identifies the countersignature - attribute: - - id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } - - Countersignature attribute values have ASN.1 type Countersignature: - - Countersignature ::= SignerInfo - - Countersignature values have the same meaning as SignerInfo values - for ordinary signatures, except that: - - 1. The signedAttributes field MUST NOT contain a content-type - attribute; there is no content type for countersignatures. - - 2. The signedAttributes field MUST contain a message-digest - attribute if it contains any other attributes. - - 3. The input to the message-digesting process is the contents octets - of the DER encoding of the signatureValue field of the SignerInfo - value with which the attribute is associated. - - A countersignature attribute can have multiple attribute values. The - syntax is defined as a SET OF AttributeValue, and there MUST be one - or more instances of AttributeValue present. - - The UnsignedAttributes syntax is defined as a SET OF Attributes. The - UnsignedAttributes in a signerInfo may include multiple instances of - the countersignature attribute. - - A countersignature, since it has type SignerInfo, can itself contain - a countersignature attribute. Thus, it is possible to construct an - arbitrarily long series of countersignatures. - -12. ASN.1 Modules - - Section 12.1 contains the ASN.1 module for the CMS, and Section 12.2 - contains the ASN.1 module for the Version 1 Attribute Certificate. - - - - - - - - -Housley Standards Track [Page 43] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -12.1. CMS ASN.1 Module - - CryptographicMessageSyntax2004 - { iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) } - - DEFINITIONS IMPLICIT TAGS ::= - BEGIN - - -- EXPORTS All - -- The types and values defined in this module are exported for use - -- in the other ASN.1 modules. Other applications may use them for - -- their own purposes. - - IMPORTS - - -- Imports from RFC 5280 [PROFILE], Appendix A.1 - AlgorithmIdentifier, Certificate, CertificateList, - CertificateSerialNumber, Name - FROM PKIX1Explicit88 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - mod(0) pkix1-explicit(18) } - - -- Imports from RFC 3281 [ACPROFILE], Appendix B - AttributeCertificate - FROM PKIXAttributeCertificate - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - mod(0) attribute-cert(12) } - - -- Imports from Appendix B of this document - AttributeCertificateV1 - FROM AttributeCertificateVersion1 - { iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs-9(9) smime(16) modules(0) - v1AttrCert(15) } ; - - -- Cryptographic Message Syntax - - ContentInfo ::= SEQUENCE { - contentType ContentType, - content [0] EXPLICIT ANY DEFINED BY contentType } - - ContentType ::= OBJECT IDENTIFIER - - - - - - -Housley Standards Track [Page 44] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - SignedData ::= SEQUENCE { - version CMSVersion, - digestAlgorithms DigestAlgorithmIdentifiers, - encapContentInfo EncapsulatedContentInfo, - certificates [0] IMPLICIT CertificateSet OPTIONAL, - crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, - signerInfos SignerInfos } - - DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier - - SignerInfos ::= SET OF SignerInfo - - EncapsulatedContentInfo ::= SEQUENCE { - eContentType ContentType, - eContent [0] EXPLICIT OCTET STRING OPTIONAL } - - SignerInfo ::= SEQUENCE { - version CMSVersion, - sid SignerIdentifier, - digestAlgorithm DigestAlgorithmIdentifier, - signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, - signatureAlgorithm SignatureAlgorithmIdentifier, - signature SignatureValue, - unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } - - SignerIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier } - - SignedAttributes ::= SET SIZE (1..MAX) OF Attribute - - UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute - - Attribute ::= SEQUENCE { - attrType OBJECT IDENTIFIER, - attrValues SET OF AttributeValue } - - AttributeValue ::= ANY - - SignatureValue ::= OCTET STRING - - EnvelopedData ::= SEQUENCE { - version CMSVersion, - originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, - recipientInfos RecipientInfos, - encryptedContentInfo EncryptedContentInfo, - unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } - - - - -Housley Standards Track [Page 45] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - OriginatorInfo ::= SEQUENCE { - certs [0] IMPLICIT CertificateSet OPTIONAL, - crls [1] IMPLICIT RevocationInfoChoices OPTIONAL } - - RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo - - EncryptedContentInfo ::= SEQUENCE { - contentType ContentType, - contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, - encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL } - - EncryptedContent ::= OCTET STRING - - UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute - - RecipientInfo ::= CHOICE { - ktri KeyTransRecipientInfo, - kari [1] KeyAgreeRecipientInfo, - kekri [2] KEKRecipientInfo, - pwri [3] PasswordRecipientInfo, - ori [4] OtherRecipientInfo } - - EncryptedKey ::= OCTET STRING - - KeyTransRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 0 or 2 - rid RecipientIdentifier, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - RecipientIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier } - - KeyAgreeRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 3 - originator [0] EXPLICIT OriginatorIdentifierOrKey, - ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - recipientEncryptedKeys RecipientEncryptedKeys } - - OriginatorIdentifierOrKey ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - subjectKeyIdentifier [0] SubjectKeyIdentifier, - originatorKey [1] OriginatorPublicKey } - - - - - - -Housley Standards Track [Page 46] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - OriginatorPublicKey ::= SEQUENCE { - algorithm AlgorithmIdentifier, - publicKey BIT STRING } - - RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey - - RecipientEncryptedKey ::= SEQUENCE { - rid KeyAgreeRecipientIdentifier, - encryptedKey EncryptedKey } - - KeyAgreeRecipientIdentifier ::= CHOICE { - issuerAndSerialNumber IssuerAndSerialNumber, - rKeyId [0] IMPLICIT RecipientKeyIdentifier } - - RecipientKeyIdentifier ::= SEQUENCE { - subjectKeyIdentifier SubjectKeyIdentifier, - date GeneralizedTime OPTIONAL, - other OtherKeyAttribute OPTIONAL } - - SubjectKeyIdentifier ::= OCTET STRING - - KEKRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 4 - kekid KEKIdentifier, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - KEKIdentifier ::= SEQUENCE { - keyIdentifier OCTET STRING, - date GeneralizedTime OPTIONAL, - other OtherKeyAttribute OPTIONAL } - - PasswordRecipientInfo ::= SEQUENCE { - version CMSVersion, -- always set to 0 - keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier - OPTIONAL, - keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, - encryptedKey EncryptedKey } - - OtherRecipientInfo ::= SEQUENCE { - oriType OBJECT IDENTIFIER, - oriValue ANY DEFINED BY oriType } - - DigestedData ::= SEQUENCE { - version CMSVersion, - digestAlgorithm DigestAlgorithmIdentifier, - encapContentInfo EncapsulatedContentInfo, - digest Digest } - - - -Housley Standards Track [Page 47] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - Digest ::= OCTET STRING - - EncryptedData ::= SEQUENCE { - version CMSVersion, - encryptedContentInfo EncryptedContentInfo, - unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL } - - AuthenticatedData ::= SEQUENCE { - version CMSVersion, - originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, - recipientInfos RecipientInfos, - macAlgorithm MessageAuthenticationCodeAlgorithm, - digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL, - encapContentInfo EncapsulatedContentInfo, - authAttrs [2] IMPLICIT AuthAttributes OPTIONAL, - mac MessageAuthenticationCode, - unauthAttrs [3] IMPLICIT UnauthAttributes OPTIONAL } - - AuthAttributes ::= SET SIZE (1..MAX) OF Attribute - - UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute - - MessageAuthenticationCode ::= OCTET STRING - - DigestAlgorithmIdentifier ::= AlgorithmIdentifier - - SignatureAlgorithmIdentifier ::= AlgorithmIdentifier - - KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier - - ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier - - MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier - - KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier - - RevocationInfoChoices ::= SET OF RevocationInfoChoice - - RevocationInfoChoice ::= CHOICE { - crl CertificateList, - other [1] IMPLICIT OtherRevocationInfoFormat } - - OtherRevocationInfoFormat ::= SEQUENCE { - otherRevInfoFormat OBJECT IDENTIFIER, - otherRevInfo ANY DEFINED BY otherRevInfoFormat } - - - - - - -Housley Standards Track [Page 48] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - CertificateChoices ::= CHOICE { - certificate Certificate, - extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete - v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete - v2AttrCert [2] IMPLICIT AttributeCertificateV2, - other [3] IMPLICIT OtherCertificateFormat } - - AttributeCertificateV2 ::= AttributeCertificate - - OtherCertificateFormat ::= SEQUENCE { - otherCertFormat OBJECT IDENTIFIER, - otherCert ANY DEFINED BY otherCertFormat } - - CertificateSet ::= SET OF CertificateChoices - - IssuerAndSerialNumber ::= SEQUENCE { - issuer Name, - serialNumber CertificateSerialNumber } - - CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) } - - UserKeyingMaterial ::= OCTET STRING - - OtherKeyAttribute ::= SEQUENCE { - keyAttrId OBJECT IDENTIFIER, - keyAttr ANY DEFINED BY keyAttrId OPTIONAL } - - -- Content Type Object Identifiers - - id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 } - - id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 } - - id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } - - id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 } - - id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 } - - id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 } - - - - - -Housley Standards Track [Page 49] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 2 } - - -- The CMS Attributes - - MessageDigest ::= OCTET STRING - - SigningTime ::= Time - - Time ::= CHOICE { - utcTime UTCTime, - generalTime GeneralizedTime } - - Countersignature ::= SignerInfo - - -- Attribute Object Identifiers - - id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 } - - id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 } - - id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 } - - id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 } - - -- Obsolete Extended Certificate syntax from PKCS #6 - - ExtendedCertificateOrCertificate ::= CHOICE { - certificate Certificate, - extendedCertificate [0] IMPLICIT ExtendedCertificate } - - ExtendedCertificate ::= SEQUENCE { - extendedCertificateInfo ExtendedCertificateInfo, - signatureAlgorithm SignatureAlgorithmIdentifier, - signature Signature } - - ExtendedCertificateInfo ::= SEQUENCE { - version CMSVersion, - certificate Certificate, - attributes UnauthAttributes } - - Signature ::= BIT STRING - - END -- of CryptographicMessageSyntax2004 - - - -Housley Standards Track [Page 50] - -RFC 5652 Cryptographic Message Syntax September 2009 - - -12.2. Version 1 Attribute Certificate ASN.1 Module - - AttributeCertificateVersion1 - { iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) } - - DEFINITIONS EXPLICIT TAGS ::= - BEGIN - - -- EXPORTS All - - IMPORTS - - -- Imports from RFC 5280 [PROFILE], Appendix A.1 - AlgorithmIdentifier, Attribute, CertificateSerialNumber, - Extensions, UniqueIdentifier - FROM PKIX1Explicit88 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - mod(0) pkix1-explicit(18) } - - -- Imports from RFC 5280 [PROFILE], Appendix A.2 - GeneralNames - FROM PKIX1Implicit88 - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - mod(0) pkix1-implicit(19) } - - -- Imports from RFC 3281 [ACPROFILE], Appendix B - AttCertValidityPeriod, IssuerSerial - FROM PKIXAttributeCertificate - { iso(1) identified-organization(3) dod(6) - internet(1) security(5) mechanisms(5) pkix(7) - mod(0) attribute-cert(12) } ; - - -- Definition extracted from X.509-1997 [X.509-97], but - -- different type names are used to avoid collisions. - - AttributeCertificateV1 ::= SEQUENCE { - acInfo AttributeCertificateInfoV1, - signatureAlgorithm AlgorithmIdentifier, - signature BIT STRING } - - - - - - - - - -Housley Standards Track [Page 51] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - AttributeCertificateInfoV1 ::= SEQUENCE { - version AttCertVersionV1 DEFAULT v1, - subject CHOICE { - baseCertificateID [0] IssuerSerial, - -- associated with a Public Key Certificate - subjectName [1] GeneralNames }, - -- associated with a name - issuer GeneralNames, - signature AlgorithmIdentifier, - serialNumber CertificateSerialNumber, - attCertValidityPeriod AttCertValidityPeriod, - attributes SEQUENCE OF Attribute, - issuerUniqueID UniqueIdentifier OPTIONAL, - extensions Extensions OPTIONAL } - - AttCertVersionV1 ::= INTEGER { v1(0) } - - END -- of AttributeCertificateVersion1 - -13. References - -13.1. Normative References - - [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute - Certificate Profile for Authorization", RFC 3281, April - 2002. - - [PROFILE] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., - Housley, R., and W. Polk, "Internet X.509 Public Key - Infrastructure Certificate and Certificate Revocation - List (CRL) Profile", RFC 5280, May 2008. - - [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [X.208-88] CCITT. Recommendation X.208: Specification of Abstract - Syntax Notation One (ASN.1), 1988. - - [X.209-88] CCITT. Recommendation X.209: Specification of Basic - Encoding Rules for Abstract Syntax Notation One - (ASN.1), 1988. - - [X.501-88] CCITT. Recommendation X.501: The Directory - Models, - 1988. - - [X.509-88] CCITT. Recommendation X.509: The Directory - - Authentication Framework, 1988. - - - - -Housley Standards Track [Page 52] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - [X.509-97] ITU-T. Recommendation X.509: The Directory - - Authentication Framework, 1997. - - [X.509-00] ITU-T. Recommendation X.509: The Directory - - Authentication Framework, 2000. - -13.2. Informative References - - [CMS1] Housley, R., "Cryptographic Message Syntax", RFC 2630, - June 1999. - - [CMS2] Housley, R., "Cryptographic Message Syntax (CMS)", RFC - 3369, August 2002. - - [CMS3] Housley, R., "Cryptographic Message Syntax (CMS)", RFC - 3852, July 2004. - - [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) - Algorithms", RFC 3370, August 2002. - - [CMSMSIG] Housley, R., "Cryptographic Message Syntax (CMS) - Multiple Signer Clarification", RFC 4853, April 2007. - - [DH-X9.42] Rescorla, E., "Diffie-Hellman Key Agreement Method", - RFC 2631, June 1999. - - [ESS] Hoffman, P., Ed., "Enhanced Security Services for - S/MIME", RFC 2634, June 1999. - - [MSAC] Microsoft Development Network (MSDN) Library, - "Authenticode", April 2004 Release. - - [MSG2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., - and L. Repka, "S/MIME Version 2 Message Specification", - RFC 2311, March 1998. - - [MSG3] Ramsdell, B., Ed., "S/MIME Version 3 Message - Specification", RFC 2633, June 1999. - - [MSG3.1] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail - Extensions (S/MIME) Version 3.1 Message Specification", - RFC 3851, July 2004. - - [NEWPKCS#1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography - Specifications Version 2.0", RFC 2437, October 1998. - - - - - - -Housley Standards Track [Page 53] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and - C. Adams, "X.509 Internet Public Key Infrastructure - Online Certificate Status Protocol - OCSP", RFC 2560, - June 1999. - - [PKCS#1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC - 2313, March 1998. - - [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax - Standard, Version 1.5. November 1993. - - [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax - Version 1.5", RFC 2315, March 1998. - - [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, - Version 1.1. November 1993. - - [PWRI] Gutmann, P., "Password-based Encryption for CMS", RFC - 3211, December 2001. - - [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC - 4086, June 2005. - -14. Security Considerations - - The Cryptographic Message Syntax provides a method for digitally - signing data, digesting data, encrypting data, and authenticating - data. - - Implementations must protect the signer's private key. Compromise of - the signer's private key permits masquerade. - - Implementations must protect the key management private key, the - key-encryption key, and the content-encryption key. Compromise of - the key management private key or the key-encryption key may result - in the disclosure of all contents protected with that key. - Similarly, compromise of the content-encryption key may result in - disclosure of the associated encrypted content. - - Implementations must protect the key management private key and the - message-authentication key. Compromise of the key management private - key permits masquerade of authenticated data. Similarly, compromise - of the message-authentication key may result in undetectable - modification of the authenticated content. - - - - - - -Housley Standards Track [Page 54] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The key management technique employed to distribute message- - authentication keys must itself provide data origin authentication; - otherwise, the contents are delivered with integrity from an unknown - source. Neither RSA [PKCS#1] [NEWPKCS#1] nor Ephemeral-Static - Diffie-Hellman [DH-X9.42] provide the necessary data origin - authentication. Static-Static Diffie-Hellman [DH-X9.42] does provide - the necessary data origin authentication when both the originator and - recipient public keys are bound to appropriate identities in X.509 - certificates. - - When more than two parties share the same message-authentication key, - data origin authentication is not provided. Any party that knows the - message-authentication key can compute a valid MAC; therefore, the - contents could originate from any one of the parties. - - Implementations must randomly generate content-encryption keys, - message-authentication keys, initialization vectors (IVs), and - padding. Also, the generation of public/private key pairs relies on - random numbers. The use of inadequate pseudo-random number - generators (PRNGs) to generate cryptographic keys can result in - little or no security. An attacker may find it much easier to - reproduce the PRNG environment that produced the keys, searching the - resulting small set of possibilities, rather than brute force - searching the whole key space. The generation of quality random - numbers is difficult. RFC 4086 [RANDOM] offers important guidance in - this area. - - When using key-agreement algorithms or previously distributed - symmetric key-encryption keys, a key-encryption key is used to - encrypt the content-encryption key. If the key-encryption and - content-encryption algorithms are different, the effective security - is determined by the weaker of the two algorithms. If, for example, - content is encrypted with Triple-DES using a 168-bit Triple-DES - content-encryption key, and the content-encryption key is wrapped - with RC2 using a 40-bit RC2 key-encryption key, then at most 40 bits - of protection is provided. A trivial search to determine the value - of the 40-bit RC2 key can recover the Triple-DES key, and then the - Triple-DES key can be used to decrypt the content. Therefore, - implementers must ensure that key-encryption algorithms are as strong - or stronger than content-encryption algorithms. - - Implementers should be aware that cryptographic algorithms become - weaker with time. As new cryptoanalysis techniques are developed and - computing performance improves, the work factor to break a particular - cryptographic algorithm will be reduced. Therefore, cryptographic - algorithm implementations should be modular, allowing new algorithms - to be readily inserted. That is, implementers should be prepared for - the set of algorithms that must be supported to change over time. - - - -Housley Standards Track [Page 55] - -RFC 5652 Cryptographic Message Syntax September 2009 - - - The countersignature unsigned attribute includes a digital signature - that is computed on the content signature value; thus, the - countersigning process need not know the original signed content. - This structure permits implementation efficiency advantages; however, - this structure may also permit the countersigning of an inappropriate - signature value. Therefore, implementations that perform - countersignatures should either verify the original signature value - prior to countersigning it (this verification requires processing of - the original content), or implementations should perform - countersigning in a context that ensures that only appropriate - signature values are countersigned. - -15. Acknowledgments - - This document is the result of contributions from many professionals. - I appreciate the hard work of all members of the IETF S/MIME Working - Group. I extend a special thanks to Rich Ankney, Simon Blake-Wilson, - Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, - Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt - Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, - Jim Schaad, Dave Solo, Paul Timmel, and Sean Turner for their efforts - and support. - - I thank Tim Polk for his encouragement in advancing this - specification along the standards maturity ladder. In addition, I - thank Jan Vilhuber for the careful reading that resulted in RFC - Errata 1744. - -Author's Address - - Russell Housley - Vigil Security, LLC - 918 Spring Knoll Drive - Herndon, VA 20170 - USA - EMail: housley@vigilsec.com - - - - - - - - - - - - - - - -Housley Standards Track [Page 56] - diff --git a/specifications/mail/rfc8551.txt b/specifications/mail/rfc8551.txt deleted file mode 100644 index b07ea089..00000000 --- a/specifications/mail/rfc8551.txt +++ /dev/null @@ -1,3531 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) J. Schaad -Request for Comments: 8551 August Cellars -Obsoletes: 5751 B. Ramsdell -Category: Standards Track Brute Squad Labs, Inc. -ISSN: 2070-1721 S. Turner - sn3rd - April 2019 - - - Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 - Message Specification - -Abstract - - This document defines Secure/Multipurpose Internet Mail Extensions - (S/MIME) version 4.0. S/MIME provides a consistent way to send and - receive secure MIME data. Digital signatures provide authentication, - message integrity, and non-repudiation with proof of origin. - Encryption provides data confidentiality. Compression can be used to - reduce data size. This document obsoletes RFC 5751. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc8551. - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 1] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -Copyright Notice - - Copyright (c) 2019 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - - - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 2] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Specification Overview . . . . . . . . . . . . . . . . . 5 - 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.3. Conventions Used in This Document . . . . . . . . . . . . 7 - 1.4. Compatibility with Prior Practice of S/MIME . . . . . . . 8 - 1.5. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 9 - 1.6. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 9 - 1.7. Changes for S/MIME v4.0 . . . . . . . . . . . . . . . . . 11 - 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 2.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 12 - 2.2. SignatureAlgorithmIdentifier . . . . . . . . . . . . . . 12 - 2.3. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 13 - 2.4. General Syntax . . . . . . . . . . . . . . . . . . . . . 13 - 2.4.1. Data Content Type . . . . . . . . . . . . . . . . . . 14 - 2.4.2. SignedData Content Type . . . . . . . . . . . . . . . 14 - 2.4.3. EnvelopedData Content Type . . . . . . . . . . . . . 14 - 2.4.4. AuthEnvelopedData Content Type . . . . . . . . . . . 14 - 2.4.5. CompressedData Content Type . . . . . . . . . . . . . 14 - 2.5. Attributes and the SignerInfo Type . . . . . . . . . . . 15 - 2.5.1. Signing Time Attribute . . . . . . . . . . . . . . . 15 - 2.5.2. SMIMECapabilities Attribute . . . . . . . . . . . . . 16 - 2.5.3. Encryption Key Preference Attribute . . . . . . . . . 17 - 2.6. SignerIdentifier SignerInfo Type . . . . . . . . . . . . 19 - 2.7. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 19 - 2.7.1. Deciding Which Encryption Method to Use . . . . . . . 19 - 2.7.2. Choosing Weak Encryption . . . . . . . . . . . . . . 21 - 2.7.3. Multiple Recipients . . . . . . . . . . . . . . . . . 21 - 3. Creating S/MIME Messages . . . . . . . . . . . . . . . . . . 21 - 3.1. Preparing the MIME Entity for Signing, Enveloping, or - Compressing . . . . . . . . . . . . . . . . . . . . . . . 22 - 3.1.1. Canonicalization . . . . . . . . . . . . . . . . . . 23 - 3.1.2. Transfer Encoding . . . . . . . . . . . . . . . . . . 24 - 3.1.3. Transfer Encoding for Signing Using multipart/signed 25 - 3.1.4. Sample Canonical MIME Entity . . . . . . . . . . . . 25 - 3.2. The application/pkcs7-mime Media Type . . . . . . . . . . 26 - 3.2.1. The name and filename Parameters . . . . . . . . . . 27 - 3.2.2. The smime-type Parameter . . . . . . . . . . . . . . 28 - 3.3. Creating an Enveloped-Only Message . . . . . . . . . . . 29 - 3.4. Creating an Authenticated Enveloped-Only Message . . . . 30 - 3.5. Creating a Signed-Only Message . . . . . . . . . . . . . 31 - 3.5.1. Choosing a Format for Signed-Only Messages . . . . . 32 - 3.5.2. Signing Using application/pkcs7-mime with SignedData 32 - 3.5.3. Signing Using the multipart/signed Format . . . . . . 33 - 3.6. Creating a Compressed-Only Message . . . . . . . . . . . 36 - 3.7. Multiple Operations . . . . . . . . . . . . . . . . . . . 37 - 3.8. Creating a Certificate Management Message . . . . . . . . 38 - - - -Schaad, et al. Standards Track [Page 3] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - 3.9. Registration Requests . . . . . . . . . . . . . . . . . . 38 - 3.10. Identifying an S/MIME Message . . . . . . . . . . . . . . 39 - 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 39 - 4.1. Key Pair Generation . . . . . . . . . . . . . . . . . . . 40 - 4.2. Signature Generation . . . . . . . . . . . . . . . . . . 40 - 4.3. Signature Verification . . . . . . . . . . . . . . . . . 40 - 4.4. Encryption . . . . . . . . . . . . . . . . . . . . . . . 41 - 4.5. Decryption . . . . . . . . . . . . . . . . . . . . . . . 41 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 - 5.1. Media Type for application/pkcs7-mime . . . . . . . . . . 42 - 5.2. Media Type for application/pkcs7-signature . . . . . . . 43 - 5.3. authEnveloped-data smime-type . . . . . . . . . . . . . . 44 - 5.4. Reference Updates . . . . . . . . . . . . . . . . . . . . 44 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 - 7.1. Reference Conventions . . . . . . . . . . . . . . . . . . 48 - 7.2. Normative References . . . . . . . . . . . . . . . . . . 49 - 7.3. Informative References . . . . . . . . . . . . . . . . . 52 - Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 57 - Appendix B. Historic Mail Considerations . . . . . . . . . . . . 59 - B.1. DigestAlgorithmIdentifier . . . . . . . . . . . . . . . . 59 - B.2. Signature Algorithms . . . . . . . . . . . . . . . . . . 59 - B.3. ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 61 - B.4. KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . . 62 - Appendix C. Moving S/MIME v2 Message Specification to Historic - Status . . . . . . . . . . . . . . . . . . . . . . . 62 - Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 4] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -1. Introduction - - S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a - consistent way to send and receive secure MIME data. Based on the - popular Internet MIME standard, S/MIME provides the following - cryptographic security services for electronic messaging - applications: authentication, message integrity, and non-repudiation - of origin (using digital signatures), and data confidentiality (using - encryption). As a supplementary service, S/MIME provides message - compression. - - S/MIME can be used by traditional mail user agents (MUAs) to add - cryptographic security services to mail that is sent, and to - interpret cryptographic security services in mail that is received. - However, S/MIME is not restricted to mail; it can be used with any - transport mechanism that transports MIME data, such as HTTP or SIP. - As such, S/MIME takes advantage of the object-based features of MIME - and allows secure messages to be exchanged in mixed-transport - systems. - - Further, S/MIME can be used in automated message transfer agents that - use cryptographic security services that do not require any human - intervention, such as the signing of software-generated documents and - the encryption of FAX messages sent over the Internet. - - This document defines version 4.0 of the S/MIME Message - Specification. As such, this document obsoletes version 3.2 of the - S/MIME Message Specification [RFC5751]. - - This specification contains a number of references to documents that - have been obsoleted or replaced. This is intentional, as the updated - documents often do not have the same information or protocol - requirements in them. - -1.1. Specification Overview - - This document describes a protocol for adding cryptographic signature - and encryption services to MIME data. The MIME standard [MIME-SPEC] - provides a general structure for the content of Internet messages and - allows extensions for new applications based on content-type. - - This specification defines how to create a MIME body part that has - been cryptographically enhanced according to the Cryptographic - Message Syntax (CMS) [CMS], which is derived from PKCS #7 [RFC2315]. - This specification also defines the application/pkcs7-mime media - type, which can be used to transport those body parts. - - - - - -Schaad, et al. Standards Track [Page 5] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - This document also discusses how to use the multipart/signed media - type defined in [RFC1847] to transport S/MIME signed messages. - multipart/signed is used in conjunction with the - application/pkcs7-signature media type, which is used to transport a - detached S/MIME signature. - - In order to create S/MIME messages, an S/MIME agent MUST follow the - specifications in this document, as well as the specifications listed - in [CMS], [RFC3370], [RFC4056], [RFC3560], and [RFC5754]. - - Throughout this specification, there are requirements and - recommendations made for how receiving agents handle incoming - messages. There are separate requirements and recommendations for - how sending agents create outgoing messages. In general, the best - strategy is to follow the Robustness Principle (be liberal in what - you receive and conservative in what you send). Most of the - requirements are placed on the handling of incoming messages, while - the recommendations are mostly on the creation of outgoing messages. - - The separation for requirements on receiving agents and sending - agents also derives from the likelihood that there will be S/MIME - systems that involve software other than traditional Internet mail - clients. S/MIME can be used with any system that transports MIME - data. An automated process that sends an encrypted message might not - be able to receive an encrypted message at all, for example. Thus, - the requirements and recommendations for the two types of agents are - listed separately when appropriate. - -1.2. Definitions - - For the purposes of this specification, the following definitions - apply. - - ASN.1: - Abstract Syntax Notation One, as defined in ITU-T Recommendations - X.680, X.681, X.682, and X.683 [ASN.1]. - - BER: - Basic Encoding Rules for ASN.1, as defined in ITU-T Recommendation - X.690 [X.690]. - - Certificate: - A type that binds an entity's name to a public key with a digital - signature. - - DER: - Distinguished Encoding Rules for ASN.1, as defined in ITU-T - Recommendation X.690 [X.690]. - - - -Schaad, et al. Standards Track [Page 6] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - 7-bit data: - Text data with lines less than 998 characters long, where none of - the characters have the 8th bit set, and there are no NULL - characters. and occur only as part of a - end-of-line delimiter. - - 8-bit data: - Text data with lines less than 998 characters, and where none of - the characters are NULL characters. and occur only as - part of a end-of-line delimiter. - - Binary data: - Arbitrary data. - - Transfer encoding: - A reversible transformation made on data so 8-bit or binary data - can be sent via a channel that only transmits 7-bit data. - - Receiving agent: - Software that interprets and processes S/MIME CMS objects, MIME - body parts that contain CMS content types, or both. - - Sending agent: - Software that creates S/MIME CMS content types, MIME body parts - that contain CMS content types, or both. - - S/MIME agent: - User software that is a receiving agent, a sending agent, or both. - - Data integrity service: - A security service that protects against unauthorized changes to - data by ensuring that changes to the data are detectable - [RFC4949]. - - Data confidentiality: - The property that data is not disclosed to system entities unless - they have been authorized to know the data [RFC4949]. - -1.3. 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - - - - - -Schaad, et al. Standards Track [Page 7] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - We define the additional requirement levels: - - SHOULD+ This term means the same as SHOULD. However, the authors - expect that a requirement marked as SHOULD+ will be - promoted at some future time to be a MUST. - - SHOULD- This term means the same as SHOULD. However, the authors - expect that a requirement marked as SHOULD- will be demoted - to a MAY in a future version of this document. - - MUST- This term means the same as MUST. However, the authors - expect that this requirement will no longer be a MUST in a - future document. Although its status will be determined at - a later time, it is reasonable to expect that if a future - revision of a document alters the status of a MUST- - requirement, it will remain at least a SHOULD or a SHOULD-. - - The term "RSA" in this document almost always refers to the - PKCS #1 v1.5 RSA [RFC2313] signature or encryption algorithms even - when not qualified as such. There are a couple of places where it - refers to the general RSA cryptographic operation; these can be - determined from the context where it is used. - -1.4. Compatibility with Prior Practice of S/MIME - - S/MIME version 4.0 agents ought to attempt to have the greatest - interoperability possible with agents for prior versions of S/MIME. - - - S/MIME version 2 is described in RFC 2311 through RFC 2315 - inclusive [SMIMEv2]. - - - S/MIME version 3 is described in RFC 2630 through RFC 2634 - inclusive and RFC 5035 [SMIMEv3]. - - - S/MIME version 3.1 is described in RFC 2634, RFC 3850, RFC 3851, - RFC 3852, and RFC 5035 [SMIMEv3.1]. - - - S/MIME version 3.2 is described in RFC 2634, RFC 5035, RFC 5652, - RFC 5750, and RFC 5751 [SMIMEv3.2]. - - - [RFC2311] also has historical information about the development of - S/MIME. - - - - - - - - - -Schaad, et al. Standards Track [Page 8] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -1.5. Changes from S/MIME v3 to S/MIME v3.1 - - This section describes the changes made between S/MIME v3 and - S/MIME v3.1. Note that the requirement levels indicated by the - capitalized key words ("MUST", "SHOULD", etc.) may have changed in - later versions of S/MIME. - - - The RSA public key algorithm was changed to a MUST implement. The - key wrap algorithm and the Diffie-Hellman (DH) algorithm [RFC2631] - were changed to a SHOULD implement. - - - The AES symmetric encryption algorithm has been included as a - SHOULD implement. - - - The RSA public key algorithm was changed to a MUST implement - signature algorithm. - - - Ambiguous language about the use of "empty" SignedData messages to - transmit certificates was clarified to reflect that transmission - of Certificate Revocation Lists is also allowed. - - - The use of binary encoding for some MIME entities is now - explicitly discussed. - - - Header protection through the use of the message/rfc822 media type - has been added. - - - Use of the CompressedData CMS type is allowed, along with required - media type and file extension additions. - -1.6. Changes from S/MIME v3.1 to S/MIME v3.2 - - This section describes the changes made between S/MIME v3.1 and - S/MIME v3.2. Note that the requirement levels indicated by the - capitalized key words ("MUST", "SHOULD", etc.) may have changed in - later versions of S/MIME. Note that the section numbers listed here - (e.g., 3.4.3.2) are from [RFC5751]. - - - Made editorial changes, e.g., replaced "MIME type" with "media - type", "content-type" with "Content-Type". - - - Moved "Conventions Used in This Document" to Section 1.3. Added - definitions for SHOULD+, SHOULD-, and MUST-. - - - Section 1.1 and Appendix A: Added references to RFCs for - RSASSA-PSS, RSAES-OAEP, and SHA2 CMS algorithms. Added CMS - Multiple Signers Clarification to CMS reference. - - - - -Schaad, et al. Standards Track [Page 9] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - Section 1.2: Updated references to ASN.1 to X.680, and BER and DER - to X.690. - - - Section 1.4: Added references to S/MIME v3.1 RFCs. - - - Section 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and - MD5 made SHOULD-. - - - Section 2.2 (signature algorithms): RSA with SHA-256 added as - MUST; DSA with SHA-256 added as SHOULD+; RSA with SHA-1, DSA with - SHA-1, and RSA with MD5 changed to SHOULD-; and RSASSA-PSS with - SHA-256 added as SHOULD+. Also added note about what S/MIME v3.1 - clients support. - - - Section 2.3 (key encryption): DH changed to SHOULD-, and RSAES- - OAEP added as SHOULD+. Elaborated on requirements for key wrap - algorithm. - - - Section 2.5.1: Added requirement that receiving agents MUST - support both GeneralizedTime and UTCTime. - - - Section 2.5.2: Replaced reference "sha1WithRSAEncryption" with - "sha256WithRSAEncryption", replaced "DES-3EDE-CBC" with "AES-128 - CBC", and deleted the RC5 example. - - - Section 2.5.2.1: Deleted entire section (discussed - deprecated RC2). - - - Section 2.7, Section 2.7.1, and Appendix A: References to RC2/40 - removed. - - - Section 2.7 (content encryption): AES-128 CBC added as MUST, - AES-192 and AES-256 CBC SHOULD+, and tripleDES now SHOULD-. - - - Section 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to - 2.7.1.1 and 2.7.1.2. - - - Section 3.1.1: Removed text about MIME character sets. - - - Sections 3.2.2 and 3.6: Replaced "encrypted" with "enveloped". - Updated OID example to use AES-128 CBC OID. - - - Section 3.4.3.2: Replaced "micalg" parameter for "SHA-1" with - "sha-1". - - - Section 4: Updated reference to CERT v3.2. - - - - - -Schaad, et al. Standards Track [Page 10] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - Section 4.1: Updated RSA and DSA key size discussion. Moved last - four sentences to security considerations. Updated reference to - randomness requirements for security. - - - Section 5: Added IANA registration templates to update media type - registry to point to this document as opposed to RFC 2311. - - - Section 6: Updated security considerations. - - - Section 7: Moved references from Appendix B to this section. - Updated references. Added informative references to SMIMEv2, - SMIMEv3, and SMIMEv3.1. - - - Appendix B: Added Appendix B to move S/MIME v2 to Historic status. - -1.7. Changes for S/MIME v4.0 - - This section describes the changes made between S/MIME v3.2 and - S/MIME v4.0. - - - Added the use of AuthEnvelopedData, including defining and - registering an smime-type value (Sections 2.4.4 and 3.4). - - - Updated the content-encryption algorithms (Sections 2.7 and - 2.7.1.2): added AES-256 Galois/Counter Mode (GCM), added - ChaCha20-Poly1305, removed mention of AES-192 Cipher Block - Chaining (CBC), and marked tripleDES as historic. - - - Updated the set of signature algorithms (Section 2.2): added the - Edwards-curve Digital Signature Algorithm (EdDSA), added the - Elliptic Curve Digital Signature Algorithm (ECDSA), and marked DSA - as historic. - - - Updated the set of digest algorithms (Section 2.1): added SHA-512, - and marked SHA-1 as historic. - - - Updated the size of keys to be used for RSA encryption and RSA - signing (Section 4). - - - Created Appendix B, which discusses considerations for dealing - with historic email messages. - - - - - - - - - - -Schaad, et al. Standards Track [Page 11] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -2. CMS Options - - CMS allows for a wide variety of options in content, attributes, and - algorithm support. This section puts forth a number of support - requirements and recommendations in order to achieve a base level of - interoperability among all S/MIME implementations. [RFC3370] and - [RFC5754] provide additional details regarding the use of the - cryptographic algorithms. [ESS] provides additional details - regarding the use of additional attributes. - -2.1. DigestAlgorithmIdentifier - - The algorithms here are used for digesting the body of the message - and are not the same as the digest algorithms used as part of the - signature algorithms. The result of this is placed in the - message-digest attribute of the signed attributes. It is RECOMMENDED - that the algorithm used for digesting the body of the message be of - similar strength to, or greater strength than, the signature - algorithm. - - Sending and receiving agents: - - - MUST support SHA-256. - - - MUST support SHA-512. - - [RFC5754] provides the details for using these algorithms with - S/MIME. - -2.2. SignatureAlgorithmIdentifier - - There are different sets of requirements placed on receiving and - sending agents. By having the different requirements, the maximum - amount of interoperability is achieved, as it allows for specialized - protection of private key material but maximum signature validation. - - Receiving agents: - - - MUST support ECDSA with curve P-256 and SHA-256. - - - MUST support EdDSA with curve25519 using PureEdDSA mode [RFC8419]. - - - MUST- support RSA PKCS #1 v1.5 with SHA-256. - - - SHOULD support the RSA Probabilistic Signature Scheme (RSASSA-PSS) - with SHA-256. - - - - - -Schaad, et al. Standards Track [Page 12] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - Sending agents: - - - MUST support at least one of the following algorithms: ECDSA with - curve P-256 and SHA-256, or EdDSA with curve25519 using PureEdDSA - mode. - - - MUST- support RSA PKCS #1 v1.5 with SHA-256. - - - SHOULD support RSASSA-PSS with SHA-256. - - See Section 4.1 for information on key size and algorithm references. - -2.3. KeyEncryptionAlgorithmIdentifier - - Receiving and sending agents: - - - MUST support Elliptic Curve Diffie-Hellman (ECDH) ephemeral-static - mode for P-256, as specified in [RFC5753]. - - - MUST support ECDH ephemeral-static mode for X25519 using HKDF-256 - ("HKDF" stands for "HMAC-based Key Derivation Function") for the - KDF, as specified in [RFC8418]. - - - MUST- support RSA encryption, as specified in [RFC3370]. - - - SHOULD+ support RSA Encryption Scheme - Optimal Asymmetric - Encryption Padding (RSAES-OAEP), as specified in [RFC3560]. - - When ECDH ephemeral-static is used, a key wrap algorithm is also - specified in the KeyEncryptionAlgorithmIdentifier [RFC5652]. The - underlying encryption functions for the key wrap and content- - encryption algorithms [RFC3370] [RFC3565] and the key sizes for the - two algorithms MUST be the same (e.g., AES-128 key wrap algorithm - with AES-128 content-encryption algorithm). As both 128-bit and - 256-bit AES modes are mandatory to implement as content-encryption - algorithms (Section 2.7), both the AES-128 and AES-256 key wrap - algorithms MUST be supported when ECDH ephemeral-static is used. - Recipients MAY enforce this but MUST use the weaker of the two as - part of any cryptographic strength computations they might do. - - Appendix B provides information on algorithm support in older - versions of S/MIME. - -2.4. General Syntax - - There are several CMS content types. Of these, only the Data, - SignedData, EnvelopedData, AuthEnvelopedData, and CompressedData - content types are currently used for S/MIME. - - - -Schaad, et al. Standards Track [Page 13] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -2.4.1. Data Content Type - - Sending agents MUST use the id-data content type identifier to - identify the "inner" MIME message content. For example, when - applying a digital signature to MIME data, the CMS SignedData - encapContentInfo eContentType MUST include the id-data object - identifier (OID), and the media type MUST be stored in the SignedData - encapContentInfo eContent OCTET STRING (unless the sending agent is - using multipart/signed, in which case the eContent is absent, per - Section 3.5.3 of this document). As another example, when applying - encryption to MIME data, the CMS EnvelopedData encryptedContentInfo - contentType MUST include the id-data OID and the encrypted MIME - content MUST be stored in the EnvelopedData encryptedContentInfo - encryptedContent OCTET STRING. - -2.4.2. SignedData Content Type - - Sending agents MUST use the SignedData content type to apply a - digital signature to a message or, in a degenerate case where there - is no signature information, to convey certificates. Applying a - signature to a message provides authentication, message integrity, - and non-repudiation of origin. - -2.4.3. EnvelopedData Content Type - - This content type is used to apply data confidentiality to a message. - In order to distribute the symmetric key, a sender needs to have - access to a public key for each intended message recipient to use - this service. - -2.4.4. AuthEnvelopedData Content Type - - This content type is used to apply data confidentiality and message - integrity to a message. This content type does not provide - authentication or non-repudiation. In order to distribute the - symmetric key, a sender needs to have access to a public key for each - intended message recipient to use this service. - -2.4.5. CompressedData Content Type - - This content type is used to apply data compression to a message. - This content type does not provide authentication, message integrity, - non-repudiation, or data confidentiality; it is only used to reduce - the message's size. - - See Section 3.7 for further guidance on the use of this type in - conjunction with other CMS types. - - - - -Schaad, et al. Standards Track [Page 14] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -2.5. Attributes and the SignerInfo Type - - The SignerInfo type allows the inclusion of unsigned and signed - attributes along with a signature. These attributes can be required - for the processing of messages (e.g., message digest), information - the signer supplied (e.g., SMIME capabilities) that should be - processed, or attributes that are not relevant to the current - situation (e.g., mlExpansionHistory [RFC2634] for mail viewers). - - Receiving agents MUST be able to handle zero or one instance of each - of the signed attributes listed here. Sending agents SHOULD generate - one instance of each of the following signed attributes in each - S/MIME message: - - - Signing time (Section 2.5.1 in this document) - - - SMIME capabilities (Section 2.5.2 in this document) - - - Encryption key Preference (Section 2.5.3 in this document) - - - Message digest (Section 11.2 in [RFC5652]) - - - Content type (Section 11.1 in [RFC5652]) - - Further, receiving agents SHOULD be able to handle zero or one - instance of the signingCertificate and signingCertificateV2 signed - attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3 - of RFC 5035 [ESS], respectively. - - Sending agents SHOULD generate one instance of the signingCertificate - or signingCertificateV2 signed attribute in each SignerInfo - structure. - - Additional attributes and values for these attributes might be - defined in the future. Receiving agents SHOULD handle attributes or - values that they do not recognize in a graceful manner. - - Interactive sending agents that include signed attributes that are - not listed here SHOULD display those attributes to the user, so that - the user is aware of all of the data being signed. - -2.5.1. Signing Time Attribute - - The signingTime attribute is used to convey the time that a message - was signed. The time of signing will most likely be created by a - signer and therefore is only as trustworthy as that signer. - - - - - -Schaad, et al. Standards Track [Page 15] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - Sending agents MUST encode signing time through the year 2049 as - UTCTime; signing times in 2050 or later MUST be encoded as - GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST - interpret the year field (YY) as follows: - - If YY is greater than or equal to 50, the year is interpreted as - 19YY; if YY is less than 50, the year is interpreted as 20YY. - - Receiving agents MUST be able to process signingTime attributes that - are encoded in either UTCTime or GeneralizedTime. - -2.5.2. SMIMECapabilities Attribute - - The SMIMECapabilities attribute includes signature algorithms (such - as "sha256WithRSAEncryption"), symmetric algorithms (such as "AES-128 - CBC"), authenticated symmetric algorithms (such as "AES-128 GCM"), - and key encipherment algorithms (such as "rsaEncryption"). The - presence of an SMIMECapability attribute containing an algorithm - implies that the sender can deal with the algorithm as well as - understand the ASN.1 structures associated with that algorithm. - There are also several identifiers that indicate support for other - optional features such as binary encoding and compression. The - SMIMECapabilities attribute was designed to be flexible and - extensible so that, in the future, a means of identifying other - capabilities and preferences such as certificates can be added in a - way that will not cause current clients to break. - - If present, the SMIMECapabilities attribute MUST be a - SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. - The SignedAttributes in a signerInfo MUST include a single instance - of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for - Attribute to include attrValues SET OF AttributeValue. An - SMIMECapabilities attribute MUST only include a single instance of - AttributeValue. If a signature is detected as violating these - requirements, the signature SHOULD be treated as failing. - - The semantics of the SMIMECapabilities attribute specify a partial - list as to what the client announcing the SMIMECapabilities can - support. A client does not have to list every capability it - supports, and it need not list all its capabilities so that the - capabilities list doesn't get too long. In an SMIMECapabilities - attribute, the OIDs are listed in order of their preference but - SHOULD be separated logically along the lines of their categories - (signature algorithms, symmetric algorithms, key encipherment - algorithms, etc.). - - - - - - -Schaad, et al. Standards Track [Page 16] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - The structure of the SMIMECapabilities attribute is to facilitate - simple table lookups and binary comparisons in order to determine - matches. For instance, the encoding for the SMIMECapability for - sha256WithRSAEncryption includes rather than omits the NULL - parameter. Because of the requirement for identical encoding, - individuals documenting algorithms to be used in the - SMIMECapabilities attribute SHOULD explicitly document the correct - byte sequence for the common cases. - - For any capability, the associated parameters for the OID MUST - specify all of the parameters necessary to differentiate between two - instances of the same algorithm. - - The same OID that is used to identify an algorithm SHOULD also be - used in the SMIMECapability for that algorithm. There are cases - where a single OID can correspond to multiple algorithms. In these - cases, a single algorithm MUST be assigned to the SMIMECapability - using that OID. Additional OIDs from the smimeCapabilities OID tree - are then allocated for the other algorithms usages. For instance, in - an earlier specification, rsaEncryption was ambiguous because it - could refer to either a signature algorithm or a key encipherment - algorithm. In the event that an OID is ambiguous, it needs to be - arbitrated by the maintainer of the registered SMIMECapabilities list - as to which type of algorithm will use the OID, and a new OID MUST be - allocated under the smimeCapabilities OID to satisfy the other use of - the OID. - - The registered SMIMECapabilities list specifies the parameters for - OIDs that need them, most notably key lengths in the case of - variable-length symmetric ciphers. In the event that there are no - differentiating parameters for a particular OID, the parameters MUST - be omitted and MUST NOT be encoded as NULL. Additional values for - the SMIMECapabilities attribute might be defined in the future. - Receiving agents MUST handle an SMIMECapabilities object that has - values that it does not recognize in a graceful manner. - - Section 2.7.1 explains a strategy for caching capabilities. - -2.5.3. Encryption Key Preference Attribute - - The encryption key preference attribute allows the signer to - unambiguously describe which of the signer's certificates has the - signer's preferred encryption key. This attribute is designed to - enhance behavior for interoperating with those clients that use - separate keys for encryption and signing. This attribute is used to - convey to anyone viewing the attribute which of the listed - certificates is appropriate for encrypting a session key for future - encrypted messages. - - - -Schaad, et al. Standards Track [Page 17] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - If present, the SMIMEEncryptionKeyPreference attribute MUST be a - SignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. - The SignedAttributes in a signerInfo MUST include a single instance - of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 - syntax for Attribute to include attrValues SET OF AttributeValue. An - SMIMEEncryptionKeyPreference attribute MUST only include a single - instance of AttributeValue. If a signature is detected as violating - these requirements, the signature SHOULD be treated as failing. - - The sending agent SHOULD include the referenced certificate in the - set of certificates included in the signed message if this attribute - is used. The certificate MAY be omitted if it has been previously - made available to the receiving agent. Sending agents SHOULD use - this attribute if the commonly used or preferred encryption - certificate is not the same as the certificate used to sign the - message. - - Receiving agents SHOULD store the preference data if the signature on - the message is valid and the signing time is greater than the - currently stored value. (As with the SMIMECapabilities, the clock - skew SHOULD be checked and the data not used if the skew is too - great.) Receiving agents SHOULD respect the sender's encryption key - preference attribute if possible. This, however, represents only a - preference, and the receiving agent can use any certificate in - replying to the sender that is valid. - - Section 2.7.1 explains a strategy for caching preference data. - -2.5.3.1. Selection of Recipient Key Management Certificate - - In order to determine the key management certificate to be used when - sending a future CMS EnvelopedData message for a particular - recipient, the following steps SHOULD be followed: - - - If an SMIMEEncryptionKeyPreference attribute is found in a - SignedData object received from the desired recipient, this - identifies the X.509 certificate that SHOULD be used as the X.509 - key management certificate for the recipient. - - - If an SMIMEEncryptionKeyPreference attribute is not found in a - SignedData object received from the desired recipient, the set of - X.509 certificates SHOULD be searched for an X.509 certificate - with the same subject name as the signer of an X.509 certificate - that can be used for key management. - - - - - - - -Schaad, et al. Standards Track [Page 18] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - Or, use some other method of determining the user's key management - key. If an X.509 key management certificate is not found, then - encryption cannot be done with the signer of the message. If - multiple X.509 key management certificates are found, the S/MIME - agent can make an arbitrary choice between them. - -2.6. SignerIdentifier SignerInfo Type - - S/MIME v4.0 implementations MUST support both issuerAndSerialNumber - and subjectKeyIdentifier. Messages that use the subjectKeyIdentifier - choice cannot be read by S/MIME v2 clients. - - It is important to understand that some certificates use a value for - subjectKeyIdentifier that is not suitable for uniquely identifying a - certificate. Implementations MUST be prepared for multiple - certificates for potentially different entities to have the same - value for subjectKeyIdentifier and MUST be prepared to try each - matching certificate during signature verification before indicating - an error condition. - -2.7. ContentEncryptionAlgorithmIdentifier - - Sending and receiving agents: - - - MUST support encryption and decryption with AES-128 GCM and - AES-256 GCM [RFC5084]. - - - MUST- support encryption and decryption with AES-128 CBC - [RFC3565]. - - - SHOULD+ support encryption and decryption with ChaCha20-Poly1305 - [RFC7905]. - -2.7.1. Deciding Which Encryption Method to Use - - When a sending agent creates an encrypted message, it has to decide - which type of encryption to use. The decision process involves using - information garnered from the capabilities lists included in messages - received from the recipient, as well as out-of-band information such - as private agreements, user preferences, legal restrictions, and - so on. - - Section 2.5.2 defines a method by which a sending agent can - optionally announce, among other things, its decrypting capabilities - in its order of preference. The following method for processing and - remembering the encryption capabilities attribute in incoming signed - messages SHOULD be used. - - - - -Schaad, et al. Standards Track [Page 19] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - If the receiving agent has not yet created a list of capabilities - for the sender's public key, then, after verifying the signature - on the incoming message and checking the timestamp, the receiving - agent SHOULD create a new list containing at least the signing - time and the symmetric capabilities. - - - If such a list already exists, the receiving agent SHOULD verify - that the signing time in the incoming message is greater than the - signing time stored in the list and that the signature is valid. - If so, the receiving agent SHOULD update both the signing time and - capabilities in the list. Values of the signing time that lie far - in the future (that is, a greater discrepancy than any reasonable - clock skew), or a capabilities list in messages whose signature - could not be verified, MUST NOT be accepted. - - The list of capabilities SHOULD be stored for future use in creating - messages. - - Before sending a message, the sending agent MUST decide whether it is - willing to use weak encryption for the particular data in the - message. If the sending agent decides that weak encryption is - unacceptable for this data, then the sending agent MUST NOT use a - weak algorithm. The decision to use or not use weak encryption - overrides any other decision in this section about which encryption - algorithm to use. - - Sections 2.7.1.1 and 2.7.1.2 describe the decisions a sending agent - SHOULD use when choosing which type of encryption will be applied to - a message. These rules are ordered, so the sending agent SHOULD make - its decision in the order given. - -2.7.1.1. Rule 1: Known Capabilities - - If the sending agent has received a set of capabilities from the - recipient for the message the agent is about to encrypt, then the - sending agent SHOULD use that information by selecting the first - capability in the list (that is, the capability most preferred by the - intended recipient) that the sending agent knows how to encrypt. The - sending agent SHOULD use one of the capabilities in the list if the - agent reasonably expects the recipient to be able to decrypt the - message. - -2.7.1.2. Rule 2: Unknown Capabilities, Unknown Version of S/MIME - - If the following two conditions are met, the sending agent SHOULD use - AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required - by S/MIME v4.0: - - - - -Schaad, et al. Standards Track [Page 20] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - The sending agent has no knowledge of the encryption capabilities - of the recipient. - - - The sending agent has no knowledge of the version of S/MIME used - or supported by the recipient. - - If the sending agent chooses not to use AES-256 GCM in this step, - given the presumption is that a client implementing AES-GCM would do - both AES-256 and AES-128, it SHOULD use AES-128 CBC. - -2.7.2. Choosing Weak Encryption - - Algorithms such as RC2 are considered to be weak encryption - algorithms. Algorithms such as TripleDES are not state of the art - and are considered to be weaker algorithms than AES. A sending agent - that is controlled by a human SHOULD allow a human sender to - determine the risks of sending data using a weaker encryption - algorithm before sending the data, and possibly allow the human to - use a stronger encryption algorithm such as AES GCM or AES CBC even - if there is a possibility that the recipient will not be able to - process that algorithm. - -2.7.3. Multiple Recipients - - If a sending agent is composing an encrypted message to a group of - recipients where the encryption capabilities of some of the - recipients do not overlap, the sending agent is forced to send more - than one message. Please note that if the sending agent chooses to - send a message encrypted with a strong algorithm and then send the - same message encrypted with a weak algorithm, someone watching the - communications channel could learn the contents of the strongly - encrypted message simply by decrypting the weakly encrypted message. - -3. Creating S/MIME Messages - - This section describes the S/MIME message formats and how they are - created. S/MIME messages are a combination of MIME bodies and CMS - content types. Several media types as well as several CMS content - types are used. The data to be secured is always a canonical MIME - entity. The MIME entity and other data, such as certificates and - algorithm identifiers, are given to CMS processing facilities that - produce a CMS object. Finally, the CMS object is wrapped in MIME. - The "Enhanced Security Services for S/MIME" documents [ESS] provide - descriptions of how nested, secured S/MIME messages are formatted. - ESS provides a description of how a triple-wrapped S/MIME message is - formatted using multipart/signed and application/pkcs7-mime for the - signatures. - - - - -Schaad, et al. Standards Track [Page 21] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - S/MIME provides one format for enveloped-only data, several formats - for signed-only data, and several formats for signed and enveloped - data. Several formats are required to accommodate several - environments -- in particular, for signed messages. The criteria for - choosing among these formats are also described. - - Anyone reading this section is expected to understand MIME as - described in [MIME-SPEC] and [RFC1847]. - -3.1. Preparing the MIME Entity for Signing, Enveloping, or Compressing - - S/MIME is used to secure MIME entities. A MIME message is composed - of a MIME header and a MIME body. A body can consist of a single - MIME entity or a tree of MIME entities (rooted with a multipart). - S/MIME can be used to secure either a single MIME entity or a tree of - MIME entities. These entities can be in locations other than the - root. S/MIME can be applied multiple times to different entities in - a single message. A MIME entity that is the whole message includes - only the MIME message headers and MIME body and does not include the - rfc822 header. Note that S/MIME can also be used to secure MIME - entities used in applications other than Internet mail. For cases - where protection of the rfc822 header is required, the use of the - message/rfc822 media type is explained later in this section. - - The MIME entity that is secured and described in this section can be - thought of as the "inside" MIME entity. That is, it is the - "innermost" object in what is possibly a larger MIME message. - Processing "outside" MIME entities into CMS EnvelopedData, - CompressedData, and AuthEnvelopedData content types is described in - Sections 3.2 and 3.5. Other documents define additional CMS content - types; those documents should be consulted for processing those CMS - content types. - - The procedure for preparing a MIME entity is given in [MIME-SPEC]. - The same procedure is used here with some additional restrictions - when signing. The description of the procedures from [MIME-SPEC] is - repeated here, but it is suggested that the reader refer to those - documents for the exact procedures. This section also describes - additional requirements. - - A single procedure is used for creating MIME entities that are to - have any combination of signing, enveloping, and compressing applied. - Some additional steps are recommended to defend against known - corruptions that can occur during mail transport that are of - particular importance for clear-signing using the multipart/signed - format. It is recommended that these additional steps be performed - on enveloped messages, or signed and enveloped messages, so that the - messages can be forwarded to any environment without modification. - - - -Schaad, et al. Standards Track [Page 22] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - These steps are descriptive rather than prescriptive. The - implementer is free to use any procedure as long as the result is - the same. - - Step 1. The MIME entity is prepared according to local conventions. - - Step 2. The leaf parts of the MIME entity are converted to - canonical form. - - Step 3. Appropriate transfer encoding is applied to the leaves - of the MIME entity. - - When an S/MIME message is received, the security services on the - message are processed, and the result is the MIME entity. That MIME - entity is typically passed to a MIME-capable user agent where it is - further decoded and presented to the user or receiving application. - - In order to protect outer, non-content-related message header fields - (for instance, the "Subject", "To", "From", and "Cc" fields), the - sending client MAY wrap a full MIME message in a message/rfc822 - wrapper in order to apply S/MIME security services to these header - fields. It is up to the receiving client to decide how to present - this "inner" header along with the unprotected "outer" header. Given - the security difference between headers, it is RECOMMENDED that the - receiving client provide a distinction between header fields, - depending on where they are located. - - When an S/MIME message is received, if the top-level protected MIME - entity has a Content-Type of message/rfc822, it can be assumed that - the intent was to provide header protection. This entity SHOULD be - presented as the top-level message, taking into account - header-merging issues as previously discussed. - -3.1.1. Canonicalization - - Each MIME entity MUST be converted to a canonical form that is - uniquely and unambiguously representable in the environment where the - signature is created and the environment where the signature will be - verified. MIME entities MUST be canonicalized for enveloping and - compressing as well as signing. - - The exact details of canonicalization depend on the actual media type - and subtype of an entity and are not described here. Instead, the - standard for the particular media type SHOULD be consulted. For - example, canonicalization of type text/plain is different from - canonicalization of audio/basic. Other than text types, most types - have only one representation, regardless of computing platform or - environment, that can be considered their canonical representation. - - - -Schaad, et al. Standards Track [Page 23] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - In general, canonicalization will be performed by the non-security - part of the sending agent rather than the S/MIME implementation. - - The most common and important canonicalization is for text, which is - often represented differently in different environments. MIME - entities of major type "text" MUST have both their line endings and - character set canonicalized. The line ending MUST be the pair of - characters , and the charset SHOULD be a registered charset - [CHARSETS]. The details of the canonicalization are specified in - [MIME-SPEC]. - - Note that some charsets such as ISO-2022 have multiple - representations for the same characters. When preparing such text - for signing, the canonical representation specified for the charset - MUST be used. - -3.1.2. Transfer Encoding - - When generating any of the secured MIME entities below, except the - signing using the multipart/signed format, no transfer encoding is - required at all. S/MIME implementations MUST be able to deal with - binary MIME objects. If no Content-Transfer-Encoding header field is - present, the transfer encoding is presumed to be 7BIT. - - As a rule, S/MIME implementations SHOULD use transfer encoding as - described in Section 3.1.3 for all MIME entities they secure. The - reason for securing only 7-bit MIME entities, even for enveloped data - that is not exposed to the transport, is that it allows the MIME - entity to be handled in any environment without changing it. For - example, a trusted gateway might remove the envelope, but not the - signature, of a message, and then forward the signed message on to - the end recipient so that they can verify the signatures directly. - If the transport internal to the site is not 8-bit clean, such as on - a wide-area network with a single mail gateway, verifying the - signature will not be possible unless the original MIME entity was - only 7-bit data. - - In the case where S/MIME implementations can determine that all - intended recipients are capable of handling inner (all but the - outermost) binary MIME objects, implementations SHOULD use binary - encoding as opposed to a 7-bit-safe transfer encoding for the inner - entities. The use of a 7-bit-safe encoding (such as base64) - unnecessarily expands the message size. Implementations MAY - determine that recipient implementations are capable of - handling inner binary MIME entities by (1) interpreting the - id-cap-preferBinaryInside SMIMECapabilities attribute, (2) prior - agreement, or (3) other means. - - - - -Schaad, et al. Standards Track [Page 24] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - If one or more intended recipients are unable to handle inner binary - MIME objects or if this capability is unknown for any of the intended - recipients, S/MIME implementations SHOULD use transfer encoding as - described in Section 3.1.3 for all MIME entities they secure. - -3.1.3. Transfer Encoding for Signing Using multipart/signed - - If a multipart/signed entity is ever to be transmitted over the - standard Internet SMTP infrastructure or other transport that is - constrained to 7-bit text, it MUST have transfer encoding applied so - that it is represented as 7-bit text. MIME entities that are already - 7-bit data need no transfer encoding. Entities such as 8-bit text - and binary data can be encoded with quoted-printable or base64 - transfer encoding. - - The primary reason for the 7-bit requirement is that the Internet - mail transport infrastructure cannot guarantee transport of 8-bit or - binary data. Even though many segments of the transport - infrastructure now handle 8-bit and even binary data, it is sometimes - not possible to know whether the transport path is 8-bit clean. If a - mail message with 8-bit data were to encounter a message transfer - agent that cannot transmit 8-bit or binary data, the agent has three - options, none of which are acceptable for a clear-signed message: - - - The agent could change the transfer encoding; this would - invalidate the signature. - - - The agent could transmit the data anyway, which would most likely - result in the 8th bit being corrupted; this too would invalidate - the signature. - - - The agent could return the message to the sender. - - [RFC1847] prohibits an agent from changing the transfer encoding of - the first part of a multipart/signed message. If a compliant agent - that cannot transmit 8-bit or binary data encountered a - multipart/signed message with 8-bit or binary data in the first part, - it would have to return the message to the sender as undeliverable. - -3.1.4. Sample Canonical MIME Entity - - This example shows a multipart/mixed message with full transfer - encoding. This message contains a text part and an attachment. The - sample message text includes characters that are not ASCII and thus - need to be transfer encoded. Though not shown here, the end of each - line is . The line ending of the MIME headers, the text, and - the transfer-encoded parts all MUST be . - - - - -Schaad, et al. Standards Track [Page 25] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - Note that this example is not an example of an S/MIME message. - - Content-Type: multipart/mixed; boundary=bar - - --bar - Content-Type: text/plain; charset=iso-8859-1 - Content-Transfer-Encoding: quoted-printable - - =A1Hola Michael! - - How do you like the new S/MIME specification? - - It's generally a good idea to encode lines that begin with - From=20because some mail transport agents will insert a - greater-than (>) sign, thus invalidating the signature. - - Also, in some cases it might be desirable to encode any =20 - trailing whitespace that occurs on lines in order to ensure =20 - that the message signature is not invalidated when passing =20 - a gateway that modifies such whitespace (like BITNET). =20 - - --bar - Content-Type: image/jpeg - Content-Transfer-Encoding: base64 - - iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// - jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq - uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn - HOxEa44b+EI= - - --bar-- - -3.2. The application/pkcs7-mime Media Type - - The application/pkcs7-mime media type is used to carry CMS content - types, including EnvelopedData, SignedData, and CompressedData. The - details of constructing these entities are described in subsequent - sections. This section describes the general characteristics of the - application/pkcs7-mime media type. - - The carried CMS object always contains a MIME entity that is prepared - as described in Section 3.1 if the eContentType is id-data. Other - contents MAY be carried when the eContentType contains different - values. See [ESS] for an example of this with signed receipts. - - Since CMS content types are binary data, in most cases base64 - transfer encoding is appropriate -- in particular, when used with - SMTP transport. The transfer encoding used depends on the transport - - - -Schaad, et al. Standards Track [Page 26] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - through which the object is to be sent and is not a characteristic of - the media type. - - Note that this discussion refers to the transfer encoding of the CMS - object or "outside" MIME entity. It is completely distinct from, and - unrelated to, the transfer encoding of the MIME entity secured by the - CMS object -- the "inside" object, which is described in Section 3.1. - - Because there are several types of application/pkcs7-mime objects, a - sending agent SHOULD do as much as possible to help a receiving agent - know about the contents of the object without forcing the receiving - agent to decode the ASN.1 for the object. The Content-Type header - field of all application/pkcs7-mime objects SHOULD include the - optional "smime-type" parameter, as described in the following - sections. - -3.2.1. The name and filename Parameters - - For application/pkcs7-mime, sending agents SHOULD emit the - optional "name" parameter to the Content-Type field for compatibility - with older systems. Sending agents SHOULD also emit the optional - Content-Disposition field [RFC2183] with the "filename" parameter. - If a sending agent emits the above parameters, the value of the - parameters SHOULD be a filename with the appropriate extension: - - File - Media Type Extension - ------------------------------------------------------------------- - application/pkcs7-mime (SignedData, EnvelopedData, .p7m - AuthEnvelopedData) - application/pkcs7-mime (degenerate SignedData certificate .p7c - management message) - application/pkcs7-mime (CompressedData) .p7z - application/pkcs7-signature (SignedData) .p7s - - In addition, the filename SHOULD be limited to eight characters - followed by a three-letter extension. The eight-character filename - base can be any distinct name; the use of the filename base "smime" - SHOULD be used to indicate that the MIME entity is associated with - S/MIME. - - Including a filename serves two purposes. It facilitates easier use - of S/MIME objects as files on disk. It also can convey type - information across gateways. When a MIME entity of type - application/pkcs7-mime (for example) arrives at a gateway that has no - special knowledge of S/MIME, it will default the entity's media type - to application/octet-stream and treat it as a generic attachment, - thus losing the type information. However, the suggested filename - - - -Schaad, et al. Standards Track [Page 27] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - for an attachment is often carried across a gateway. This often - allows the receiving systems to determine the appropriate application - to hand the attachment off to -- in this case, a standalone S/MIME - processing application. Note that this mechanism is provided as a - convenience for implementations in certain environments. A proper - S/MIME implementation MUST use the media types and MUST NOT rely on - the file extensions. - -3.2.2. The smime-type Parameter - - The application/pkcs7-mime content type defines the optional - "smime-type" parameter. The intent of this parameter is to convey - details about the security applied (signed or enveloped) along with - information about the contained content. This specification defines - the following smime-types. - - Name CMS Type Inner Content - ---------------------------------------------------------- - enveloped-data EnvelopedData id-data - signed-data SignedData id-data - certs-only SignedData id-data - compressed-data CompressedData id-data - authEnveloped-data AuthEnvelopedData id-data - - In order for consistency to be obtained with future specifications, - the following guidelines SHOULD be followed when assigning a new - smime-type parameter. - - 1. If both signing and encryption can be applied to the content, - then three values for smime-type SHOULD be assigned: "signed-*", - "authEnv-*", and "enveloped-*". If one operation can be - assigned, then this can be omitted. Thus, since "certs-only" can - only be signed, "signed-" is omitted. - - 2. A common string for a content OID SHOULD be assigned. We use - "data" for the id-data content OID when MIME is the inner - content. - - 3. If no common string is assigned, then the common string of - "OID." is recommended (for example, - "OID.2.16.840.1.101.3.4.1.2" would be AES-128 CBC). - - It is explicitly intended that this field be a suitable hint for mail - client applications to indicate whether a message is "signed", - "authEnveloped", or "enveloped" without having to tunnel into the CMS - payload. - - - - - -Schaad, et al. Standards Track [Page 28] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - A registry for additional smime-type parameter values has been - defined in [RFC7114]. - -3.3. Creating an Enveloped-Only Message - - This section describes the format for enveloping a MIME entity - without signing it. It is important to note that sending enveloped - but not signed messages does not provide for data integrity. The - "enveloped-only" structure does not support authenticated symmetric - algorithms. Use the "authenticated enveloped" structure for these - algorithms. Thus, it is possible to replace ciphertext in such a way - that the processed message will still be valid, but the meaning can - be altered. - - Step 1. The MIME entity to be enveloped is prepared according to - Section 3.1. - - Step 2. The MIME entity and other required data are processed into a - CMS object of type EnvelopedData. In addition to encrypting - a copy of the content-encryption key (CEK) for each - recipient, a copy of the CEK SHOULD be encrypted for the - originator and included in the EnvelopedData (see [RFC5652], - Section 6). - - Step 3. The EnvelopedData object is wrapped in a CMS ContentInfo - object. - - Step 4. The ContentInfo object is inserted into an - application/pkcs7-mime MIME entity. - - The smime-type parameter for enveloped-only messages is - "enveloped-data". The file extension for this type of message - is ".p7m". - - A sample message would be: - - Content-Type: application/pkcs7-mime; name=smime.p7m; - smime-type=enveloped-data - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7m - - MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEw - dDYXJsUlNBAhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAC3EN5nGI - iJi2lsGPcP2iJ97a4e8kbKQz36zg6Z2i0yx6zYC4mZ7mX7FBs3IWg+f6KgCLx3M1eC - bWx8+MDFbbpXadCDgO8/nUkUNYeNxJtuzubGgzoyEd8Ch4H/dd9gdzTd+taTEgS0ip - dSJuNnkVY4/M652jKKHRLFf02hosdR8wQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBA - gtaMXpRwZRNYAgDsiSf8Z9P43LrY4OxUk660cu1lXeCSFOSOpOJ7FuVyU= - - - - -Schaad, et al. Standards Track [Page 29] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -3.4. Creating an Authenticated Enveloped-Only Message - - This section describes the format for enveloping a MIME entity - without signing it. Authenticated enveloped messages provide - confidentiality and data integrity. It is important to note that - sending authenticated enveloped messages does not provide for proof - of origination when using S/MIME. It is possible for a third party - to replace ciphertext in such a way that the processed message will - still be valid, but the meaning can be altered. However, this is - substantially more difficult than it is for an enveloped-only - message, as the algorithm does provide a level of authentication. - Any recipient for whom the message is encrypted can replace it - without detection. - - Step 1. The MIME entity to be enveloped is prepared according to - Section 3.1. - - Step 2. The MIME entity and other required data are processed into a - CMS object of type AuthEnvelopedData. In addition to - encrypting a copy of the CEK for each recipient, a copy of - the CEK SHOULD be encrypted for the originator and included - in the AuthEnvelopedData (see [RFC5083]). - - Step 3. The AuthEnvelopedData object is wrapped in a CMS ContentInfo - object. - - Step 4. The ContentInfo object is inserted into an - application/pkcs7-mime MIME entity. - - The smime-type parameter for authenticated enveloped-only messages is - "authEnveloped-data". The file extension for this type of message - is ".p7m". - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 30] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - A sample message would be: - - Content-Type: application/pkcs7-mime; smime-type=authEnveloped-data; - name=smime.p7m - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7m - - MIIDWQYLKoZIhvcNAQkQARegggNIMIIDRAIBADGBvjCBuwIBADAmMBIxEDAO - BgNVBAMTB0NhcmxSU0ECEEY0a8eAAFa8EdNuLs1dcdAwCwYJKoZIhvcNAQEB - BIGAgyZJo0ERTxA4xdTri5P5tVMyh0RARepTUCORZvlUbcUlaI8IpJZH3/J1 - Fv6MxTRS4O/K+ZcTlQmYeWLQvwdltQdOIP3mhpqXzTnOYhTK1IDtF2zx75Lg - vE+ilpcLIzXfJB4RCBPtBWaHAof4Wb+VMQvLkk9OolX4mRSH1LPktgAwggJq - BgkqhkiG9w0BBwEwGwYJYIZIAWUDBAEGMA4EDGPizioC9OHSsnNx4oCCAj7Y - Cb8rOy8+55106newEJohC/aDgWbJhrMKzSOwa7JraXOV3HXD3NvKbl665dRx - vmDwSCNaLCRU5q8/AxQx2SvnAbM+JKcEfC/VFdd4SiHNiUECAApLku2rMi5B - WrhW/FXmx9d+cjum2BRwB3wj0q1wajdB0/kVRbQwg697dnlYyUog4vpJERjr - 7KAkawZx1RMHaM18wgZjUNpCBXFS3chQi9mTBp2i2Hf5iZ8OOtTx+rCQUmI6 - Jhy03vdcPCCARBjn3v0d3upZYDZddMA41CB9fKnnWFjadV1KpYwv80tqsEfx - Vo0lJQ5VtJ8MHJiBpLVKadRIZ4iH2ULC0JtN5mXE1SrFKh7cqbJ4+7nqSRL3 - oBTud3rX41DGshOjpqcYHT4sqYlgZkc6dp0g1+hF1p3cGmjHdpysV2NVSUev - ghHbvSqhIsXFzRSWKiZOigmlkv3R5LnjpYyP4brM62Jl7y0qborvV4dNMz7m - D+5YxSlH0KAe8z6TT3LHuQdN7QCkFoiUSCaNhpAFaakkGIpqcqLhpOK4lXxt - kptCG93eUwNCcTxtx6bXufPR5TUHohvZvfeqMp42kL37FJC/A8ZHoOxXy8+X - X5QYxCQNuofWlvnIWv0Nr8w65x6lgVjPYmd/cHwzQKBTBMXN6pBud/PZL5zF - tw3QHlQkBR+UflMWZKeN9L0KdQ27mQlCo5gQS85aifxoiiA2v9+0hxZw91rP - IW4D+GS7oMMoKj8ZNyCJJsyf5smRZ+WxeBoolb3+TiGcBBCsRnfe6noLZiFO - 6Zeu2ZwE - -3.5. Creating a Signed-Only Message - - There are two formats for signed messages defined for S/MIME: - - - application/pkcs7-mime with SignedData. - - - multipart/signed. - - In general, the multipart/signed form is preferred for sending, and - receiving agents MUST be able to handle both. - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 31] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -3.5.1. Choosing a Format for Signed-Only Messages - - There are no hard-and-fast rules as to when a particular signed-only - format is chosen. It depends on the capabilities of all the - receivers and the relative importance of receivers with S/MIME - facilities being able to verify the signature versus the importance - of receivers without S/MIME software being able to view the message. - - Messages signed using the multipart/signed format can always be - viewed by the receiver whether or not they have S/MIME software. - They can also be viewed whether they are using a MIME-native user - agent or they have messages translated by a gateway. In this - context, "be viewed" means the ability to process the message - essentially as if it were not a signed message, including any other - MIME structure the message might have. - - Messages signed using the SignedData format cannot be viewed by a - recipient unless they have S/MIME facilities. However, the - SignedData format protects the message content from being changed by - benign intermediate agents. Such agents might do line wrapping or - content-transfer encoding changes that would break the signature. - -3.5.2. Signing Using application/pkcs7-mime with SignedData - - This signing format uses the application/pkcs7-mime media type. The - steps to create this format are as follows: - - Step 1. The MIME entity is prepared according to Section 3.1. - - Step 2. The MIME entity and other required data are processed into a - CMS object of type SignedData. - - Step 3. The SignedData object is wrapped in a CMS ContentInfo - object. - - Step 4. The ContentInfo object is inserted into an - application/pkcs7-mime MIME entity. - - The smime-type parameter for messages using application/pkcs7-mime - with SignedData is "signed-data". The file extension for this type - of message is ".p7m". - - - - - - - - - - -Schaad, et al. Standards Track [Page 32] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - A sample message would be: - - Content-Type: application/pkcs7-mime; smime-type=signed-data; - name=smime.p7m - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7m - - MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjAtBgkqhkiG9w0BBw - GgIAQeDQpUaGlzIGlzIHNvbWUgc2FtcGxlIGNvbnRlbnQuoIIC4DCCAtwwggKboAMC - AQICAgDIMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMT - EwNDlaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsG - ByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij5EeT3Q7XqA7sU8WrhAhP/5Thc0 - h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiVm96nXvn89J8v3UOo - i1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvbAhUA4k - emGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDD - HlBd3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dow - fNI4W4LzABfG1JiRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2 - OQOBhAACgYBc47ladRSWC6l63eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+ - VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbOBoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxi - rGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL08oPluKOBgTB/MAwGA1UdEw - EB/wQCMAAwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0g - vEMrk/EfMB0GA1UdDgQWBBS+bKGz48H37UNwpM4TAeL945f+zTAfBgNVHREEGDAWgR - RBbGljZURTU0BleGFtcGxlLmNvbTAJBgcqhkjOOAQDAzAAMC0CFFUMpBkfQiuJcSIz - jYNqtT1na79FAhUAn2FTUlQLXLLd2ud2HeIQUltDXr0xYzBhAgEBMBgwEjEQMA4GA1 - UEAxMHQ2FybERTUwICAMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFD1cSW6LIUFz - eXle3YI5SKSBer/sAhQmCq7s/CTFHOEjgASeUjbMpx5g6A== - -3.5.3. Signing Using the multipart/signed Format - - This format is a clear-signing format. Recipients without any S/MIME - or CMS processing facilities are able to view the message. It makes - use of the multipart/signed media type described in [RFC1847]. The - multipart/signed media type has two parts. The first part contains - the MIME entity that is signed; the second part contains the - "detached signature" CMS SignedData object in which the - encapContentInfo eContent field is absent. - -3.5.3.1. The application/pkcs7-signature Media Type - - This media type always contains a CMS ContentInfo containing a single - CMS object of type SignedData. The SignedData encapContentInfo - eContent field MUST be absent. The signerInfos field contains the - signatures for the MIME entity. - - The file extension for signed-only messages using - application/pkcs7-signature is ".p7s". - - - - - -Schaad, et al. Standards Track [Page 33] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -3.5.3.2. Creating a multipart/signed Message - - Step 1. The MIME entity to be signed is prepared according to - Section 3.1, taking special care for clear-signing. - - Step 2. The MIME entity is presented to CMS processing in order to - obtain an object of type SignedData in which the - encapContentInfo eContent field is absent. - - Step 3. The MIME entity is inserted into the first part of a - multipart/signed message with no processing other than that - described in Section 3.1. - - Step 4. Transfer encoding is applied to the "detached signature" CMS - SignedData object, and it is inserted into a MIME entity of - type application/pkcs7-signature. - - Step 5. The MIME entity of the application/pkcs7-signature is - inserted into the second part of the multipart/signed - entity. - - The multipart/signed Content-Type has two required parameters: the - protocol parameter and the micalg parameter. - - The protocol parameter MUST be "application/pkcs7-signature". Note - that quotation marks are required around the protocol parameter - because MIME requires that the "/" character in the parameter value - MUST be quoted. - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 34] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - The micalg parameter allows for one-pass processing when the - signature is being verified. The value of the micalg parameter is - dependent on the message digest algorithm(s) used in the calculation - of the Message Integrity Check. If multiple message digest - algorithms are used, they MUST be separated by commas per [RFC1847]. - The values to be placed in the micalg parameter SHOULD be from the - following: - - Algorithm Value Used - ----------------------------------------------------------- - MD5* md5 - SHA-1* sha-1 - SHA-224 sha-224 - SHA-256 sha-256 - SHA-384 sha-384 - SHA-512 sha-512 - Any other (defined separately in the algorithm profile - or "unknown" if not defined) - - *Note: MD5 and SHA-1 are historical and no longer considered secure. - See Appendix B for details. - - (Historical note: Some early implementations of S/MIME emitted and - expected "rsa-md5", "rsa-sha1", and "sha1" for the micalg parameter.) - Receiving agents SHOULD be able to recover gracefully from a micalg - parameter value that they do not recognize. Future values for this - parameter will be taken from the IANA "Hash Function Textual Names" - registry. - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 35] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -3.5.3.3. Sample multipart/signed Message - - Content-Type: multipart/signed; - micalg=sha-256; - boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21"; - protocol="application/pkcs7-signature" - - This is a multipart message in MIME format. - - ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21 - - This is some sample content. - ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21 - Content-Type: application/pkcs7-signature; name=smime.p7s - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7s - - MIIBJgYJKoZIhvcNAQcCoIIBFzCCARMCAQExADALBgkqhkiG9w0BBwExgf4w - gfsCAQIwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7EELOw - MAsGCWCGSAFlAwQCAaAxMC8GCSqGSIb3DQEJBDEiBCCxwpZGNZzTSsugsn+f - lEidzQK4mf/ozKqfmbxhcIkKqjALBgkqhkiG9w0BAQsEgYB0XJV7fjPa5Nuh - oth5msDfP8A5urYUMjhNpWgXG8ae3XpppqVrPi2nVO41onHnkByjkeD/wc31 - A9WH8MzFQgSTsrJ65JvffTTXkOpRPxsSHn3wJFwP/atWHkh8YK/jR9bULhUl - Mv5jQEDiwVX5DRasxu6Ld8zv9u5/TsdBNiufGw== - - ------=_NextBoundary____Fri,_06_Sep_2002_00:25:21-- - - The content that is digested (the first part of the multipart/signed) - consists of the bytes: - - 54 68 69 73 20 69 73 20 73 6f 6d 65 20 73 61 6d 70 6c 65 20 63 6f 6e - 74 65 6e 74 2e 0d 0a - -3.6. Creating a Compressed-Only Message - - This section describes the format for compressing a MIME entity. - Please note that versions of S/MIME prior to version 3.1 did not - specify any use of CompressedData and will not recognize it. The use - of a capability to indicate the ability to receive CompressedData is - described in [RFC3274] and is the preferred method for compatibility. - - Step 1. The MIME entity to be compressed is prepared according to - Section 3.1. - - Step 2. The MIME entity and other required data are processed into a - CMS object of type CompressedData. - - - - - -Schaad, et al. Standards Track [Page 36] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - Step 3. The CompressedData object is wrapped in a CMS ContentInfo - object. - - Step 4. The ContentInfo object is inserted into an - application/pkcs7-mime MIME entity. - - The smime-type parameter for compressed-only messages is - "compressed-data". The file extension for this type of message - is ".p7z". - - A sample message would be: - - Content-Type: application/pkcs7-mime; smime-type=compressed-data; - name=smime.p7z - Content-Transfer-Encoding: base64 - Content-Disposition: attachment; filename=smime.p7z - - eNoLycgsVgCi4vzcVIXixNyCnFSF5Py8ktS8Ej0AlCkKVA== - -3.7. Multiple Operations - - The signed-only, enveloped-only, and compressed-only MIME formats can - be nested. This works because these formats are all MIME entities - that encapsulate other MIME entities. - - An S/MIME implementation MUST be able to receive and process - arbitrarily nested S/MIME within reasonable resource limits of the - recipient computer. - - It is possible to apply any of the signing, encrypting, and - compressing operations in any order. It is up to the implementer and - the user to choose. When signing first, the signatories are then - securely obscured by the enveloping. When enveloping first, the - signatories are exposed, but it is possible to verify signatures - without removing the enveloping. This can be useful in an - environment where automatic signature verification is desired, as no - private key material is required to verify a signature. - - There are security ramifications related to choosing whether to sign - first or encrypt first. A recipient of a message that is encrypted - and then signed can validate that the encrypted block was unaltered - but cannot determine any relationship between the signer and the - unencrypted contents of the message. A recipient of a message that - is signed and then encrypted can assume that the signed message - itself has not been altered but that a careful attacker could have - changed the unauthenticated portions of the encrypted message. - - - - - -Schaad, et al. Standards Track [Page 37] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - When using compression, keep the following guidelines in mind: - - - Compression of encrypted data that is transferred as binary data - is discouraged, since it will not yield significant compression. - Encrypted data that is transferred as base64-encoded data could - benefit as well. - - - If a lossy compression algorithm is used with signing, you will - need to compress first, then sign. - -3.8. Creating a Certificate Management Message - - The certificate management message or MIME entity is used to - transport certificates and/or Certificate Revocation Lists (CRLs), - such as in response to a registration request. - - Step 1. The certificates and/or CRLs are made available to the CMS - generating process that creates a CMS object of type - SignedData. The SignedData encapContentInfo eContent field - MUST be absent, and the signerInfos field MUST be empty. - - Step 2. The SignedData object is wrapped in a CMS ContentInfo - object. - - Step 3. The ContentInfo object is enclosed in an - application/pkcs7-mime MIME entity. - - The smime-type parameter for a certificate management message is - "certs-only". The file extension for this type of message is ".p7c". - -3.9. Registration Requests - - A sending agent that signs messages MUST have a certificate for the - signature so that a receiving agent can verify the signature. There - are many ways of getting certificates, such as through an exchange - with a certification authority, through a hardware token or diskette, - and so on. - - S/MIME v2 [SMIMEv2] specified a method for "registering" public keys - with certificate authorities using an application/pkcs10 body part. - Since that time, the IETF PKIX Working Group has developed other - methods for requesting certificates. However, S/MIME v4.0 does not - require a particular certificate request mechanism. - - - - - - - - -Schaad, et al. Standards Track [Page 38] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -3.10. Identifying an S/MIME Message - - Because S/MIME takes into account interoperation in non-MIME - environments, several different mechanisms are employed to carry the - type information, and it becomes a bit difficult to identify S/MIME - messages. The following table lists criteria for determining whether - or not a message is an S/MIME message. A message is considered an - S/MIME message if it matches any of the criteria listed below. - - The file suffix in the table below comes from the "name" parameter in - the Content-Type header field or the "filename" parameter in the - Content-Disposition header field. The MIME parameters that carry the - file suffix are not listed below. - - Media Type Parameters File Suffix - --------------------------------------------------------------------- - application/pkcs7-mime N/A N/A - - multipart/signed protocol= N/A - "application/pkcs7-signature" - - application/octet-stream N/A p7m, p7s, - p7c, p7z - -4. Certificate Processing - - A receiving agent MUST provide some certificate retrieval mechanism - in order to gain access to certificates for recipients of digital - envelopes. This specification does not cover how S/MIME agents - handle certificates -- only what they do after a certificate has been - validated or rejected. S/MIME certificate issues are covered in - [RFC5750]. - - At a minimum, for initial S/MIME deployment, a user agent could - automatically generate a message to an intended recipient requesting - that recipient's certificate in a signed return message. Receiving - and sending agents SHOULD also provide a mechanism to allow a user to - "store and protect" certificates for correspondents in such a way as - to guarantee their later retrieval. - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 39] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -4.1. Key Pair Generation - - All key pairs MUST be generated from a good source of - non-deterministic random input [RFC4086], and the private key MUST be - protected in a secure fashion. - - An S/MIME user agent MUST NOT generate asymmetric keys less than - 2048 bits for use with an RSA signature algorithm. - - For 2048-bit through 4096-bit RSA with SHA-256, see [RFC5754] and - [FIPS186-4]. The first reference provides the signature algorithm's - OID, and the second provides the signature algorithm's definition. - - For RSASSA-PSS with SHA-256, see [RFC4056]. For RSAES-OAEP, see - [RFC3560]. - -4.2. Signature Generation - - The following are the requirements for an S/MIME agent when - generating RSA and RSASSA-PSS signatures: - - key size <= 2047 : SHOULD NOT (Note 2) - 2048 <= key size <= 4096 : SHOULD (Note 1) - 4096 < key size : MAY (Note 1) - - Note 1: See Security Considerations in Section 6. - Note 2: See Historical Mail Considerations in Appendix B. - - Key sizes for ECDSA and EdDSA are fixed by the curve. - -4.3. Signature Verification - - The following are the requirements for S/MIME receiving agents during - verification of RSA and RSASSA-PSS signatures: - - key size <= 2047 : SHOULD NOT (Note 2) - 2048 <= key size <= 4096 : MUST (Note 1) - 4096 < key size : MAY (Note 1) - - Note 1: See Security Considerations in Section 6. - Note 2: See Historical Mail Considerations in Appendix B. - - Key sizes for ECDSA and EdDSA are fixed by the curve. - - - - - - - - -Schaad, et al. Standards Track [Page 40] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -4.4. Encryption - - The following are the requirements for an S/MIME agent when - establishing keys for content encryption using the RSA and RSA-OAEP - algorithms: - - key size <= 2047 : SHOULD NOT (Note 2) - 2048 <= key size <= 4096 : SHOULD (Note 1) - 4096 < key size : MAY (Note 1) - - Note 1: See Security Considerations in Section 6. - Note 2: See Historical Mail Considerations in Appendix B. - - Key sizes for ECDH are fixed by the curve. - -4.5. Decryption - - The following are the requirements for an S/MIME agent when - establishing keys for content decryption using the RSA and RSAES-OAEP - algorithms: - - key size <= 2047 : MAY (Note 2) - 2048 <= key size <= 4096 : MUST (Note 1) - 4096 < key size : MAY (Note 1) - - Note 1: See Security Considerations in Section 6. - Note 2: See Historical Mail Considerations in Appendix B. - - Key sizes for ECDH are fixed by the curve. - -5. IANA Considerations - - This section (1) updates the media type registrations for - application/pkcs7-mime and application/pkcs7-signature to refer to - this document as opposed to RFC 5751, (2) adds authEnveloped-data to - the list of values for smime-type, and (3) updates references from - RFC 5751 to this document in general. - - Note that other documents can define additional media types for - S/MIME. - - - - - - - - - - - -Schaad, et al. Standards Track [Page 41] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -5.1. Media Type for application/pkcs7-mime - - Type name: application - - Subtype Name: pkcs7-mime - - Required Parameters: NONE - - Optional Parameters: smime-type - name - - Encoding Considerations: See Section 3 of this document - - Security Considerations: See Section 6 of this document - - Interoperability Considerations: See Sections 1-6 of this document - - Published Specification: RFC 2311, RFC 2633, RFC 5751, - and this document - - Applications that use this media type: Security applications - - Fragment identifier considerations: N/A - - Additional information: - Deprecated alias names for this type: N/A - Magic number(s): N/A - File extensions(s): See Section 3.2.1 of this document - Macintosh file type code(s): N/A - - Person & email address to contact for further information: - The IESG - - Intended usage: COMMON - - Restrictions on usage: NONE - - Author: Sean Turner - - Change Controller: LAMPS working group delegated from the IESG - - - - - - - - - - - -Schaad, et al. Standards Track [Page 42] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -5.2. Media Type for application/pkcs7-signature - - Type name: application - - Subtype Name: pkcs7-signature - - Required Parameters: N/A - - Optional Parameters: N/A - - Encoding Considerations: See Section 3 of this document - - Security Considerations: See Section 6 of this document - - Interoperability Considerations: See Sections 1-6 of this document - - Published Specification: RFC 2311, RFC 2633, RFC 5751, - and this document - - Applications that use this media type: Security applications - - Fragment identifier considerations: N/A - - Additional information: - Deprecated alias names for this type: N/A - Magic number(s): N/A - File extensions(s): See Section 3.2.1 of this document - Macintosh file type code(s): N/A - - Person & email address to contact for further information: - The IESG - - Intended usage: COMMON - - Restrictions on usage: N/A - - Author: Sean Turner - - Change Controller: LAMPS working group delegated from the IESG - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 43] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -5.3. authEnveloped-data smime-type - - IANA has registered the following value in the "Parameter Values for - the smime-type Parameter" registry. - - smime-type value: authEnveloped-data - - Reference: RFC 8551, Section 3.2.2 - -5.4. Reference Updates - - IANA is to update all references to RFC 5751 to this document. Known - registries to be updated are "CoAP Content-Formats" and "media- - types". - -6. Security Considerations - - Cryptographic algorithms will be broken or weakened over time. - Implementers and users need to check that the cryptographic - algorithms listed in this document continue to provide the expected - level of security. The IETF from time to time may issue documents - dealing with the current state of the art. For example: - - - The Million Message Attack described in RFC 3218 [RFC3218]. - - - The Diffie-Hellman "small-subgroup" attacks described in RFC 2785 - [RFC2785]. - - - The attacks against hash algorithms described in RFC 4270 - [RFC4270]. - - This specification uses Public-Key Cryptography technologies. It is - assumed that the private key is protected to ensure that it is not - accessed or altered by unauthorized parties. - - It is impossible for most people or software to estimate the value of - a message's content. Further, it is impossible for most people or - software to estimate the actual cost of recovering an encrypted - message's content that is encrypted with a key of a particular size. - Further, it is quite difficult to determine the cost of a failed - decryption if a recipient cannot process a message's content. Thus, - choosing between different key sizes (or choosing whether to just use - plaintext) is also impossible for most people or software. However, - decisions based on these criteria are made all the time, and - therefore this specification gives a framework for using those - estimates in choosing algorithms. - - - - - -Schaad, et al. Standards Track [Page 44] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - The choice of 2048 bits as an RSA asymmetric key size in this - specification is based on the desire to provide at least 100 bits of - security. The key sizes that must be supported to conform to this - specification seem appropriate for the Internet, based on [RFC3766]. - Of course, there are environments, such as financial and medical - systems, that may select different key sizes. For this reason, an - implementation MAY support key sizes beyond those recommended in this - specification. - - Receiving agents that validate signatures and sending agents that - encrypt messages need to be cautious of cryptographic processing - usage when validating signatures and encrypting messages using keys - larger than those mandated in this specification. An attacker could - send certificates with keys that would result in excessive - cryptographic processing -- for example, keys larger than those - mandated in this specification, as such keys could swamp the - processing element. Agents that use such keys without first - validating the certificate to a trust anchor are advised to have some - sort of cryptographic resource management system to prevent such - attacks. - - Some cryptographic algorithms such as RC2 offer little actual - security over sending plaintext. Other algorithms such as TripleDES - provide security but are no longer considered to be state of the art. - S/MIME requires the use of current state-of-the-art algorithms such - as AES and provides the ability to announce cryptographic - capabilities to parties with whom you communicate. This allows the - sender to create messages that can use the strongest common - encryption algorithm. Using algorithms such as RC2 is never - recommended unless the only alternative is no cryptography. - - RSA and DSA keys of less than 2048 bits are now considered by many - experts to be cryptographically insecure (due to advances in - computing power) and should no longer be used to protect messages. - Such keys were previously considered secure, so processing previously - received signed and encrypted mail will often result in the use of - weak keys. Implementations that wish to support previous versions of - S/MIME or process old messages need to consider the security risks - that result from smaller key sizes (e.g., spoofed messages) versus - the costs of denial of service. If an implementation supports - verification of digital signatures generated with RSA and DSA keys of - less than 1024 bits, it MUST warn the user. Implementers should - consider providing different warnings for newly received messages and - previously stored messages. Server implementations (e.g., secure - mail list servers) where user warnings are not appropriate SHOULD - reject messages with weak signatures. - - - - - -Schaad, et al. Standards Track [Page 45] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - Implementers SHOULD be aware that multiple active key pairs can be - associated with a single individual. For example, one key pair can - be used to support confidentiality, while a different key pair can be - used for digital signatures. - - If a sending agent is sending the same message using different - strengths of cryptography, an attacker watching the communications - channel might be able to determine the contents of the strongly - encrypted message by decrypting the weakly encrypted version. In - other words, a sender SHOULD NOT send a copy of a message using - weaker cryptography than they would use for the original of the - message. - - Modification of the ciphertext in EnvelopedData can go undetected if - authentication is not also used, which is the case when sending - EnvelopedData without wrapping it in SignedData or enclosing - SignedData within it. This is one of the reasons for moving from - EnvelopedData to AuthEnvelopedData, as the authenticated encryption - algorithms provide the authentication without needing the SignedData - layer. - - If an implementation is concerned about compliance with National - Institute of Standards and Technology (NIST) key size - recommendations, then see [SP800-57]. - - If messaging environments make use of the fact that a message is - signed to change the behavior of message processing (examples would - be running rules or UI display hints), without first verifying that - the message is actually signed and knowing the state of the - signature, this can lead to incorrect handling of the message. - Visual indicators on messages may need to have the signature - validation code checked periodically if the indicator is supposed to - give information on the current status of a message. - - Many people assume that the use of an authenticated encryption - algorithm is all that is needed for the sender of the message to be - authenticated. In almost all cases, this is not a correct statement. - There are a number of preconditions that need to hold for an - authenticated encryption algorithm to provide this service: - - - The starting key must be bound to a single entity. The use of a - group key only would allow for the statement that a message was - sent by one of the entities that held the key but will not - identify a specific entity. - - - - - - - -Schaad, et al. Standards Track [Page 46] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - The message must have exactly one sender and one recipient. - Having more than one recipient would allow for the second - recipient to create a message that the first recipient would - believe is from the sender by stripping the second recipient from - the message. - - - A direct path needs to exist from the starting key to the key used - as the CEK. That path needs to guarantee that no third party - could have seen the resulting CEK. This means that one needs to - be using an algorithm that is called a "Direct Encryption" or a - "Direct Key Agreement" algorithm in other contexts. This means - that the starting key is (1) used directly as the CEK or (2) used - to create a secret that is then transformed into the CEK via a - KDF step. - - S/MIME implementations almost universally use ephemeral-static rather - than static-static key agreement and do not use a shared secret for - encryption. This means that the first precondition is not met. - [RFC6278] defines how to use static-static key agreement with CMS, so - the first precondition can be met. Currently, all S/MIME key - agreement methods derive a key-encryption key (KEK) and wrap a CEK. - This violates the third precondition above. New key agreement - algorithms that directly created the CEK without creating an - intervening KEK would need to be defined. - - Even when all of the preconditions are met and origination of a - message is established by the use of an authenticated encryption - algorithm, users need to be aware that there is no way to prove this - to a third party. This is because either of the parties can - successfully create the message (or just alter the content) based on - the fact that the CEK is going to be known to both parties. Thus, - the origination is always built on a presumption that "I did not send - this message to myself." - - All of the authenticated encryption algorithms in this document use - counter mode for the encryption portion of the algorithm. This means - that the length of the plaintext will always be known, as the - ciphertext length and the plaintext length are always the same. This - information can enable passive observers to infer information based - solely on the length of the message. Applications for which this is - a concern need to provide some type of padding so that the length of - the message does not provide this information. - - When compression is used with encryption, it has the potential to - provide an additional layer of security. However, care needs to be - taken when designing a protocol that relies on using compression, so - as not to create a compression oracle. Compression oracle attacks - require an adaptive input to the process and attack the unknown - - - -Schaad, et al. Standards Track [Page 47] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - content of a message based on the length of the compressed output. - This means that no attack on the encryption key is necessarily - required. - - A recent paper on S/MIME and OpenPGP email security [Efail] has - pointed out a number of problems with the current S/MIME - specifications and how people have implemented mail clients. Due to - the nature of how CBC mode operates, the modes allow for malleability - of plaintexts. This malleability allows for attackers to make - changes in the ciphertext and, if parts of the plaintext are known, - create arbitrary blocks of plaintext. These changes can be made - without the weak integrity check in CBC mode being triggered. This - type of attack can be prevented by the use of an Authenticated - Encryption with Associated Data (AEAD) algorithm with a more robust - integrity check on the decryption process. It is therefore - recommended that mail systems migrate to using AES-GCM as quickly as - possible and that the decrypted content not be acted on prior to - finishing the integrity check. - - The other attack that is highlighted in [Efail] is due to an error in - how mail clients deal with HTML and multipart/mixed messages. - Clients MUST require that a text/html content type be a complete HTML - document (per [RFC1866]). Clients SHOULD treat each of the different - pieces of the multipart/mixed construct as being of different - origins. Clients MUST treat each encrypted or signed piece of a MIME - message as being of different origins both from unprotected content - and from each other. - -7. References - -7.1. Reference Conventions - - [ASN.1] refers to [X.680], [X.681], [X.682], and [X.683]. - - [CMS] refers to [RFC5083] and [RFC5652]. - - [ESS] refers to [RFC2634] and [RFC5035]. - - [MIME-SPEC] refers to [RFC2045], [RFC2046], [RFC2047], [RFC2049], - [RFC6838], and [RFC4289]. - - [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and - [RFC2315]. - - [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633], - [RFC2634], and [RFC5035]. - - - - - -Schaad, et al. Standards Track [Page 48] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [SMIMEv3.1] refers to [RFC2634], [RFC5035], [RFC5652], [RFC5750], and - [RFC5751]. - - [SMIMEv3.2] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and - [RFC5035]. - - [SMIMEv4] refers to [RFC2634], [RFC5035], [RFC5652], [RFC8550], and - this document. - -7.2. Normative References - - [CHARSETS] IANA, "Character sets assigned by IANA", - . - - [FIPS186-4] - National Institute of Standards and Technology (NIST), - "Digital Signature Standard (DSS)", Federal Information - Processing Standards Publication 186-4, - DOI 10.6028/NIST.FIPS.186-4, July 2013, - . - - [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, - "Security Multiparts for MIME: Multipart/Signed and - Multipart/Encrypted", RFC 1847, DOI 10.17487/RFC1847, - October 1995, . - - [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, - . - - [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Two: Media Types", RFC 2046, - DOI 10.17487/RFC2046, November 1996, - . - - [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) - Part Three: Message Header Extensions for Non-ASCII Text", - RFC 2047, DOI 10.17487/RFC2047, November 1996, - . - - [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail - Extensions (MIME) Part Five: Conformance Criteria and - Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996, - . - - - - - -Schaad, et al. Standards Track [Page 49] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating - Presentation Information in Internet Messages: The - Content-Disposition Header Field", RFC 2183, - DOI 10.17487/RFC2183, August 1997, - . - - [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", - RFC 2634, DOI 10.17487/RFC2634, June 1999, - . - - [RFC3274] Gutmann, P., "Compressed Data Content Type for - Cryptographic Message Syntax (CMS)", RFC 3274, - DOI 10.17487/RFC3274, June 2002, - . - - [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) - Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002, - . - - [RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport - Algorithm in Cryptographic Message Syntax (CMS)", - RFC 3560, DOI 10.17487/RFC3560, July 2003, - . - - [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) - Encryption Algorithm in Cryptographic Message Syntax - (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, - . - - [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail - Extensions (MIME) Part Four: Registration Procedures", - BCP 13, RFC 4289, DOI 10.17487/RFC4289, December 2005, - . - - [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in - Cryptographic Message Syntax (CMS)", RFC 4056, - DOI 10.17487/RFC4056, June 2005, - . - - [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, - "Randomness Requirements for Security", BCP 106, RFC 4086, - DOI 10.17487/RFC4086, June 2005, - . - - - -Schaad, et al. Standards Track [Page 50] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) - Authenticated-Enveloped-Data Content Type", RFC 5083, - DOI 10.17487/RFC5083, November 2007, - . - - [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated - Encryption in the Cryptographic Message Syntax (CMS)", - RFC 5084, DOI 10.17487/RFC5084, November 2007, - . - - [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, - RFC 5652, DOI 10.17487/RFC5652, September 2009, - . - - [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve - Cryptography (ECC) Algorithms in Cryptographic Message - Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, - January 2010, . - - [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic - Message Syntax", RFC 5754, DOI 10.17487/RFC5754, - January 2010, . - - [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type - Specifications and Registration Procedures", BCP 13, - RFC 6838, DOI 10.17487/RFC6838, January 2013, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - - [RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key - Agreement Algorithm with X25519 and X448 in the - Cryptographic Message Syntax (CMS)", RFC 8418, - DOI 10.17487/RFC8418, August 2018, - . - - [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature - Algorithm (EdDSA) Signatures in the Cryptographic Message - Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, - August 2018, . - - [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, - "Secure/Multipurpose Internet Mail Extensions (S/MIME) - Version 4.0 Certificate Handling", RFC 8550, - DOI 10.17487/RFC8550, April 2019, - . - - - -Schaad, et al. Standards Track [Page 51] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [X.680] "Information Technology - Abstract Syntax Notation One - (ASN.1): Specification of basic notation", ITU-T - Recommendation X.680, ISO/IEC 8824-1:2015, August 2015, - . - - [X.681] "Information Technology - Abstract Syntax Notation One - (ASN.1): Information object specification", ITU-T - Recommendation X.681, ISO/IEC 8824-2:2015, August 2015, - . - - [X.682] "Information Technology - Abstract Syntax Notation One - (ASN.1): Constraint specification", ITU-T - Recommendation X.682, ISO/IEC 8824-3:2015, August 2015, - . - - [X.683] "Information Technology - Abstract Syntax Notation One - (ASN.1): Parameterization of ASN.1 specifications", ITU-T - Recommendation X.683, ISO/IEC 8824-4:2015, August 2015, - . - - [X.690] "Information Technology - ASN.1 encoding rules: - Specification of Basic Encoding Rules (BER), Canonical - Encoding Rules (CER) and Distinguished Encoding Rules - (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2015, - August 2015, . - -7.3. Informative References - - [Efail] Poddebniak, D., Dresen, C., Muller, J., Ising, F., - Schinzel, S., Friedberger, S., Somorovsky, J., and J. - Schwenk, "Efail: Breaking S/MIME and OpenPGP Email - Encryption using Exfiltration Channels", - UsenixSecurity 2018, August 2018, - . - - [FIPS186-2] - National Institute of Standards and Technology (NIST), - "Digital Signature Standard (DSS) (also with Change - Notice 1)", Federal Information Processing Standards - Publication 186-2, January 2000, - . - - [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup - Language - 2.0", RFC 1866, DOI 10.17487/RFC1866, - November 1995, . - - - - -Schaad, et al. Standards Track [Page 52] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [RFC2268] Rivest, R., "A Description of the RC2(r) Encryption - Algorithm", RFC 2268, DOI 10.17487/RFC2268, March 1998, - . - - [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and - L. Repka, "S/MIME Version 2 Message Specification", - RFC 2311, DOI 10.17487/RFC2311, March 1998, - . - - [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, - "S/MIME Version 2 Certificate Handling", RFC 2312, DOI - 10.17487/RFC2312, March 1998, - . - - [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", - RFC 2313, DOI 10.17487/RFC2313, March 1998, - . - - [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax - Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, - . - - [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax - Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, - . - - [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, - DOI 10.17487/RFC2630, June 1999, - . - - [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", - RFC 2631, DOI 10.17487/RFC2631, June 1999, - . - - [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate - Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, - . - - [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message - Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, - . - - [RFC2785] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" - Attacks on the Diffie-Hellman Key Agreement Method for - S/MIME", RFC 2785, DOI 10.17487/RFC2785, March 2000, - . - - - - - -Schaad, et al. Standards Track [Page 53] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [RFC3218] Rescorla, E., "Preventing the Million Message Attack on - Cryptographic Message Syntax", RFC 3218, - DOI 10.17487/RFC3218, January 2002, - . - - [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For - Public Keys Used For Exchanging Symmetric Keys", BCP 86, - RFC 3766, DOI 10.17487/RFC3766, April 2004, - . - - [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail - Extensions (S/MIME) Version 3.1 Certificate Handling", - RFC 3850, DOI 10.17487/RFC3850, July 2004, - . - - [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail - Extensions (S/MIME) Version 3.1 Message Specification", - RFC 3851, DOI 10.17487/RFC3851, July 2004, - . - - [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", - RFC 3852, DOI 10.17487/RFC3852, July 2004, - . - - [RFC4134] Hoffman, P., Ed., "Examples of S/MIME Messages", RFC 4134, - DOI 10.17487/RFC4134, July 2005, - . - - [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic - Hashes in Internet Protocols", RFC 4270, - DOI 10.17487/RFC4270, November 2005, - . - - [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", - FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, - . - - [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: - Adding CertID Algorithm Agility", RFC 5035, DOI - 10.17487/RFC5035, August 2007, - . - - [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Certificate - Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, - . - - - - - -Schaad, et al. Standards Track [Page 54] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet - Mail Extensions (S/MIME) Version 3.2 Message - Specification", RFC 5751, DOI 10.17487/RFC5751, - January 2010, . - - [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations - for the MD5 Message-Digest and the HMAC-MD5 Algorithms", - RFC 6151, DOI 10.17487/RFC6151, March 2011, - . - - [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security - Considerations for the SHA-0 and SHA-1 Message-Digest - Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, - . - - [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules - for the Cryptographic Message Syntax (CMS) and the Public - Key Infrastructure Using X.509 (PKIX)", RFC 6268, - DOI 10.17487/RFC6268, July 2011, - . - - [RFC6278] Herzog, J. and R. Khazan, "Use of Static-Static Elliptic - Curve Diffie-Hellman Key Agreement in Cryptographic - Message Syntax", RFC 6278, DOI 10.17487/RFC6278, - June 2011, . - - [RFC7114] Leiba, B., "Creation of a Registry for smime-type - Parameter Values", RFC 7114, DOI 10.17487/RFC7114, - January 2014, . - - [RFC7905] Langley, A., Chang, W., Mavrogiannopoulos, N., - Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305 - Cipher Suites for Transport Layer Security (TLS)", - RFC 7905, DOI 10.17487/RFC7905, June 2016, - . - - [SP800-56A] - National Institute of Standards and Technology (NIST), - "Recommendation for Pair-Wise Key Establishment Schemes - Using Discrete Logarithm Cryptography", NIST Special - Publication 800-56A Revision 2, - DOI 10.6028/NIST.SP.800-56Ar2, May 2013, - . - - - - - - - -Schaad, et al. Standards Track [Page 55] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - [SP800-57] National Institute of Standards and Technology (NIST), - "Recommendation for Key Management - Part 1: General", - NIST Special Publication 800-57 Revision 4, - DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, - . - - [TripleDES] - Tuchman, W., "Hellman Presents No Shortcut Solutions to - the DES", IEEE Spectrum v. 16, n. 7, pp. 40-41, - DOI 10.1109/MSPEC.1979.6368160, July 1979. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 56] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -Appendix A. ASN.1 Module - - Note: The ASN.1 module contained herein is unchanged from RFC 5751 - [SMIMEv2] and RFC 3851 [SMIMEv3.1], with the exception of a change to - the preferBinaryInside ASN.1 comment in RFC 3851 [SMIMEv3.1]. If a - module is needed that is compatible with current ASN.1 standards, one - can be found in [RFC6268]. This module uses the 1988 version - of ASN.1. - - SecureMimeMessageV3dot1 - - { iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } - - DEFINITIONS IMPLICIT TAGS ::= - - BEGIN - - IMPORTS - - -- Cryptographic Message Syntax [CMS] - SubjectKeyIdentifier, IssuerAndSerialNumber, - RecipientKeyIdentifier - FROM CryptographicMessageSyntax - { iso(1) member-body(2) us(840) rsadsi(113549) - pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }; - - -- id-aa is the arc with all new authenticated and unauthenticated - -- attributes produced by the S/MIME Working Group. - - id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) - rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)} - - -- S/MIME Capabilities provides a method of broadcasting the - -- symmetric capabilities understood. Algorithms SHOULD be ordered - -- by preference and grouped by type. - - smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) - us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} - - SMIMECapability ::= SEQUENCE { - capabilityID OBJECT IDENTIFIER, - parameters ANY DEFINED BY capabilityID OPTIONAL } - - SMIMECapabilities ::= SEQUENCE OF SMIMECapability - - -- Encryption Key Preference provides a method of broadcasting the - -- preferred encryption certificate. - - - -Schaad, et al. Standards Track [Page 57] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} - - SMIMEEncryptionKeyPreference ::= CHOICE { - issuerAndSerialNumber [0] IssuerAndSerialNumber, - receipentKeyId [1] RecipientKeyIdentifier, - subjectAltKeyIdentifier [2] SubjectKeyIdentifier - } - - -- "receipentKeyId" is spelled incorrectly but is kept for - -- historical reasons. - - id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) - rsadsi(113549) pkcs(1) pkcs-9(9) 16 } - - id-cap OBJECT IDENTIFIER ::= { id-smime 11 } - - -- The preferBinaryInside OID indicates an ability to receive - -- messages with binary encoding inside the CMS wrapper. - -- The preferBinaryInside attribute's value field is ABSENT. - - id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 } - - -- The following is a list of OIDs to be used with S/MIME v3. - - -- Signature Algorithms Not Found in [RFC3370], [RFC5754], [RFC4056], - -- and [RFC3560] - - -- - -- md2WithRSAEncryption OBJECT IDENTIFIER ::= - -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) - -- 2} - - -- - -- Other Signed Attributes - -- - -- signingTime OBJECT IDENTIFIER ::= - -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) - -- 5} - -- See [CMS] for a description of how to encode the attribute - -- value. - - SMIMECapabilitiesParametersForRC2CBC ::= INTEGER - -- (RC2 Key Length (number of bits)) - - END - - - - - - -Schaad, et al. Standards Track [Page 58] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -Appendix B. Historic Mail Considerations - - Over the course of updating the S/MIME specifications, the set of - recommended algorithms has been modified each time the documents have - been updated. This means that if a user has historic emails and - their user agent has been updated to only support the current set of - recommended algorithms, some of those old emails will no longer be - accessible. It is strongly suggested that user agents implement some - of the following algorithms for dealing with historic emails. - - This appendix contains a number of references to documents that have - been obsoleted or replaced. This is intentional, as the updated - documents often do not have the same information in them. - -B.1. DigestAlgorithmIdentifier - - The following algorithms have been called out for some level of - support by previous S/MIME specifications: - - - SHA-1 was dropped in [SMIMEv4]. SHA-1 is no longer considered to - be secure, as it is no longer collision resistant. The IETF - statement on SHA-1 can be found in [RFC6194], but it is out of - date relative to the most recent advances. - - - MD5 was dropped in [SMIMEv4]. MD5 is no longer considered to be - secure, as it is no longer collision resistant. Details can be - found in [RFC6151]. - -B.2. Signature Algorithms - - There are a number of problems with validating signatures on - sufficiently historic messages. For this reason, it is strongly - suggested that user agents treat these signatures differently from - those on current messages. These problems include the following: - - - Certification authorities are not required to keep certificates on - a CRL beyond one update after a certificate has expired. This - means that unless CRLs are cached as part of the message it is not - always possible to check to see if a certificate has been revoked. - The same problems exist with Online Certificate Status Protocol - (OCSP) responses, as they may be based on a CRL rather than on the - certificate database. - - - - - - - - - -Schaad, et al. Standards Track [Page 59] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - - RSA and DSA keys of less than 2048 bits are now considered by many - experts to be cryptographically insecure (due to advances in - computing power). Such keys were previously considered secure, so - the processing of historic signed messages will often result in - the use of weak keys. Implementations that wish to support - previous versions of S/MIME or process old messages need to - consider the security risks that result from smaller key sizes - (e.g., spoofed messages) versus the costs of denial of service. - - [SMIMEv3.1] set the lower limit on suggested key sizes for - creating and validation at 1024 bits. Prior to that, the lower - bound on key sizes was 512 bits. - - - Hash functions used to validate signatures on historic messages - may no longer be considered to be secure (see below). While there - are not currently any known practical pre-image or second - pre-image attacks against MD5 or SHA-1, the fact that they are no - longer considered to be collision resistant implies that the - security levels of the signatures are generally considered - suspect. If a message is known to be historic and it has been in - the possession of the client for some time, then it might still be - considered to be secure. - - - The previous two issues apply to the certificates used to validate - the binding of the public key to the identity that signed the - message as well. - - The following algorithms have been called out for some level of - support by previous S/MIME specifications: - - - RSA with MD5 was dropped in [SMIMEv4]. MD5 is no longer - considered to be secure, as it is no longer collision resistant. - Details can be found in [RFC6151]. - - - RSA and DSA with SHA-1 were dropped in [SMIMEv4]. SHA-1 is no - longer considered to be secure, as it is no longer collision - resistant. The IETF statement on SHA-1 can be found in [RFC6194], - but it is out of date relative to the most recent advances. - - - DSA with SHA-256 was dropped in [SMIMEv4]. DSA has been replaced - by elliptic curve versions. - - - - - - - - - - -Schaad, et al. Standards Track [Page 60] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - - As requirements for "mandatory to implement" have changed over time, - some issues have been created that can cause interoperability - problems: - - - S/MIME v2 clients are only required to verify digital signatures - using the rsaEncryption algorithm with SHA-1 or MD5 and might not - implement id-dsa-with-sha1 or id-dsa at all. - - - S/MIME v3 clients might only implement signing or signature - verification using id-dsa-with-sha1 and might also use id-dsa as - an AlgorithmIdentifier in this field. - - - Note that S/MIME v3.1 clients support verifying id-dsa-with-sha1 - and rsaEncryption and might not implement sha256WithRSAEncryption. - - NOTE: Receiving clients SHOULD recognize id-dsa as equivalent to - id-dsa-with-sha1. - - For 512-bit RSA with SHA-1, see [RFC3370] and [FIPS186-2] without - Change Notice 1; for 512-bit RSA with SHA-256, see [RFC5754] and - [FIPS186-2] without Change Notice 1; and for 1024-bit through - 2048-bit RSA with SHA-256, see [RFC5754] and [FIPS186-2] with Change - Notice 1. The first reference provides the signature algorithm's - OID, and the second provides the signature algorithm's definition. - - For 512-bit DSA with SHA-1, see [RFC3370] and [FIPS186-2] without - Change Notice 1; for 512-bit DSA with SHA-256, see [RFC5754] and - [FIPS186-2] without Change Notice 1; for 1024-bit DSA with SHA-1, see - [RFC3370] and [FIPS186-2] with Change Notice 1; and for 1024-bit and - above DSA with SHA-256, see [RFC5754] and [FIPS186-4]. The first - reference provides the signature algorithm's OID, and the second - provides the signature algorithm's definition. - -B.3. ContentEncryptionAlgorithmIdentifier - - The following algorithms have been called out for some level of - support by previous S/MIME specifications: - - - RC2/40 [RFC2268] was dropped in [SMIMEv3.2]. The algorithm is - known to be insecure and, if supported, should only be used to - decrypt existing email. - - - DES EDE3 CBC [TripleDES], also known as "tripleDES", was dropped - in [SMIMEv4]. This algorithm is removed from the list of - supported algorithms because (1) it has a 64-bit block size and - (2) it offers less than 128 bits of security. This algorithm - should be supported only to decrypt existing email; it should not - be used to encrypt new emails. - - - -Schaad, et al. Standards Track [Page 61] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -B.4. KeyEncryptionAlgorithmIdentifier - - The following algorithms have been called out for some level of - support by previous S/MIME specifications: - - - DH ephemeral-static mode, as specified in [RFC3370] and - [SP800-57], was dropped in [SMIMEv4]. - - - RSA key sizes have been increased over time. Decrypting old mail - with smaller key sizes is reasonable; however, new mail should use - the updated key sizes. - - For 1024-bit DH, see [RFC3370]. For 1024-bit and larger DH, see - [SP800-56A]; regardless, use the KDF, which is from X9.42, specified - in [RFC3370]. - -Appendix C. Moving S/MIME v2 Message Specification to Historic Status - - The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 [SMIMEv3.2] - specifications are backward compatible with the S/MIME v2 Message - Specification [SMIMEv2], with the exception of the algorithms - (dropped RC2/40 requirement and added DSA and RSASSA-PSS - requirements). Therefore, RFC 2311 [SMIMEv2] was moved to Historic - status. - -Acknowledgements - - Many thanks go out to the other authors of the S/MIME version 2 - Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence - Lundblade, and Lisa Repka. Without v2, there wouldn't be a v3, v3.1, - v3.2, or v4.0. - - Some of the examples in this document were copied from [RFC4134]. - Thanks go to the people who wrote and verified the examples in that - document. - - A number of the members of the S/MIME Working Group have also worked - very hard and contributed to this document. Any list of people is - doomed to omission, and for that I apologize. In alphabetical order, - the following people stand out in my mind because they made direct - contributions to this document: - - Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter - Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, - and John Pawling. - - The version 4 update to the S/MIME documents was done under the - auspices of the LAMPS Working Group. - - - -Schaad, et al. Standards Track [Page 62] - -RFC 8551 S/MIME 4.0 Message Specification April 2019 - - -Authors' Addresses - - Jim Schaad - August Cellars - - Email: ietf@augustcellars.com - - - Blake Ramsdell - Brute Squad Labs, Inc. - - Email: blaker@gmail.com - - - Sean Turner - sn3rd - - Email: sean@sn3rd.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schaad, et al. Standards Track [Page 63] - diff --git a/specifications/mail/rfc8621.pdf b/specifications/mail/rfc8621.pdf deleted file mode 100644 index ae1c0acb..00000000 Binary files a/specifications/mail/rfc8621.pdf and /dev/null differ diff --git a/specifications/mail/rfc8621.txt b/specifications/mail/rfc8621.txt deleted file mode 100644 index 9add50ee..00000000 --- a/specifications/mail/rfc8621.txt +++ /dev/null @@ -1,6051 +0,0 @@ - - - - - - -Internet Engineering Task Force (IETF) N. Jenkins -Request for Comments: 8621 Fastmail -Updates: 5788 C. Newman -Category: Standards Track Oracle -ISSN: 2070-1721 August 2019 - - - The JSON Meta Application Protocol (JMAP) for Mail - -Abstract - - This document specifies a data model for synchronising email data - with a server using the JSON Meta Application Protocol (JMAP). - Clients can use this to efficiently search, access, organise, and - send messages, and to get push notifications for fast - resynchronisation when new messages are delivered or a change is made - in another client. - -Status of This Memo - - This is an Internet Standards Track document. - - This document is a product of the Internet Engineering Task Force - (IETF). It represents the consensus of the IETF community. It has - received public review and has been approved for publication by the - Internet Engineering Steering Group (IESG). Further information on - Internet Standards is available in Section 2 of RFC 7841. - - Information about the current status of this document, any errata, - and how to provide feedback on it may be obtained at - https://www.rfc-editor.org/info/rfc8621. - -Copyright Notice - - Copyright (c) 2019 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - - - - -Jenkins & Newman Standards Track [Page 1] - -RFC 8621 JMAP Mail August 2019 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Additions to the Capabilities Object . . . . . . . . . . 5 - 1.3.1. urn:ietf:params:jmap:mail . . . . . . . . . . . . . . 5 - 1.3.2. urn:ietf:params:jmap:submission . . . . . . . . . . . 7 - 1.3.3. urn:ietf:params:jmap:vacationresponse . . . . . . . . 8 - 1.4. Data Type Support in Different Accounts . . . . . . . . . 8 - 1.5. Push . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 1.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 9 - 1.6. Ids . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.1. Mailbox/get . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.2. Mailbox/changes . . . . . . . . . . . . . . . . . . . . . 14 - 2.3. Mailbox/query . . . . . . . . . . . . . . . . . . . . . . 14 - 2.4. Mailbox/queryChanges . . . . . . . . . . . . . . . . . . 15 - 2.5. Mailbox/set . . . . . . . . . . . . . . . . . . . . . . . 16 - 2.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 3. Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 3.1. Thread/get . . . . . . . . . . . . . . . . . . . . . . . 22 - 3.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 22 - 3.2. Thread/changes . . . . . . . . . . . . . . . . . . . . . 22 - 4. Emails . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.1. Properties of the Email Object . . . . . . . . . . . . . 23 - 4.1.1. Metadata . . . . . . . . . . . . . . . . . . . . . . 24 - 4.1.2. Header Fields Parsed Forms . . . . . . . . . . . . . 26 - 4.1.3. Header Fields Properties . . . . . . . . . . . . . . 32 - 4.1.4. Body Parts . . . . . . . . . . . . . . . . . . . . . 35 - 4.2. Email/get . . . . . . . . . . . . . . . . . . . . . . . . 42 - 4.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 44 - 4.3. Email/changes . . . . . . . . . . . . . . . . . . . . . . 45 - 4.4. Email/query . . . . . . . . . . . . . . . . . . . . . . . 45 - 4.4.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 46 - 4.4.2. Sorting . . . . . . . . . . . . . . . . . . . . . . . 49 - 4.4.3. Thread Collapsing . . . . . . . . . . . . . . . . . . 50 - 4.5. Email/queryChanges . . . . . . . . . . . . . . . . . . . 51 - 4.6. Email/set . . . . . . . . . . . . . . . . . . . . . . . . 51 - 4.7. Email/copy . . . . . . . . . . . . . . . . . . . . . . . 53 - 4.8. Email/import . . . . . . . . . . . . . . . . . . . . . . 54 - 4.9. Email/parse . . . . . . . . . . . . . . . . . . . . . . . 56 - 4.10. Examples . . . . . . . . . . . . . . . . . . . . . . . . 58 - 5. Search Snippets . . . . . . . . . . . . . . . . . . . . . . . 68 - 5.1. SearchSnippet/get . . . . . . . . . . . . . . . . . . . . 69 - 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 71 - - - - - -Jenkins & Newman Standards Track [Page 2] - -RFC 8621 JMAP Mail August 2019 - - - 6. Identities . . . . . . . . . . . . . . . . . . . . . . . . . 72 - 6.1. Identity/get . . . . . . . . . . . . . . . . . . . . . . 73 - 6.2. Identity/changes . . . . . . . . . . . . . . . . . . . . 73 - 6.3. Identity/set . . . . . . . . . . . . . . . . . . . . . . 73 - 6.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 73 - 7. Email Submission . . . . . . . . . . . . . . . . . . . . . . 74 - 7.1. EmailSubmission/get . . . . . . . . . . . . . . . . . . . 80 - 7.2. EmailSubmission/changes . . . . . . . . . . . . . . . . . 80 - 7.3. EmailSubmission/query . . . . . . . . . . . . . . . . . . 80 - 7.4. EmailSubmission/queryChanges . . . . . . . . . . . . . . 81 - 7.5. EmailSubmission/set . . . . . . . . . . . . . . . . . . . 81 - 7.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 84 - 8. Vacation Response . . . . . . . . . . . . . . . . . . . . . . 86 - 8.1. VacationResponse/get . . . . . . . . . . . . . . . . . . 87 - 8.2. VacationResponse/set . . . . . . . . . . . . . . . . . . 88 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 - 9.1. EmailBodyPart Value . . . . . . . . . . . . . . . . . . . 88 - 9.2. HTML Email Display . . . . . . . . . . . . . . . . . . . 88 - 9.3. Multiple Part Display . . . . . . . . . . . . . . . . . . 91 - 9.4. Email Submission . . . . . . . . . . . . . . . . . . . . 91 - 9.5. Partial Account Access . . . . . . . . . . . . . . . . . 92 - 9.6. Permission to Send from an Address . . . . . . . . . . . 92 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 93 - 10.1. JMAP Capability Registration for "mail" . . . . . . . . 93 - 10.2. JMAP Capability Registration for "submission" . . . . . 93 - 10.3. JMAP Capability Registration for "vacationresponse" . . 94 - 10.4. IMAP and JMAP Keywords Registry . . . . . . . . . . . . 94 - 10.4.1. Registration of JMAP Keyword "$draft" . . . . . . . 95 - 10.4.2. Registration of JMAP Keyword "$seen" . . . . . . . . 96 - 10.4.3. Registration of JMAP Keyword "$flagged" . . . . . . 97 - 10.4.4. Registration of JMAP Keyword "$answered" . . . . . . 98 - 10.4.5. Registration of "$recent" Keyword . . . . . . . . . 99 - 10.5. IMAP Mailbox Name Attributes Registry . . . . . . . . . 99 - 10.5.1. Registration of "inbox" Role . . . . . . . . . . . . 99 - 10.6. JMAP Error Codes Registry . . . . . . . . . . . . . . . 100 - 10.6.1. mailboxHasChild . . . . . . . . . . . . . . . . . . 100 - 10.6.2. mailboxHasEmail . . . . . . . . . . . . . . . . . . 100 - 10.6.3. blobNotFound . . . . . . . . . . . . . . . . . . . . 100 - 10.6.4. tooManyKeywords . . . . . . . . . . . . . . . . . . 101 - 10.6.5. tooManyMailboxes . . . . . . . . . . . . . . . . . . 101 - 10.6.6. invalidEmail . . . . . . . . . . . . . . . . . . . . 101 - 10.6.7. tooManyRecipients . . . . . . . . . . . . . . . . . 102 - 10.6.8. noRecipients . . . . . . . . . . . . . . . . . . . . 102 - 10.6.9. invalidRecipients . . . . . . . . . . . . . . . . . 102 - 10.6.10. forbiddenMailFrom . . . . . . . . . . . . . . . . . 103 - 10.6.11. forbiddenFrom . . . . . . . . . . . . . . . . . . . 103 - 10.6.12. forbiddenToSend . . . . . . . . . . . . . . . . . . 103 - - - - -Jenkins & Newman Standards Track [Page 3] - -RFC 8621 JMAP Mail August 2019 - - - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 104 - 11.2. Informative References . . . . . . . . . . . . . . . . . 107 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 108 - -1. Introduction - - The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic - protocol for synchronising data, such as mail, calendars, or contacts - between a client and a server. It is optimised for mobile and web - environments and aims to provide a consistent interface to different - data types. - - This specification defines a data model for accessing a mail store - over JMAP, allowing you to query, read, organise, and submit mail for - sending. - - The data model is designed to allow a server to provide consistent - access to the same data via IMAP [RFC3501] as well as JMAP. As in - IMAP, a message must belong to a mailbox; however, in JMAP, its id - does not change if you move it between mailboxes, and the server may - allow it to belong to multiple mailboxes simultaneously (often - exposed in a user agent as labels rather than folders). - - As in IMAP, messages may also be assigned zero or more keywords: - short arbitrary strings. These are primarily intended to store - metadata to inform client display, such as unread status or whether a - message has been replied to. An IANA registry allows common - semantics to be shared between clients and extended easily in the - future. - - A message and its replies are linked on the server by a common Thread - id. Clients may fetch the list of messages with a particular Thread - id to more easily present a threaded or conversational interface. - - Permissions for message access happen on a per-mailbox basis. - Servers may give the user restricted permissions for certain - mailboxes, for example, if another user's inbox has been shared as - read-only with them. - -1.1. Notational Conventions - - 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 - BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all - capitals, as shown here. - - - - -Jenkins & Newman Standards Track [Page 4] - -RFC 8621 JMAP Mail August 2019 - - - Type signatures, examples, and property descriptions in this document - follow the conventions established in Section 1.1 of [RFC8620]. Data - types defined in the core specification are also used in this - document. - - Servers MUST support all properties specified for the new data types - defined in this document. - -1.2. Terminology - - This document uses the same terminology as in the core JMAP - specification. - - The terms Mailbox, Thread, Email, SearchSnippet, EmailSubmission and - VacationResponse (with that specific capitalisation) are used to - refer to the data types defined in this document and instances of - those data types. - - The term message refers to a document in Internet Message Format, as - described in [RFC5322]. The Email data type represents messages in - the mail store and associated metadata. - -1.3. Additions to the Capabilities Object - - The capabilities object is returned as part of the JMAP Session - object; see [RFC8620], Section 2. - - This document defines three additional capability URIs. - -1.3.1. urn:ietf:params:jmap:mail - - This represents support for the Mailbox, Thread, Email, and - SearchSnippet data types and associated API methods. The value of - this property in the JMAP session "capabilities" property is an empty - object. - - The value of this property in an account's "accountCapabilities" - property is an object that MUST contain the following information on - server capabilities and permissions for that account: - - o maxMailboxesPerEmail: "UnsignedInt|null" - - The maximum number of Mailboxes (see Section 2) that can be can - assigned to a single Email object (see Section 4). This MUST be - an integer >= 1, or null for no limit (or rather, the limit is - always the number of Mailboxes in the account). - - - - - -Jenkins & Newman Standards Track [Page 5] - -RFC 8621 JMAP Mail August 2019 - - - o maxMailboxDepth: "UnsignedInt|null" - - The maximum depth of the Mailbox hierarchy (i.e., one more than - the maximum number of ancestors a Mailbox may have), or null for - no limit. - - o maxSizeMailboxName: "UnsignedInt" - - The maximum length, in (UTF-8) octets, allowed for the name of a - Mailbox. This MUST be at least 100, although it is recommended - servers allow more. - - o maxSizeAttachmentsPerEmail: "UnsignedInt" - - The maximum total size of attachments, in octets, allowed for a - single Email object. A server MAY still reject the import or - creation of an Email with a lower attachment size total (for - example, if the body includes several megabytes of text, causing - the size of the encoded MIME structure to be over some server- - defined limit). - - Note that this limit is for the sum of unencoded attachment sizes. - Users are generally not knowledgeable about encoding overhead, - etc., nor should they need to be, so marketing and help materials - normally tell them the "max size attachments". This is the - unencoded size they see on their hard drive, so this capability - matches that and allows the client to consistently enforce what - the user understands as the limit. - - The server may separately have a limit for the total size of the - message [RFC5322], created by combining the attachments (often - base64 encoded) with the message headers and bodies. For example, - suppose the server advertises "maxSizeAttachmentsPerEmail: - 50000000" (50 MB). The enforced server limit may be for a message - size of 70000000 octets. Even with base64 encoding and a 2 MB - HTML body, 50 MB attachments would fit under this limit. - - o emailQuerySortOptions: "String[]" - - A list of all the values the server supports for the "property" - field of the Comparator object in an "Email/query" sort (see - Section 4.4.2). This MAY include properties the client does not - recognise (for example, custom properties specified in a vendor - extension). Clients MUST ignore any unknown properties in the - list. - - - - - - -Jenkins & Newman Standards Track [Page 6] - -RFC 8621 JMAP Mail August 2019 - - - o mayCreateTopLevelMailbox: "Boolean" - - If true, the user may create a Mailbox (see Section 2) in this - account with a null parentId. (Permission for creating a child of - an existing Mailbox is given by the "myRights" property on that - Mailbox.) - -1.3.2. urn:ietf:params:jmap:submission - - This represents support for the Identity and EmailSubmission data - types and associated API methods. The value of this property in the - JMAP session "capabilities" property is an empty object. - - The value of this property in an account's "accountCapabilities" - property is an object that MUST contain the following information on - server capabilities and permissions for that account: - - o maxDelayedSend: "UnsignedInt" - - The number in seconds of the maximum delay the server supports in - sending (see the EmailSubmission object description). This is 0 - if the server does not support delayed send. - - o submissionExtensions: "String[String[]]" - - The set of SMTP submission extensions supported by the server, - which the client may use when creating an EmailSubmission object - (see Section 7). Each key in the object is the "ehlo-name", and - the value is a list of "ehlo-args". - - A JMAP implementation that talks to a submission server [RFC6409] - SHOULD have a configuration setting that allows an administrator - to modify the set of submission EHLO capabilities it may expose on - this property. This allows a JMAP server to easily add access to - a new submission extension without code changes. By default, the - JMAP server should hide EHLO capabilities that have to do with the - transport mechanism and thus are only relevant to the JMAP server - (for example, PIPELINING, CHUNKING, or STARTTLS). - - Examples of Submission extensions to include: - - * FUTURERELEASE [RFC4865] - - * SIZE [RFC1870] - - * DSN [RFC3461] - - * DELIVERYBY [RFC2852] - - - -Jenkins & Newman Standards Track [Page 7] - -RFC 8621 JMAP Mail August 2019 - - - * MT-PRIORITY [RFC6710] - - A JMAP server MAY advertise an extension and implement the - semantics of that extension locally on the JMAP server even if a - submission server used by JMAP doesn't implement it. - - The full IANA registry of submission extensions can be found at - . - -1.3.3. urn:ietf:params:jmap:vacationresponse - - This represents support for the VacationResponse data type and - associated API methods. The value of this property is an empty - object in both the JMAP session "capabilities" property and an - account's "accountCapabilities" property. - -1.4. Data Type Support in Different Accounts - - The server MUST include the appropriate capability strings as keys in - the "accountCapabilities" property of any account with which the user - may use the data types represented by that URI. Supported data types - may differ between accounts the user has access to. For example, in - the user's personal account, they may have access to all three sets - of data, but in a shared account, they may only have data for - "urn:ietf:params:jmap:mail". This means they can access - Mailbox/Thread/Email data in the shared account but are not allowed - to send as that account (and so do not have access to Identity/ - EmailSubmission objects) or view/set its VacationResponse. - -1.5. Push - - Servers MUST support the JMAP push mechanisms, as specified in - [RFC8620], Section 7, to receive notifications when the state changes - for any of the types defined in this specification. - - In addition, servers that implement the "urn:ietf:params:jmap:mail" - capability MUST support pushing state changes for a type called - "EmailDelivery". There are no methods to act on this type; it only - exists as part of the push mechanism. The state string for this MUST - change whenever a new Email is added to the store, but it SHOULD NOT - change upon any other change to the Email objects, for example, if - one is marked as read or deleted. - - Clients in battery-constrained environments may wish to delay - fetching changes initiated by the user but fetch new Emails - immediately so they can notify the user. To do this, they can - register for pushes for the EmailDelivery type rather than the Email - type (as defined in Section 4). - - - -Jenkins & Newman Standards Track [Page 8] - -RFC 8621 JMAP Mail August 2019 - - -1.5.1. Example - - The client has registered for push notifications (see [RFC8620]) just - for the EmailDelivery type. The user marks an Email as read on - another device, causing the state string for the Email type to - change; however, as nothing new was added to the store, the - EmailDelivery state does not change and nothing is pushed to the - client. A new message arrives in the user's inbox, again causing the - Email state to change. This time, the EmailDelivery state also - changes, and a StateChange object is pushed to the client with the - new state string. The client may then resync to fetch the new Email - immediately. - -1.6. Ids - - If a JMAP Mail server also provides an IMAP interface to the data and - supports IMAP Extension for Object Identifiers [RFC8474], the ids - SHOULD be the same for Mailbox, Thread, and Email objects in JMAP. - -2. Mailboxes - - A Mailbox represents a named set of Email objects. This is the - primary mechanism for organising messages within an account. It is - analogous to a folder or a label in other systems. A Mailbox may - perform a certain role in the system; see below for more details. - - For compatibility with IMAP, an Email MUST belong to one or more - Mailboxes. The Email id does not change if the Email changes - Mailboxes. - - A *Mailbox* object has the following properties: - - o id: "Id" (immutable; server-set) - - The id of the Mailbox. - - o name: "String" - - User-visible name for the Mailbox, e.g., "Inbox". This MUST be a - Net-Unicode string [RFC5198] of at least 1 character in length, - subject to the maximum size given in the capability object. There - MUST NOT be two sibling Mailboxes with both the same parent and - the same name. Servers MAY reject names that violate server - policy (e.g., names containing a slash (/) or control characters). - - - - - - - -Jenkins & Newman Standards Track [Page 9] - -RFC 8621 JMAP Mail August 2019 - - - o parentId: "Id|null" (default: null) - - The Mailbox id for the parent of this Mailbox, or null if this - Mailbox is at the top level. Mailboxes form acyclic graphs - (forests) directed by the child-to-parent relationship. There - MUST NOT be a loop. - - o role: "String|null" (default: null) - - Identifies Mailboxes that have a particular common purpose (e.g., - the "inbox"), regardless of the "name" property (which may be - localised). - - This value is shared with IMAP (exposed in IMAP via the SPECIAL- - USE extension [RFC6154]). However, unlike in IMAP, a Mailbox MUST - only have a single role, and there MUST NOT be two Mailboxes in - the same account with the same role. Servers providing IMAP - access to the same data are encouraged to enforce these extra - restrictions in IMAP as well. Otherwise, modifying the IMAP - attributes to ensure compliance when exposing the data over JMAP - is implementation dependent. - - The value MUST be one of the Mailbox attribute names listed in the - IANA "IMAP Mailbox Name Attributes" registry at - , - as established in [RFC8457], converted to lowercase. New roles - may be established here in the future. - - An account is not required to have Mailboxes with any particular - roles. - - o sortOrder: "UnsignedInt" (default: 0) - - Defines the sort order of Mailboxes when presented in the client's - UI, so it is consistent between devices. The number MUST be an - integer in the range 0 <= sortOrder < 2^31. - - A Mailbox with a lower order should be displayed before a Mailbox - with a higher order (that has the same parent) in any Mailbox - listing in the client's UI. Mailboxes with equal order SHOULD be - sorted in alphabetical order by name. The sorting should take - into account locale-specific character order convention. - - o totalEmails: "UnsignedInt" (server-set) - - The number of Emails in this Mailbox. - - - - - -Jenkins & Newman Standards Track [Page 10] - -RFC 8621 JMAP Mail August 2019 - - - o unreadEmails: "UnsignedInt" (server-set) - - The number of Emails in this Mailbox that have neither the "$seen" - keyword nor the "$draft" keyword. - - o totalThreads: "UnsignedInt" (server-set) - - The number of Threads where at least one Email in the Thread is in - this Mailbox. - - o unreadThreads: "UnsignedInt" (server-set) - - An indication of the number of "unread" Threads in the Mailbox. - - For compatibility with existing implementations, the way "unread - Threads" is determined is not mandated in this document. The - simplest solution to implement is simply the number of Threads - where at least one Email in the Thread is both in this Mailbox and - has neither the "$seen" nor "$draft" keywords. - - However, a quality implementation will return the number of unread - items the user would see if they opened that Mailbox. A Thread is - shown as unread if it contains any unread Emails that will be - displayed when the Thread is opened. Therefore, "unreadThreads" - should be the number of Threads where at least one Email in the - Thread has neither the "$seen" nor the "$draft" keyword AND at - least one Email in the Thread is in this Mailbox. Note that the - unread Email does not need to be the one in this Mailbox. In - addition, the trash Mailbox (that is, a Mailbox whose "role" is - "trash") requires special treatment: - - 1. Emails that are *only* in the trash (and no other Mailbox) are - ignored when calculating the "unreadThreads" count of other - Mailboxes. - - 2. Emails that are *not* in the trash are ignored when - calculating the "unreadThreads" count for the trash Mailbox. - - The result of this is that Emails in the trash are treated as - though they are in a separate Thread for the purposes of unread - counts. It is expected that clients will hide Emails in the trash - when viewing a Thread in another Mailbox, and vice versa. This - allows you to delete a single Email to the trash out of a Thread. - - For example, suppose you have an account where the entire contents - is a single Thread with 2 Emails: an unread Email in the trash and - a read Email in the inbox. The "unreadThreads" count would be 1 - for the trash and 0 for the inbox. - - - -Jenkins & Newman Standards Track [Page 11] - -RFC 8621 JMAP Mail August 2019 - - - o myRights: "MailboxRights" (server-set) - - The set of rights (Access Control Lists (ACLs)) the user has in - relation to this Mailbox. These are backwards compatible with - IMAP ACLs, as defined in [RFC4314]. A *MailboxRights* object has - the following properties: - - * mayReadItems: "Boolean" - - If true, the user may use this Mailbox as part of a filter in - an "Email/query" call, and the Mailbox may be included in the - "mailboxIds" property of Email objects. Email objects may be - fetched if they are in *at least one* Mailbox with this - permission. If a sub-Mailbox is shared but not the parent - Mailbox, this may be false. Corresponds to IMAP ACLs "lr" (if - mapping from IMAP, both are required for this to be true). - - * mayAddItems: "Boolean" - - The user may add mail to this Mailbox (by either creating a new - Email or moving an existing one). Corresponds to IMAP ACL "i". - - * mayRemoveItems: "Boolean" - - The user may remove mail from this Mailbox (by either changing - the Mailboxes of an Email or destroying the Email). - Corresponds to IMAP ACLs "te" (if mapping from IMAP, both are - required for this to be true). - - * maySetSeen: "Boolean" - - The user may add or remove the "$seen" keyword to/from an - Email. If an Email belongs to multiple Mailboxes, the user may - only modify "$seen" if they have this permission for *all* of - the Mailboxes. Corresponds to IMAP ACL "s". - - * maySetKeywords: "Boolean" - - The user may add or remove any keyword other than "$seen" to/ - from an Email. If an Email belongs to multiple Mailboxes, the - user may only modify keywords if they have this permission for - *all* of the Mailboxes. Corresponds to IMAP ACL "w". - - * mayCreateChild: "Boolean" - - The user may create a Mailbox with this Mailbox as its parent. - Corresponds to IMAP ACL "k". - - - - -Jenkins & Newman Standards Track [Page 12] - -RFC 8621 JMAP Mail August 2019 - - - * mayRename: "Boolean" - - The user may rename the Mailbox or make it a child of another - Mailbox. Corresponds to IMAP ACL "x" (although this covers - both rename and delete permissions). - - * mayDelete: "Boolean" - - The user may delete the Mailbox itself. Corresponds to IMAP - ACL "x" (although this covers both rename and delete - permissions). - - * maySubmit: "Boolean" - - Messages may be submitted directly to this Mailbox. - Corresponds to IMAP ACL "p". - - o isSubscribed: "Boolean" - - Has the user indicated they wish to see this Mailbox in their - client? This SHOULD default to false for Mailboxes in shared - accounts the user has access to and true for any new Mailboxes - created by the user themself. This MUST be stored separately per - user where multiple users have access to a shared Mailbox. - - A user may have permission to access a large number of shared - accounts, or a shared account with a very large set of Mailboxes, - but only be interested in the contents of a few of these. Clients - may choose to only display Mailboxes where the "isSubscribed" - property is set to true, and offer a separate UI to allow the user - to see and subscribe/unsubscribe from the full set of Mailboxes. - However, clients MAY choose to ignore this property, either - entirely for ease of implementation or just for an account where - "isPersonal" is true (indicating it is the user's own rather than - a shared account). - - This property corresponds to IMAP [RFC3501] mailbox subscriptions. - - For IMAP compatibility, an Email in both the trash and another - Mailbox SHOULD be treated by the client as existing in both places - (i.e., when emptying the trash, the client should just remove it from - the trash Mailbox and leave it in the other Mailbox). - - The following JMAP methods are supported. - - - - - - - -Jenkins & Newman Standards Track [Page 13] - -RFC 8621 JMAP Mail August 2019 - - -2.1. Mailbox/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. The "ids" argument may be "null" to fetch all at once. - -2.2. Mailbox/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2 but with one extra argument to the response: - - o updatedProperties: "String[]|null" - - If only the "totalEmails", "unreadEmails", "totalThreads", and/or - "unreadThreads" Mailbox properties have changed since the old - state, this will be the list of properties that may have changed. - If the server is unable to tell if only counts have changed, it - MUST just be null. - - Since counts frequently change but other properties are generally - only changed rarely, the server can help the client optimise data - transfer by keeping track of changes to Email/Thread counts separate - from other state changes. The "updatedProperties" array may be used - directly via a back-reference in a subsequent "Mailbox/get" call in - the same request, so only these properties are returned if nothing - else has changed. - -2.3. Mailbox/query - - This is a standard "/query" method as described in [RFC8620], - Section 5.5 but with the following additional request argument: - - o sortAsTree: "Boolean" (default: false) - - If true, when sorting the query results and comparing Mailboxes A - and B: - - * If A is an ancestor of B, it always comes first regardless of - the sort comparators. Similarly, if A is descendant of B, then - B always comes first. - - * Otherwise, if A and B do not share a "parentId", find the - nearest ancestors of each that do have the same "parentId" and - compare the sort properties on those Mailboxes instead. - - The result of this is that the Mailboxes are sorted as a tree - according to the parentId properties, with each set of children - with a common parent sorted according to the standard sort - comparators. - - - -Jenkins & Newman Standards Track [Page 14] - -RFC 8621 JMAP Mail August 2019 - - - o filterAsTree: "Boolean" (default: false) - - If true, a Mailbox is only included in the query if all its - ancestors are also included in the query according to the filter. - - A *FilterCondition* object has the following properties, any of which - may be omitted: - - o parentId: "Id|null" - - The Mailbox "parentId" property must match the given value - exactly. - - o name: "String" - - The Mailbox "name" property contains the given string. - - o role: "String|null" - - The Mailbox "role" property must match the given value exactly. - - o hasAnyRole: "Boolean" - - If true, a Mailbox matches if it has any non-null value for its - "role" property. - - o isSubscribed: "Boolean" - - The "isSubscribed" property of the Mailbox must be identical to - the value given to match the condition. - - A Mailbox object matches the FilterCondition if and only if all of - the given conditions match. If zero properties are specified, it is - automatically true for all objects. - - The following Mailbox properties MUST be supported for sorting: - - o "sortOrder" - - o "name" - -2.4. Mailbox/queryChanges - - This is a standard "/queryChanges" method as described in [RFC8620], - Section 5.6. - - - - - - -Jenkins & Newman Standards Track [Page 15] - -RFC 8621 JMAP Mail August 2019 - - -2.5. Mailbox/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3 but with the following additional request argument: - - o onDestroyRemoveEmails: "Boolean" (default: false) - - If false, any attempt to destroy a Mailbox that still has Emails - in it will be rejected with a "mailboxHasEmail" SetError. If - true, any Emails that were in the Mailbox will be removed from it, - and if in no other Mailboxes, they will be destroyed when the - Mailbox is destroyed. - - The following extra SetError types are defined: - - For "destroy": - - o "mailboxHasChild": The Mailbox still has at least one child - Mailbox. The client MUST remove these before it can delete the - parent Mailbox. - - o "mailboxHasEmail": The Mailbox has at least one Email assigned to - it, and the "onDestroyRemoveEmails" argument was false. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 16] - -RFC 8621 JMAP Mail August 2019 - - -2.6. Example - - Fetching all Mailboxes in an account: - - [[ "Mailbox/get", { - "accountId": "u33084183", - "ids": null - }, "0" ]] - - And the response: - - [[ "Mailbox/get", { - "accountId": "u33084183", - "state": "78540", - "list": [{ - "id": "MB23cfa8094c0f41e6", - "name": "Inbox", - "parentId": null, - "role": "inbox", - "sortOrder": 10, - "totalEmails": 16307, - "unreadEmails": 13905, - "totalThreads": 5833, - "unreadThreads": 5128, - "myRights": { - "mayAddItems": true, - "mayRename": false, - "maySubmit": true, - "mayDelete": false, - "maySetKeywords": true, - "mayRemoveItems": true, - "mayCreateChild": true, - "maySetSeen": true, - "mayReadItems": true - }, - "isSubscribed": true - }, { - "id": "MB674cc24095db49ce", - "name": "Important mail", - ... - }, ... ], - "notFound": [] - }, "0" ]] - - - - - - - - -Jenkins & Newman Standards Track [Page 17] - -RFC 8621 JMAP Mail August 2019 - - - Now suppose an Email is marked read, and we get a push update that - the Mailbox state has changed. You might fetch the updates like - this: - - [[ "Mailbox/changes", { - "accountId": "u33084183", - "sinceState": "78540" - }, "0" ], - [ "Mailbox/get", { - "accountId": "u33084183", - "#ids": { - "resultOf": "0", - "name": "Mailbox/changes", - "path": "/created" - } - }, "1" ], - [ "Mailbox/get", { - "accountId": "u33084183", - "#ids": { - "resultOf": "0", - "name": "Mailbox/changes", - "path": "/updated" - }, - "#properties": { - "resultOf": "0", - "name": "Mailbox/changes", - "path": "/updatedProperties" - } - }, "2" ]] - - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 18] - -RFC 8621 JMAP Mail August 2019 - - - This fetches the list of ids for created/updated/destroyed Mailboxes, - then using back-references, it fetches the data for just the created/ - updated Mailboxes in the same request. The response may look - something like this: - - [[ "Mailbox/changes", { - "accountId": "u33084183", - "oldState": "78541", - "newState": "78542", - "hasMoreChanges": false, - "updatedProperties": [ - "totalEmails", "unreadEmails", - "totalThreads", "unreadThreads" - ], - "created": [], - "updated": ["MB23cfa8094c0f41e6"], - "destroyed": [] - }, "0" ], - [ "Mailbox/get", { - "accountId": "u33084183", - "state": "78542", - "list": [], - "notFound": [] - }, "1" ], - [ "Mailbox/get", { - "accountId": "u33084183", - "state": "78542", - "list": [{ - "id": "MB23cfa8094c0f41e6", - "totalEmails": 16307, - "unreadEmails": 13903, - "totalThreads": 5833, - "unreadThreads": 5127 - }], - "notFound": [] - }, "2" ]] - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 19] - -RFC 8621 JMAP Mail August 2019 - - - Here's an example where we try to rename one Mailbox and destroy - another: - - [[ "Mailbox/set", { - "accountId": "u33084183", - "ifInState": "78542", - "update": { - "MB674cc24095db49ce": { - "name": "Maybe important mail" - } - }, - "destroy": [ "MB23cfa8094c0f41e6" ] - }, "0" ]] - - Suppose the rename succeeds, but we don't have permission to destroy - the Mailbox we tried to destroy; we might get back: - - [[ "Mailbox/set", { - "accountId": "u33084183", - "oldState": "78542", - "newState": "78549", - "updated": { - "MB674cc24095db49ce": null - }, - "notDestroyed": { - "MB23cfa8094c0f41e6": { - "type": "forbidden" - } - } - }, "0" ]] - -3. Threads - - Replies are grouped together with the original message to form a - Thread. In JMAP, a Thread is simply a flat list of Emails, ordered - by date. Every Email MUST belong to a Thread, even if it is the only - Email in the Thread. - - The exact algorithm for determining whether two Emails belong to the - same Thread is not mandated in this spec to allow for compatibility - with different existing systems. For new implementations, it is - suggested that two messages belong in the same Thread if both of the - following conditions apply: - - 1. An identical message id [RFC5322] appears in both messages in any - of the Message-Id, In-Reply-To, and References header fields. - - - - - -Jenkins & Newman Standards Track [Page 20] - -RFC 8621 JMAP Mail August 2019 - - - 2. After stripping automatically added prefixes such as "Fwd:", - "Re:", "[List-Tag]", etc., and ignoring white space, the subjects - are the same. This avoids the situation where a person replies - to an old message as a convenient way of finding the right - recipient to send to but changes the subject and starts a new - conversation. - - If messages are delivered out of order for some reason, a user may - have two Emails in the same Thread but without headers that associate - them with each other. The arrival of a third Email may provide the - missing references to join them all together into a single Thread. - Since the "threadId" of an Email is immutable, if the server wishes - to merge the Threads, it MUST handle this by deleting and reinserting - (with a new Email id) the Emails that change "threadId". - - A *Thread* object has the following properties: - - o id: "Id" (immutable; server-set) - - - The id of the Thread. - - o emailIds: "Id[]" (server-set) - - The ids of the Emails in the Thread, sorted by the "receivedAt" - date of the Email, oldest first. If two Emails have an identical - date, the sort is server dependent but MUST be stable (sorting by - id is recommended). - - The following JMAP methods are supported. - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 21] - -RFC 8621 JMAP Mail August 2019 - - -3.1. Thread/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. - -3.1.1. Example - - Request: - - [[ "Thread/get", { - "accountId": "acme", - "ids": ["f123u4", "f41u44"] - }, "#1" ]] - - with response: - - [[ "Thread/get", { - "accountId": "acme", - "state": "f6a7e214", - "list": [ - { - "id": "f123u4", - "emailIds": [ "eaa623", "f782cbb"] - }, - { - "id": "f41u44", - "emailIds": [ "82cf7bb" ] - } - ], - "notFound": [] - }, "#1" ]] - -3.2. Thread/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. - -4. Emails - - An *Email* object is a representation of a message [RFC5322], which - allows clients to avoid the complexities of MIME parsing, transfer - encoding, and character encoding. - - - - - - - - - -Jenkins & Newman Standards Track [Page 22] - -RFC 8621 JMAP Mail August 2019 - - -4.1. Properties of the Email Object - - Broadly, a message consists of two parts: a list of header fields and - then a body. The Email data type provides a way to access the full - structure or to use simplified properties and avoid some complexity - if this is sufficient for the client application. - - While raw headers can be fetched and set, the vast majority of - clients should use an appropriate parsed form for each of the header - fields it wants to process, as this allows it to avoid the - complexities of various encodings that are required in a valid - message per RFC 5322. - - The body of a message is normally a MIME-encoded set of documents in - a tree structure. This may be arbitrarily nested, but the majority - of email clients present a flat model of a message body (normally - plaintext or HTML) with a set of attachments. Flattening the MIME - structure to form this model can be difficult and causes - inconsistency between clients. Therefore, in addition to the - "bodyStructure" property, which gives the full tree, the Email object - contains 3 alternate properties with flat lists of body parts: - - o "textBody"/"htmlBody": These provide a list of parts that should - be rendered sequentially as the "body" of the message. This is a - list rather than a single part as messages may have headers and/or - footers appended/prepended as separate parts when they are - transmitted, and some clients send text and images intended to be - displayed inline in the body (or even videos and sound clips) as - multiple parts rather than a single HTML part with referenced - images. - - Because MIME allows for multiple representations of the same data - (using "multipart/alternative"), there is a "textBody" property - (which prefers a plaintext representation) and an "htmlBody" - property (which prefers an HTML representation) to accommodate the - two most common client requirements. The same part may appear in - both lists where there is no alternative between the two. - - o "attachments": This provides a list of parts that should be - presented as "attachments" to the message. Some images may be - solely there for embedding within an HTML body part; clients may - wish to not present these as attachments in the user interface if - they are displaying the HTML with the embedded images directly. - Some parts may also be in htmlBody/textBody; again, clients may - wish to not present these as attachments in the user interface if - rendered as part of the body. - - - - - -Jenkins & Newman Standards Track [Page 23] - -RFC 8621 JMAP Mail August 2019 - - - The "bodyValues" property allows for clients to fetch the value of - text parts directly without having to do a second request for the - blob and to have the server handle decoding the charset into unicode. - This data is in a separate property rather than on the EmailBodyPart - object to avoid duplication of large amounts of data, as the same - part may be included twice if the client fetches more than one of - bodyStructure, textBody, and htmlBody. - - In the following subsections, the common notational convention for - wildcards has been adopted for content types, so "foo/*" means any - content type that starts with "foo/". - - Due to the number of properties involved, the set of Email properties - is specified over the following four subsections. This is purely for - readability; all properties are top-level peers. - -4.1.1. Metadata - - These properties represent metadata about the message in the mail - store and are not derived from parsing the message itself. - - o id: "Id" (immutable; server-set) - - The id of the Email object. Note that this is the JMAP object id, - NOT the Message-ID header field value of the message [RFC5322]. - - o blobId: "Id" (immutable; server-set) - - The id representing the raw octets of the message [RFC5322] for - this Email. This may be used to download the raw original message - or to attach it directly to another Email, etc. - - o threadId: "Id" (immutable; server-set) - - The id of the Thread to which this Email belongs. - - o mailboxIds: "Id[Boolean]" - - The set of Mailbox ids this Email belongs to. An Email in the - mail store MUST belong to one or more Mailboxes at all times - (until it is destroyed). The set is represented as an object, - with each key being a Mailbox id. The value for each key in the - object MUST be true. - - - - - - - - -Jenkins & Newman Standards Track [Page 24] - -RFC 8621 JMAP Mail August 2019 - - - o keywords: "String[Boolean]" (default: {}) - - A set of keywords that apply to the Email. The set is represented - as an object, with the keys being the keywords. The value for - each key in the object MUST be true. - - Keywords are shared with IMAP. The six system keywords from IMAP - get special treatment. The following four keywords have their - first character changed from "\" in IMAP to "$" in JMAP and have - particular semantic meaning: - - * "$draft": The Email is a draft the user is composing. - - * "$seen": The Email has been read. - - * "$flagged": The Email has been flagged for urgent/special - attention. - - * "$answered": The Email has been replied to. - - The IMAP "\Recent" keyword is not exposed via JMAP. The IMAP - "\Deleted" keyword is also not present: IMAP uses a delete+expunge - model, which JMAP does not. Any message with the "\Deleted" - keyword MUST NOT be visible via JMAP (and so are not counted in - the "totalEmails", "unreadEmails", "totalThreads", and - "unreadThreads" Mailbox properties). - - Users may add arbitrary keywords to an Email. For compatibility - with IMAP, a keyword is a case-insensitive string of 1-255 - characters in the ASCII subset %x21-%x7e (excludes control chars - and space), and it MUST NOT include any of these characters: - - ( ) { ] % * " \ - - Because JSON is case sensitive, servers MUST return keywords in - lowercase. - - The IANA "IMAP and JMAP Keywords" registry at - as - established in [RFC5788] assigns semantic meaning to some other - keywords in common use. New keywords may be established here in - the future. In particular, note: - - * "$forwarded": The Email has been forwarded. - - * "$phishing": The Email is highly likely to be phishing. - Clients SHOULD warn users to take care when viewing this Email - and disable links and attachments. - - - -Jenkins & Newman Standards Track [Page 25] - -RFC 8621 JMAP Mail August 2019 - - - * "$junk": The Email is definitely spam. Clients SHOULD set this - flag when users report spam to help train automated spam- - detection systems. - - * "$notjunk": The Email is definitely not spam. Clients SHOULD - set this flag when users indicate an Email is legitimate, to - help train automated spam-detection systems. - - o size: "UnsignedInt" (immutable; server-set) - - The size, in octets, of the raw data for the message [RFC5322] (as - referenced by the "blobId", i.e., the number of octets in the file - the user would download). - - o receivedAt: "UTCDate" (immutable; default: time of creation on - server) - - The date the Email was received by the message store. This is the - "internal date" in IMAP [RFC3501]. - -4.1.2. Header Fields Parsed Forms - - Header field properties are derived from the message header fields - [RFC5322] [RFC6532]. All header fields may be fetched in a raw form. - Some header fields may also be fetched in a parsed form. The - structured form that may be fetched depends on the header. The forms - are defined in the subsections that follow. - -4.1.2.1. Raw - - Type: "String" - - The raw octets of the header field value from the first octet - following the header field name terminating colon, up to but - excluding the header field terminating CRLF. Any standards-compliant - message MUST be either ASCII (RFC 5322) or UTF-8 (RFC 6532); however, - other encodings exist in the wild. A server SHOULD replace any octet - or octet run with the high bit set that violates UTF-8 syntax with - the unicode replacement character (U+FFFD). Any NUL octet MUST be - dropped. - - This form will typically have a leading space, as most generated - messages insert a space after the colon that terminates the header - field name. - - - - - - - -Jenkins & Newman Standards Track [Page 26] - -RFC 8621 JMAP Mail August 2019 - - -4.1.2.2. Text - - Type: "String" - - The header field value with: - - 1. White space unfolded (as defined in [RFC5322], Section 2.2.3). - - 2. The terminating CRLF at the end of the value removed. - - 3. Any SP characters at the beginning of the value removed. - - 4. Any syntactically correct encoded sections [RFC2047] with a known - character set decoded. Any NUL octets or control characters - encoded per [RFC2047] are dropped from the decoded value. Any - text that looks like syntax per [RFC2047] but violates placement - or white space rules per [RFC2047] MUST NOT be decoded. - - 5. The resulting unicode converted to Normalization Form C (NFC) - form. - - If any decodings fail, the parser SHOULD insert a unicode replacement - character (U+FFFD) and attempt to continue as much as possible. - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - following header fields: - - o Subject - - o Comments - - o Keywords - - o List-Id - - o Any header field not defined in [RFC5322] or [RFC2369] - -4.1.2.3. Addresses - - Type: "EmailAddress[]" - - The header field is parsed as an "address-list" value, as specified - in [RFC5322], Section 3.4, into the "EmailAddress[]" type. There is - an EmailAddress item for each "mailbox" parsed from the "address- - list". Group and comment information is discarded. - - - - - -Jenkins & Newman Standards Track [Page 27] - -RFC 8621 JMAP Mail August 2019 - - - An *EmailAddress* object has the following properties: - - o name: "String|null" - - The "display-name" of the "mailbox" [RFC5322]. If this is a - "quoted-string": - - 1. The surrounding DQUOTE characters are removed. - - 2. Any "quoted-pair" is decoded. - - 3. White space is unfolded, and then any leading and trailing - white space is removed. - - If there is no "display-name" but there is a "comment" immediately - following the "addr-spec", the value of this SHOULD be used - instead. Otherwise, this property is null. - - o email: "String" - - The "addr-spec" of the "mailbox" [RFC5322]. - - Any syntactically correct encoded sections [RFC2047] with a known - encoding MUST be decoded, following the same rules as for the Text - form (see Section 4.1.2.2). - - Parsing SHOULD be best effort in the face of invalid structure to - accommodate invalid messages and semi-complete drafts. EmailAddress - objects MAY have an "email" property that does not conform to the - "addr-spec" form (for example, may not contain an @ symbol). - - For example, the following "address-list" string: - - " James Smythe" , Friends: - jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?= - ; - - would be parsed as: - - [ - { "name": "James Smythe", "email": "james@example.com" }, - { "name": null, "email": "jane@example.com" }, - { "name": "John Smith", "email": "john@example.com" } - ] - - - - - - - -Jenkins & Newman Standards Track [Page 28] - -RFC 8621 JMAP Mail August 2019 - - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - following header fields: - - o From - - o Sender - - o Reply-To - - o To - - o Cc - - o Bcc - - o Resent-From - - o Resent-Sender - - o Resent-Reply-To - - o Resent-To - - o Resent-Cc - - o Resent-Bcc - - o Any header field not defined in [RFC5322] or [RFC2369] - -4.1.2.4. GroupedAddresses - - Type: "EmailAddressGroup[]" - - This is similar to the Addresses form but preserves group - information. The header field is parsed as an "address-list" value, - as specified in [RFC5322], Section 3.4, into the "GroupedAddresses[]" - type. Consecutive "mailbox" values that are not part of a group are - still collected under an EmailAddressGroup object to provide a - uniform type. - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 29] - -RFC 8621 JMAP Mail August 2019 - - - An *EmailAddressGroup* object has the following properties: - - o name: "String|null" - - The "display-name" of the "group" [RFC5322], or null if the - addresses are not part of a group. If this is a "quoted-string", - it is processed the same as the "name" in the EmailAddress type. - - o addresses: "EmailAddress[]" - - The "mailbox" values that belong to this group, represented as - EmailAddress objects. - - Any syntactically correct encoded sections [RFC2047] with a known - encoding MUST be decoded, following the same rules as for the Text - form (see Section 4.1.2.2). - - Parsing SHOULD be best effort in the face of invalid structure to - accommodate invalid messages and semi-complete drafts. - - For example, the following "address-list" string: - - " James Smythe" , Friends: - jane@example.com, =?UTF-8?Q?John_Sm=C3=AEth?= - ; - - would be parsed as: - - [ - { "name": null, "addresses": [ - { "name": "James Smythe", "email": "james@example.com" } - ]}, - { "name": "Friends", "addresses": [ - { "name": null, "email": "jane@example.com" }, - { "name": "John Smith", "email": "john@example.com" } - ]} - ] - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - same header fields as the Addresses form (see Section 4.1.2.3). - - - - - - - - - - -Jenkins & Newman Standards Track [Page 30] - -RFC 8621 JMAP Mail August 2019 - - -4.1.2.5. MessageIds - - Type: "String[]|null" - - The header field is parsed as a list of "msg-id" values, as specified - in [RFC5322], Section 3.6.4, into the "String[]" type. Comments and/ - or folding white space (CFWS) and surrounding angle brackets ("<>") - are removed. If parsing fails, the value is null. - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - following header fields: - - o Message-ID - - o In-Reply-To - - o References - - o Resent-Message-ID - - o Any header field not defined in [RFC5322] or [RFC2369] - -4.1.2.6. Date - - Type: "Date|null" - - The header field is parsed as a "date-time" value, as specified in - [RFC5322], Section 3.3, into the "Date" type. If parsing fails, the - value is null. - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - following header fields: - - o Date - - o Resent-Date - - o Any header field not defined in [RFC5322] or [RFC2369] - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 31] - -RFC 8621 JMAP Mail August 2019 - - -4.1.2.7. URLs - - Type: "String[]|null" - - The header field is parsed as a list of URLs, as described in - [RFC2369], into the "String[]" type. Values do not include the - surrounding angle brackets or any comments in the header field with - the URLs. If parsing fails, the value is null. - - To prevent obviously nonsense behaviour, which can lead to - interoperability issues, this form may only be fetched or set for the - following header fields: - - o List-Help - - o List-Unsubscribe - - o List-Subscribe - - o List-Post - - o List-Owner - - o List-Archive - - o Any header field not defined in [RFC5322] or [RFC2369] - -4.1.3. Header Fields Properties - - The following low-level Email property is specified for complete - access to the header data of the message: - - o headers: "EmailHeader[]" (immutable) - - This is a list of all header fields [RFC5322], in the same order - they appear in the message. An *EmailHeader* object has the - following properties: - - * name: "String" - - The header "field name" as defined in [RFC5322], with the same - capitalization that it has in the message. - - * value: "String" - - The header "field value" as defined in [RFC5322], in Raw form. - - - - - -Jenkins & Newman Standards Track [Page 32] - -RFC 8621 JMAP Mail August 2019 - - - In addition, the client may request/send properties representing - individual header fields of the form: - - header:{header-field-name} - - Where "{header-field-name}" means any series of one or more printable - ASCII characters (i.e., characters that have values between 33 and - 126, inclusive), except for colon (:). The property may also have - the following suffixes: - - o :as{header-form} - - This means the value is in a parsed form, where "{header-form}" is - one of the parsed-form names specified above. If not given, the - value is in Raw form. - - o :all - - This means the value is an array, with the items corresponding to - each instance of the header field, in the order they appear in the - message. If this suffix is not used, the result is the value of - the *last* instance of the header field (i.e., identical to the - last item in the array if :all is used), or null if none. - - If both suffixes are used, they MUST be specified in the order above. - Header field names are matched case insensitively. The value is - typed according to the requested form or to an array of that type if - :all is used. If no header fields exist in the message with the - requested name, the value is null if fetching a single instance or an - empty array if requesting :all. - - As a simple example, if the client requests a property called - "header:subject", this means find the *last* header field in the - message named "subject" (matched case insensitively) and return the - value in Raw form, or null if no header field of this name is found. - - For a more complex example, consider the client requesting a property - called "header:Resent-To:asAddresses:all". This means: - - 1. Find *all* header fields named Resent-To (matched case - insensitively). - - 2. For each instance, parse the header field value in the Addresses - form. - - 3. The result is of type "EmailAddress[][]" -- each item in the - array corresponds to the parsed value (which is itself an array) - of the Resent-To header field instance. - - - -Jenkins & Newman Standards Track [Page 33] - -RFC 8621 JMAP Mail August 2019 - - - The following convenience properties are also specified for the Email - object: - - o messageId: "String[]|null" (immutable) - - The value is identical to the value of "header:Message- - ID:asMessageIds". For messages conforming to RFC 5322, this will - be an array with a single entry. - - o inReplyTo: "String[]|null" (immutable) - - The value is identical to the value of "header:In-Reply- - To:asMessageIds". - - o references: "String[]|null" (immutable) - - The value is identical to the value of - "header:References:asMessageIds". - - o sender: "EmailAddress[]|null" (immutable) - - The value is identical to the value of - "header:Sender:asAddresses". - - o from: "EmailAddress[]|null" (immutable) - - The value is identical to the value of "header:From:asAddresses". - - o to: "EmailAddress[]|null" (immutable) - - The value is identical to the value of "header:To:asAddresses". - - o cc: "EmailAddress[]|null" (immutable) - - The value is identical to the value of "header:Cc:asAddresses". - - o bcc: "EmailAddress[]|null" (immutable) - - The value is identical to the value of "header:Bcc:asAddresses". - - o replyTo: "EmailAddress[]|null" (immutable) - - The value is identical to the value of "header:Reply- - To:asAddresses". - - o subject: "String|null" (immutable) - - The value is identical to the value of "header:Subject:asText". - - - -Jenkins & Newman Standards Track [Page 34] - -RFC 8621 JMAP Mail August 2019 - - - o sentAt: "Date|null" (immutable; default on creation: current - server time) - - The value is identical to the value of "header:Date:asDate". - -4.1.4. Body Parts - - These properties are derived from the message body [RFC5322] and its - MIME entities [RFC2045]. - - An *EmailBodyPart* object has the following properties: - - o partId: "String|null" - - Identifies this part uniquely within the Email. This is scoped to - the "emailId" and has no meaning outside of the JMAP Email object - representation. This is null if, and only if, the part is of type - "multipart/*". - - o blobId: "Id|null" - - The id representing the raw octets of the contents of the part, - after decoding any known Content-Transfer-Encoding (as defined in - [RFC2045]), or null if, and only if, the part is of type - "multipart/*". Note that two parts may be transfer-encoded - differently but have the same blob id if their decoded octets are - identical and the server is using a secure hash of the data for - the blob id. If the transfer encoding is unknown, it is treated - as though it had no transfer encoding. - - o size: "UnsignedInt" - - The size, in octets, of the raw data after content transfer - decoding (as referenced by the "blobId", i.e., the number of - octets in the file the user would download). - - o headers: "EmailHeader[]" - - This is a list of all header fields in the part, in the order they - appear in the message. The values are in Raw form. - - o name: "String|null" - - This is the decoded "filename" parameter of the Content- - Disposition header field per [RFC2231], or (for compatibility with - existing systems) if not present, then it's the decoded "name" - parameter of the Content-Type header field per [RFC2047]. - - - - -Jenkins & Newman Standards Track [Page 35] - -RFC 8621 JMAP Mail August 2019 - - - o type: "String" - - The value of the Content-Type header field of the part, if - present; otherwise, the implicit type as per the MIME standard - ("text/plain" or "message/rfc822" if inside a "multipart/digest"). - CFWS is removed and any parameters are stripped. - - o charset: "String|null" - - The value of the charset parameter of the Content-Type header - field, if present, or null if the header field is present but not - of type "text/*". If there is no Content-Type header field, or it - exists and is of type "text/*" but has no charset parameter, this - is the implicit charset as per the MIME standard: "us-ascii". - - o disposition: "String|null" - - The value of the Content-Disposition header field of the part, if - present; otherwise, it's null. CFWS is removed and any parameters - are stripped. - - o cid: "String|null" - - The value of the Content-Id header field of the part, if present; - otherwise, it's null. CFWS and surrounding angle brackets ("<>") - are removed. This may be used to reference the content from - within a "text/html" body part [HTML] using the "cid:" protocol, - as defined in [RFC2392]. - - o language: "String[]|null" - - The list of language tags, as defined in [RFC3282], in the - Content-Language header field of the part, if present. - - o location: "String|null" - - The URI, as defined in [RFC2557], in the Content-Location header - field of the part, if present. - - o subParts: "EmailBodyPart[]|null" - - If the type is "multipart/*", this contains the body parts of each - child. - - In addition, the client may request/send EmailBodyPart properties - representing individual header fields, following the same syntax and - semantics as for the Email object, e.g., "header:Content-Type". - - - - -Jenkins & Newman Standards Track [Page 36] - -RFC 8621 JMAP Mail August 2019 - - - The following Email properties are specified for access to the body - data of the message: - - o bodyStructure: "EmailBodyPart" (immutable) - - This is the full MIME structure of the message body, without - recursing into "message/rfc822" or "message/global" parts. Note - that EmailBodyParts may have subParts if they are of type - "multipart/*". - - o bodyValues: "String[EmailBodyValue]" (immutable) - - This is a map of "partId" to an EmailBodyValue object for none, - some, or all "text/*" parts. Which parts are included and whether - the value is truncated is determined by various arguments to - "Email/get" and "Email/parse". An *EmailBodyValue* object has the - following properties: - - * value: "String" - - The value of the body part after decoding Content-Transfer- - Encoding and the Content-Type charset, if both known to the - server, and with any CRLF replaced with a single LF. The - server MAY use heuristics to determine the charset to use for - decoding if the charset is unknown, no charset is given, or it - believes the charset given is incorrect. Decoding is best - effort; the server SHOULD insert the unicode replacement - character (U+FFFD) and continue when a malformed section is - encountered. - - Note that due to the charset decoding and line ending - normalisation, the length of this string will probably not be - exactly the same as the "size" property on the corresponding - EmailBodyPart. - - * isEncodingProblem: "Boolean" (default: false) - - This is true if malformed sections were found while decoding - the charset, the charset was unknown, or the content-transfer- - encoding was unknown. - - * isTruncated: "Boolean" (default: false) - - This is true if the "value" has been truncated. - - See the Security Considerations section for issues related to - truncation and heuristic determination of the content-type and - charset. - - - -Jenkins & Newman Standards Track [Page 37] - -RFC 8621 JMAP Mail August 2019 - - - o textBody: "EmailBodyPart[]" (immutable) - - A list of "text/plain", "text/html", "image/*", "audio/*", and/or - "video/*" parts to display (sequentially) as the message body, - with a preference for "text/plain" when alternative versions are - available. - - o htmlBody: "EmailBodyPart[]" (immutable) - - A list of "text/plain", "text/html", "image/*", "audio/*", and/or - "video/*" parts to display (sequentially) as the message body, - with a preference for "text/html" when alternative versions are - available. - - o attachments: "EmailBodyPart[]" (immutable) - - A list, traversing depth-first, of all parts in "bodyStructure" - that satisfy either of the following conditions: - - * not of type "multipart/*" and not included in "textBody" or - "htmlBody" - - * of type "image/*", "audio/*", or "video/*" and not in both - "textBody" and "htmlBody" - - None of these parts include subParts, including "message/*" types. - Attached messages may be fetched using the "Email/parse" method - and the "blobId". - - Note that a "text/html" body part [HTML] may reference image parts - in attachments by using "cid:" links to reference the Content-Id, - as defined in [RFC2392], or by referencing the Content-Location. - - o hasAttachment: "Boolean" (immutable; server-set) - - This is true if there are one or more parts in the message that a - client UI should offer as downloadable. A server SHOULD set - hasAttachment to true if the "attachments" list contains at least - one item that does not have "Content-Disposition: inline". The - server MAY ignore parts in this list that are processed - automatically in some way or are referenced as embedded images in - one of the "text/html" parts of the message. - - The server MAY set hasAttachment based on implementation-defined - or site-configurable heuristics. - - - - - - -Jenkins & Newman Standards Track [Page 38] - -RFC 8621 JMAP Mail August 2019 - - - o preview: "String" (immutable; server-set) - - A plaintext fragment of the message body. This is intended to be - shown as a preview line when listing messages in the mail store - and may be truncated when shown. The server may choose which part - of the message to include in the preview; skipping quoted sections - and salutations and collapsing white space can result in a more - useful preview. - - This MUST NOT be more than 256 characters in length. - - As this is derived from the message content by the server, and the - algorithm for doing so could change over time, fetching this for - an Email a second time MAY return a different result. However, - the previous value is not considered incorrect, and the change - SHOULD NOT cause the Email object to be considered as changed by - the server. - - The exact algorithm for decomposing bodyStructure into textBody, - htmlBody, and attachments part lists is not mandated, as this is a - quality-of-service implementation issue and likely to require - workarounds for malformed content discovered over time. However, the - following algorithm (expressed here in JavaScript) is suggested as a - starting point, based on real-world experience: - - function isInlineMediaType ( type ) { - return type.startsWith( 'image/' ) || - type.startsWith( 'audio/' ) || - type.startsWith( 'video/' ); - } - - function parseStructure ( parts, multipartType, inAlternative, - htmlBody, textBody, attachments ) { - - // For multipartType == alternative - let textLength = textBody ? textBody.length : -1; - let htmlLength = htmlBody ? htmlBody.length : -1; - - for ( let i = 0; i < parts.length; i += 1 ) { - let part = parts[i]; - let isMultipart = part.type.startsWith( 'multipart/' ); - // Is this a body part rather than an attachment - let isInline = part.disposition != "attachment" && - // Must be one of the allowed body types - ( part.type == "text/plain" || - part.type == "text/html" || - isInlineMediaType( part.type ) ) && - - - - -Jenkins & Newman Standards Track [Page 39] - -RFC 8621 JMAP Mail August 2019 - - - // If multipart/related, only the first part can be inline - // If a text part with a filename, and not the first item - // in the multipart, assume it is an attachment - ( i === 0 || - ( multipartType != "related" && - ( isInlineMediaType( part.type ) || !part.name ) ) ); - - if ( isMultipart ) { - let subMultiType = part.type.split( '/' )[1]; - parseStructure( part.subParts, subMultiType, - inAlternative || ( subMultiType == 'alternative' ), - htmlBody, textBody, attachments ); - } else if ( isInline ) { - if ( multipartType == 'alternative' ) { - switch ( part.type ) { - case 'text/plain': - textBody.push( part ); - break; - case 'text/html': - htmlBody.push( part ); - break; - default: - attachments.push( part ); - break; - } - continue; - } else if ( inAlternative ) { - if ( part.type == 'text/plain' ) { - htmlBody = null; - } - if ( part.type == 'text/html' ) { - textBody = null; - } - } - if ( textBody ) { - textBody.push( part ); - } - if ( htmlBody ) { - htmlBody.push( part ); - } - if ( ( !textBody || !htmlBody ) && - isInlineMediaType( part.type ) ) { - attachments.push( part ); - } - } else { - attachments.push( part ); - } - } - - - -Jenkins & Newman Standards Track [Page 40] - -RFC 8621 JMAP Mail August 2019 - - - if ( multipartType == 'alternative' && textBody && htmlBody ) { - // Found HTML part only - if ( textLength == textBody.length && - htmlLength != htmlBody.length ) { - for ( let i = htmlLength; i < htmlBody.length; i += 1 ) { - textBody.push( htmlBody[i] ); - } - } - // Found plaintext part only - if ( htmlLength == htmlBody.length && - textLength != textBody.length ) { - for ( let i = textLength; i < textBody.length; i += 1 ) { - htmlBody.push( textBody[i] ); - } - } - } - } - - // Usage: - let htmlBody = []; - let textBody = []; - let attachments = []; - - parseStructure( [ bodyStructure ], 'mixed', false, - htmlBody, textBody, attachments ); - - For instance, consider a message with both text and HTML versions - that has gone through a list software manager that attaches a header - and footer. It might have a MIME structure something like: - - multipart/mixed - text/plain, content-disposition=inline - A - multipart/mixed - multipart/alternative - multipart/mixed - text/plain, content-disposition=inline - B - image/jpeg, content-disposition=inline - C - text/plain, content-disposition=inline - D - multipart/related - text/html - E - image/jpeg - F - image/jpeg, content-disposition=attachment - G - application/x-excel - H - message/rfc822 - J - text/plain, content-disposition=inline - K - - - - - - -Jenkins & Newman Standards Track [Page 41] - -RFC 8621 JMAP Mail August 2019 - - - In this case, the above algorithm would decompose this to: - - textBody => [ A, B, C, D, K ] - htmlBody => [ A, E, K ] - attachments => [ C, F, G, H, J ] - -4.2. Email/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1 with the following additional request arguments: - - o bodyProperties: "String[]" - - A list of properties to fetch for each EmailBodyPart returned. If - omitted, this defaults to: - - [ "partId", "blobId", "size", "name", "type", "charset", - "disposition", "cid", "language", "location" ] - - o fetchTextBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "textBody" property. - - o fetchHTMLBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "htmlBody" property. - - o fetchAllBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "bodyStructure" property. - - o maxBodyValueBytes: "UnsignedInt" (default: 0) - - If greater than zero, the "value" property of any EmailBodyValue - object returned in "bodyValues" MUST be truncated if necessary so - it does not exceed this number of octets in size. If 0 (the - default), no truncation occurs. - - The server MUST ensure the truncation results in valid UTF-8 and - does not occur mid-codepoint. If the part is of type "text/html", - the server SHOULD NOT truncate inside an HTML tag, e.g., in the - middle of "". There is no - requirement for the truncated form to be a balanced tree or valid - HTML (indeed, the original source may well be neither of these - things). - - - -Jenkins & Newman Standards Track [Page 42] - -RFC 8621 JMAP Mail August 2019 - - - If the standard "properties" argument is omitted or null, the - following default MUST be used instead of "all" properties: - - [ "id", "blobId", "threadId", "mailboxIds", "keywords", "size", - "receivedAt", "messageId", "inReplyTo", "references", "sender", "from", - "to", "cc", "bcc", "replyTo", "subject", "sentAt", "hasAttachment", - "preview", "bodyValues", "textBody", "htmlBody", "attachments" ] - - The following properties are expected to be fast to fetch in a - quality implementation: - - o id - - o blobId - - o threadId - - o mailboxIds - - o keywords - - o size - - o receivedAt - - o messageId - - o inReplyTo - - o sender - - o from - - o to - - o cc - - o bcc - - o replyTo - - o subject - - o sentAt - - o hasAttachment - - o preview - - - -Jenkins & Newman Standards Track [Page 43] - -RFC 8621 JMAP Mail August 2019 - - - Clients SHOULD take care when fetching any other properties, as there - may be significantly longer latency in fetching and returning the - data. - - As specified above, parsed forms of headers may only be used on - appropriate header fields. Attempting to fetch a form that is - forbidden (e.g., "header:From:asDate") MUST result in the method call - being rejected with an "invalidArguments" error. - - Where a specific header field is requested as a property, the - capitalization of the property name in the response MUST be identical - to that used in the request. - -4.2.1. Example - - Request: - - [[ "Email/get", { - "ids": [ "f123u456", "f123u457" ], - "properties": [ "threadId", "mailboxIds", "from", "subject", - "receivedAt", "header:List-POST:asURLs", - "htmlBody", "bodyValues" ], - "bodyProperties": [ "partId", "blobId", "size", "type" ], - "fetchHTMLBodyValues": true, - "maxBodyValueBytes": 256 - }, "#1" ]] - - and response: - - [[ "Email/get", { - "accountId": "abc", - "state": "41234123231", - "list": [ - { - "id": "f123u457", - "threadId": "ef1314a", - "mailboxIds": { "f123": true }, - "from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }], - "subject": "Dinner on Thursday?", - "receivedAt": "2013-10-13T14:12:00Z", - "header:List-POST:asURLs": [ - "mailto:partytime@lists.example.com" - ], - "htmlBody": [{ - "partId": "1", - "blobId": "B841623871", - "size": 283331, - "type": "text/html" - - - -Jenkins & Newman Standards Track [Page 44] - -RFC 8621 JMAP Mail August 2019 - - - }, { - "partId": "2", - "blobId": "B319437193", - "size": 10343, - "type": "text/plain" - }], - "bodyValues": { - "1": { - "isEncodingProblem": false, - "isTruncated": true, - "value": "

Hello ..." - }, - "2": { - "isEncodingProblem": false, - "isTruncated": false, - "value": "-- Sent by your friendly mailing list ..." - } - } - } - ], - "notFound": [ "f123u456" ] - }, "#1" ]] - -4.3. Email/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. If generating intermediate states for a large set of - changes, it is recommended that newer changes be returned first, as - these are generally of more interest to users. - -4.4. Email/query - - This is a standard "/query" method as described in [RFC8620], - Section 5.5 but with the following additional request arguments: - - o collapseThreads: "Boolean" (default: false) - - If true, Emails in the same Thread as a previous Email in the list - (given the filter and sort order) will be removed from the list. - This means only one Email at most will be included in the list for - any given Thread. - - In quality implementations, the query "total" property is expected to - be fast to calculate when the filter consists solely of a single - "inMailbox" property, as it is the same as the totalEmails or - totalThreads properties (depending on whether collapseThreads is - true) of the associated Mailbox object. - - - - -Jenkins & Newman Standards Track [Page 45] - -RFC 8621 JMAP Mail August 2019 - - -4.4.1. Filtering - - A *FilterCondition* object has the following properties, any of which - may be omitted: - - o inMailbox: "Id" - - A Mailbox id. An Email must be in this Mailbox to match the - condition. - - o inMailboxOtherThan: "Id[]" - - A list of Mailbox ids. An Email must be in at least one Mailbox - not in this list to match the condition. This is to allow - messages solely in trash/spam to be easily excluded from a search. - - o before: "UTCDate" - - The "receivedAt" date-time of the Email must be before this date- - time to match the condition. - - o after: "UTCDate" - - The "receivedAt" date-time of the Email must be the same or after - this date-time to match the condition. - - o minSize: "UnsignedInt" - - The "size" property of the Email must be equal to or greater than - this number to match the condition. - - o maxSize: "UnsignedInt" - - The "size" property of the Email must be less than this number to - match the condition. - - o allInThreadHaveKeyword: "String" - - All Emails (including this one) in the same Thread as this Email - must have the given keyword to match the condition. - - o someInThreadHaveKeyword: "String" - - At least one Email (possibly this one) in the same Thread as this - Email must have the given keyword to match the condition. - - - - - - -Jenkins & Newman Standards Track [Page 46] - -RFC 8621 JMAP Mail August 2019 - - - o noneInThreadHaveKeyword: "String" - - All Emails (including this one) in the same Thread as this Email - must *not* have the given keyword to match the condition. - - o hasKeyword: "String" - - This Email must have the given keyword to match the condition. - - o notKeyword: "String" - - This Email must not have the given keyword to match the condition. - - o hasAttachment: "Boolean" - - The "hasAttachment" property of the Email must be identical to the - value given to match the condition. - - o text: "String" - - Looks for the text in Emails. The server MUST look up text in the - From, To, Cc, Bcc, and Subject header fields of the message and - SHOULD look inside any "text/*" or other body parts that may be - converted to text by the server. The server MAY extend the search - to any additional textual property. - - o from: "String" - - Looks for the text in the From header field of the message. - - o to: "String" - - Looks for the text in the To header field of the message. - - o cc: "String" - - Looks for the text in the Cc header field of the message. - - o bcc: "String" - - Looks for the text in the Bcc header field of the message. - - o subject: "String" - - Looks for the text in the Subject header field of the message. - - - - - - -Jenkins & Newman Standards Track [Page 47] - -RFC 8621 JMAP Mail August 2019 - - - o body: "String" - - Looks for the text in one of the body parts of the message. The - server MAY exclude MIME body parts with content media types other - than "text/*" and "message/*" from consideration in search - matching. Care should be taken to match based on the text content - actually presented to an end user by viewers for that media type - or otherwise identified as appropriate for search indexing. - Matching document metadata uninteresting to an end user (e.g., - markup tag and attribute names) is undesirable. - - o header: "String[]" - - The array MUST contain either one or two elements. The first - element is the name of the header field to match against. The - second (optional) element is the text to look for in the header - field value. If not supplied, the message matches simply if it - has a header field of the given name. - - If zero properties are specified on the FilterCondition, the - condition MUST always evaluate to true. If multiple properties are - specified, ALL must apply for the condition to be true (it is - equivalent to splitting the object into one-property conditions and - making them all the child of an AND filter operator). - - The exact semantics for matching "String" fields is *deliberately not - defined* to allow for flexibility in indexing implementation, subject - to the following: - - o Any syntactically correct encoded sections [RFC2047] of header - fields with a known encoding SHOULD be decoded before attempting - to match text. - - o When searching inside a "text/html" body part, any text considered - markup rather than content SHOULD be ignored, including HTML tags - and most attributes, anything inside the "" tag, Cascading - Style Sheets (CSS), and JavaScript. Attribute content intended - for presentation to the user such as "alt" and "title" SHOULD be - considered in the search. - - o Text SHOULD be matched in a case-insensitive manner. - - o Text contained in either (but matched) single (') or double (") - quotes SHOULD be treated as a *phrase search*; that is, a match is - required for that exact word or sequence of words, excluding the - surrounding quotation marks. - - - - - -Jenkins & Newman Standards Track [Page 48] - -RFC 8621 JMAP Mail August 2019 - - - Within a phrase, to match one of the following characters you MUST - escape it by prefixing it with a backslash (\): - - ' " \ - - o Outside of a phrase, white space SHOULD be treated as dividing - separate tokens that may be searched for separately but MUST all - be present for the Email to match the filter. - - o Tokens (not part of a phrase) MAY be matched on a whole-word basis - using stemming (for example, a text search for "bus" would match - "buses" but not "business"). - -4.4.2. Sorting - - The following value for the "property" field on the Comparator object - MUST be supported for sorting: - - o "receivedAt" - The "receivedAt" date as returned in the Email - object. - - The following values for the "property" field on the Comparator - object SHOULD be supported for sorting. When specifying a - "hasKeyword", "allInThreadHaveKeyword", or "someInThreadHaveKeyword" - sort, the Comparator object MUST also have a "keyword" property. - - o "size" - The "size" as returned in the Email object. - - o "from" - This is taken to be either the "name" property or if - null/empty, the "email" property of the *first* EmailAddress - object in the Email's "from" property. If still none, consider - the value to be the empty string. - - o "to" - This is taken to be either the "name" property or if null/ - empty, the "email" property of the *first* EmailAddress object in - the Email's "to" property. If still none, consider the value to - be the empty string. - - o "subject" - This is taken to be the base subject of the message, - as defined in Section 2.1 of [RFC5256]. - - o "sentAt" - The "sentAt" property on the Email object. - - o "hasKeyword" - This value MUST be considered true if the Email has - the keyword given as an additional "keyword" property on the - Comparator object, or false otherwise. - - - - - -Jenkins & Newman Standards Track [Page 49] - -RFC 8621 JMAP Mail August 2019 - - - o "allInThreadHaveKeyword" - This value MUST be considered true for - the Email if *all* of the Emails in the same Thread have the - keyword given as an additional "keyword" property on the - Comparator object. - - o "someInThreadHaveKeyword" - This value MUST be considered true for - the Email if *any* of the Emails in the same Thread have the - keyword given as an additional "keyword" property on the - Comparator object. - - The server MAY support sorting based on other properties as well. A - client can discover which properties are supported by inspecting the - account's "capabilities" object (see Section 1.3). - - Example sort: - - [{ - "property": "someInThreadHaveKeyword", - "keyword": "$flagged", - "isAscending": false - }, { - "property": "subject", - "collation": "i;ascii-casemap" - }, { - "property": "receivedAt", - "isAscending": false - }] - - This would sort Emails in flagged Threads first (the Thread is - considered flagged if any Email within it is flagged), in subject - order second, and then from newest first for messages with the same - subject. If two Emails have identical values for all three - properties, then the order is server dependent but must be stable. - -4.4.3. Thread Collapsing - - When "collapseThreads" is true, then after filtering and sorting the - Email list, the list is further winnowed by removing any Emails for a - Thread id that has already been seen (when passing through the list - sequentially). A Thread will therefore only appear *once* in the - result, at the position of the first Email in the list that belongs - to the Thread (given the current sort/filter). - - - - - - - - - -Jenkins & Newman Standards Track [Page 50] - -RFC 8621 JMAP Mail August 2019 - - -4.5. Email/queryChanges - - This is a standard "/queryChanges" method as described in [RFC8620], - Section 5.6 with the following additional request argument: - - o collapseThreads: "Boolean" (default: false) - - The "collapseThreads" argument that was used with "Email/query". - -4.6. Email/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3. The "Email/set" method encompasses: - - o Creating a draft - - o Changing the keywords of an Email (e.g., unread/flagged status) - - o Adding/removing an Email to/from Mailboxes (moving a message) - - o Deleting Emails - - The format of the "keywords"/"mailboxIds" properties means that when - updating an Email, you can either replace the entire set of keywords/ - Mailboxes (by setting the full value of the property) or add/remove - individual ones using the JMAP patch syntax (see [RFC8620], - Section 5.3 for the specification and Section 5.7 for an example). - - Due to the format of the Email object, when creating an Email, there - are a number of ways to specify the same information. To ensure that - the message [RFC5322] to create is unambiguous, the following - constraints apply to Email objects submitted for creation: - - o The "headers" property MUST NOT be given on either the top-level - Email or an EmailBodyPart -- the client must set each header field - as an individual property. - - o There MUST NOT be two properties that represent the same header - field (e.g., "header:from" and "from") within the Email or - particular EmailBodyPart. - - o Header fields MUST NOT be specified in parsed forms that are - forbidden for that particular field. - - o Header fields beginning with "Content-" MUST NOT be specified on - the Email object, only on EmailBodyPart objects. - - - - - -Jenkins & Newman Standards Track [Page 51] - -RFC 8621 JMAP Mail August 2019 - - - o If a "bodyStructure" property is given, there MUST NOT be - "textBody", "htmlBody", or "attachments" properties. - - o If given, the "bodyStructure" EmailBodyPart MUST NOT contain a - property representing a header field that is already defined on - the top-level Email object. - - o If given, textBody MUST contain exactly one body part and it MUST - be of type "text/plain". - - o If given, htmlBody MUST contain exactly one body part and it MUST - be of type "text/html". - - o Within an EmailBodyPart: - - * The client may specify a partId OR a blobId, but not both. If - a partId is given, this partId MUST be present in the - "bodyValues" property. - - * The "charset" property MUST be omitted if a partId is given - (the part's content is included in bodyValues, and the server - may choose any appropriate encoding). - - * The "size" property MUST be omitted if a partId is given. If a - blobId is given, it may be included but is ignored by the - server (the size is actually calculated from the blob content - itself). - - * A Content-Transfer-Encoding header field MUST NOT be given. - - o Within an EmailBodyValue object, isEncodingProblem and isTruncated - MUST be either false or omitted. - - Creation attempts that violate any of this SHOULD be rejected with an - "invalidProperties" error; however, a server MAY choose to modify the - Email (e.g., choose between conflicting headers, use a different - content-encoding, etc.) to comply with its requirements instead. - - The server MAY also choose to set additional headers. If not - included, the server MUST generate and set a Message-ID header field - in conformance with [RFC5322], Section 3.6.4 and a Date header field - in conformance with Section 3.6.1. - - The final message generated may be invalid per RFC 5322. For - example, if it is a half-finished draft, the To header field may have - a value that does not conform to the required syntax for this header. - The message will be checked for strict conformance when submitted for - sending (see the EmailSubmission object description). - - - -Jenkins & Newman Standards Track [Page 52] - -RFC 8621 JMAP Mail August 2019 - - - Destroying an Email removes it from all Mailboxes to which it - belonged. To just delete an Email to trash, simply change the - "mailboxIds" property, so it is now in the Mailbox with a "role" - property equal to "trash", and remove all other Mailbox ids. - - When emptying the trash, clients SHOULD NOT destroy Emails that are - also in a Mailbox other than trash. For those Emails, they SHOULD - just remove the trash Mailbox from the Email. - - For successfully created Email objects, the "created" response - contains the "id", "blobId", "threadId", and "size" properties of the - object. - - The following extra SetError types are defined: - - For "create": - - o "blobNotFound": At least one blob id given for an EmailBodyPart - doesn't exist. An extra "notFound" property of type "Id[]" MUST - be included in the SetError object containing every "blobId" - referenced by an EmailBodyPart that could not be found on the - server. - - For "create" and "update": - - o "tooManyKeywords": The change to the Email's keywords would exceed - a server-defined maximum. - - o "tooManyMailboxes": The change to the set of Mailboxes that this - Email is in would exceed a server-defined maximum. - -4.7. Email/copy - - This is a standard "/copy" method as described in [RFC8620], - Section 5.4, except only the "mailboxIds", "keywords", and - "receivedAt" properties may be set during the copy. This method - cannot modify the message represented by the Email. - - The server MAY forbid two Email objects with identical message - content [RFC5322], or even just with the same Message-ID [RFC5322], - to coexist within an account; if the target account already has the - Email, the copy will be rejected with a standard "alreadyExists" - error. - - For successfully copied Email objects, the "created" response - contains the "id", "blobId", "threadId", and "size" properties of the - new object. - - - - -Jenkins & Newman Standards Track [Page 53] - -RFC 8621 JMAP Mail August 2019 - - -4.8. Email/import - - The "Email/import" method adds messages [RFC5322] to the set of - Emails in an account. The server MUST support messages with Email - Address Internationalization (EAI) headers [RFC6532]. The messages - must first be uploaded as blobs using the standard upload mechanism. - The method takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o ifInState: "String|null" - - This is a state string as returned by the "Email/get" method. If - supplied, the string must match the current state of the account - referenced by the accountId; otherwise, the method will be aborted - and a "stateMismatch" error returned. If null, any changes will - be applied to the current state. - - o emails: "Id[EmailImport]" - - A map of creation id (client specified) to EmailImport objects. - - An *EmailImport* object has the following properties: - - o blobId: "Id" - - The id of the blob containing the raw message [RFC5322]. - - o mailboxIds: "Id[Boolean]" - - The ids of the Mailboxes to assign this Email to. At least one - Mailbox MUST be given. - - o keywords: "String[Boolean]" (default: {}) - - The keywords to apply to the Email. - - o receivedAt: "UTCDate" (default: time of most recent Received - header, or time of import on server if none) - - The "receivedAt" date to set on the Email. - - Each Email to import is considered an atomic unit that may succeed or - fail individually. Importing successfully creates a new Email object - from the data referenced by the blobId and applies the given - Mailboxes, keywords, and receivedAt date. - - - -Jenkins & Newman Standards Track [Page 54] - -RFC 8621 JMAP Mail August 2019 - - - The server MAY forbid two Email objects with the same exact content - [RFC5322], or even just with the same Message-ID [RFC5322], to - coexist within an account. In this case, it MUST reject attempts to - import an Email considered to be a duplicate with an "alreadyExists" - SetError. An "existingId" property of type "Id" MUST be included on - the SetError object with the id of the existing Email. If duplicates - are allowed, the newly created Email object MUST have a separate id - and independent mutable properties to the existing object. - - If the "blobId", "mailboxIds", or "keywords" properties are invalid - (e.g., missing, wrong type, id not found), the server MUST reject the - import with an "invalidProperties" SetError. - - If the Email cannot be imported because it would take the account - over quota, the import should be rejected with an "overQuota" - SetError. - - If the blob referenced is not a valid message [RFC5322], the server - MAY modify the message to fix errors (such as removing NUL octets or - fixing invalid headers). If it does this, the "blobId" on the - response MUST represent the new representation and therefore be - different to the "blobId" on the EmailImport object. Alternatively, - the server MAY reject the import with an "invalidEmail" SetError. - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for this call. - - o oldState: "String|null" - - The state string that would have been returned by "Email/get" on - this account before making the requested changes, or null if the - server doesn't know what the previous state string was. - - o newState: "String" - - The state string that will now be returned by "Email/get" on this - account. - - o created: "Id[Email]|null" - - A map of the creation id to an object containing the "id", - "blobId", "threadId", and "size" properties for each successfully - imported Email, or null if none. - - - - - -Jenkins & Newman Standards Track [Page 55] - -RFC 8621 JMAP Mail August 2019 - - - o notCreated: "Id[SetError]|null" - - A map of the creation id to a SetError object for each Email that - failed to be created, or null if all successful. The possible - errors are defined above. - - The following additional errors may be returned instead of the - "Email/import" response: - - "stateMismatch": An "ifInState" argument was supplied, and it does - not match the current state. - -4.9. Email/parse - - This method allows you to parse blobs as messages [RFC5322] to get - Email objects. The server MUST support messages with EAI headers - [RFC6532]. This can be used to parse and display attached messages - without having to import them as top-level Email objects in the mail - store in their own right. - - The following metadata properties on the Email objects will be null - if requested: - - o id - - o mailboxIds - - o keywords - - o receivedAt - - The "threadId" property of the Email MAY be present if the server can - calculate which Thread the Email would be assigned to were it to be - imported. Otherwise, this too is null if fetched. - - The "Email/parse" method takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o blobIds: "Id[]" - - The ids of the blobs to parse. - - - - - - - -Jenkins & Newman Standards Track [Page 56] - -RFC 8621 JMAP Mail August 2019 - - - o properties: "String[]" - - If supplied, only the properties listed in the array are returned - for each Email object. If omitted, defaults to: - - [ "messageId", "inReplyTo", "references", "sender", "from", "to", - "cc", "bcc", "replyTo", "subject", "sentAt", "hasAttachment", - "preview", "bodyValues", "textBody", "htmlBody", "attachments" ] - - o bodyProperties: "String[]" - - A list of properties to fetch for each EmailBodyPart returned. If - omitted, defaults to the same value as the "Email/get" - "bodyProperties" default argument. - - o fetchTextBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "textBody" property. - - o fetchHTMLBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "htmlBody" property. - - o fetchAllBodyValues: "Boolean" (default: false) - - If true, the "bodyValues" property includes any "text/*" part in - the "bodyStructure" property. - - o maxBodyValueBytes: "UnsignedInt" (default: 0) - - If greater than zero, the "value" property of any EmailBodyValue - object returned in "bodyValues" MUST be truncated if necessary so - it does not exceed this number of octets in size. If 0 (the - default), no truncation occurs. - - The server MUST ensure the truncation results in valid UTF-8 and - does not occur mid-codepoint. If the part is of type "text/html", - the server SHOULD NOT truncate inside an HTML tag, e.g., in the - middle of "". There is no - requirement for the truncated form to be a balanced tree or valid - HTML (indeed, the original source may well be neither of these - things). - - - - - - - -Jenkins & Newman Standards Track [Page 57] - -RFC 8621 JMAP Mail August 2019 - - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - o parsed: "Id[Email]|null" - - A map of blob id to parsed Email representation for each - successfully parsed blob, or null if none. - - o notParsable: "Id[]|null" - - A list of ids given that corresponded to blobs that could not be - parsed as Emails, or null if none. - - o notFound: "Id[]|null" - - A list of blob ids given that could not be found, or null if none. - - As specified above, parsed forms of headers may only be used on - appropriate header fields. Attempting to fetch a form that is - forbidden (e.g., "header:From:asDate") MUST result in the method call - being rejected with an "invalidArguments" error. - - Where a specific header field is requested as a property, the - capitalization of the property name in the response MUST be identical - to that used in the request. - -4.10. Examples - - A client logs in for the first time. It first fetches the set of - Mailboxes. Now it will display the inbox to the user, which we will - presume has Mailbox id "fb666a55". The inbox may be (very!) large, - but the user's screen is only so big, so the client can just load the - Threads it needs to fill the screen and then load in more only when - the user scrolls. The client sends this request: - - [[ "Email/query",{ - "accountId": "ue150411c", - "filter": { - "inMailbox": "fb666a55" - }, - "sort": [{ - "isAscending": false, - "property": "receivedAt" - }], - "collapseThreads": true, - - - -Jenkins & Newman Standards Track [Page 58] - -RFC 8621 JMAP Mail August 2019 - - - "position": 0, - "limit": 30, - "calculateTotal": true - }, "0" ], - [ "Email/get", { - "accountId": "ue150411c", - "#ids": { - "resultOf": "0", - "name": "Email/query", - "path": "/ids" - }, - "properties": [ - "threadId" - ] - }, "1" ], - [ "Thread/get", { - "accountId": "ue150411c", - "#ids": { - "resultOf": "1", - "name": "Email/get", - "path": "/list/*/threadId" - } - }, "2" ], - [ "Email/get", { - "accountId": "ue150411c", - "#ids": { - "resultOf": "2", - "name": "Thread/get", - "path": "/list/*/emailIds" - }, - "properties": [ - "threadId", - "mailboxIds", - "keywords", - "hasAttachment", - "from", - "subject", - "receivedAt", - "size", - "preview" - ] - }, "3" ]] - - - - - - - - - -Jenkins & Newman Standards Track [Page 59] - -RFC 8621 JMAP Mail August 2019 - - - Let's break down the 4 method calls to see what they're doing: - - "0": This asks the server for the ids of the first 30 Email objects - in the inbox, sorted newest first, ignoring Emails from the same - Thread as a newer Email in the Mailbox (i.e., it is the first 30 - unique Threads). - - "1": Now we use a back-reference to fetch the Thread ids for each of - these Email ids. - - "2": Another back-reference fetches the Thread object for each of - these Thread ids. - - "3": Finally, we fetch the information we need to display the Mailbox - listing (but no more!) for every Email in each of these 30 Threads. - The client may aggregate this data for display, for example, by - showing the Thread as "flagged" if any of the Emails in it has the - "$flagged" keyword. - - The response from the server may look something like this: - - [[ "Email/query", { - "accountId": "ue150411c", - "queryState": "09aa9a075588-780599:0", - "canCalculateChanges": true, - "position": 0, - "total": 115, - "ids": [ "Ma783e5cdf5f2deffbc97930a", - "M9bd17497e2a99cb345fc1d0a", ... ] - }, "0" ], - [ "Email/get", { - "accountId": "ue150411c", - "state": "780599", - "list": [{ - "id": "Ma783e5cdf5f2deffbc97930a", - "threadId": "T36703c2cfe9bd5ed" - }, { - "id": "M9bd17497e2a99cb345fc1d0a", - "threadId": "T0a22ad76e9c097a1" - }, ... ], - "notFound": [] - }, "1" ], - [ "Thread/get", { - "accountId": "ue150411c", - "state": "22a8728b", - "list": [{ - "id": "T36703c2cfe9bd5ed", - "emailIds": [ "Ma783e5cdf5f2deffbc97930a" ] - - - -Jenkins & Newman Standards Track [Page 60] - -RFC 8621 JMAP Mail August 2019 - - - }, { - "id": "T0a22ad76e9c097a1", - "emailIds": [ "M3b568670a63e5d100f518fa5", - "M9bd17497e2a99cb345fc1d0a" ] - }, ... ], - "notFound": [] - }, "2" ], - [ "Email/get", { - "accountId": "ue150411c", - "state": "780599", - "list": [{ - "id": "Ma783e5cdf5f2deffbc97930a", - "threadId": "T36703c2cfe9bd5ed", - "mailboxIds": { - "fb666a55": true - }, - "keywords": { - "$seen": true, - "$flagged": true - }, - "hasAttachment": true, - "from": [{ - "email": "jdoe@example.com", - "name": "Jane Doe" - }], - "subject": "The Big Reveal", - "receivedAt": "2018-06-27T00:20:35Z", - "size": 175047, - "preview": "As you may be aware, we are required to prepare a - presentation where we wow a panel of 5 random members of the - public, on or before 30 June each year. We have drafted..." - }, - ... - ], - "notFound": [] - }, "3" ]] - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 61] - -RFC 8621 JMAP Mail August 2019 - - - Now, on another device, the user marks the first Email as unread, - sending this API request: - - [[ "Email/set", { - "accountId": "ue150411c", - "update": { - "Ma783e5cdf5f2deffbc97930a": { - "keywords/$seen": null - } - } - }, "0" ]] - - The server applies this and sends the success response: - - [[ "Email/set", { - "accountId": "ue150411c", - "oldState": "780605", - "newState": "780606", - "updated": { - "Ma783e5cdf5f2deffbc97930a": null - }, - ... - }, "0" ]] - - The user also deletes a few Emails, and then a new message arrives. - - - - - - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 62] - -RFC 8621 JMAP Mail August 2019 - - - Back on our original machine, we receive a push update that the state - string for Email is now "780800". As this does not match the - client's current state, it issues a request for the changes: - - [[ "Email/changes", { - "accountId": "ue150411c", - "sinceState": "780605", - "maxChanges": 50 - }, "3" ], - [ "Email/queryChanges", { - "accountId": "ue150411c", - "filter": { - "inMailbox": "fb666a55" - }, - "sort": [{ - "property": "receivedAt", - "isAscending": false - }], - "collapseThreads": true, - "sinceQueryState": "09aa9a075588-780599:0", - "upToId": "Mc2781d5e856a908d8a35a564", - "maxChanges": 25, - "calculateTotal": true - }, "11" ]] - - The response: - - [[ "Email/changes", { - "accountId": "ue150411c", - "oldState": "780605", - "newState": "780800", - "hasMoreChanges": false, - "created": [ "Me8de6c9f6de198239b982ea2" ], - "updated": [ "Ma783e5cdf5f2deffbc97930a" ], - "destroyed": [ "M9bd17497e2a99cb345fc1d0a", ... ] - }, "3" ], - [ "Email/queryChanges", { - "accountId": "ue150411c", - "oldQueryState": "09aa9a075588-780599:0", - "newQueryState": "e35e9facf117-780615:0", - "added": [{ - "id": "Me8de6c9f6de198239b982ea2", - "index": 0 - }], - "removed": [ "M9bd17497e2a99cb345fc1d0a" ], - "total": 115 - }, "11" ]] - - - - -Jenkins & Newman Standards Track [Page 63] - -RFC 8621 JMAP Mail August 2019 - - - The client can update its local cache of the query results by - removing "M9bd17497e2a99cb345fc1d0a" and then splicing in - "Me8de6c9f6de198239b982ea2" at position 0. As it does not have the - data for this new Email, it will then fetch it (it also could have - done this in the same request using back-references). - - It knows something has changed about "Ma783e5cdf5f2deffbc97930a", so - it will refetch the Mailbox ids and keywords (the only mutable - properties) for this Email too. - - The user starts composing a new Email. The email is plaintext and - the client knows the email in English so adds this metadata to the - body part. The user saves a draft while the composition is still in - progress. The client sends: - - [[ "Email/set", { - "accountId": "ue150411c", - "create": { - "k192": { - "mailboxIds": { - "2ea1ca41b38e": true - }, - "keywords": { - "$seen": true, - "$draft": true - }, - "from": [{ - "name": "Joe Bloggs", - "email": "joe@example.com" - }], - "subject": "World domination", - "receivedAt": "2018-07-10T01:03:11Z", - "sentAt": "2018-07-10T11:03:11+10:00", - "bodyStructure": { - "type": "text/plain", - "partId": "bd48", - "header:Content-Language": "en" - }, - "bodyValues": { - "bd48": { - "value": "I have the most brilliant plan. Let me tell - you all about it. What we do is, we", - "isTruncated": false - } - } - } - } - }, "0" ]] - - - -Jenkins & Newman Standards Track [Page 64] - -RFC 8621 JMAP Mail August 2019 - - - The server creates the message and sends the success response: - - [[ "Email/set", { - "accountId": "ue150411c", - "oldState": "780823", - "newState": "780839", - "created": { - "k192": { - "id": "Mf40b5f831efa7233b9eb1c7f", - "blobId": "Gf40b5f831efa7233b9eb1c7f8f97d84eeeee64f7", - "threadId": "Td957e72e89f516dc", - "size": 359 - } - }, - ... - }, "0" ]] - - The message created on the server looks something like this: - - Message-Id: - User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44 - Mime-Version: 1.0 - Date: Tue, 10 Jul 2018 11:03:11 +1000 - From: "Joe Bloggs" - Subject: World domination - Content-Language: en - Content-Type: text/plain - - I have the most brilliant plan. Let me tell you all about it. What we - do is, we - - The user adds a recipient and converts the message to HTML so they - can add formatting, then saves an updated draft: - - [[ "Email/set", { - "accountId": "ue150411c", - "create": { - "k1546": { - "mailboxIds": { - "2ea1ca41b38e": true - }, - "keywords": { - "$seen": true, - "$draft": true - }, - "from": [{ - "name": "Joe Bloggs", - "email": "joe@example.com" - - - -Jenkins & Newman Standards Track [Page 65] - -RFC 8621 JMAP Mail August 2019 - - - }], - "to": [{ - "name": "John", - "email": "john@example.com" - }], - "subject": "World domination", - "receivedAt": "2018-07-10T01:05:08Z", - "sentAt": "2018-07-10T11:05:08+10:00", - "bodyStructure": { - "type": "multipart/alternative", - "subParts": [{ - "partId": "a49d", - "type": "text/html", - "header:Content-Language": "en" - }, { - "partId": "bd48", - "type": "text/plain", - "header:Content-Language": "en" - }] - }, - "bodyValues": { - "bd48": { - "value": "I have the most brilliant plan. Let me tell - you all about it. What we do is, we", - "isTruncated": false - }, - "a49d": { - "value": " - -

- ", - "isTruncated": false - } - } - } - }, - "destroy": [ "Mf40b5f831efa7233b9eb1c7f" ] - }, "0" ]] - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 66] - -RFC 8621 JMAP Mail August 2019 - - - The server creates the new draft, deletes the old one, and sends the - success response: - - [[ "Email/set", { - "accountId": "ue150411c", - "oldState": "780839", - "newState": "780842", - "created": { - "k1546": { - "id": "Md45b47b4877521042cec0938", - "blobId": "Ge8de6c9f6de198239b982ea214e0f3a704e4af74", - "threadId": "Td957e72e89f516dc", - "size": 11721 - } - }, - "destroyed": [ "Mf40b5f831efa7233b9eb1c7f" ], - ... - }, "0" ]] - - The client moves this draft to a different account. The only way to - do this is via the "Email/copy" method. It MUST set a new - "mailboxIds" property, since the current value will not be valid - Mailbox ids in the destination account: - - [[ "Email/copy", { - "fromAccountId": "ue150411c", - "accountId": "u6c6c41ac", - "create": { - "k45": { - "id": "Md45b47b4877521042cec0938", - "mailboxIds": { - "75a4c956": true - } - } - }, - "onSuccessDestroyOriginal": true - }, "0" ]] - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 67] - -RFC 8621 JMAP Mail August 2019 - - - The server successfully copies the Email and deletes the original. - Due to the implicit call to "Email/set", there are two responses to - the single method call, both with the same method call id: - - [[ "Email/copy", { - "fromAccountId": "ue150411c", - "accountId": "u6c6c41ac", - "oldState": "7ee7e9263a6d", - "newState": "5a0d2447ed26", - "created": { - "k45": { - "id": "M138f9954a5cd2423daeafa55", - "blobId": "G6b9fb047cba722c48c611e79233d057c6b0b74e8", - "threadId": "T2f242ea424a4079a", - "size": 11721 - } - }, - "notCreated": null - }, "0" ], - [ "Email/set", { - "accountId": "ue150411c", - "oldState": "780842", - "newState": "780871", - "destroyed": [ "Md45b47b4877521042cec0938" ], - ... - }, "0" ]] - -5. Search Snippets - - When doing a search on a "String" property, the client may wish to - show the relevant section of the body that matches the search as a - preview and to highlight any matching terms in both this and the - subject of the Email. Search snippets represent this data. - - A *SearchSnippet* object has the following properties: - - o emailId: "Id" - - The Email id the snippet applies to. - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 68] - -RFC 8621 JMAP Mail August 2019 - - - o subject: "String|null" - - If text from the filter matches the subject, this is the subject - of the Email with the following transformations: - - 1. Any instance of the following three characters MUST be - replaced by an appropriate HTML entity: & (ampersand), < - (less-than sign), and > (greater-than sign) [HTML]. Other - characters MAY also be replaced with an HTML entity form. - - 2. The matching words/phrases from the filter are wrapped in HTML - "" tags. - - If the subject does not match text from the filter, this property - is null. - - o preview: "String|null" - - If text from the filter matches the plaintext or HTML body, this - is the relevant section of the body (converted to plaintext if - originally HTML), with the same transformations as the "subject" - property. It MUST NOT be bigger than 255 octets in size. If the - body does not contain a match for the text from the filter, this - property is null. - - What is a relevant section of the body for preview is server defined. - If the server is unable to determine search snippets, it MUST return - null for both the "subject" and "preview" properties. - - Note that unlike most data types, a SearchSnippet DOES NOT have a - property called "id". - - The following JMAP method is supported. - -5.1. SearchSnippet/get - - To fetch search snippets, make a call to "SearchSnippet/get". It - takes the following arguments: - - o accountId: "Id" - - The id of the account to use. - - o filter: "FilterOperator|FilterCondition|null" - - The same filter as passed to "Email/query"; see the description of - this method in Section 4.4 for details. - - - - -Jenkins & Newman Standards Track [Page 69] - -RFC 8621 JMAP Mail August 2019 - - - o emailIds: "Id[]" - - The ids of the Emails to fetch snippets for. - - The response has the following arguments: - - o accountId: "Id" - - The id of the account used for the call. - - o list: "SearchSnippet[]" - - An array of SearchSnippet objects for the requested Email ids. - This may not be in the same order as the ids that were in the - request. - - o notFound: "Id[]|null" - - An array of Email ids requested that could not be found, or null - if all ids were found. - - As the search snippets are derived from the message content and the - algorithm for doing so could change over time, fetching the same - snippets a second time MAY return a different result. However, the - previous value is not considered incorrect, so there is no state - string or update mechanism needed. - - The following additional errors may be returned instead of the - "SearchSnippet/get" response: - - "requestTooLarge": The number of "emailIds" requested by the client - exceeds the maximum number the server is willing to process in a - single method call. - - "unsupportedFilter": The server is unable to process the given - "filter" for any reason. - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 70] - -RFC 8621 JMAP Mail August 2019 - - -5.2. Example - - Here, we did an "Email/query" to search for any Email in the account - containing the word "foo"; now, we are fetching the search snippets - for some of the ids that were returned in the results: - - [[ "SearchSnippet/get", { - "accountId": "ue150411c", - "filter": { - "text": "foo" - }, - "emailIds": [ - "M44200ec123de277c0c1ce69c", - "M7bcbcb0b58d7729686e83d99", - "M28d12783a0969584b6deaac0", - ... - ] - }, "0" ]] - - Example response: - - [[ "SearchSnippet/get", { - "accountId": "ue150411c", - "list": [{ - "emailId": "M44200ec123de277c0c1ce69c", - "subject": null, - "preview": null - }, { - "emailId": "M7bcbcb0b58d7729686e83d99", - "subject": "The Foosball competition", - "preview": "...year the foosball competition will - be held in the Stadium de ..." - }, { - "emailId": "M28d12783a0969584b6deaac0", - "subject": null, - "preview": "...the Foo/bar method results often - returns <1 widget rather than the complete..." - }, - ... - ], - "notFound": null - }, "0" ]] - - - - - - - - - -Jenkins & Newman Standards Track [Page 71] - -RFC 8621 JMAP Mail August 2019 - - -6. Identities - - An *Identity* object stores information about an email address or - domain the user may send from. It has the following properties: - - o id: "Id" (immutable; server-set) - - The id of the Identity. - - o name: "String" (default: "") - - The "From" name the client SHOULD use when creating a new Email - from this Identity. - - o email: "String" (immutable) - - The "From" email address the client MUST use when creating a new - Email from this Identity. If the "mailbox" part of the address - (the section before the "@") is the single character "*" (e.g., - "*@example.com"), the client may use any valid address ending in - that domain (e.g., "foo@example.com"). - - o replyTo: "EmailAddress[]|null" (default: null) - - The Reply-To value the client SHOULD set when creating a new Email - from this Identity. - - o bcc: "EmailAddress[]|null" (default: null) - - The Bcc value the client SHOULD set when creating a new Email from - this Identity. - - o textSignature: "String" (default: "") - - A signature the client SHOULD insert into new plaintext messages - that will be sent from this Identity. Clients MAY ignore this - and/or combine this with a client-specific signature preference. - - o htmlSignature: "String" (default: "") - - A signature the client SHOULD insert into new HTML messages that - will be sent from this Identity. This text MUST be an HTML - snippet to be inserted into the "" section of the - HTML. Clients MAY ignore this and/or combine this with a client- - specific signature preference. - - - - - - -Jenkins & Newman Standards Track [Page 72] - -RFC 8621 JMAP Mail August 2019 - - - o mayDelete: "Boolean" (server-set) - - Is the user allowed to delete this Identity? Servers may wish to - set this to false for the user's username or other default - address. Attempts to destroy an Identity with "mayDelete: false" - will be rejected with a standard "forbidden" SetError. - - See the "Addresses" header form description in the Email object - (Section 4.1.2.3) for the definition of EmailAddress. - - Multiple identities with the same email address MAY exist, to allow - for different settings the user wants to pick between (for example, - with different names/signatures). - - The following JMAP methods are supported. - -6.1. Identity/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. The "ids" argument may be null to fetch all at once. - -6.2. Identity/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. - -6.3. Identity/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3. The following extra SetError types are defined: - - For "create": - - o "forbiddenFrom": The user is not allowed to send from the address - given as the "email" property of the Identity. - -6.4. Example - - Request: - - [ "Identity/get", { - "accountId": "acme" - }, "0" ] - - - - - - - - -Jenkins & Newman Standards Track [Page 73] - -RFC 8621 JMAP Mail August 2019 - - - with response: - - [ "Identity/get", { - "accountId": "acme", - "state": "99401312ae-11-333", - "list": [ - { - "id": "XD-3301-222-11_22AAz", - "name": "Joe Bloggs", - "email": "joe@example.com", - "replyTo": null, - "bcc": [{ - "name": null, - "email": "joe+archive@example.com" - }], - "textSignature": "-- \nJoe Bloggs\nMaster of Email", - "htmlSignature": "
Joe Bloggs
-
Master of Email
", - "mayDelete": false - }, - { - "id": "XD-9911312-11_22AAz", - "name": "Joe B", - "email": "*@example.com", - "replyTo": null, - "bcc": null, - "textSignature": "", - "htmlSignature": "", - "mayDelete": true - } - ], - "notFound": [] - }, "0" ] - -7. Email Submission - - An *EmailSubmission* object represents the submission of an Email for - delivery to one or more recipients. It has the following properties: - - o id: "Id" (immutable; server-set) - - The id of the EmailSubmission. - - o identityId: "Id" (immutable) - - The id of the Identity to associate with this submission. - - - - - -Jenkins & Newman Standards Track [Page 74] - -RFC 8621 JMAP Mail August 2019 - - - o emailId: "Id" (immutable) - - The id of the Email to send. The Email being sent does not have - to be a draft, for example, when "redirecting" an existing Email - to a different address. - - o threadId: "Id" (immutable; server-set) - - The Thread id of the Email to send. This is set by the server to - the "threadId" property of the Email referenced by the "emailId". - - o envelope: "Envelope|null" (immutable) - - Information for use when sending via SMTP. An *Envelope* object - has the following properties: - - * mailFrom: "Address" - - The email address to use as the return address in the SMTP - submission, plus any parameters to pass with the MAIL FROM - address. The JMAP server MAY allow the address to be the empty - string. - - When a JMAP server performs an SMTP message submission, it MAY - use the same id string for the ENVID parameter [RFC3461] and - the EmailSubmission object id. Servers that do this MAY - replace a client-provided value for ENVID with a server- - provided value. - - * rcptTo: "Address[]" - - The email addresses to send the message to, and any RCPT TO - parameters to pass with the recipient. - - An *Address* object has the following properties: - - * email: "String" - - The email address being represented by the object. This is a - "Mailbox" as used in the Reverse-path or Forward-path of the - MAIL FROM or RCPT TO command in [RFC5321]. - - * parameters: "Object|null" - - Any parameters to send with the email address (either mail- - parameter or rcpt-parameter as appropriate, as specified in - [RFC5321]). If supplied, each key in the object is a parameter - name, and the value is either the parameter value (type - - - -Jenkins & Newman Standards Track [Page 75] - -RFC 8621 JMAP Mail August 2019 - - - "String") or null if the parameter does not take a value. For - both name and value, any xtext or unitext encodings are removed - (see [RFC3461] and [RFC6533]) and JSON string encoding is - applied. - - If the "envelope" property is null or omitted on creation, the - server MUST generate this from the referenced Email as follows: - - * "mailFrom": The email address in the Sender header field, if - present; otherwise, it's the email address in the From header - field, if present. In either case, no parameters are added. - - If multiple addresses are present in one of these header - fields, or there is more than one Sender/From header field, the - server SHOULD reject the EmailSubmission as invalid; otherwise, - it MUST take the first address in the last Sender/From header - field. - - If the address found from this is not allowed by the Identity - associated with this submission, the "email" property from the - Identity MUST be used instead. - - * "rcptTo": The deduplicated set of email addresses from the To, - Cc, and Bcc header fields, if present, with no parameters for - any of them. - - o sendAt: "UTCDate" (immutable; server-set) - - The date the submission was/will be released for delivery. If the - client successfully used FUTURERELEASE [RFC4865] with the - submission, this MUST be the time when the server will release the - message; otherwise, it MUST be the time the EmailSubmission was - created. - - o undoStatus: "String" - - This represents whether the submission may be canceled. This is - server set on create and MUST be one of the following values: - - * "pending": It may be possible to cancel this submission. - - * "final": The message has been relayed to at least one recipient - in a manner that cannot be recalled. It is no longer possible - to cancel this submission. - - * "canceled": The submission was canceled and will not be - delivered to any recipient. - - - - -Jenkins & Newman Standards Track [Page 76] - -RFC 8621 JMAP Mail August 2019 - - - On systems that do not support unsending, the value of this - property will always be "final". On systems that do support - canceling submission, it will start as "pending" and MAY - transition to "final" when the server knows it definitely cannot - recall the message, but it MAY just remain "pending". If in - pending state, a client can attempt to cancel the submission by - setting this property to "canceled"; if the update succeeds, the - submission was successfully canceled, and the message has not been - delivered to any of the original recipients. - - o deliveryStatus: "String[DeliveryStatus]|null" (server-set) - - This represents the delivery status for each of the submission's - recipients, if known. This property MAY not be supported by all - servers, in which case it will remain null. Servers that support - it SHOULD update the EmailSubmission object each time the status - of any of the recipients changes, even if some recipients are - still being retried. - - This value is a map from the email address of each recipient to a - DeliveryStatus object. - - A *DeliveryStatus* object has the following properties: - - * smtpReply: "String" - - The SMTP reply string returned for this recipient when the - server last tried to relay the message, or in a later Delivery - Status Notification (DSN, as defined in [RFC3464]) response for - the message. This SHOULD be the response to the RCPT TO stage, - unless this was accepted and the message as a whole was - rejected at the end of the DATA stage, in which case the DATA - stage reply SHOULD be used instead. - - Multi-line SMTP responses should be concatenated to a single - string as follows: - - + The hyphen following the SMTP code on all but the last line - is replaced with a space. - - + Any prefix in common with the first line is stripped from - lines after the first. - - + CRLF is replaced by a space. - - - - - - - -Jenkins & Newman Standards Track [Page 77] - -RFC 8621 JMAP Mail August 2019 - - - For example: - - 550-5.7.1 Our system has detected that this message is - 550 5.7.1 likely spam. - - would become: - - 550 5.7.1 Our system has detected that this message is likely spam. - - For messages relayed via an alternative to SMTP, the server MAY - generate a synthetic string representing the status instead. - If it does this, the string MUST be of the following form: - - + A 3-digit SMTP reply code, as defined in [RFC5321], - Section 4.2.3. - - + Then a single space character. - - + Then an SMTP Enhanced Mail System Status Code as defined in - [RFC3463], with a registry defined in [RFC5248]. - - + Then a single space character. - - + Then an implementation-specific information string with a - human-readable explanation of the response. - - * delivered: "String" - - Represents whether the message has been successfully delivered - to the recipient. This MUST be one of the following values: - - + "queued": The message is in a local mail queue and the - status will change once it exits the local mail queues. The - "smtpReply" property may still change. - - + "yes": The message was successfully delivered to the mail - store of the recipient. The "smtpReply" property is final. - - + "no": Delivery to the recipient permanently failed. The - "smtpReply" property is final. - - + "unknown": The final delivery status is unknown, (e.g., it - was relayed to an external machine and no further - information is available). The "smtpReply" property may - still change if a DSN arrives. - - - - - - -Jenkins & Newman Standards Track [Page 78] - -RFC 8621 JMAP Mail August 2019 - - - Note that successful relaying to an external SMTP server SHOULD - NOT be taken as an indication that the message has successfully - reached the final mail store. In this case though, the server - may receive a DSN response, if requested. - - If a DSN is received for the recipient with Action equal to - "delivered", as per [RFC3464], Section 2.3.3, then the - "delivered" property SHOULD be set to "yes"; if the Action - equals "failed", the property SHOULD be set to "no". Receipt - of any other DSN SHOULD NOT affect this property. - - The server MAY also set this property based on other feedback - channels. - - * displayed: "String" - - Represents whether the message has been displayed to the - recipient. This MUST be one of the following values: - - + "unknown": The display status is unknown. This is the - initial value. - - + "yes": The recipient's system claims the message content has - been displayed to the recipient. Note that there is no - guarantee that the recipient has noticed, read, or - understood the content. - - If a Message Disposition Notification (MDN) is received for - this recipient with Disposition-Type (as per [RFC8098], - Section 3.2.6.2) equal to "displayed", this property SHOULD be - set to "yes". - - The server MAY also set this property based on other feedback - channels. - - o dsnBlobIds: "Id[]" (server-set) - - A list of blob ids for DSNs [RFC3464] received for this - submission, in order of receipt, oldest first. The blob is the - whole MIME message (with a top-level content-type of "multipart/ - report"), as received. - - o mdnBlobIds: "Id[]" (server-set) - - A list of blob ids for MDNs [RFC8098] received for this - submission, in order of receipt, oldest first. The blob is the - whole MIME message (with a top-level content-type of "multipart/ - report"), as received. - - - -Jenkins & Newman Standards Track [Page 79] - -RFC 8621 JMAP Mail August 2019 - - - JMAP servers MAY choose not to expose DSN and MDN responses as Email - objects if they correlate to an EmailSubmission object. It SHOULD - only do this if it exposes them in the "dsnBlobIds" and "mdnblobIds" - fields instead, and it expects the user to be using clients capable - of fetching and displaying delivery status via the EmailSubmission - object. - - For efficiency, a server MAY destroy EmailSubmission objects at any - time after the message is successfully sent or after it has finished - retrying to send the message. For very basic SMTP proxies, this MAY - be immediately after creation, as it has no way to assign a real id - and return the information again if fetched later. - - The following JMAP methods are supported. - -7.1. EmailSubmission/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. - -7.2. EmailSubmission/changes - - This is a standard "/changes" method as described in [RFC8620], - Section 5.2. - -7.3. EmailSubmission/query - - This is a standard "/query" method as described in [RFC8620], - Section 5.5. - - A *FilterCondition* object has the following properties, any of which - may be omitted: - - o identityIds: "Id[]" - - The EmailSubmission "identityId" property must be in this list to - match the condition. - - o emailIds: "Id[]" - - The EmailSubmission "emailId" property must be in this list to - match the condition. - - o threadIds: "Id[]" - - The EmailSubmission "threadId" property must be in this list to - match the condition. - - - - -Jenkins & Newman Standards Track [Page 80] - -RFC 8621 JMAP Mail August 2019 - - - o undoStatus: "String" - - The EmailSubmission "undoStatus" property must be identical to the - value given to match the condition. - - o before: "UTCDate" - - The "sendAt" property of the EmailSubmission object must be before - this date-time to match the condition. - - o after: "UTCDate" - - The "sendAt" property of the EmailSubmission object must be the - same as or after this date-time to match the condition. - - An EmailSubmission object matches the FilterCondition if and only if - all of the given conditions match. If zero properties are specified, - it is automatically true for all objects. - - The following EmailSubmission properties MUST be supported for - sorting: - - o "emailId" - - o "threadId" - - o "sentAt" - -7.4. EmailSubmission/queryChanges - - This is a standard "/queryChanges" method as described in [RFC8620], - Section 5.6. - -7.5. EmailSubmission/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3 with the following two additional request arguments: - - o onSuccessUpdateEmail: "Id[PatchObject]|null" - - A map of EmailSubmission id to an object containing properties to - update on the Email object referenced by the EmailSubmission if - the create/update/destroy succeeds. (For references to - EmailSubmissions created in the same "/set" invocation, this is - equivalent to a creation-reference, so the id will be the creation - id prefixed with a "#".) - - - - - -Jenkins & Newman Standards Track [Page 81] - -RFC 8621 JMAP Mail August 2019 - - - o onSuccessDestroyEmail: "Id[]|null" - - A list of EmailSubmission ids for which the Email with the - corresponding "emailId" should be destroyed if the create/update/ - destroy succeeds. (For references to EmailSubmission creations, - this is equivalent to a creation-reference, so the id will be the - creation id prefixed with a "#".) - - After all create/update/destroy items in the "EmailSubmission/set" - invocation have been processed, a single implicit "Email/set" call - MUST be made to perform any changes requested in these two arguments. - The response to this MUST be returned after the "EmailSubmission/set" - response. - - An Email is sent by creating an EmailSubmission object. When - processing each create, the server must check that the message is - valid, and the user has sufficient authorisation to send it. If the - creation succeeds, the message will be sent to the recipients given - in the envelope "rcptTo" parameter. The server MUST remove any Bcc - header field present on the message during delivery. The server MAY - add or remove other header fields from the submitted message or make - further alterations in accordance with the server's policy during - delivery. - - If the referenced Email is destroyed at any point after the - EmailSubmission object is created, this MUST NOT change the behaviour - of the submission (i.e., it does not cancel a future send). The - "emailId" and "threadId" properties of the EmailSubmission object - remain, but trying to fetch them (with a standard "Email/get" call) - will return a "notFound" error if the corresponding objects have been - destroyed. - - Similarly, destroying an EmailSubmission object MUST NOT affect the - deliveries it represents. It purely removes the record of the - submission. The server MAY automatically destroy EmailSubmission - objects after some time or in response to other triggers, and MAY - forbid the client from manually destroying EmailSubmission objects. - - If the message to be sent is larger than the server supports sending, - a standard "tooLarge" SetError MUST be returned. A "maxSize" - "UnsignedInt" property MUST be present on the SetError specifying the - maximum size of a message that may be sent, in octets. - - If the Email or Identity id given cannot be found, the submission - creation is rejected with a standard "invalidProperties" SetError. - - - - - - -Jenkins & Newman Standards Track [Page 82] - -RFC 8621 JMAP Mail August 2019 - - - The following extra SetError types are defined: - - For "create": - - o "invalidEmail" - The Email to be sent is invalid in some way. The - SetError SHOULD contain a property called "properties" of type - "String[]" that lists *all* the properties of the Email that were - invalid. - - o "tooManyRecipients" - The envelope (supplied or generated) has - more recipients than the server allows. A "maxRecipients" - "UnsignedInt" property MUST also be present on the SetError - specifying the maximum number of allowed recipients. - - o "noRecipients" - The envelope (supplied or generated) does not - have any rcptTo email addresses. - - o "invalidRecipients" - The "rcptTo" property of the envelope - (supplied or generated) contains at least one rcptTo value, which - is not a valid email address for sending to. An - "invalidRecipients" "String[]" property MUST also be present on - the SetError, which is a list of the invalid addresses. - - o "forbiddenMailFrom" - The server does not permit the user to send - a message with the envelope From address [RFC5321]. - - o "forbiddenFrom" - The server does not permit the user to send a - message with the From header field [RFC5322] of the message to be - sent. - - o "forbiddenToSend" - The user does not have permission to send at - all right now for some reason. A "description" "String" property - MAY be present on the SetError object to display to the user why - they are not permitted. - - For "update": - - o "cannotUnsend" - The client attempted to update the "undoStatus" - of a valid EmailSubmission object from "pending" to "canceled", - but the message cannot be unsent. - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 83] - -RFC 8621 JMAP Mail August 2019 - - -7.5.1. Example - - The following example presumes a draft of the Email to be sent has - already been saved, and its Email id is "M7f6ed5bcfd7e2604d1753f6c". - This call then sends the Email immediately, and if successful, - removes the "$draft" flag and moves it from the drafts folder (which - has Mailbox id "7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e") to the sent - folder (which we presume has Mailbox id "73dbcb4b-bffc-48bd-8c2a- - a2e91ca672f6"). - - [[ "EmailSubmission/set", { - "accountId": "ue411d190", - "create": { - "k1490": { - "identityId": "I64588216", - "emailId": "M7f6ed5bcfd7e2604d1753f6c", - "envelope": { - "mailFrom": { - "email": "john@example.com", - "parameters": null - }, - "rcptTo": [{ - "email": "jane@example.com", - "parameters": null - }, - ... - ] - } - } - }, - "onSuccessUpdateEmail": { - "#k1490": { - "mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null, - "mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true, - "keywords/$draft": null - } - } - }, "0" ]] - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 84] - -RFC 8621 JMAP Mail August 2019 - - - A successful response might look like this. Note that there are two - responses due to the implicit "Email/set" call, but both have the - same method call id as they are due to the same call in the request: - - [[ "EmailSubmission/set", { - "accountId": "ue411d190", - "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", - "newState": "355421f6-8aed-4cf4-a0c4-7377e951af36", - "created": { - "k1490": { - "id": "ES-3bab7f9a-623e-4acf-99a5-2e67facb02a0" - } - } - }, "0" ], - [ "Email/set", { - "accountId": "ue411d190", - "oldState": "778193", - "newState": "778197", - "updated": { - "M7f6ed5bcfd7e2604d1753f6c": null - } - }, "0" ]] - - Suppose instead an admin has removed sending rights for the user, so - the submission is rejected with a "forbiddenToSend" error. The - description argument of the error is intended for display to the - user, so it should be localised appropriately. Let's suppose the - request was sent with an Accept-Language header like this: - - Accept-Language: de;q=0.9,en;q=0.8 - - - - - - - - - - - - - - - - - - - - - -Jenkins & Newman Standards Track [Page 85] - -RFC 8621 JMAP Mail August 2019 - - - The server should attempt to choose the best localisation from those - it has available based on the Accept-Language header, as described in - [RFC8620], Section 3.8. If the server has English, French, and - German translations, it would choose German as the preferred language - and return a response like this: - -[[ "EmailSubmission/set", { - "accountId": "ue411d190", - "oldState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", - "newState": "012421s6-8nrq-4ps4-n0p4-9330r951ns21", - "notCreated": { - "k1490": { - "type": "forbiddenToSend", - "description": "Verzeihung, wegen verdaechtiger Aktivitaeten Ihres - Benutzerkontos haben wir den Versand von Nachrichten gesperrt. - Bitte wenden Sie sich fuer Hilfe an unser Support Team." - } - } -}, "0" ]] - -8. Vacation Response - - A vacation response sends an automatic reply when a message is - delivered to the mail store, informing the original sender that their - message may not be read for some time. - - Automated message sending can produce undesirable behaviour. To - avoid this, implementors MUST follow the recommendations set forth in - [RFC3834]. - - The *VacationResponse* object represents the state of vacation- - response-related settings for an account. It has the following - properties: - - o id: "Id" (immutable; server-set) - - The id of the object. There is only ever one VacationResponse - object, and its id is "singleton". - - o isEnabled: "Boolean" - - Should a vacation response be sent if a message arrives between - the "fromDate" and "toDate"? - - - - - - - - -Jenkins & Newman Standards Track [Page 86] - -RFC 8621 JMAP Mail August 2019 - - - o fromDate: "UTCDate|null" - - If "isEnabled" is true, messages that arrive on or after this - date-time (but before the "toDate" if defined) should receive the - user's vacation response. If null, the vacation response is - effective immediately. - - o toDate: "UTCDate|null" - - If "isEnabled" is true, messages that arrive before this date-time - (but on or after the "fromDate" if defined) should receive the - user's vacation response. If null, the vacation response is - effective indefinitely. - - o subject: "String|null" - - The subject that will be used by the message sent in response to - messages when the vacation response is enabled. If null, an - appropriate subject SHOULD be set by the server. - - o textBody: "String|null" - - The plaintext body to send in response to messages when the - vacation response is enabled. If this is null, the server SHOULD - generate a plaintext body part from the "htmlBody" when sending - vacation responses but MAY choose to send the response as HTML - only. If both "textBody" and "htmlBody" are null, an appropriate - default body SHOULD be generated for responses by the server. - - o htmlBody: "String|null" - - The HTML body to send in response to messages when the vacation - response is enabled. If this is null, the server MAY choose to - generate an HTML body part from the "textBody" when sending - vacation responses or MAY choose to send the response as plaintext - only. - - The following JMAP methods are supported. - -8.1. VacationResponse/get - - This is a standard "/get" method as described in [RFC8620], - Section 5.1. - - There MUST only be exactly one VacationResponse object in an account. - It MUST have the id "singleton". - - - - - -Jenkins & Newman Standards Track [Page 87] - -RFC 8621 JMAP Mail August 2019 - - -8.2. VacationResponse/set - - This is a standard "/set" method as described in [RFC8620], - Section 5.3. - -9. Security Considerations - - All security considerations of JMAP [RFC8620] apply to this - specification. Additional considerations specific to the data types - and functionality introduced by this document are described in the - following subsections. - -9.1. EmailBodyPart Value - - Service providers typically perform security filtering on incoming - messages, and it's important that the detection of content-type and - charset for the security filter aligns with the heuristics performed - by JMAP servers. Servers that apply heuristics to determine the - content-type or charset for an EmailBodyValue SHOULD document the - heuristics and provide a mechanism to turn them off in the event they - are misaligned with the security filter used at a particular mail - host. - - Automatic conversion of charsets that allow hidden channels for ASCII - text, such as UTF-7, have been problematic for security filters in - the past, so server implementations can mitigate this risk by having - such conversions off-by-default and/or separately configurable. - - To allow the client to restrict the volume of data it can receive in - response to a request, a maximum length may be requested for the data - returned for a textual body part. However, truncating the data may - change the semantic meaning, for example, truncating a URL changes - its location. Servers that scan for links to malicious sites should - take care to either ensure truncation is not at a semantically - significant point or rescan the truncated value for malicious content - before returning it. - -9.2. HTML Email Display - - HTML message bodies provide richer formatting for messages but - present a number of security challenges, especially when embedded in - a webmail context in combination with interface HTML. Clients that - render HTML messages should carefully consider the potential risks, - including: - - - - - - - -Jenkins & Newman Standards Track [Page 88] - -RFC 8621 JMAP Mail August 2019 - - - o Embedded JavaScript can rewrite the message to change its content - on subsequent opening, allowing users to be mislead. In webmail - systems, if run in the same origin as the interface, it can access - and exfiltrate all private data accessible to the user, including - all other messages and potentially contacts, calendar events, - settings, and credentials. It can also rewrite the interface to - undetectably phish passwords. A compromise is likely to be - persistent, not just for the duration of page load, due to - exfiltration of session credentials or installation of a service - worker that can intercept all subsequent network requests - (however, this would only be possible if blob downloads are also - available on the same origin, and the service worker script is - attached to the message). - - o HTML documents may load content directly from the Internet rather - than just referencing attached resources. For example, you may - have an "" tag with an external "src" attribute. This may - leak to the sender when a message is opened, as well as the IP - address of the recipient. Cookies may also be sent and set by the - server, allowing tracking between different messages and even - website visits and advertising profiles. - - o In webmail systems, CSS can break the layout or create phishing - vulnerabilities. For example, the use of "position:fixed" can - allow a message to draw content outside of its normal bounds, - potentially clickjacking a real interface element. - - o If in a webmail context and not inside a separate frame, any - styles defined in CSS rules will apply to interface elements as - well if the selector matches, allowing the interface to be - modified. Similarly, any interface styles that match elements in - the message will alter their appearance, potentially breaking the - layout of the message. - - o The link text in HTML has no necessary correlation with the actual - target of the link, which can be used to make phishing attacks - more convincing. - - o Links opened from a message or embedded external content may leak - private info in the Referer header sent by default in most - systems. - - o Forms can be used to mimic login boxes, providing a potent - phishing vector if allowed to submit directly from the message - display. - - - - - - -Jenkins & Newman Standards Track [Page 89] - -RFC 8621 JMAP Mail August 2019 - - - There are a number of ways clients can mitigate these issues, and a - defence-in-depth approach that uses a combination of techniques will - provide the strongest security. - - o HTML can be filtered before rendering, stripping potentially - malicious content. Sanitising HTML correctly is tricky, and - implementors are strongly recommended to use a well-tested library - with a carefully vetted whitelist-only approach. New features - with unexpected security characteristics may be added to HTML - rendering engines in the future; a blacklist approach is likely to - result in security issues. - - Subtle differences in parsing of HTML can introduce security - flaws: to filter with 100% accuracy, you need to use the same - parser that the HTML rendering engine will use. - - o Encapsulating the message in an "