diff --git a/.gitignore b/.gitignore index f70b6fde..fd6cd363 100644 --- a/.gitignore +++ b/.gitignore @@ -23,7 +23,6 @@ # misc .DS_Store *.pem -/specifications/ # debug npm-debug.log* diff --git a/specifications/addon-plugin-theme-concept.md b/specifications/addon-plugin-theme-concept.md new file mode 100644 index 00000000..801ee8c9 --- /dev/null +++ b/specifications/addon-plugin-theme-concept.md @@ -0,0 +1,937 @@ +# Addons, Plugins & Themes — Architecture Concept + +> **Status**: Draft Concept +> **Date**: 2026-03-13 + +--- + +## Table of Contents + +1. [Overview](#1-overview) +2. [Terminology](#2-terminology) +3. [Manifest Format](#3-manifest-format) +4. [Themes](#4-themes) +5. [Plugins](#5-plugins) +6. [Addon Lifecycle](#6-addon-lifecycle) +7. [Extension Points (Hooks & Slots)](#7-extension-points-hooks--slots) +8. [Security & Sandboxing](#8-security--sandboxing) +9. [Storage & Distribution](#9-storage--distribution) +10. [Settings Integration](#10-settings-integration) +11. [API Surface](#11-api-surface) +12. [Migration Path](#12-migration-path) + +--- + +## 1. Overview + +This document describes a system that allows the JMAP Webmail application to be extended through **themes** (visual customization) and **plugins** (functional extensions). Together, these are called **addons**. + +### Design Goals + +- **Safe by default** — addons cannot break core functionality or access data beyond their declared scope. +- **Zero-config for users** — install, enable, done. No code changes to the host app. +- **Declarative where possible** — prefer JSON/CSS-based customization over imperative code. +- **Aligned with existing architecture** — builds on Zustand stores, React context/providers, CSS variables, and the Next.js App Router patterns already in use. +- **Incrementally adoptable** — the core app can ship without any addons; the addon system is a layer on top. + +### Non-Goals (for v1) + +- Server-side plugin execution (all addons run client-side). +- A public addon marketplace (addons are self-hosted or bundled). +- Modifying JMAP protocol behavior (addons consume JMAP data, not intercept it). + +--- + +## 2. Terminology + +| Term | Definition | +|------|-----------| +| **Addon** | Any installable extension — umbrella term for themes and plugins. | +| **Theme** | An addon that only customizes visual appearance (colors, fonts, spacing, density). Ships as CSS + a manifest. Contains no executable code. | +| **Plugin** | An addon that adds or modifies functionality. Ships as a JS/TS module + a manifest. May include a theme. | +| **Slot** | A named insertion point in the UI where plugins can render components. | +| **Hook Point** | A named event or state transition where plugins can run logic. | +| **Manifest** | A `addon.json` file that declares metadata, permissions, and extension points. | + +--- + +## 3. Manifest Format + +Every addon has an `addon.json` at its root: + +```jsonc +{ + // ── Identity ── + "id": "com.example.my-addon", // Reverse-domain unique ID + "name": "My Addon", + "version": "1.0.0", // Semver + "description": "A brief description.", + "author": { + "name": "Jane Doe", + "url": "https://example.com" + }, + "license": "MIT", + "homepage": "https://example.com/my-addon", + + // ── Compatibility ── + "engine": { + "webmail": ">=1.0.0" // Required host app version range + }, + + // ── Type ── + "type": "plugin", // "theme" | "plugin" + + // ── Entry Points (plugins only) ── + "main": "dist/index.js", // Plugin entry module + "styles": "dist/styles.css", // Optional supplementary CSS + + // ── Theme Definition (themes, or plugins that include a theme) ── + "theme": { + "variables": "theme.css", // CSS file with variable overrides + "presets": ["light", "dark"], // Which base modes it provides + "preview": "preview.png" // Screenshot for settings UI + }, + + // ── Permissions (plugins only) ── + "permissions": [ + "emails:read", // Read email data from store + "emails:write", // Modify email data (move, flag, etc.) + "contacts:read", + "calendar:read", + "settings:read", + "settings:write", + "notifications", // Show toasts / browser notifications + "compose:toolbar", // Add buttons to composer toolbar + "sidebar:section", // Add sections to the sidebar + "viewer:action", // Add actions to email viewer toolbar + "navigation:tab", // Add a top-level navigation tab + "context-menu:email", // Extend email context menu + "keyboard-shortcuts", // Register keyboard shortcuts + "external-fetch" // Fetch external URLs (declared origins) + ], + + // ── External Origins (if external-fetch permission is declared) ── + "allowedOrigins": [ + "https://api.example.com" + ], + + // ── Slots (declares which UI slots the plugin uses) ── + "slots": [ + "sidebar.bottom", + "compose.toolbar", + "viewer.actions" + ], + + // ── Settings Schema (plugin-specific preferences) ── + "settings": { + "apiKey": { + "type": "string", + "label": "API Key", + "description": "Your API key for the service.", + "secret": true + }, + "enabled": { + "type": "boolean", + "label": "Enable integration", + "default": true + } + }, + + // ── i18n ── + "locales": "locales/" // Directory with {locale}.json files +} +``` + +--- + +## 4. Themes + +Themes are the simplest addon type — pure CSS, no executable code. + +### 4.1 How Themes Work + +The app already uses CSS custom properties (variables) for all colors, defined in `globals.css` under `:root` and `.dark`. A theme overrides these variables: + +```css +/* theme.css — "Nord" theme example */ + +:root[data-theme="com.example.nord"] { + --color-background: #eceff4; + --color-foreground: #2e3440; + --color-primary: #5e81ac; + --color-primary-foreground: #eceff4; + --color-border: #d8dee9; + --color-sidebar-bg: #e5e9f0; + --color-sidebar-hover: #d8dee9; + --color-muted: #4c566a; + --color-accent: #88c0d0; + --color-destructive: #bf616a; + + /* Extended variables for advanced customization */ + --font-family-base: "Inter", sans-serif; + --font-family-mono: "JetBrains Mono", monospace; + --radius-base: 8px; + --spacing-density: 1; /* 0.8 = compact, 1 = normal, 1.2 = comfortable */ + --shadow-elevation-1: 0 1px 3px rgba(0,0,0,0.08); +} + +:root[data-theme="com.example.nord"].dark { + --color-background: #2e3440; + --color-foreground: #eceff4; + --color-primary: #88c0d0; + --color-border: #3b4252; + --color-sidebar-bg: #3b4252; + --color-sidebar-hover: #434c5e; +} +``` + +### 4.2 Theme Application + +``` +User selects theme in Settings → Appearance + → ThemeStore sets `activeTheme: "com.example.nord"` + → + → Theme CSS is loaded via a tag with the theme's CSS file + → CSS specificity ensures theme variables override defaults +``` + +### 4.3 Theme Capabilities + +| Capability | Mechanism | +|-----------|-----------| +| Colors | Override `--color-*` CSS variables | +| Typography | Override `--font-family-*` variables | +| Spacing/density | Override `--spacing-density` multiplier | +| Border radius | Override `--radius-*` variables | +| Shadows | Override `--shadow-*` variables | +| Dark mode variant | Provide `.dark` overrides | +| Tag/label colors | Override `--tag-color-*` palette | +| Custom CSS | Additional rules scoped under `[data-theme="..."]` | + +### 4.4 Theme Constraints + +- Themes **cannot** add or remove DOM elements. +- Themes **cannot** execute JavaScript. +- Themes **cannot** override layout structure (flexbox directions, grid templates). +- Theme CSS is scoped by `[data-theme]` attribute — removing the attribute instantly reverts to defaults. +- A maximum CSS file size is enforced (e.g., 100 KB) to prevent abuse. + +--- + +## 5. Plugins + +Plugins are JavaScript modules that interact with the app through a controlled API. + +### 5.1 Plugin Entry Point + +A plugin exports a single `activate` function and optionally a `deactivate` function: + +```ts +// index.ts — Plugin entry point +import type { PluginContext } from "@jmap-webmail/addon-api"; + +export function activate(ctx: PluginContext) { + // Register a sidebar section + ctx.slots.register("sidebar.bottom", { + component: MySidebarWidget, + priority: 10, + }); + + // Register a composer toolbar button + ctx.slots.register("compose.toolbar", { + component: EncryptButton, + priority: 50, + }); + + // Listen to store changes + ctx.hooks.on("email:selected", (email) => { + // React to email selection + }); + + // Register a keyboard shortcut + ctx.shortcuts.register({ + key: "g t", + description: "Open translation panel", + action: () => ctx.panels.open("translate"), + }); + + // Add a context menu item + ctx.contextMenu.register("email", { + label: ctx.i18n.t("translateEmail"), + icon: "Languages", + action: (emailId) => { /* ... */ }, + }); +} + +export function deactivate(ctx: PluginContext) { + // Cleanup — called when the plugin is disabled or uninstalled. + // All slot registrations and event subscriptions are + // automatically cleaned up, so this is only needed + // for external resource cleanup. +} +``` + +### 5.2 PluginContext API + +The `PluginContext` object is the plugin's only interface to the host app. It is scoped and sandboxed based on the declared permissions: + +```ts +interface PluginContext { + /** Plugin metadata from manifest */ + manifest: AddonManifest; + + /** UI slot registration */ + slots: { + register(slotId: string, registration: SlotRegistration): Disposable; + }; + + /** Event hooks */ + hooks: { + on(event: HookEvent, handler: Function): Disposable; + once(event: HookEvent, handler: Function): Disposable; + }; + + /** Store access (read-only or read-write based on permissions) */ + stores: { + emails: PluginEmailStore; // If emails:read or emails:write + contacts: PluginContactStore; // If contacts:read + calendar: PluginCalendarStore; // If calendar:read + settings: PluginSettingsStore; // If settings:read or settings:write + }; + + /** Plugin-specific settings (defined in manifest "settings" schema) */ + config: { + get(key: string): T; + set(key: string, value: unknown): void; + onChange(key: string, handler: (value: unknown) => void): Disposable; + }; + + /** Toast notifications */ + notifications: { + success(message: string): void; + error(message: string): void; + info(message: string): void; + }; + + /** i18n — scoped to plugin's locale files */ + i18n: { + t(key: string, params?: Record): string; + locale: string; + }; + + /** Keyboard shortcuts */ + shortcuts: { + register(shortcut: ShortcutDefinition): Disposable; + }; + + /** Context menu extensions */ + contextMenu: { + register(target: ContextMenuTarget, item: ContextMenuItem): Disposable; + }; + + /** Panel API — open side panels or modals */ + panels: { + open(panelId: string, props?: Record): void; + close(panelId: string): void; + register(panelId: string, component: React.ComponentType): Disposable; + }; + + /** Scoped fetch — only allowed origins from manifest */ + fetch(url: string, init?: RequestInit): Promise; +} +``` + +### 5.3 Disposable Pattern + +All registrations return a `Disposable` object. On plugin deactivation, all disposables are automatically cleaned up: + +```ts +interface Disposable { + dispose(): void; +} +``` + +--- + +## 6. Addon Lifecycle + +``` +┌──────────────────────────────────────────────────────────┐ +│ Addon Lifecycle │ +├──────────────────────────────────────────────────────────┤ +│ │ +│ ┌─────────┐ install ┌───────────┐ enable │ +│ │ Store │────────────▶│ Installed │──────────┐ │ +│ │ / URL │ │ (disabled) │ │ │ +│ └─────────┘ └───────────┘ ▼ │ +│ ▲ ┌──────────┐ │ +│ disable│ │ Active │ │ +│ │ │(running) │ │ +│ └───────────┤ │ │ +│ └──────────┘ │ +│ │ ▲ │ +│ uninstall update│ │ +│ │ │ │ +│ ▼ ┌────┴─────┐ │ +│ ┌────────┐ │ Updating │ │ +│ │Removed │ └──────────┘ │ +│ └────────┘ │ +│ │ +└──────────────────────────────────────────────────────────┘ +``` + +### 6.1 Loading Sequence + +1. **Boot**: App starts, `AddonManager` reads the addon registry from `localStorage` (list of installed addons + enabled state). +2. **Resolve**: For each enabled addon, load its manifest and verify compatibility (`engine.webmail`). +3. **Load Themes**: Inject theme CSS `` for the active theme. +4. **Load Plugins**: Dynamically import each plugin's `main` entry point. +5. **Activate**: Call `activate(ctx)` for each plugin, passing a scoped `PluginContext`. +6. **Ready**: Emit `app:ready` hook — plugins can now interact with stores. + +### 6.2 Addon Manager Store + +A new Zustand store manages addon state: + +```ts +interface AddonManagerState { + /** Registry of all installed addons */ + addons: Record; + + /** Currently active theme ID (null = default) */ + activeTheme: string | null; + + /** Actions */ + installAddon(source: AddonSource): Promise; + uninstallAddon(id: string): void; + enableAddon(id: string): void; + disableAddon(id: string): void; + setActiveTheme(id: string | null): void; + getAddon(id: string): InstalledAddon | undefined; + getEnabledPlugins(): InstalledAddon[]; +} + +interface InstalledAddon { + manifest: AddonManifest; + enabled: boolean; + installedAt: string; // ISO timestamp + source: AddonSource; // Where it was loaded from + runtimeState: "inactive" | "active" | "error"; + error?: string; // Last activation error +} + +type AddonSource = + | { type: "bundled" } // Shipped with the app + | { type: "url"; url: string } // Loaded from a URL + | { type: "local"; path: string }; // Development: local file +``` + +--- + +## 7. Extension Points (Hooks & Slots) + +### 7.1 UI Slots + +Slots are named insertion points scattered across the UI. The host app renders a `` component at each point; plugins register components into slots. + +```tsx +// Host app — in sidebar.tsx +import { Slot } from "@/components/addons/slot"; + +function Sidebar() { + return ( + + ); +} +``` + +```tsx +// Slot component implementation +function Slot({ name }: { name: string }) { + const registrations = useAddonSlot(name); + if (registrations.length === 0) return null; + + return ( + <> + {registrations + .sort((a, b) => a.priority - b.priority) + .map((reg) => ( + + + + ))} + + ); +} +``` + +#### Available Slots + +| Slot Name | Location | Use Case | +|-----------|----------|----------| +| `sidebar.top` | Top of sidebar, below compose button | Quick-access widgets | +| `sidebar.bottom` | Bottom of sidebar, above storage quota | Extra navigation, widgets | +| `navigation.tabs` | Navigation rail, below contacts icon | New top-level views | +| `compose.toolbar` | Composer toolbar (formatting bar) | Encrypt, translate, AI assist buttons | +| `compose.footer` | Below composer body, above send button | Send-time options (delay, schedule) | +| `viewer.actions` | Email viewer toolbar | Custom actions (translate, summarize) | +| `viewer.header` | Above email body in viewer | Banners, warnings, metadata | +| `viewer.footer` | Below email body in viewer | Related content, suggestions | +| `list.toolbar` | Above email list | Additional filters, bulk actions | +| `settings.sections` | Settings page, below existing sections | Plugin settings panels | +| `calendar.toolbar` | Calendar view toolbar | Calendar-specific actions | +| `contacts.toolbar` | Contacts view toolbar | Contact-specific actions | + +### 7.2 Hook Events + +Plugins can listen to app events and state transitions: + +#### Email Hooks + +| Event | Payload | Description | +|-------|---------|-------------| +| `email:selected` | `{ emailId, email }` | User selected an email | +| `email:opened` | `{ emailId, email }` | Email viewer rendered | +| `email:compose:open` | `{ mode, replyTo? }` | Composer opened | +| `email:compose:before-send` | `{ draft }` | Before sending — can modify draft | +| `email:compose:sent` | `{ emailId }` | Email sent successfully | +| `email:moved` | `{ emailId, from, to }` | Email moved between mailboxes | +| `email:deleted` | `{ emailId }` | Email deleted | +| `email:flagged` | `{ emailId, flags }` | Email flags changed | + +#### Calendar Hooks + +| Event | Payload | Description | +|-------|---------|-------------| +| `calendar:event:created` | `{ event }` | New event created | +| `calendar:event:updated` | `{ event, changes }` | Event modified | +| `calendar:event:deleted` | `{ eventId }` | Event deleted | +| `calendar:view:changed` | `{ view, date }` | Calendar view switched | + +#### Contact Hooks + +| Event | Payload | Description | +|-------|---------|-------------| +| `contact:selected` | `{ contactId }` | Contact selected | +| `contact:created` | `{ contact }` | New contact created | +| `contact:updated` | `{ contact }` | Contact modified | + +#### App Hooks + +| Event | Payload | Description | +|-------|---------|-------------| +| `app:ready` | `{}` | App fully loaded | +| `app:theme:changed` | `{ theme }` | Theme switched | +| `app:locale:changed` | `{ locale }` | Language changed | +| `app:navigation` | `{ from, to }` | User navigated between views | + +--- + +## 8. Security & Sandboxing + +### 8.1 Permission Model + +Plugins declare required permissions in their manifest. On installation, the user sees a permission prompt: + +``` +"My Translation Plugin" requests: + ✉️ Read your emails + 🔔 Show notifications + 🌐 Connect to https://api.translate.example.com + + [Allow] [Cancel] +``` + +Permissions are enforced at the `PluginContext` level — if a plugin didn't declare `emails:read`, `ctx.stores.emails` is `undefined`. + +### 8.2 Sandboxing Strategy + +| Layer | Mechanism | +|-------|-----------| +| **Store access** | `PluginContext` exposes only permitted store slices. Write access returns proxied objects — mutations are validated before applying. | +| **DOM access** | Plugin components render inside an ``. They receive a scoped React tree — no direct `document` manipulation. | +| **Network** | `ctx.fetch()` is a controlled wrapper. Requests are only allowed to origins listed in `allowedOrigins`. All other `fetch` / `XMLHttpRequest` calls from plugin code are blocked via CSP headers. | +| **Storage** | Plugins use `ctx.config` (backed by a namespaced key in `localStorage`). No direct `localStorage` / `sessionStorage` access. | +| **Error isolation** | Each plugin slot is wrapped in an `AddonErrorBoundary`. A crashing plugin is caught and disabled without affecting the rest of the app. | +| **Resource limits** | Plugin CSS is limited to 100 KB. Plugin JS bundles are limited to 500 KB (configurable). | + +### 8.3 Content Security Policy + +Theme CSS is sanitized to disallow: +- `url()` references to external domains (only data URIs and same-origin). +- `@import` statements. +- `expression()` or `behavior:` (legacy IE attack vectors). + +### 8.4 Error Boundary + +```tsx +function AddonErrorBoundary({ addonId, children }) { + return ( + } + onError={(error) => { + console.error(`[Addon: ${addonId}] Crashed:`, error); + addonManager.reportError(addonId, error); + // Auto-disable after 3 crashes in 5 minutes + }} + > + {children} + + ); +} +``` + +--- + +## 9. Storage & Distribution + +### 9.1 Addon Formats + +| Format | Description | Use Case | +|--------|-------------|----------| +| **Bundled** | Shipped inside the app's `/addons/` directory | Default themes, first-party plugins | +| **URL** | Loaded from a remote URL at runtime | Self-hosted or third-party addons | +| **Local file** | Loaded from a local path (dev mode only) | Plugin development | + +### 9.2 Addon Bundle Structure + +``` +my-addon/ +├── addon.json # Manifest (required) +├── dist/ +│ ├── index.js # Plugin entry (plugins only) +│ └── styles.css # Additional styles (optional) +├── theme.css # Theme variables (themes only) +├── preview.png # Theme preview image (optional) +└── locales/ + ├── en.json # English strings + ├── fr.json # French strings + └── ... +``` + +### 9.3 Built-in Addon Directory + +``` +addons/ +├── themes/ +│ ├── nord/ +│ │ ├── addon.json +│ │ ├── theme.css +│ │ └── preview.png +│ ├── dracula/ +│ ├── solarized/ +│ ├── catppuccin/ +│ └── high-contrast/ +└── plugins/ + └── (none bundled by default) +``` + +### 9.4 Installation Flow + +**From URL:** +1. User pastes addon URL into Settings → Addons → "Install from URL". +2. App fetches `{url}/addon.json`, validates schema and compatibility. +3. Manifest is stored in addon registry (`localStorage`). +4. On next activation, the addon's assets are fetched and cached. + +**Bundled:** +1. Addons in `/addons/` are auto-discovered at build time. +2. A generated `addon-registry.json` maps addon IDs to their local paths. +3. Bundled addons appear pre-installed (but can be disabled). + +--- + +## 10. Settings Integration + +### 10.1 Addon Settings Page + +A new page at `/settings/addons` integrates into the existing settings layout: + +``` +Settings +├── Appearance +├── Language & Region +├── Email +├── Composer +├── Calendar +├── Privacy & Security +├── Keyboard Shortcuts +├── Addons ← NEW +│ ├── Themes +│ │ ├── Default (active) +│ │ ├── Nord +│ │ ├── Dracula +│ │ └── [Install Theme...] +│ ├── Plugins +│ │ ├── Translation Plugin (enabled) [Settings] [Disable] +│ │ ├── PGP Encryption (disabled) [Enable] [Uninstall] +│ │ └── [Install Plugin...] +│ └── Developer +│ └── [Load from local path...] +``` + +### 10.2 Plugin-Specific Settings + +Plugins declare their settings schema in `addon.json`. The app auto-generates a settings UI: + +```jsonc +// In addon.json +"settings": { + "provider": { + "type": "select", + "label": "Translation Provider", + "options": [ + { "value": "deepl", "label": "DeepL" }, + { "value": "google", "label": "Google Translate" } + ], + "default": "deepl" + }, + "targetLanguage": { + "type": "select", + "label": "Default Target Language", + "options": "locales", // Special: populated from app locales + "default": "en" + }, + "autoTranslate": { + "type": "boolean", + "label": "Auto-translate foreign emails", + "default": false + } +} +``` + +Supported setting types: `string`, `boolean`, `number`, `select`, `multiselect`, `color`, `secret` (masked input). + +### 10.3 Theme Selector + +The existing Appearance settings page gains a theme gallery: + +``` +Appearance +├── Theme: [Default ▾] ← dropdown with installed themes +│ Preview: [████████████████] ← live color preview strip +├── Mode: Light / Dark / System +├── Font Size: Small / Medium / Large +└── ... +``` + +When a theme is selected, the app: +1. Sets `data-theme` attribute on ``. +2. Loads the theme's CSS file. +3. Persists the choice in `ThemeStore`. + +--- + +## 11. API Surface + +### 11.1 Core Registry (`AddonRegistry`) + +```ts +class AddonRegistry { + /** Register a slot for plugin component injection */ + defineSlot(name: string, options?: SlotOptions): void; + + /** Get all registrations for a slot */ + getSlotRegistrations(name: string): SlotRegistration[]; + + /** Subscribe to slot changes (for reactive rendering) */ + onSlotChange(name: string, cb: () => void): Disposable; + + /** Emit a hook event to all listening plugins */ + emitHook(event: string, payload: unknown): void; + + /** Emit a hook event that plugins can modify (pipeline) */ + emitHookPipeline(event: string, value: T): T; +} +``` + +### 11.2 Hook Pipeline (Interceptors) + +Some hooks allow plugins to transform data flowing through them. For example, `email:compose:before-send` lets plugins modify the draft before it's sent: + +```ts +// Plugin: auto-add disclaimer +ctx.hooks.on("email:compose:before-send", (draft) => { + return { + ...draft, + htmlBody: draft.htmlBody + "

Sent from JMAP Webmail

", + }; +}); +``` + +Pipeline hooks execute in priority order. If any handler throws, the pipeline is aborted and the action is cancelled (with a notification to the user). + +### 11.3 React Hooks for Addon Developers + +```ts +// Available inside plugin components: + +/** Access the plugin's scoped context */ +usePluginContext(): PluginContext; + +/** Access plugin-specific settings (reactive) */ +usePluginConfig(key: string): [T, (value: T) => void]; + +/** Access plugin's i18n */ +usePluginI18n(): { t: (key: string, params?: Record) => string }; + +/** Access host app theme info */ +useHostTheme(): { mode: "light" | "dark"; resolvedMode: "light" | "dark" }; +``` + +--- + +## 12. Migration Path + +### Phase 1: Foundation + +- [ ] Define the complete `addon.json` schema with JSON Schema validation. +- [ ] Create the `AddonManagerStore` (Zustand store for managing installed addons). +- [ ] Extend `ThemeStore` with `activeTheme` and `data-theme` attribute management. +- [ ] Implement CSS variable injection for themes. +- [ ] Add 3–5 bundled themes (Nord, Dracula, Solarized, Catppuccin, High Contrast). +- [ ] Add the theme selector to Settings → Appearance. + +### Phase 2: Plugin Infrastructure + +- [ ] Implement the `` component and `AddonErrorBoundary`. +- [ ] Add `` insertion points to the 12 defined locations in the UI. +- [ ] Build the `PluginContext` factory with permission-gated store access. +- [ ] Implement the hook event system (`emitHook`, `emitHookPipeline`). +- [ ] Create the Settings → Addons page with install/enable/disable/uninstall UI. +- [ ] Implement auto-generated settings UI from plugin settings schema. + +### Phase 3: Developer Experience + +- [ ] Create `@jmap-webmail/addon-api` — TypeScript type definitions package. +- [ ] Create `create-jmap-addon` CLI scaffolding tool. +- [ ] Write addon developer documentation with examples. +- [ ] Build a sample plugin (e.g., email translation) as a reference. +- [ ] Add dev mode: hot-reload addons from local filesystem. + +### Phase 4: Hardening + +- [ ] Security audit of the sandboxing layer. +- [ ] CSP header configuration for addon CSS/JS. +- [ ] Rate limiting for hook events (prevent infinite loops). +- [ ] Performance budgets: measure and enforce bundle size + render time limits. +- [ ] Auto-disable addons that crash repeatedly. + +--- + +## Appendix: Example Addons + +### A. Theme: "Nord" + +``` +nord-theme/ +├── addon.json +├── theme.css +└── preview.png +``` + +`addon.json`: +```json +{ + "id": "org.nordtheme.jmap-webmail", + "name": "Nord", + "version": "1.0.0", + "type": "theme", + "description": "An arctic, north-bluish color palette.", + "author": { "name": "Arctic Ice Studio" }, + "license": "MIT", + "engine": { "webmail": ">=1.0.0" }, + "theme": { + "variables": "theme.css", + "presets": ["light", "dark"], + "preview": "preview.png" + } +} +``` + +### B. Plugin: "Email Translator" + +``` +email-translator/ +├── addon.json +├── dist/ +│ └── index.js +└── locales/ + ├── en.json + └── fr.json +``` + +`addon.json`: +```json +{ + "id": "com.example.email-translator", + "name": "Email Translator", + "version": "1.0.0", + "type": "plugin", + "description": "Translate emails with one click.", + "author": { "name": "JMAP Community" }, + "license": "MIT", + "engine": { "webmail": ">=1.0.0" }, + "main": "dist/index.js", + "permissions": [ + "emails:read", + "notifications", + "viewer:action", + "external-fetch" + ], + "allowedOrigins": ["https://api.deepl.com"], + "slots": ["viewer.actions"], + "settings": { + "apiKey": { + "type": "secret", + "label": "DeepL API Key" + }, + "targetLanguage": { + "type": "select", + "label": "Target Language", + "options": "locales", + "default": "en" + } + }, + "locales": "locales/" +} +``` + +### C. Plugin: "Send Later" + +Adds a "Schedule Send" button to the composer: + +```ts +export function activate(ctx: PluginContext) { + ctx.slots.register("compose.footer", { + component: ScheduleSendPicker, + priority: 10, + }); + + ctx.hooks.on("email:compose:before-send", (draft) => { + const scheduledTime = ctx.config.get("pendingSchedule"); + if (scheduledTime) { + // Store the scheduled time — the host app handles deferred sending + return { ...draft, deliverAt: scheduledTime }; + } + return draft; + }); +} +``` + +--- + +## Open Questions + +1. **Should plugins be able to define new routes (pages)?** Adding full pages (e.g., `/addons/my-plugin/dashboard`) would require deeper Next.js integration. Could use a `navigation:tab` slot that renders a full-pane view instead. + +2. **Web Worker isolation?** Running plugin JS in a Web Worker would provide stronger isolation but prevents direct React rendering. A message-passing bridge is possible but adds complexity. Probably not worth it for v1. + +3. **Server-side plugins?** Some use cases (email filtering, webhook integrations) need server execution. This is out of scope for v1 but could be explored as Sieve filter generation or JMAP push notification handlers. + +4. **Addon signing?** For URL-installed addons, a signature verification system would prevent tampering. Worth considering for v2. + +5. **Shared dependencies?** Should plugins be able to declare peer dependencies on the host app's packages (React, date-fns, Lucide icons)? This would reduce bundle sizes but creates coupling. Recommend providing these as globals via the plugin runtime. diff --git a/specifications/auth/rfc6570.pdf b/specifications/auth/rfc6570.pdf new file mode 100644 index 00000000..76def4cc Binary files /dev/null and b/specifications/auth/rfc6570.pdf differ diff --git a/specifications/auth/rfc6570.txt b/specifications/auth/rfc6570.txt new file mode 100644 index 00000000..12d5c0f9 --- /dev/null +++ b/specifications/auth/rfc6570.txt @@ -0,0 +1,1907 @@ + + + + + + +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/rfc7636.pdf b/specifications/auth/rfc7636.pdf new file mode 100644 index 00000000..4acbd26f Binary files /dev/null and b/specifications/auth/rfc7636.pdf differ diff --git a/specifications/auth/rfc7636.txt b/specifications/auth/rfc7636.txt new file mode 100644 index 00000000..653cb531 --- /dev/null +++ b/specifications/auth/rfc7636.txt @@ -0,0 +1,1123 @@ + + + + + + +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/rfc8984.pdf b/specifications/calendar/rfc8984.pdf new file mode 100644 index 00000000..71318d7d Binary files /dev/null and b/specifications/calendar/rfc8984.pdf differ diff --git a/specifications/calendar/rfc8984.txt b/specifications/calendar/rfc8984.txt new file mode 100644 index 00000000..565277cc --- /dev/null +++ b/specifications/calendar/rfc8984.txt @@ -0,0 +1,3987 @@ + + + + +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 new file mode 100644 index 00000000..d63d9fd5 Binary files /dev/null and b/specifications/calendar/rfc9670.pdf differ diff --git a/specifications/calendar/rfc9670.txt b/specifications/calendar/rfc9670.txt new file mode 100644 index 00000000..13dd6891 --- /dev/null +++ b/specifications/calendar/rfc9670.txt @@ -0,0 +1,857 @@ + + + + +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 new file mode 100644 index 00000000..a40987ca Binary files /dev/null and b/specifications/contacts/rfc6350.pdf differ diff --git a/specifications/contacts/rfc6350.txt b/specifications/contacts/rfc6350.txt new file mode 100644 index 00000000..d853cbc6 --- /dev/null +++ b/specifications/contacts/rfc6350.txt @@ -0,0 +1,4147 @@ + + + + + + +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 new file mode 100644 index 00000000..d58949d8 --- /dev/null +++ b/specifications/contacts/rfc9553.pdf @@ -0,0 +1,17115 @@ +%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);MNN*KZJb3mʋ}Cz i$Lc@,p=o]HxNHBΌq{.?ӗ?qͽ>Q#9 ?}?|7 ~H2eI}PNgè,detYNj~=Z:P˥~:oT\pa{)dc #)W:*yq'oOF̲.{xgh|fn(Kkb>w{E.~Q!˷- +-1:7Vp"8Ո"Gl̞@c7̲ePm):W^fc ţW\< + +A˜6"٪S@L^c&ZC9./Td +,` ttniHc9빶p핗m4[b:9UV޲ + p1R 0]nrBXaLj M0̬4RL쀱#RfQDnPj=NP&,#ܲ/نhdX/rxaƭ,leB)7핐VpCyu?|M6344 q/X0gl-Q`LZՓyKs;vy&J7P[#CU>.9"ƈДyZfH8D.䵇U\m0iu& ~Qyx0eS%%88\r#=9a^ڞF'¹j)٥`}3iykMWii$0PMjR$u@J2VׄPEVYQMjpeW/HJߑNSuE=h|5+AsdCN;}+2+<\GNw!@߮vf`^UvR00ž\=-N5@=hKߪڝ6BTwy>D.K2 $O_[XMDbfx~Eqvk֮M|QRh +f:8gĵ;jx4xwPD_$ uxxd^⬖`EиyhsaOj;q>q.J}}wfcTnAߧO +ɳC\Z2_t]ؠ{f`%PP5Y5joJ| 9,ɹ([P\m> 2$l(?3f㸱2Yͷ)Ý$M$?,vwGi[ٵw-O4Nt-:n;c[ll6[/nSutt-W-iya &٪K6 c`QSz}l*%qa74i~@g 8\Uq] $%ϬBxɦYɽVWfҪiwOYTFi~uקK5z^=J%ҔFgT^0P,QDžFDS ѧXCR56Žxs>/Font<>>> +endobj +1615 0 obj +<> +endobj +1619 0 obj +<> +endobj +1867 0 obj +<>stream +HtS0!RBBUEʒ]Ce{C8Cͼ/ꠚ3}@ F*bqlPO +Ԕw zLcɒS-A?.S<v=ԩ.8ڑ˘a?\҉{b + +LeC1ڶT8@+Zwk`H#&\YFAL/}{fH-qhԮC幐r3Jp,!'9:$z%)mB]s":ru"vDs(&t3<-Y| YY5mL!.yy-O@=PcBטQz>/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 +HU{L[?^ c.66'8,DB!@iFvDլmVKJX)꒨YJLmmi۪$ӒfǢ%x߽0=s{E!z_;^m'k@  F.!U.6j##T8>Rl*}p^8046V!XoF.M?v#4 t67nZ7|=6ԧmIkcב!^$joRÚߋ8=wgn#=G<7Ww-U8~>٘A܌{(>Lx* ϑo&rswB[#|A#=)zOUJuS3w))S))fvH-[W&[~/C11#I$"#h\U6@_I$/$#8D蟌[p1,$DI$D}ʺDI$DI"ۋ"s`,@a~֡ + un4v9bGK|HkJ -bP#㟮9cހ@])OLn &I)xhpP:X::4N#% r#pDwP|s()D~fhЯ_>= /byV;e*EnTP˰β2M\.(EYVr}'۲^-'ƍVưY]?-I=d*:%c\p -79J^}̶Ǻf[p!WUgK;LLȍ*Xc/4u ͜ ޖH +VЀI|{,L$H)W`OǨ9QJ5Ӆc&'m4.HVa BRi0ē6oJ ǎNLEx +_H(Rh. ֽڠ~Mw55:lGbjٚ:ڋo>{o;sfqk[9$Z >5ny\7_5{3WIrRS N<\ȔXp==|Zf*^dJ 3=L zLBBl[\dT-6@hnpq7(;8;;??;{2|`@'K$ҁ[#+Z+՚ʪ"RzyQ9HXQrDe:Sp[4[ +=ȑk4%0 Vlj1kM!jӸ O K쉼ѱVQR#!k~c)KL6"1SY].47nWhlHSlt0O 0FJ/jG ȓsmؑEo8 IR.|]ڌX@jU*_^kX/6Z%E]UPBaiBg`@yQ,ZROE}ҸYhR4SR5si3nn4IR(FsYf JyDUEu e] +>J.?]4fƶicsu=@xnOg B=n^*h `Uiz\ #wc+߿CL9Dk +Qf ;2a +9w}IwSW= r"<$v֠UFU[pAt9uȩqehR+hlQ]r΃D- >uW*i%Ճ>M_cuISdR :ʴ~vv+?-n+\Y8yyG>vV.m[vv2R\ecIЖLcC@s5^ctm-Ϯm.QujKBFDgVMG&O}-}훟oF1V.% ~ο1^MwwĎ_ؗ;NL8MbBBRh"Uj)HЊAh0&6iN6VֲU+PD1;~?:w5J9]X~` +N_502qT1򚃆'4Z*PVG=)6{l˽KIֲ*¬gjB@aBJz~1}tTo?m6 OӴ0&oK?Z{;-ɡU;6_64tW0F:Rzf +xWjEx{_O7^0s$xtf/Pnlzb2uxfdewթJu`L5rfnǙx榚< _K+|!?F4 +Z(|Ҏ {$ ɡȉGBA6`*(i3gxm/pT_ǣ9Jy*3酺t ms0Xl]?{{b'yG@⑽پbJo٧"['Uc' +4k b01 +pxaBk1̟p +Q5ɚ_] oV]J]ʯe~P%+Br'{p{tH>_O1ر4nXqu81nM4YYbjZ\{jmC?h +'Ɛn*wlu.H#,q:IsOrs<8^9d'#΢݀E8Љ3jo=$ؔ9նExzCj(vOO)h-DN$QJA`*U -5#2+/j'0ZvId/9UC*9rD&_"v 仈њrb׳:Bi J>ZwnkyqU;@GξV,y2H#=&SbI%K]M =*ӃQԁW,ML6 yw A: +"cKSdawLnՊo&b`;9<3t +R2V`3|JF8Q,lY !sj^Bh8OeK{2#hL}H8y 4ADx3 7ewwES-9֢:{OMՄA[dx]$pD'RM&t^!V%c= +h/,LB^I5_[eiF2Έ'7/1e vWCH$@rf_`w&5 [j~|W0YҦn/wԌnrl6qy`8l6{f&{$JSs4I d_WcoG5[D~%;Eiw7,u+ep֤[b#rieFpNmȉzh km5#C+5QdQ2.# ^qԣ?o7~)6)գVF"q_\`J#d/ҜEvqϑ9]O<ϜH:eBEZ~-%j'|sXzbz٨9fu 42^4]V[<0a؉,hb̢Wc2_)!7F-b~9&ɸ%anea^x\ELj{VIJșʄ g!Kq)k AYUk"uNSD +5BZ?`&QixNvuxϳsPr/۸ؚrHUDXW/!LÓh!Ge"A,N?$uxɂ'n05+Zj$)eoWTפ1 HSD͜6^ynEK8gLy ~[v1  ?&նyx}X\*7LF@EoU.Wɫu7lV XnY4>ENR5de>oV-᢯AO}=3sRDt)ost򖑍{S{TmȎ%NfaJ8so1d3 خއ.A'^|NFZBF+LLSOIk1k#|$wG4Qh꩑Cj|m`m\NՑx&\j`]kX?o/h$jʕx%VkrzO_4w]LdG4iaW4f1)\ķd3m٪)7ֺ +9src+)]b}\| Aw};sbN]ctf6Rc[ =!KPctdR)nrB8nDZq XEܸ. +,XcƒXZ$cXbF0>l霄݁2|~,#Xށ}2F ?&nSX4? +A9=Iׁ)嬻]MIH )ʽr"== 9bLIZYob{ȇ!o@l+ib4 :yK,7@}e| C ~2 W>BS{jzj=8Tq mh/I% +loŢ bOmS0Z[6xLkzW`?oݰgg AZq|Lcovhjك]4Hk?+Gp 7<ʪG*:(`oaWdR%kƕC8%w/kF)+އЮBmcÙXg!6ݎc->ett9Z 8JԠS{ SqN]AB2k5>|!N +endstream +endobj +1866 0 obj +<>stream +H|n0E i B*JT*MH9ɂǓTU,3׏> 9` +ڴVb~K`0ٖBWG[#l`n:oFjY +{h\_qn3 yLo*RWL""hg֦5Au fVK \6Yɩn@̜j>O 9fTx餭)6?Z]Z"DOGN„{ǜSuJ>bBKXy/d>C&R{ѤRVw^MW ;|@Cq{nisyva&Cl#?p)+n;3IzNZia|=*SQfK+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 +HUswWZɲ$[Vlvz[öd%ab`\`  3q)Ő0MBI'0}NۄN;t2iIIh:dP&ɐRޕGL~ݽsw9@ +8;‡͑rws/o /ԫ0`||iOw,^X{SYrTKML-Hz(!e@摍^ݑݑ{{,Ehѡ)łvqMW+1erQ+PUCgT7~A9"D!B"D!B/M"D!B+JZCwJ0zR4p:vpSˡ5a$647)r}!0$(ˏ-o@mZ&_@@9 +8VOק7V{.XJ%fO#ͰM` iwp1#FڱJ,3T g|54]c { pZsO}BйO0GP*H`'u04A0< OLÑ*F1|ivp+.,."X[=(9ģ! +ÜF8rht,ڲMft.ZFك.(^`B`yH L8V^ԩ1c9kTqh*ƺ'zs;Q9u1ݓ65dÄTly-b"P>|&j2 &c2a[oN4z]UvU5>:v*J$*xOs(K95Ǻ[2g. B7!(S<4ɐy e?1ѵٻ􍩩ZZMKQOF,˲1w¯tE(NW{ǹ(MȜZq:PвUqw Z7SMN_cGQniiukX mTŲ28:]Q4=4|He%R ++ +y +VROCLIlHt3bSe}еpCg2{OOǬ48>2^ha՜>FNQ +,h S$\쿃 dmkGB 5_#pQc-W(ms'/͖`OsCzot{|kvt[k}qEOR@]XgCWȆ9H'j\2hbmv#_^ǰ[`5ynR +u}ذa_-m95x +3-R_f]ұgqn9v1·mz׽?OҨ Q'<ҎW>v$ }B(N&XIrTy] SP PLᵾo5N\islk2{RՖD;(я=/#>%iyHoel= h7{Ϥ=:Yy1+UN'#mٛ)GT5Dm o 2f[oنVc])QΣY+¦;̟~anDLpt 3^Yp3folyBtoF0h. {d?-2P6:^>(R!ޯ}gkG>ؐHo=kSYMWEgX'E\68r8ƖO~pEgy6/iR aڂ8]ɲd[JZҮWwi-GI3=&ICPԹ! L;P +mhf(mL&&3e m^T2ߕd6 z/s_z1<Jwp|}@_(vü5NxMRD)7&ܴΕ3ē4$Fwh0f%%\$+ϧ(eDmG5 .!Opk\jɘza7rzvDNЎۜ_mTsD 9_JSD-~s)MRe\DVQy  9;PAAeM4(H ʉ^K/- dxt8߼)NĒ:-xJ R+8|ߚ?14=8h`hdxH]+nb+vPho:>Ty㹯ȃ-v-Itv}[޶giۈ鷀[)!f|'.Lnئb5v'; +ˆU j6Lxђj*em4FF&w%CM{v\I,C6\OEp):1yBƅ%5"/rN ~g lzDt4mU? `U.Π%==rVKkYu#@o!DT js%9]#ez匬ʨK""iSv 03VsEU*k8 +ɯ2- DnD?WZa*eURU[r]#NArU|'׈C.@bknnn]VAKTo[AgM,V6)k=,?4Vm'p(+j `Pbe^g㯠v ob;itTɽu^/8* *F]F2y0.R$'FうWas=3v"L*IDxXϒ'a>#|K7呾FYX›"ݒ쥬-~bbj4i8 =A=Ca-JkX$`-5,|[ʨ3++ J uy9CkMur?ٔCKhHUtV b~q2hX2w4UiG绛XO?n }w3c:PkOV{j>5y6ʾaYC䊐Wn6h3u60XtzҪ4z̢ZR;Rɶܞxev pؙɤX(9TR%#.LL4D\CX|XdZeI"j,*G^Ny`꣰Y@};Y}طQ8>w}."i}F}r'/$O|$ˆ&QEDs] N $~ C""%]̳7*x WSuDRDh'DDo妳K ; 3#Qٚ[A>}#) *'LSW:]|# l.3J{|u1e})nA٢/qS+~ғsz +hDPU2 ƚxX^&l2/u$ƕFób a ,R9bبTнs~pOf2QV{%)t?{lSU{k۽mm[KKW`va S# fbP2DA >>>B"F+MUC(&Ri?z={~q9 5?H|$16{ҼhX̛WuXf7X+Q.ɛq vX-urzcƦԒh8xW F4s{}eѶtY|Y-v\W( +\2(:O\_j@-;u7>M_^u<l-Sn6)[6phUk6l%R>G0{+?ΊJ?ո2Q$饙,?i<$b1^_;GSjmÛvř]&i1{No낤9q9K]!]uDIeWp}iv D~HB۰<5*a*GM#u_v&L&?Z$}z|$yOk:^눔&tSI^68z֦La{Oaж TWC&C8柚*Vy}n"%k1%ܛj^z#NRWKWiƑjXA4,x[R PU5,rQ3OԹޒ7nH(WpV3%\ׅwܿVeC\ݭV|XpS/~CDGWHuDJp5\s~Qk`}LJJ~J/ӕ^P;炳~ǞعO$ɰ'd5/!7k4 ŝюl$#JY ,?}wG՞e]]]cLJהּy,Wkw=fp$Ր5m㾐=$pfW р*c5/WW?VQ8k7ۘil}"<, + .V|vg/!(Z-fA5)h~5$g6!Eu@0<D D;QAa~ͅSZ9N;HR},*,sS6cD NN&WA@V)Źo.:>uL"?n̫Cط[8("u_ `0 `0 `0 `0 ƿ~`0 `0-p0O p$@ +s oZ)NO8=$Q-΃ׁH xc=su L|Z a0։)n*ך,>`8:z}Mb,>cn_ӏ^ָ]\c-ŴIL@?E޿_{G#0kb[1L`(-rƴyX?(-OOp>Ms_)$C$YLzJyuS Ix%_pyy 2o +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 +HR(T0u +endstream +endobj +1882 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1881 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1880 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1879 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1878 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1877 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1876 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1875 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1874 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1873 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1872 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1871 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1870 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1864 0 obj +<>stream +x\IonЅ:زvF&6R!1EK").CDC~zz3T+i̛RL8^ }pVzs^u9;Z1ǹnaZ췿omc[o?m`|?]X~D)zC|/$/Ԕ\5sS4o#?^]}1z߼^^<85rEK1( 0=NVN;& DgHڬIG̑{u`;1tđF1 m'f{!آ&2+wmO',chQZ+!+.U>Y^#xPXS.J?.K|+Iu3^)JgM앎 Z3õy1^&J9wGS҂[Gŷ:-Ί;9$ :! tV< !ڑS34i>W"^6VIpz KyXm1ic 0 9v8;dXzp fIlUPЄ`&+aa3*.Z2X=~Qo l G/ӄ8t݀ȥMv ݜWszq]nj!v,յŀREV@;J I4IX$ɂ0[ nt$D'Ϧ׋ۭ5 +OٴVDCt{ lPH,l+ql.$ts 2`܌a_ky ZpJ6&1};(@]4&XNwZd];ӒH I#(g9PKk"0H@3,蒩R1ڐKtT +\E6@*FU4pj7cN`^35'tŒmM +x*?ؑ vߧ!ፖnT=KRs\ +D{1kZ# G l$,Z4aYTR% ZFs` m]}͔QGYavc4@5ѸI~, HgV@}L&AU"l[]W8Q &qډ(Zo]Z6O֧# Q|4 <Ћi4b y*=R^uԊ]a gثc|U8R+ +_UއcVTyZ"*ؔ(!A% +Iµd!JRd#|9Ik(n:ρDXgu8íV] Ã~s4TecbɺMK{_ c6 +v khx )4Fy?-B(_;&I-ЀjUdss&E5 GE,nraE2 ]xF[92p|%^y׏dCF8A_bh hʹM9\@QkuunKO5ri +G,dY'Rsg͐9z]S(rIGo3Z >K0Z3X/GTT:jV+:>Ģ +@e'D8s(t#OWj;u2Zh4,}Jke^Q65Qq]x?疹.rNpNyhCGR1g+\4YmЖHI]>{dW$ 3BƱN6Kd{%SgJ`,[>x~Y}"›DaN^IuZ4y{z3( 49[ܸɃWS&ûM'<[6G&ol))k[6$0i +`H{%oIx29S2V oɍ_YtrJ41/tkֽxaU[&9HfN8>G[ݷ3r}W!:txDM|6NO/ӽrSv_8$3xr8A~J&SstCU+HM33^-c]g\]ƴfi; 6["y +\p}PAP3d BɘUvR3,BNt`5Υ&c; +C-sɗši0@嵕>eŤ`iDX%(8#F MVm^8W=:~JIJ*g4'#R|XZ-O싽+LS,7&c_MucڛQ>2U4qC&xS2TS#XC`ɘsNV֡BG[.N޽,Zuc}`(@$ Kg㊒č9UݸbW"C,9[\Q;4 ,/P%P acO4g{ .ot+( d&@E C2Dpi)F,zA;U7v}u)Ae2w (K;65ñ xFcgZژe-u]8nCNۆ%>/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 +HR(T0u +endstream +endobj +1902 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1901 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1900 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1899 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1898 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1897 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1896 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1895 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1894 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1893 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1892 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1891 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1890 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1889 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1888 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1887 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1886 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1885 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1884 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1863 0 obj +<>stream +x\[s*^ʦ +"JR)G +`!Iخ<;=3ٳe%鯻Υ/35x=*c +Ώ;"g;x[#!Y NX+usÎow] 9;QJkT1+h[ }n;kwzr8_lo ??ׇna-~/~nK(C?|“.ΔB7kyVJwȍzu( +'o`#0#WKp^h#FJ/VZa,6rZqQwjM [-ZFn`6J3xHQ7Bq^D3gP\sW"1>zjzU=rGD)`G~h]LlFi6~|PW+ <1گ^W'z%F9V ^aKTB_^;)NcqԄ! ?2cP1(Z[،QQTHkt٤dT){|ܛ& i+^` _f"Y{R\D<@^Po 1h^= %84h}kP~a6 Ù017lQ@aytVsv)4'l1h90T +?cߏ-F_\cv.@ e RD{=>sY/tP^[ d҃ 田n~#+ +/Nih wQZL9D2%7&g +PO¥b_)3XKaM,Љդ[.g" C aPL LDtgι֮w1z oҰK+Þ 5^2@ছ&/WQH8$,~ +xN4Eccgcl8c"OB +J%R"It +WI׃] .Ѩ¦mcB-SB\-(,5 6N nT(\/`",69y\=~ᔐ@^$/ɫt ##Rh8ci,J/y&5,ImR#1.($0!3<̃Er3+r0^2B!&o + WF &sheDۑ R ;xF< a17zI,o%lDJPxI\.HG)ȍ Bspl$4R<ᅌ<*bNe?鍾/Dsq@x8"W+p a֩rGhYV ;x;Ew(fخWsD)X1PySH1? ۯuTu9)o S1x!UÝJW'g,(p=6G(MA"܌slm}NKnQlAOoߠr ٖ_C7@{k@f>oz#62R |#FWR_(V7*%*=+tTҁ; vf9L9O ("L!U*2<,w'jF#wE;E +8ag"EG5#vGjs/M埑8Uvqj ++j%6B L[;@kU8Fכ$&jKU\XeWm{V7ςL_tr-*>m0Vf_֥ZԾ}\ ja=B1$A s)6+#f;dECot]=OWh0,R(=T6󰞢17p)ƊQIΝ٘OwX |3t +_ȼw.i2VfL 42Z^LJXw\\GjTdY[YshԷWɜ:gƇ +?Ly :Zr;FztE=&w6[(``H'@py aM+)ADc6°6F-:}㷸AհpdV=:3ahp*Vبd)|\o 2rFy@ur{:D< yV0'yAf%AIKXɉ.ɰ/^Di9V"nAEY$8-8>$ TbHv7H&i$;8Fcܖn |j16z-gbI'1"f`h" ?mbʭ&>>..S_on=?JC>.9ݝ=#}z?Ո2d?;toe(p1G>wͨO&ϻlj}G1w>xK1?Nh4=&,FRN!lإ{t@̺f: .F@\7K\ye+]" >d;wfα+(Ƚd81s]{ xǹpW\NsYplw)I-eps-./YûWv \A +J", H&ó޹e&hj~5_/!fc`Ń6!z6vZ7CLJ^nCm_e~n7sIe2ܬ`7`OJ!ZҩWZ~<,̕:- < Ʃm\7Wia?8?6K').kO :lh^2nV)WY +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 +HR(T0u +endstream +endobj +1922 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1921 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1920 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1919 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1918 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1917 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1916 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1915 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1914 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1913 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1912 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1911 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1910 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1909 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1908 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1907 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1906 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1905 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1904 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1862 0 obj +<>stream +x[Is*/A"[ +R=}9ؕr@aE@C|Se' 8A AOu7:8s59̭/W!>Y7J1lY+ż_~8?!ǯ?> Y/o\\soL]1T~&RS"SyWm`2N\V~UE=US+U.9_Z%0GsW/>|˫}.sA2/26;>8G;t/)g\3!}Dn՞olfg3f2/u37&ǂ}}=ʞq99Үoj#;:?Ve7ʅzQʘx_. DwNb0'#2ݍ(QcsgfwS^sh?W\E;grR Cg[OPv |+7A1M Q}L3Hz!LBAiQ +;|m +%^[,L ;w@8}'"JZȰ&u'} 0˾!? +HiIǁTݒ~IrW;HP=DFT"Rmښm:[sg)~V 8(=OxA>Zu#Vxm&^ ʼni}Eζo6U _;-Q.;!Q7E?6t]:`Ot+=$΋XPWtD9 L Y͸N,+a6h<vҀykoh6Z:%@\0e#%V=Vl2F/W0]oѩQR޿O:a1Rܸ[ī)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 +HR(T0u +endstream +endobj +1938 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1937 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1936 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1935 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1934 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1933 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1932 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1931 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1930 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1929 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1928 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1927 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1926 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1925 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1924 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1861 0 obj +<>stream +x[Ks*ܠmNJ刮h󞹤`! I*JsOOObw! &_@ +x4'FI>\ YşpHrPZ9b??dd_4|W5Bi.<DOJʧ侽~r=r'Ut9F>]?k]lnq32<#Rv*F ,p.$)v(3rW[H(Ĵ|`r27V<rfrSP2j,c;`~ 23}}`#;Ak@VZ]|m/~>"Ci揱]0VXR}$HnL. # sV^Z?Yjq.Nhu/XF`wׄ9m=bXdf0MDO-?rY#"}YˬIc|lLUi7^x%Ejc{\Y掺գ ά{׃eegE?= O-Ȥq>AsW}}/gR%;[֟eκ(qnsFOS 2iiUA_ԭnΖy٬>30gsv+5YK9WB6{֟ZI|x6gN3p=гM! 7^,/#r +"F׏÷W2 3x+> ]? D6~Yfx,oM6W2u\PrvM@iήwa25Xbb7)Aߤz}}?_ZnR?hNfc sy$?28}u#CgVȬ[={.Kop+UBW܃30mm=RD=XHPş6W")C6C_ք*5;@s[w~ P} mAl +8nN)ܙq G~k*cYddHX%~d"edooZZq[eRfDLN}dL5tY5 UJbfԶ8D4/O.akG|͘  ŞԭgezEd]p}=Y[w6E7ߣ Lf>M%,ޥ/KPi{~-)N +s + CP-f֗PTv6 Xps;{pᴩO+66ˮe}z)\bkqEq ䷾&zzvn2hySh,*%wZ[&5*LRݙ;ë廪S<oaMGwYvU=OE!!e1z|Qu|R% wq\'YF-I+=ƱfeSaCwy +!/~X¡qy^}Z׳g=aЦÿ"JWj^f_f_8si %?`( >%F' T%Md__fG[I*I*0MRT{ٯÔ5L)si!"Jg8>dzZ(r"r7 Xbd(9 Z%lIkVR~YNaJd +endstream +endobj +1776 0 obj +<>/Font<>>> +endobj +1623 0 obj +<> +endobj +1940 0 obj +<>stream +HMo0CbɪԤMݻcY$1b4Ҫyg^ZR0L3x^F`Ż`xbhQD9?hQx,TmFP$ϵ",_:,UXX"꽶HA=܆^ne}D=fU<98Y ;~K^_^zm* )qr& z?zk.$w rG#G=rq`>Jqt1r"D7~t c*ľ Wg czo]SR*+QNQ"WE/7 7skדgk*W(fdLc釔'!YLI* dJR"se$H"y|ɜ9uLur``xrzDY +?Z;Oq9`^[ +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 +HVip]Y+E,ɲ$XYul#`_ò_1.# @~$L'4dH:1tO;L#dI!Δm C ݕ 3{|y=V#hgb4pGvݑ&G#TNܷ+3݇~4Axy P?A &Ϙ^XFZ1FH^c333{ӣÙ/B[{]7(w"!6Ԫ # [ŧYd$wR+62Q計wїXGe)#jcį/'$$'J, + QgIoT5NfuY_n-?/*QTBRV|0L3W@P@P@P@c$l$pY\pFfdE.EMh͠,FxDT֠vԇh + +ϲ m:o/RA؏9;X E>*CHkCq\pw˩mtqoNl\׺ͻO8F|-OqI8dw!jsoBh݃^B  |D8  +וWL6(rcۑ8"Qbrvf!ʈ#db"Ip2$)55u5(g`GO=3퉝>g 8Աp_GSB;M7ȈhHgRHR` ),l2- *s:?qlp&TzxUYRpW`!q<'DRJ(HJQ/$Tn뭔2;>✽7b}nokqVYٸ;ۼ#Ϩ| fE508Y~j%{.[&tz:ݴ9:tyu&ݰ3?M6F=0Ex"sC_Y:x{- +?@j3 RyaI2ȃ ¥#%G@]y%Sl}.L :( +LH3~z]I(.Wb"*sASbbP ms2+jsPkM 0e=y/`ei8gI%Y-S@NHF;|8xκ~x3\ة]|{=<+dTnBYW48D_p۳_6݌oi%C +VBݱ7yə:+9I$>ĪzzPu<«*w)4v)=iَMİUR#a`PbCy#x,CC$av.}H24^f%w482j3ZזO`[F4hpiΑ{5d^i8%fZihܬ\>K?,yWf)qb@ax=gg_5^iϛ0ĵrO)7ښ<gC+eWDW@hXk 8F,Y/"\e44*U|=b+~ۺ]_](WY#jc۸˸gbǎ_/g}~=v⤎8mIi7BQZn똄Є|Et_2Q +hc_(_  +CTBӐP[&ξi2;w<vK7ȧиNç{7_tBJ) t^pDVp@O A3kj`[5h4N,YÙo<1RՆ2&b`wʹ;\a++ H ,y~[I)1$Ow߼ Dan.\ܩ/ŽP*IT_ +8څF ?OɈ<>'C?Si +\aE*NT ZTxhʌrzqW'*f3Nj׿Y,^_*œ:.M.I3Fg@~u;j__5䚸QG +KףsӉ`?}2Ҭ'_j镑#UMmًeY+]\JH7c + H1O2|N{K ^4ɻQPWGY**&tm໳҂fʑvc J1S;3|r4,Љr,#RSӜ+*o} i|WCVL-9V)@aodlApL?D$⎴x!UO}DM]=n_k]1#e~?~\@$L.:C_S]jYQw"tfDZTٻ@z8tz"&Y19,$7e <6%^;rT-&n#f +ĝL&/y^>Y|iqD;?IL jW8#O?<5tOVX~s6/ޑpfI L&wx +%E| +~S8 &'|j3X>VbȀ\~3Xч'9ǹmv>h'5ay cN0i=P$%uU~QTfW%N V ,h.˯Т2a…j$QNO!W /X|$fkJɝUy;x9xiəX +)(n'K{SW A({Mx})blg Fn)HLmS-`119+-ךlʩƹZs1#zp )mWMnB7hYZYk +oP[=JNo}iV ! +lP6R( !}!b]_ZH ~˨!d˫a_>)wxKI>8# A츕s,Û]\2BDzzt* P,z.}N1`A\X|%=/q#ͥ Qb-sR*>ws9o[FP?rJ?G.Bq=fik?[u({΄VÔh˙jol@D02iG')v#0p1ozvvF-G 1`InA}Ӿyfޭplp2vn–PdW׸ +\;UTvXck5_l5ZR'QoLM</CGh$7iNv,>?;:}ۍ\ǝ*IBү6]2I菷'^"Ltg\SQ2tUkݞSg}ӽ*v>wc/,%SCؑn\jla6~6P(֯WHaxF?RGMRҷύ[`8Ÿ}r7{_$ቯY ]{W_݄=p{lsUȿmjOf?Vqf334uȾmSnIJz5+Wߑy> ^;9u swXE&lP G٬9񧡰DXTˏ&{T`|LL1P͡[؀=jύMp6 TF@M~P>kJP8f$%kx; +c ͖rL*llFlKum467ߐ{ț! 3+$|1uOS4j%ƀ<˪Y^vz?ZLK+$,&%'zXf RG] ~zz]1PBSceߐ!ex=9 )jAZE8e,|R]"Fd>OɠdA),g!Q-rS*ꤗDAHa=4@9:Ig@(]"Nh;a`_,r#tZ,H'^\im=Ө9%BS}%: +DvB_xiYQʺӺ4Ƭ<vZP3Gg1a'vC(Q#z@.͍ qVzRedr#7.iQqxbb1R0)_CC .GT_EE0~ +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 +HR(T0u +endstream +endobj +1952 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1951 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1950 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1949 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1948 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1947 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1946 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1945 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1944 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1943 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1942 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1860 0 obj +<>stream +x]ێ%CĎ$!p,#~yRt_I7A`'OOsbSSˮSuNlV//>O采SMz{!|mon?~a?d/?g3DJz+ Ӛw#EBqa9|f%F?8-'ZuTx<K3?z_!ׯ6G7B V Ғ7_=_o:m}n*}}tw:랥wW{mVD/];+,7.™>ͬQf?'lj\5.kiIJ^ M:A?MŌ%ܙ + S"RK.hz"Kz4:y=,^GB&.1hgxke.8Cɀ4\q]L[U:^ Ccz谌egfԱe-? vXOp{R[[XF;X?RgdA)j*W5Fu +;1)&HU1X{FNşndAuCi@f L>x]aza^"cYvȌ^iuTTxn*Y߁gif:Ȝ2^ȗ0.id֗Uz +euJ#szV3^yU3ݑP`ܮӌ3| +YFY'I\֭]42O?J:3MN_wӝ'IA&ڧBK5suwpAq#G4xOvv>I>.V%FBXzjPDtPiSoݛuԠLF;'e*]f18e._P:R`_^?yJw vWOz|4'IOoU$5Χ=퍿LT.ܛ(S]ɝy];W9k?_Mb<~ Rш \)izn~\y0>VJavv%mS*JSRr>X c{,;tËد^vFPҏIONy'"뗝}X뗝}"뗝}X뗝aa~~ٙu,azy(c!뗝}X뗝}/ 뼗د_v^a د_vf +Q8egfԱee?MGRe<>c|lEw;Љ_p\c|Չ_< +kwžx`w"qtnPU]ȷORuT\r*RsvZ+v +z4LJ3Xvfdnj3^yjqڠ0uuI#S+JB'sYvȜ?4#6S O򧑖ć3ӪSU| IWvI#Uu.֮S'ԳŸ&rwZ5yM-O]?M; ֹ]gƫ'_%JOT!Гֹ[NidΟ@ +ۨ+ӴYޝy:wAy 4+Xf]a9cj| tDv ,WuHu$- +֬K3dqޏV^0f KIxܬʍK + 8O>2cIWI%򪠧 -Y%hIk\֬]42cKe/M[ݔb'VsvZlWMcNs|(0uniF漙j DՅ,uI#Uu.֮S'гŸ>qw͗Z5yM-ϼ]?; ֹ]gƫ'_%FOT!Гֹ[NidΟ@y:)WеfVAvS3oWO')fU''FY'I\֭]42Og?vUԲ( +`u9fB=oEa: u]Ȭ?D=i˺F w)NM NzaNjNE~='G-ߛb[n/SPަcJ̉a~jg?tߞއ.z睜Nː#%7HwxQߤ/^ݧC뵕$t*=n>}սy%B.6x<*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 +HR(T0u +endstream +endobj +1974 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1973 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1972 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1971 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1970 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1969 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1968 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1967 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1966 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1965 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1964 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1963 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1962 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1961 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1960 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1959 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1958 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1957 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1956 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1955 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1954 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1859 0 obj +<>stream +x\Ks*6TخC*])EI96}H"_V]`iku 0ܞO+-_|X7?<3RCF)_/X?xFh~q)qNss-݌ke+#_x#AG/vqo^Bϗ =„İ_.[C)KmϨ%\8l~_LQwO?u7u;ﾃ_rqzsnJ*f$@ѝtW +oX4#ayaA_qDZ'd m qRF8aτ-ehIOǖEh<.[3ns?T-:CemQXK9#!]!_! +..!4%:3 +L_WIv?*ś0|y9}[~ uWԜ3x{x)h)?,3T@nIu/Ϭ,Ȟ2ekb8+E"nt$u;ǮdT&]Ե/ߵbmOlǼ<2g:#LwfL#Yg!3svKD|&9y[sJMJ7:Ó/vX'b7y4+D8+<՝w/bHlݛaYEB@[ 8߬U gR & ('ݯ,| +cKƈZ[FMK0mjiw^eU㖦Pe J.zhyv^m"\Z +8 +P{˫s,#j˩m_mlqr/r/Khn ?mvNePѰ#u?[i4 m~ Nr[^v26\-D VK=i5~awpVv'JrK_6㓪_? 8 կvSD :FelM[n\8Fx{!QD~feF.,ǯ}OUOcvkE4ZQrٗ,wU&S\ZWqo.3L#"D|y.4rA +}jNbQ{ӮkDi:`_f*.Ӏ\g'3ҭtg>/4rQU|F"> +ڃv][gWOә2Sv>^>1ni;3yY39[L%}">[JfRJ=MV\ttyߌ~5s,`>jbޔ&yU>rUj 7SKb9e btdqoVVjda0ܚ^Uaq.= 5~IiwO;z!cŠUîjʼnQƲiRisvQ9[}DŽO;p0o٣v٭}G[v\8oGxQ`?L#fqWZ W.qGO;.Wh\զ?v%3 e212 ȥ xW؎yKwylexYg!3svKD|V*bpڃv][gWO+ә2Sv>^>1ny;3yY39[L%}">?J]O-3ҧ?LeLeV">^>#>#Lw3L#Yg!3sv |VSQsŝv=[T'WNyntUbe- sVKc$Wiʌ}Vi*xIz52 [dZLís}m$aZr+p{5k7WcM DsgmY]>nE P)|B3z^]"Ǐ\Z^7T;I^Rtd/ioG%m?l)vF\G;L]&:L# Lb>>vB;b69G4$ 9DT _Ni%1,֥o·gû KgZ[3(Q~2| @ mk!i_ˉ5pZ`ab[ +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 +HR(T0u +endstream +endobj +1991 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1990 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1989 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1988 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1987 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1986 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1985 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1984 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1983 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1982 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1981 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1980 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1979 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1978 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1977 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1976 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1858 0 obj +<>stream +x]Ks*ސSprDW4iEԃJLRЗU䧧wpY@(@c\5G/>8|zbΌ/~w+xjλwi̓6_Y{%/?C0?a Sܭ \ (oG(=y}x~51xAnzpǰ~\x9\ńco^y0T #/߮_'߬b/V?>T^tN:ѝuO//VO^n]1L*k+ +b9~mP3,L$5|8, %l!XKcF",|O5s-asR0ɝҡ^PdN")vi~m*Y = m4@#߭in;M3i +6 +- , ɇ +!xe6'Z y#&Ϊu4 LEq̨{4`hχ<ıN?qQ0!qQ<#v{4xfq%~QS'iWI(7!݆^=GמMF!L7 {Uf]/ej5/dH/̊"E|_i,\B_&,vG?;4NƧ3>SsL#rIFOKΌ}Yi.$">Kpj$ {|})&wv +.W3Cͪ~#W1ӎF UdFvTraGU YgC,2\}YN/Ln]RNّv\Wh\jxJe}2=*S\ZW"|";-ľ04rqyU'9[L}b>+irPYWZ9i~umQh\> Og}2vF>#^>1D>ӝ,E}VI"D|y.4rI +}zXfnJ]+'O-3'}&3>SsL#rIFO[Ό}Yi>k$">lŮSv]זUS LezUOWO'ѭtgھ04rY5|i4\'s\a OPMN(͙~̳|5˝2OTcGrY؂-{fiU\Z|U47 r۪ܟxߪP*؅kgs[d-Qܒցq sKB̓KR;+`2Z1.-O; &njӎ{ )Wi=GSi=da>:ӎ[}njO;nl$;Z?q̨~#Wq&}Vͫ~#W1ӎƩafCSؽ}2!*2}>gQig9}iؚ֬ĥG?,|B>әF{LoiD.umī8Dv[˩}Yi*>I4yeF.9O=&XK]+O-3ҧ.)OLrABO[δ}ai>k$">a=6RI{ӮkDB:h3Wp2%}F}b>n];3eY|y.4rI +}:,)vG?8NN3>SsL#rIFOlǼڗeF.볆O!3svKD|Ns87GJ]+O-3ҧ:)OLrABO[δ}ai>k$">gÍVNڣv]['WOҙF{ ]ψWO'ѭtgƾ,4rQU|i4\'B39'PZ9i~umYq\>mHg}2vF>#^>1D.ӝ,e}c>=WL#/v#?8Jdg*S?2E}" +}>J0o.'YDL]i>1T9)Ů]Stg*CyniD.3It+3ݙ/2\g$BgxQ=g77:~좋SWߟ ^` .>_vne`jh-cuS9u N:YPh/ ȿ ZV#TPx_L!689|qohgH]xI(ćR5~J&0)*wE/qS_N Z1xBQ>~Vl?ތlaP2,XnsnC)t橃Gy[xP#!S7O?zf QNKwI3s{nWdJorˁnO!Zee:+&(da]r4>~ߟ^ssʈ$ 6C;wۻmwgҌ:jƿC[t94߶?.g֙k&Vb}V8r +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 +HR(T0u +endstream +endobj +2012 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2011 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2010 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2009 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2008 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2007 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2006 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2005 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2004 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2003 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2002 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2001 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2000 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1999 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1998 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1997 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1996 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1995 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1994 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1993 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1857 0 obj +<>stream +x\M툹'۰Fx#t6LQGf;>8f/#X;%MeJUtiIzS%Śk??>3㓻i][y0yfVV^OGj!dF9VK (G(=y~x{c~&,Lv=?=&oax;xׂ{&UƯ|\=8?b +F|Xxcw=i;н˻|<[=~%x[fl[G^W5x&×`h0Y2ؚ뒔I p;NFR5&H-MB)++7Pv6-*@Z708b;UƧ0m 2k8jkƊ݉ ,^w$)ʚN0%! Gp%MH |i,:p)黋2iu?h8}ER=y<u." a|g +t6V3PFq%y^S'ig(6!݆^̹=F!-2 FWHDuZE ՅUvUCBZ¨(!_91K]a*e 0;bUI{\]Uutg2CyniD./Iti3ՙ/2\eCgHG}&3vF>#^>1D>S(e}IgTԄ0,p͘?x,vﻗIX~lвyMVLw=KC M} Rey]u3Z厫v֓p]Z +Í . I¡ $nzZfςoyμ>LwvRDVbZf2KaŋkX\'ݝޢN1ὃz(L\[R9Rk6);Ɋ;>ɮUj7o~iۜD>=kxaz~EjyO;no1ST?}:e w΢(ȅ p,uciK9ixU]+ӑF{L(҈\ڈWqOv[ʩ}YiCgsH#rIFO[Ό}Yi>k$">a9.UuUmYq\>0Hd߿~h)B.UIt2ՙ/2\g CgOG}&3vF>#^>1D&S(E}VIfU:3eQxL]i>i)͙~dp}Zt&*'?!z +۵𲟻:ΰ!Uc7iinr[2Ϳ9_嘱Nm>\ CV}߽^-gWj؄#NJ9r~j1\2u-/VGYݦR=|,)r^f7˙PxafЯAAm3qM 6^=|x9:*prwVy#KcO;FPnjYӎ7on(~~?TTdEUu}%+B.\" q$th:L#.pӍJ\);ZF Whq\'#E>~_m"EȅEx'UN L#-U|i󼵋4\'BʳSVN:O4NpI4Lf("%}F}b>nu:3eQxL]i> }7bI{\]Ֆӆtg2CyniD.3It2ՙ/2\g x<3svKD|~BX2XHjF]NZ}7,:;nEmjT=j|Й^-peBֽbƥW8ux/:>/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 +HR(T0u +endstream +endobj +2031 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2030 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2029 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2028 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2027 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2026 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2025 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2024 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2023 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2022 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2021 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2020 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2019 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2018 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2017 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2016 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2015 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2014 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1856 0 obj +<>stream +x]o@MҦh!m㠦cSRÑd[Ncu.I{*PzgvIÕ%Ӑ{YqM)Μ֨ޭ~\1on?W̚QپήL+׫:<~a诜 + \7nvu nr _`̭71Dɷ-Zl?=P2Yư_\w9z]Ff՞_[=z~헧_dZ|zY'WU;ϯ<[mfsW%r޽pᝓIRxπTx8-ȇ)av/j3J;9tٝu'#pr*z0SH50j$3; +MȀyُ0A1c\i H8cÕ҆oOԳ0ϥp +K~9/gN m3)>GHơ|4<|/:"q3xv1nYSczؑGyazqڄ~Î>cÎ˾ _~㲏~#YW;2(9W;. +^Va ܒa~qy`~q܄{S;.8;n^߭+|<у  uKE`}ȋ>'p{͌&kZa˚"F1kKFqa7$"[}6Ed=U :Or^mP|ԇv#y*tEE2BzuҮ4rWX +iϼ‹bWx]W}vJc|0CunWiD./I|i2ݙ/2\e$CgZn*M#Ln~PZ1ڲ?qu<]if*%Fb=o];3eUѓdL׭]i?BNVL.oLٸ79u@C23̠q~=^\\u{d.iIVg0W@zBf=}yH>i@6y1}"JSPRh@97!۠d%2=PTG{%F7r^-"zTQ/\I65!!ϗC&~j XDŽ4F?Wj8K>7YF$yl/]n Z y/$ƅiR.L|Kp H1\糥C&~j{.G|wx&q4UhR=^kph1|ඐN|Rjw܄eIZ]if*%Fb=om;3eUғdL׭]i?{2'+uyumٟ:Z4Ƈ 3]lJ#rɟƟXO>ӝ*eI2Dzu֮4rɟHi0]kTӮkU:Y)f:OJrŸDO[t|ai?k$"=:ukWiOg7yAvLxo&M^Vxf0~jt|Y[ZoEΙq9W_Lv |2R]`|ln.-y6I]vO1Ccfj >J rpavN:upVtwK+P_$ ܈iɂvѩGNVL?@w7 ߓV@Ϝ5.S@C2F^M"qomqu_ %G[yÌߜx-/𨻺yt]RLVǻߩv6vݽcI|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 +HR(T0u +endstream +endobj +2053 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2052 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2051 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2050 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2049 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2048 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2047 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2046 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2045 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2044 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2043 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2042 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2041 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2040 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2039 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2038 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2037 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2036 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2035 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2034 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2033 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1855 0 obj +<>stream +x]Kn@)s0ˈ$ھzNvew?nn{vW`ns6"(|&!E=|oKm/O39%iqᝓ/0kg$̂ܪl- IDozڽ//Fj{ܗcPOFaeC3} %DpSRagc +O# +" ޔ\z(ז94î1\)mlx\Z{?:J#AXΤPB!pT:. ,x4!L{;eYg! \L`)qP=PrP=IxyχyLAWx&lѥ LCt)$z+.Z $lxb? mc'h@ʓ #d)hzz8Qm"CLN+d}($?]~7W;~蠄5dYJ3y2锵Z&N0wӞy)dY{ӮCI%qՊ.lp.N)2((:`_eTjI"${-(q[X&]ӊy>h +9]RlīQ,f5Q+tj.<2VEI[ğQ,v^B(WIŜibZ +!"P(Δv"pBB ySYiְD(-M.">Xmbe0 +O6G?:T,WXmFP( b#^b1eS uYIVD(-M."bY.^5b4WOs+17_t/Uw͸$_ R%spq&z<8<۳sݽ,xc“baeJ>xBLXi! (G/߆b* ntQ +I'SqXi|}[Z]kT].{%`X^^[(^XqvuǤ0u^aêΎ.Yy~@(Rb~zo%y8tWPÚñd ~>z;Zyf{aߣbyay79E3a +.dpp <|7α"V H1$xi]W0-~s,g28T~yWĕ^Z\ƒ:o2Zvԩv8~yG?;%oɑ}H*?Ⱦ8BJޏ+ཛྷoe,ٗI2|4GgIXjvRK1gG~qI~%᳆fC2&SLt-+w2IѸ:}*4ڇBeRe)}F}b>Bw#3[LȔ> b=^SM+fG7zVgWNg<|U黇6Ya)ajtxL +MY0L$c"aͲRkL"D|y..<2O> ,찒Z1gG~u-8JL}(TfH!DxLLtk ݙ2L볆$Bg2o2#|z͠=mvf9d{ic <w6P]HŻ83N9۳Y/=4{K\|$.庄]{c{OCc^7xv펱6M56Q7ډÖRNT'w\DLg6T&A%@Du +ގ_KRM1HhWzm(n M]n =~m U٫phKSv(!<ސii4|.@ӛF-bs;+nߪvMЅZ8m8oby7B?2|~?`IeY,#cIw뢓:Fj[}ǂO;sNɇ >vd_BĚuܚ4|l?#QXP)Rڣv\qGb.3Paz liD6╻?v1o.O#~6 q<3sv)}">zɄ֢wd׊9;Ӯki}qUt?) V"dBB X%|'Yi}D\]ydB +}5]Q]+fO%S|>*3Lbe)}F}b>݊Bw#3[LȔ>4>MwNzV^u,8Nh +IxmeD&T*tf1g]aVQmv\ʼ0wOu8SOp+ uZؤv\ }ܬ+Og(O-~N{XGc fw_~yX>d>h"2$ctj㟥5|} ,)6k}g1̸rs] ow.O*k{88 '{C:,=OK;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 +HR(T0u +endstream +endobj +2073 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2072 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2071 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2070 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2069 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2068 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2067 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2066 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2065 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2064 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2063 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2062 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2061 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2060 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2059 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2058 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2057 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2056 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2055 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1854 0 obj +<>stream +x\[s%NN3ÇNbejxqʖ|ٲ-ۉN =bɳ}[8\u?܃c~X}\-ݣ~\+Jp^6Z!z+ެkϫ_J#Ze Fޔ\o{;0Fzۛpr8:ߍݱ{5E<$?[_7-z*Moִ7qˤY~߯)'^QWWv^t/3x|]]uGN WW^ .)5u)pp9~hJW +;_`)%8nP\ȚfJ"BUDq&5&4e+yOBOܝ5%(S W FYyy*ǧ2cN4.,1)=..ogҕK#޷3[x yw>.񡫻P'pY"(7>wo1ȹ?h8=HO=-Z9CaCPp1P)bW|)ϣKpėOJlxu_/\0y]@qfpK'>+gA-@#|};L.LhO(rPҕc @jsRT Kq(tHK5\xφwFmM;8cf^ n +3N?]}ǜWO;(kfge~ai.r +q& qZ>,~OiXw@QF311 >M8th"=L[v->ʴhT%Ή 2%=!*'xܕ4784X.UmZ~]mO,Ǹ3w]1m퐙}s|QNbjۅ gëxϒ*1bJ%F*a{5'=U{'>eGkmix4!dDq[:XP ~hk-υaY-imc?f}.),â6~~ú婢o Z & \X { (th"=L[.|@QN/]MmMdSr4WT$#EM&31 D,٫X@Gx"y[#(Ӗ *<#i󸵋4mOg?mQղIyӮjD)t: d2.``ψ"S(Ӗ39[HӖKDxVrtj٤iOF"Hhkocӌ5Lk[/Mɑv\flWXd2X$d3Ƽ]x^c#T#&L L[.3Ci"z/3c[X +'RIyӮE [&=01Yf*5#_erUF"HhkocXj"f]U3`|I K jQl2/2mT#Y赋7kiZ&7RP],b6%GzUpa\-c-`|Iv""{Pg*5-_er5F"Hhko~MsmW7.nh)o77TGnInzXη̍Xf]wlە~;`a8I[NRBL.ﯻm7"NMSSk;Kmd +ϗCzqĚo71ն^{3vWD'=%:P} ?_e\Yb~7ehJyPLiK}wt?3澦]k\Ф xL8U%WIz?rڽKn5O_k\jg}JNFu_uwx? +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 +HR(T0u +endstream +endobj +2092 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2091 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2090 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2089 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2088 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2087 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2086 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2085 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2084 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2083 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2082 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2081 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2080 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2079 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2078 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2077 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2076 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2075 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1853 0 obj +<>stream +xZIs*/AR]v$H! + +}\e'M`g 1KO[-@r +d%#:eݻcbg|εPjɭQDJx5ar7|)qNs✇4@R@m4W1bѰ ?|/Ǒjϟ Lyzv\5IZ…ƯϦ_L\C['uvY|6lLG| ́`bcM_"[S2Ņ%B;S2.(m:sUy 8_|dƴ%9mc +!j+ndA6+L#qF9 h3u , |NPs=iO>wVz \{ F (As|;%.1S'0_+~ZI^qMPН@$y ]iQ9Wi( haW\x= xQSxV=PpѭljQ ~ƙ1: 2IΩ؞f\pNaߍ*Q}tWEpZ!jm|^s^~&3B4$+x?1BRzr|ƜQY>/S'H -f( V-j桬VIB ?FY`sVҒ.bFϦgN&-ZR:[MVsYK%Z!طyo D5: 1(,`U4NBJՊM Rn2+ЊǦm3Ŀ6\T ڢXVL U$y5TQǼB; gpW ޲;qra mOGbnIUS/LwȔӈҷuJPYeLᖂ[}׋(/˫7繯P2eٗb@YFeY0aP o. D( m4n{/bJB>gݟC64DPMiQPqw <,1`WAx1Է"dO-ej1,rNZbՈFKG<" V`/9R IP9\!T1Ṛ7xy%>׸,d{iO'+=ɴZs0]FQ\NQIq*[*fvri(,7ƹ{_a[Ł V_5׽PM7ݨVi/fԮ9Iz6zuP +gEbB o`=]=oT\@c7ĠT_Ջg4d ?P[!zqY)=Nw#:@Jpfm7 0fMO(6ToY`gIw󳦲M[5aR9r_5XۥcveAW4FK,PD +|K{[1ԿHoQl\[F} +qH6Mn"WAepeh=F>/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 +HR(T0u +endstream +endobj +2101 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2100 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2099 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2098 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2097 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2096 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2095 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2094 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1852 0 obj +<>stream +x\Is*.CJ8qT 1IђJI#!IESe'~hvS#rmfk +JFuF?~^"F{(eWFPjY[I_+_Z=#tӿWq.qNsچ>VZJ6כou( + P>5C׸*cua[1wV[C)KZRJPϫg5$pǍi^6Q}sټeCh^@٦9iN׿k(m\vo^ʯ}~?<zl..vy^3}Aӫ _tx)ǎ>nC񱄏㿾{ DUi#N=ΤHkh:k>}'oegiU/9d~ϑ,ʳVoAwY.|EӅǜLcy/黎e-{ NfRCZ P4ۍB+ʀQɏ .aN +0"eTƔrDw$TrNuw#Gr.R@1-6X vpha98H)v; %A>h?eu06b M$UF_%M}l͡4|lwj##7muXz/!&UxT:cfe-g!B/fgeRATght=Ӳ0r1r>nF(nxceip8:ijziKfQ:N*r[6-fq^dYIራ:y\k!k:-giY*:NRrں^ڒ<پeg 9-d-hq^lYY6y˜k!k:-giYmזU5Hڒ<پeg9Q6pmYY(Y&c3-M#9[HCt[4r8UUA wu5%3xeg 9-d-hq^lYY"yk!k:-giY*ZGLdqoYY蝱r[6x=z=f gq#.LfYF.s&(xcigQ4rUq4DqM;,M#8mt.zqT9.xEz]yaI9wbq?5d}X-]kA+mEƊJӚ~ {>=}~cNCnn+؁8A8l$m n_4独}1Ox P|Qɩ+,g!>i^7Xz*n.T +>ڄX_Kjgb Uvmq5?|j1p?Sv_"`ԃ~.E0J ƹ/;_}ų|CL#o~G&>߱m"[iF.Uc| m ,d7yop,{^bo?0L8-*xdQ o?o>~kowJc +`Qiwy4]RrCX;E)UV)]`8pn`Xͦv[ޥĆoͧGaB;3k2) +X}Xr6{TȾfY{4.j2Z U(ca}vFްY6ߴ*U$\6ϊu5%#< +?p+cs_3ilY$kA{QK9p"@p+f36mOXr#>#Z>GR]7[5 +|PUt"䃺i<&4v#P$sӊZcET||gY#KAskOVTz] IZkٵ{,rd~x}x38 +d ?$+"Zv9X:BA9NB^?x`¹fZN_rc=jܱq~׭,H(R(U)% \'CP"8ۊ'= +Hױ7b&l˒&ZPIwNc^lBf_oyc@GGyM߆|'7dcCw.<#rT-onAݧXEěpzu:M@6Govi@2uC + +B]V.3.BpgrNBwxW)gG7bǂ?2y{r\M8=P,:{D.YБ{wTDǞ쟽gx7`I1: pgrY(638qўHO>HNIo(ՌLlys~~F#;Sj;զο%_yVP'Ko_Ne1zzĹ631B/w,k5OT(>Y>O[``@\f7i^E GV;a$!PrGttcOJIfr%Wq%S!qϱ{(#F +i w%o@ͧXInɹq}09Ө~> >χ09Fs՟ρA#g1]vhy!u$|"avi;wa,H Ț`;JPXxVAw4HX:HM3L>_LJ -+ h6 +tiHZK)>Hg40$ЏuŒ:U7..'RQ&35\$̏o75'(­jj?5gtX@ +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 +HR(T0u +endstream +endobj +2119 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2118 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2117 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2116 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2115 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2114 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2113 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2112 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2111 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2110 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2109 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2108 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2107 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2106 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2105 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2104 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2103 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1851 0 obj +<>stream +x]ɒf[}ph *U&E48lKt5@VVmgÒ/_|U5==;ӧ`!zgvxwv<~JysF ?>]V3Fcwտnz姫/.ŸW~O[TJX]No)  ew;=YawV<FLlN8?{_8]ތ҆1v'AZN;G"^Q&:/7Zh:f(+IopQ٤"%XoFS&J_6U污mHR)#36 +7^V.@B~1 +<(vi5"yQ:Q*ؠۥ02 +0mبeylP +#ƨ7.\Ɩsw]) AK+1 AUA+qtj! +<(vi|` *ؠۥH[ƭAUA+8Z?eMM=ݻEvtS7 /+ s[{l[b%hF+F1e&A9ofQֈT +W?#`w]"n,ܱ֔p3j8V?8YM, +h-~o4m"ǫ@YdaYix20T(gQhXa)f9ҋ=lLXv͢,Z*|̾Z=Տ/@'m +0>E"ryqi24EMZudzLXj~zv]J_Mq3KBfE8~͘B]c+mLȤeY ecZF< dy6H7pLֳp{;|7< rx4|;z8}>}}3Haߤk'jWxӿ>{e)׏RXOW7sǯ*NTq,$%̯\R~;jx?W K᧗aUP :(4jt3N)%jX[P3 +@d|tt`|fDO|Tic6*,zT>ƻR؃n{e66Y 2>VzxV4Mħ3"m(jEr|!}~ֳU Ŧd (*H l +zUacUIy]UƔ蓔棶gԥ[d]UҨU#/<}?*(ƪLsJLWTtebtʤWwsOZm>2ZZi/wX)ߗ):5h;4QC-Ox ӟWxRzOo.k s)OKdOWͩN7p:9|1>HgW qjGaDT0WA ֆM&= z\<^nؔt㹇\!8N7\9+ +HP7)կS'=|HFKԖ>b5^hbMG4N. ڪ@褆66Ut(vׇ馺g<5tK+OuS|ΈogMV'Z1Fm莃ot:\G뻷8G8۝ύk).n?Mߥd@4rUS>&+xHF:8>/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 +HR(T0u +endstream +endobj +2143 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2142 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2141 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2140 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2139 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2138 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2137 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2136 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2135 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2134 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2133 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2132 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2131 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2130 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2129 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2128 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2127 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2126 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2125 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2124 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2123 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2122 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2121 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1850 0 obj +<>stream +x\In }['1R dB II edN9UU/UaON=$|ofd~hNFIs>]sRr!9C +cB+8dž/?¾~qŏS bvs>FώXܕ$~{! G*M#h +5 yAۼaߢf^cҊc"4 8Xczyϗ뷗oD.n>xY<-_n4K Ŧ8/ŮXWź}V*$=;u +B5toB tĤ9` \nq *AP}{;X9e1Um 7~Z,hH#ܴ1U(\VٺF[+G}  A)3 >WYADQ0>eW/ۦ]%^fXY;=]+` rc%Ky-;j庀?14KG6 Ӏyb5+|t{6 Xx{CR`jJ  4zumKRkgv'N=+`̫{mmg3c+1 sCU RDꨆ=\M޾,nh%2A)ex԰ګO@ԧF8O`i@̝3uiW~L5elX )p0"5-{Ai'&GFbmH>uE CPK9@:akss''Ȱyr(į]Y;Kk0%,q,S>h:c_:L)(>X0V.?4SBτȵkVM,2&d H$2bө ׵GlfN&aQbU}(EP+[%?f^|wSLIlĒt`7%m2lڤ]IaO3D! +**.M6;5QލS.vo~u싢<#DSx+y| +Sx OBhۿa*HS~ԉ+B,a!ۢ+5*ج +:,cۂ&9_{D3Y||q~!T l0EdU>|$jd@CR.X>O scl2,\ya-ZۃΊ׫ ƕ|l``(X'ڀKVW7{oDePsbm#OEۭfŢ0znN2tacJ%T"ʈN)_6͔QWVY*o=窂ZW8ߔ(]߿՗PYO>}*3 vG +ƱN؆^onD3eVɹKI-J +!*?w^7^D 7YMqmR<>SUF +DvN~o#5EI͜GfSL:t`a- N0cХ3]<@LT{+Vɴ2 ZjLJ4LQ#vt#e\b@ +lD]3pԒW26 +Hiڍ!3waOzwar] GRJߍv &!4C@(ȨR.ȱJl.v`l[}2ɽD>Ţ"+8'Yn5wh{Õ;/naMpUYQ5:>x{Z#pgæ90 +e]Gr)m4a^2pN]!="!cJlMF"=`H= 1dO{#Ew"#r$O{p`°Q(#1i qjz= +!^!] /Rt{E# ڞMk[h$MSv89|")c@>zզ/@ܻRGYu-9&o nK!iˏ4My4'ݸFn:IӔ|63gD.RҎ<繰OACfs;5'!7gywz:uv5^hfuvے;~kgb`ƾMSq,_b)+eӬ65p02%io(Yք7!‘_h?L4^505w7vIY>kK꼞f)-xgy>kXMOgCɢ&  |wXlGa)liN4> YC%v_6l32g 2=wzךNz43|6B8ea%MS\#\xwc7i=>ٱGILI`QgjZ'x9L> +1Z NUCg'϶km?fe<+{vBt4ϧ?ѝ&>ӑ;cqYtWZLZ{re՚ #Dp9piUq{MfQH>2|4$wgzJQ=4PAc@A {MX{z?ktM;:^[nŮ4BčĆ2i\|}ꪟJAB{Q#Ôg_߯X,$ICy).n?ej.!`9{>{N>nVoGVj#ŠԬ>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 +HR(T0u +endstream +endobj +2157 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2156 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2155 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2154 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2153 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2152 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2151 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2150 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2149 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2148 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2147 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2146 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2145 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1849 0 obj +<>stream +x]KGr.``+Q A C.Ajw`^ZvȬȪGKLWV_Fė1< sϟ/z[¿^7kvF2f9{WzK =.Cp.D7.t>`sһr﷿1 'YE͟~7vkqln;Gq?Oeo7!>*Ƶcn`ϗ߿~㲏6${Olwoy{ٽ^װCK{ ?>>%GXrBkq /z{ҙ,}¿vC`7`8x{oҘh+aW~>oԻ `Uagw]w=Cthza{ sX9u>x(qUw\^[ϙIHcRc/{.ЌCE*<0g(/bgk/d[Wpyf3E jp5w^[VLWg?W% +#E&G9@@@p3\iwAn^MiuԱ +Xj%Ns3'cN4w;s$?fOss'syDZ]ؠH'IHft*d9G"Fi-™I-"|CmԔAG2ŀmƒPBk %zm8VP+IԐlmX'$(ئ@OojkڐoBPl!̖2*4rM59D%:_#[Cc\vuh~pbClFO<<(zR-w@8%,OaH114L9'``0e~1R1|VOoŒr{:>twqGC|,4Hւ|57ybʋvj`佒G >nv=-cL:}X@gxNX35&43$37,-9sVzX"O6O. +;_!zoU* j_7c|Vx2w,bW_-x&&]9J\o@VP3v=0W|)YJ}L9Ü3R9Hc[UKnxA|jnX<a O33uPr8ƫդ0o^ $x-ث͒Psؕ؇G#WKI'r/Jq5Bl(\JyF6[ðc} 1W}%"*`n3 su| n^S ė~ednn(}|g0JGy03E\1W333)z]Bv˥$Dfn݉ ъ}M|Fw[^^EDgYH *^7Tq!K㘞rf NVg0>Ek}n eF3%'`oosʶ}P# us`T_/ՇYIz#QPv+ӊ-NHvA=f̈vvVF ;u=-dݨC6p.x:ae^ˇ2 \HՎ]OqcXKS;Mu;Z +qGjIJz|l5*|Cnjmv:̲|ۻ}T؏o- 22-&+&GA ӫ&Z/:[zʌFS +42jrV~<K}h\FFZY~2XlF +42Jr֓K}MfgK9(+@k]zX!ԂmD'^|R~{UAsF-8s[1FUE ڛG()\^f,ie6U,ib7cI/bI#W7ؒiZ,iȚ(œs9n1+ g,cL•+kkIֶ Zm9g,!^ef,ңPfYŔF2e,Yl2;XȵYle0K}MfgK6==`MfSu,i,ӤD(tqێ)\ePp蓬吶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 +HR(T0u +endstream +endobj +2187 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2186 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2185 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2184 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2183 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2182 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2181 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2180 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2179 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2178 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2177 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2176 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2175 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2174 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2173 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2172 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2171 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2170 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2169 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2168 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2167 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2166 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2165 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2164 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2163 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2162 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2161 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2160 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2159 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1848 0 obj +<>stream +x]K@!0b[v +l&/F(Z1d=-'VA +`'? ?=ŞaU7ɩ6WݽE!Do~ގ_ǃ?^O~ Ozu+O?˿K14)VF9o @y;B򆌧_Dxg<& ԝhD?y! m>aja}k9iu6e+(Wv@PPj)g^8.AFЃ>T\^8.LKDLna'8(/P ʅ?@~,) O e#bOp!?{څ (.]@:_Ņğx~,( cI]P6hF8j'^VMl!?P%_5d膨BOla?(e D.]@@/a- ǂOl!? (zBH{ .\@ُEĞvN-Ola?e .]@AyrYX@- ǂOl!?eU5D7#&8n/}H i;Tݐb/$_NnĂS|:)*oF~΃kb%>!UY8T5Ck 5k.5G3>6LO9N.sB#78P["f LF(;}YV St|Iڇ獬(Ҽ>)r:G(_<ҏY(,6݅73) 5yd<ՑqFo+O(f[Bi<%CypErƲT$VQ>y2rK2O٥7sʔ)S5ydLՑqFo+S(f[BiL%Cp +ƲV&NQ>y2rK2KP:cnwi` k=23YʤpF#78P[#2!L2(;ʄYW&RDd/7,#SCryǴP&S&>¤٥73ʄ)u5ydLՑqFo+S(f[BiL%CpҕƲT&VQ>y2rK2OB>0Kѥ7sʔ)̮p#Së3z[2&G0rꌈML-eB,ʄ(e6e2qxYs=o[ʔXʤkE. dg{+7 a2-GƴP&2:&*}Y>ey^eOՋ=,繞~L eBxg9cZFn)Sc)Qi8٥539t&k7;QFnq1FMeB e"lQ3"v61-#7 Z-79ecU/峜z1-#7 ZϩhHֳO(:LydLՑqFo+S(f[BiL%CpRƲT&VQ>y2rK2K\ +s. dg{ ! +θ.&=qJ魂ehj[T%P%¶:#bg2rC0DjdFeiU.岜z,#7 %SCo$[٣gJLZ 9LU 3#:2mUʘUlQ3"v61-#T dcVҗXk%VQ>y2rK2Ob.fHֳO)S>L8瑩2afVGLLm9 +uF&e2! euLTr|2r[8KLpypF#78>7 a2-GƴP&2:&+}Y>eL|\[?e2!<29-44F}zFЙeL%|\[?e2!<2Ac*ڤ7r2ֳK:K6VhaCٞےtB(Y_%lXmQ"TD|+71,7U|bz ƲO2gd` d[N)PT5ydAՑoFoPf[Bi%F%Cp PMMoXmr(s֏g%HHB~o2F;qQW_O g_᳝޽==]Wׯwwvrwdw}o/eFlmԈO1| +׻v%J֤_1?O(M}^|]>|pNUμ`SKxgqޟ^}L^᧬nY$ ߌ1`CA.@ o0Io[M+aA%1@ < HOݿ[! M8r֣zv|CZJ˱r0I+VN-.L#L)HM M^ Ԋ)#:DkIHoCc>.qO|:i^[1k ʪ~! :vJB7KJL(6Hp/Pz{`I359ajufW{P2Ψ񶣖B"Lm0^῁Xv2B!"l䚎, X9 Yqx;{ԇ30ѓgUvjq`.?ƪoz὆bIH6c;X`R4B~W+/HS1kr%n^`lʻA򱏵rx>+oh.:<9y\Hr?X!>HrAJw=l1D/Z +\jl6֝qp5:}G+tI+4RY>{GR[Ύ35]^-4]֟ΌjK{_YjNJXbNJl捨t NJ$٤nI &!/7$LQ)%G +_7>,=;|`Tui GaVM8>v;EtXm QE@I'j:=;^]D _"6v;E(XY +MDgLL;(* Hpc RikZ4LTsfWQ`ɏZN<%s'j:nM|c4f.^OO ;q9%ZOZ3D薩M⍓6&ʉw(vE"iit'@?~a4Y{?Pq:@z~ ]pɳ@_@o͐^$jRyaw0)Mϻp^[Ypx;,7;K-%LKs,?W~r$Bxah*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 +HR(T0u +endstream +endobj +2226 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2225 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2224 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2223 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2222 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2221 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2220 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2219 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2218 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2217 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2216 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2215 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2214 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2213 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2212 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2211 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2210 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2209 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2208 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2207 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2206 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2205 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2204 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2203 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2202 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2201 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2200 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2199 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2198 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2197 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2196 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2195 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2194 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2193 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2192 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2191 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2190 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2189 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1847 0 obj +<>stream +x]KqER}E +pChI,!YáեBteU z#jT~C^WW0r!zg͏7·ow{g1"nF_|A7i!R*5X]|0-eO?]phh_N݉V=B}+B7B >ՃQ +sCV ^Y!N @A F'sSvz+l6*A /}p\& 1:oih֕"iPr_"^̗_1 +#/P\_1 +kQx~,c]V*:b1DE[@؏\ e]v +f%O/T +c]K?T©x~,( cI]\ښxB~,) +PcQ]Qy[@؏vB~,) kPvVZtx~,( cI]7 ~0ْ[1:K}ط)cՉJKxO=ǯ"rxh/ ;<,^yMRc^SCGVsp{ʄ[g2eL2a(;[ʄX2 1Q,Ym,z(<֏iLL5g]x{}za΄͙q{ʄ[g2eL2a(;[ʄX2 1Q,Ym,9z(<֏iLLVzK3GE4 k=2#YdpF{8~zS&CrꌈML e,/+cXҗYĩ^!g9cZFn(c)Sznvi`Azا=gTTБ@tz\hϡՏ1Bo*d(a[BʄY^V&RD\/7,#Iz(<֏iLLZmviz9:5gr8=Së3z[2&G0rꌈML-eB,ʄ(ee6e有UCryǴRS&SKoOֳO/)S>L.8=Se&_x8)cr -Ghݸ L-eB,ʄ(ee6e2qxYs=o[ʔXd_sճG/R>J^"C%>j3nSx %B Kk< J .UIyؕqéP92Ջa 7g,x1w8۳~=(I=^Uq@pz`Ai[eyTm0mɘlQ3|{2rKK%$}Xܺa u^%/Uy,緞~,-x,% +R9{>vg`Az煹:5 鹭"gPӁ7 a2-GΈĴP$":ڀkdFe漈UCryǴP&S& Mۓ ʄ)65yT0ɫI1meʘelQ3d2rKK2:&*}YپeL%|\[?e2e<2J6hޞlg^R|$Oq{ʄ[g2eL2a(;[ʄX2 1Q,Sm,meT/峜z1-#)㱔) +14ݥY٧)S&Ls3}fߜՓqFoc,cr -Gmk2rdee"uLW}#2r[8Ջ,繞~Lȭe2 R?o7%I;Da2?|/|QnN^wwOvrw{򏯟exe>~jj)a=|aZdMz!^hF,ӛZQxyVgT9Sq7Jɀ Ě 4p~7FGO῟V=mz+E?ac)7/"@cpq+$97XaBЧ䥀|E@aL fbr||s1reJ zI?^H?=F-_OL2ڧ Ч[pO +[Y/)`O"h ɚbڨ/.\%fa(1NRB p ʹ>YI)y `"l,@.-s<Vb,ѝ7ç4J 8CYk9 +8-C s+zheb%H}H_§um%2|DW-DF4soG7VNhH]jzE,kwBOeoGYݩɞ? Z?Ht2bn4pKq!pgc?gPbऽ &fA,~z⾸ ,Рftc=)Ipx;Qo/I+:r>:*ƴ+c$AוUlBJefPVG7l,U&h}k;8\dx4#Z5ҡy'+- Uf-& NkN!j:ND=¼BGW|vV`e:i󶞕_yLvbxa 46JkPނ51wO*Uj:f{]I_WJ.x+#AfxU^g``\&5rflv{=)¿Oob#>OF%=54FFA)uř8dӚ+XYqdNF1~p5ِ@D̆J5Wr"Dh9ϮωLfzA{}{'bPϙMVdZ rn,SK{W2aNlN7`%cAmg1 +5V/O8][Q:~3^i8;g g7~ptLMNV4~ اi?G0`]"|ޜ Cù^769#Mȧelg]ڤWf떌GPtL} +:z5Usf^W䓍LKP֖=xqv ]gem4S + 08/X7xF4a6}0ثGJé48:;/awZ1~Qӏ??b4Y{8 8vTɬݽ_v?O0e３=|y6Eqt)`uInEx?.ѧpzmeÍ8~>^u~zƏ)2o5|~KSh/ +ًY'Vx[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 +HR(T0u +endstream +endobj +2269 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2268 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2267 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2266 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2265 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2264 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2263 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2262 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2261 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2260 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2259 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2258 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2257 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2256 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2255 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2254 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2253 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2252 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2251 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2250 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2249 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2248 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2247 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2246 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2245 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2244 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2243 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2242 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2241 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2240 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2239 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2238 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2237 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2236 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2235 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2234 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2233 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2232 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2231 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2230 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2229 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2228 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1846 0 obj +<>stream +x]]ooCQ4]LH?_"Ul5dK4QPEu䮖3$ ׍b~ֆo|}Y{krg?FOg-0fXz)j?nu7Ͼ;p.D6ywv_`ۻ;}RroXo71'wa=㔸n9CO.d\Yf7Nj+8|ךK4Kق)qPN ZLk ;=s \L;冝¹~`yd ;g}bU_W +cFЧ}Tȏ9Cv:pl8+;O\@ȏ9Dv~* S0JyPR, cFѧs +>4(3a%>Q@i- ǜO;uIi3O[@؏DvB~) SN f/a- njO;m!?} Ⱥ9>FxB~) PcV6NnޟY[g]HJMط1 +W]1Ӫ1xz_y-kTo6`:xz_u,x$'\]y|4E02"[FsȶmjC^I藄m> +eFULȕ,%%St=dڇ+YHLՙxc9/+hʢ\!wDk-;i82V,ՐqD+OĤ(fBQbg張cG(£) jZHֲOF^9aeBwe29 3Kl5d1)ʄPfY4\S&ĒL +}YeyZyO՛xs9okH40;ᴝl.de3;I{•F8mS[#2!L2%lQ(3JbG(fy\:NK2}%=gBwL2%qdLmG2EL2a(iL%Ap' }Yeg"Uo!g>張cG)Sģ)csL_JF}zdτ홬+q#cḛ#z]"&E0|ʌuL5eB, ʄ8Q,Su,=z8<֎iLLRPwVԒF}zL$e\sF#bvzU&A(%vV1#W = IzΤ =yhd[6Վ1B*$(S62GV0#W +eFUL5eB, ʄ8Q,Uu,=zQ>y.張cG(#)P +BջԒF}ʠ6Y?8eaK>8U%cY/cMmcЫ0 G(iJqUJj8Q+^,Q;|9k2\Q$W;F߱v'ӸSN͛g_>wm޼;nvtݽwݫoGBOn&6zlDqAp +~nRK)Ya( p='` v/yM2X0m.3G}Oa6`׽ovp|4Kz6X@[EWS"vA(,\}W!4z.oCjV4' G !ATjv!;>@yZLdLOhb!L,17jpzLifb|R>AN2鷠Tw/"_`-⬬`FVqo4εB7j_wtWGOBxjCl@PAh&;yo3a[Y51X렻S-28\ұuhmPrvs,p= M~ )g<=_˴Ʃ^)̇ȍBHEgӠ `9AH_腔61r=~N!>rM? a?hI! y3%/ixax{,T/J6TxwoܮC%9 ?dv@TSLb-j@aD_@/+L%ܩt4*G dّmgc341e0vUK%hI̘ڂ> Ha4tzra,/IOʓIWïdƫ2L9K`ߎF ҚU^;ȟvx{O1 +>sbRљI]v_ULafVsp%5,Rjzaai_~44(~95i&bCo,6x3e,DG՜ҙe( enAy3l j9ÊCz7C|P\O&Mſ +Vӿ:ɝv2](7ssδGܔCyϜf9gas0Sv.GBX+>zK^^|dnf/g+`ӱQ+o#]X) ;(T-n!gǵEUt$}gxa-x24z 2}V !maq>J}g(}ֶ˥}dzc9~0Pz6g^yѝ bzhTa\H-\A Xo +ˢPڌfAavŃBjxN:/exrGi2{e%^߲)Q8&tTbn3+: ws X0Zz?#= W V#h{`' J' `m4? +t>󐴆%FGbC~ 8A,/ʿꋰ',׷{]όb=w;z 3' :ڿ5yx 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 +HR(T0u +endstream +endobj +2301 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2300 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2299 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2298 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2297 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2296 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2295 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2294 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2293 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2292 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2291 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2290 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2289 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2288 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2287 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2286 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2285 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2284 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2283 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2282 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2281 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2280 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2279 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2278 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2277 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2276 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2275 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2274 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2273 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2272 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2271 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1845 0 obj +<>stream +x]Kn`oC Ķ88aQ|?.Fଽ+Yc:/vS~`ĮbN G ;Nz~{}~dwZ"LYjWNbJe|%wJm:DŽ2k{p(Acfざj-!8ieI5)'p爠q\2͸&΃(ߒÅS6S ͈7U$ :=W@FGp=ʾ0yT;n 7q gtEj[t"Z%ykT7wG. GKU7;r~4PuFIZC,,.Op4e+mm]u{7D343}fS>cTn]6T˵ž}^ʂ1yq.O[^zJL+VSr}lk9OfEئgٙ4\Wem}j2byc>/1K#U)Ԗ0GݻŽV]A֖쇐Qqi"l}Ցd+ǶcЋ0+T'bBQdg4rAu0êpF:'ӟdFnڏ\Fޡ\sr,EBxUWtXa*vP[ue4d=0B߬ IK}.Fӕťr4"֨♤%3Y瘄-wXpFd21ym9i2!:eҜ8 Kmݕڒ2o)f9㕩2afee1k MG!(3iLe2:ƟZMy,EeCty[iL#^29Et\ں+%!eYLN8WʄEdym9i2xUd!9nXڪ+ڒ2߬R&JrFWqm- aV(S6<,i2a)Hd_?2\VɀYEcO85O:`(Evf1M#@,RTÑZLL>eyZi?ryrq>g˱L#ҊD?1owE'"*OWVL`CVoߟ zx3\n8p1hvچ?LH6j0|\ ? qj(W)\s 󛚃f gyJv>^7@Ά ߼ϰ?&@qnQ + Md5`~ ?<> ßcaŽ֟np|Ĵ&JkE6\^A

|E=Ѣ0Z1^T1*u|N|NRlGQA:R:+'6GPR3t7U]d6 /\zp +%D'J`F fݷ'.]ry nХ*¨[H#Z bJ6G"_#X@ nls&TJ]41[}ܿ烨 aSH/5룙]{',H}{WλSscsA6A4ma uFmoO°pQ~ԧf;SRBZ1T5B(8q .\j1k ɰ:_B*ySHAЮOrnrdnC-ai#\x6̚ӧ4م&qwFA +c`N!r3<Vg}xin5nS`߾׬f}Qi3;Ѕ6eve?UBrr_6Tnk%4*dgbNOi(Daj MGָ6/yJX٤*}6R6}#'æu |9iV=UJw>/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 +HR(T0u +endstream +endobj +2360 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2359 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2358 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2357 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2356 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2355 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2354 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2353 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2352 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2351 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2350 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2349 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2348 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2347 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2346 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2345 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2344 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2343 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2342 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2341 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2340 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2339 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2338 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2337 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2336 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2335 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2334 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2333 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2332 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2331 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2330 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2329 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2328 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2327 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2326 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2325 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2324 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2323 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2322 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2321 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2320 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2319 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2318 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2317 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2316 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2315 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2314 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2313 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2312 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2311 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2310 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2309 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2308 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2307 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2306 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2305 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2304 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2303 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1844 0 obj +<>stream +xZo#E/shvUЀ! f؉ 6\f`t?& NOrw}`p|NNqꜷFz7uH/3:+k +$Yg g5Uy=\ "<|?# A53+8`j;@;IpQWuy;@Ɖm/pv6^ueW4u\+;KUk\Bz]qn䛂KsHɂL"5Naoχ'ɹrbJ~% a\_%WdȒJ8MA=Cf m ^ JjF1ΈiF.PCICf;p:kO!.`-;5?Cʕs%܀hі=XH#E3D8 w + Ev-B=;<H3BN}ye^U\%Fz@0O*|OiTX +e:l_}abI1$Im|`dыGG8P:MV_;O^"bJt QesK`,]&#\y]t_PƮ3|.hT/ i -%)T4UH0J +|B)֣<&–{:whO#h؎Rpq+ 6}>Ŕi ;Xjc8XqA =7ABt80zU"{]"f4W c@*Gjteަ("5&,k/j +? q!j(V/T?%j +PnhEcnG3@;*Q +"vsN07Pp~])DHH+h~+{ F`)g:g5qzIL}7%9XEqRlյ˿"Pk#tN( CbHI=v:Kn,>A2 t.9@nAI* c\G X=%eMYxu9\ڶ,bK,Ƹ<BM 1 +E-۫T~|*} ;Me)zT]EsUV\&,[jm_jn5b* ^A̺6 z}y^H1ȀJOZJ)*e*XtldA?*k Ik4*դoO)lGZB9R-s jupYy Ux<] gZA +2m\^-:t]M$ c4He{ɹgC{z:PHlcja9w1,{]a[}|0J.Fi_Ҳ9x7V^Ł&#f]o%wk_joYg-Ը֪?Ӡ"ၯ)U1׈bEv3&BνWO2Ksi0:fQ4+v@^Yc )I2 vKC='=LXkVj)`ZuWd=hK8>c`j[>д؅FZVf: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 +HR(T0u +endstream +endobj +2366 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2365 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2364 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2363 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2362 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1843 0 obj +<>stream +x[Ks7F+^\89RVx? %Q"H[\Jv{؟`0áHƌ$f_?L+Z⟟Mf6+ +%8քh %X!5]O=/L|m)2%9 ij''Jˇ辻^ ̰)B~, Gup㷩8V+~(ip ,nE7dݴhA4 !׋K=E_es(8OL|hfh. Z >k'RN#E^%Z5$\ +XX4f(]!yc +-%jT{53g iq\w)6 7@HWo[q VUd3`|` S& sOC[L5#sg ]x3~ȘS5| ƖSAػ pѧ3J9 +(feZܫh幯~s\rE^ ~NS?e"!HNs_'v2H6f+) af8VIk -P*}D̕I7-|V^e05qwZk<&`0aDbk9*j )`ydSnsWsl,BN H4 +6tVU*nBY)zc5؟{YX[U讀u~לaXi*r0U#*b̗kMEPx?9NVq*lDeB6fB+9IYRvԒuY/|KDIenUpXpv+kW&4؆Y.WP~ZngxK +*0BJCdH ,ÀV^m=NeRH߰%4^L`k<\4[.êu[ <ԱdTmvj(-nMRYԦ\g0d{_/]:QkCPrdb0adQlcuK6\`On)ՂӮPC.a,6r:"]WNcu +k"J.UnaĈ-RAݹN[0 +BHEsGNÖr$$3 +IH`j%ɋi_XXUk&,#'B `”Tl;= 3),á9q ~[:lpeR'ebxܴ`:TY俆r9SЬM<I6(DtvBG#x*B)te}?N(󜡬=μ$s?![:ZRpq^Mmi;У4e iy(>[~c3DGߏ&ɫ;seo|&B Cs<<%Оy;mH3Qq\& [4\no/>3QܸL9CfҖP&jD!<~4P9eLzm8zg>P9g1^I3o~ip&j9eOg[xli]`|[woB$&+I;:S݁IzZV_e=G?4}T# z牜A23[WW/>=zts(ٜ$Ls,*"DI Qjr8:@ṰU פbI%&&ztd!qö CG +L-G%PiLUqbHފ5W'pʟ{>Hs: z>|Vj"+Onݙzo-skb;vԇčbƬi^UQ̽KqFKIll9{OW^e8/o +5hu֪raeUE/I*nDmWE{n9B'-'Bڽw-'΃<*%ݑڳʡalW7/6rz4sE.tA{! oT{ZPT Zɪέ(1J&~<zZR9Dx:MZ1lPN1,=mes >&Ӻ<:beT*^~҂GP +n?t=/]笒G\>X}픬j>/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 +HR(T0u +endstream +endobj +2380 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2379 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2378 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2377 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2376 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2375 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2374 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2373 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2372 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2371 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2370 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2369 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2368 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1842 0 obj +<>stream +xYKF& Ha"1&=85f&&XbH]`znHz}UU{|c~,*~09޴x!i5RuB +YY>a:2~W'uټByZy;\N Hy;λoAX\W %iavn}U̅j9N|^c6I Y+bՎsx +Zc `P—I9̩Vk^wx*f`υY,U) vX,!qel-3k E 6eF'MLRm .ITD +5*Ls˼YkÂ鞷SC^@k{/* ER-jRkhy ;O1;}m/e*es6o2y8zrWh?uj&{c9jOC aQƠ>ɇtӗv ur6EGm+cJ[.N=Q/k2[ *^) 2|=SW zʸUrzg pJ8aUpoS=7ABvp[X-ugÖmSYX82oHe `叽R,H%~ +Ҷ[./UZdL֫Ov5x8ϩ!P?V]cF12 +#- $`iXIhzϤ]wh|tcwt#D*:ٹµBb*tLa!t4`hb_9YM#O;L:tzF̜8Gƕ!|& :?20K ڂvvru6uȣTP4+εe3,[)3D~SCF#Az;'hOQFVO:7k rA Ogw_ay [ +@.LQ $Mڰ%bd79`h +…wsT3x:01APm9[fEhҰ 21d\fBn MH?a0ۄT(䨟9 A0ݼ :~]ӈ9KvyT*UIx$@J3OBݻ}3G 5gIţqawv +hP1mʴ(1M3k73 +5m :cg]s]l~ϻ,/,@*@VZ'e$)":;-)qY |?0oZ"P'[p#?M1{M}'q +hhT"N7jI|<VKnm@']8TOk +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 +HR(T0u +endstream +endobj +2388 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2387 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2386 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2385 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2384 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2383 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2382 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1841 0 obj +<>stream +xZKoDЅ ^$&AX=RdƢ(iDC6b/S]=INLK"ꫪc-Z> ~Z4OZ &D=4ZB+n?н~a$1pk[B)cV~p/XxH}>;>߼a-J:9},Gg|NKfuWI7lM~{5oti Tbqˤ^}~;;;58\5{^|S)FEqVLXk +~w`|!W)<)dvw^.VA*}"LI2lHUx?^heLQH|t5h):w*\]:1 g +ݼZeqK$mKn(۩E)DluQA1PaAbra!nsq0.] bpŬSe +@.`w~J sEgUI;(pE9P%|R 2ܣ9pF >b*帋h-m0LS=/7)Bg J3]R*iX zefvCmaåڼh>.^+ unq&M8TIu^y,f %BcZx*1|ǁiz+)C}qtm6]UjiBM7ZYn/2F6[md=!y'FyMf>-[<"Ƙa4PVn_w(.֘n#ݲI0Kb}Z`ЛDU1RØ`%b._GM2FBCn KG')Nq[f?-5nIu8 ^DF>gy)ƨu%'lĦd;h%#͝A gݛV!#t_SC|X!w^*KMn+8=\|jpP?k{ko ?OҙԭNJ5}&2ZYmoh)UDt{-u68n6M3)ȼ'b^nk2+ [%#AǞ.nP]V{.,ac4E ֽ¢Oag4%1'q{c,ɺ?B[! Q12[,N>\5wIZhKT><(~ IJ)rW$A!̡Gw*#X{g1=-xI՞dC?aE51,̃ l=+8BT1Jb>.֔Z3!K:NĨEuO@nX4k?QTR3n'3H5#h +##gZjx j/OTR2f,s¶@BZtʔRk5zŷ:7;_Q`kmҟ=Ek#`C䛑#̪2&M;4*)Т767r(-XeWڃ7zڴ_W&*Ud :%]I7}g sպ~K)Cduc?bO {Rhem]w0QZGJncaF4 +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 +HR(T0u +endstream +endobj +2400 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2399 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2398 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2397 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2396 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2395 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2394 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2393 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2392 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2391 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2390 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1840 0 obj +<>stream +xZYn D"1lbZn}^ZZ ɀ@%=U[zn)%9!slPS{svZD~hkWEүAxtIl_ 7T %z!1yjzLbBydJS)dF\"id @pgQ<T9xA6#l#g4uЇ&^*2C6\H&/;"]8KPZFV-6T Mа6p9 !~ѣ1C``)o hB*`*K,amIM-ZAB*h0݀l6 [ R(cj\ ¬1]fX%~\`Ir_4uUyЇV;YLQ7-k6%bn1q",8*C*P?k:`o ٻwЃtҧL ybBy|],2g\p`, L|3[P+&v6ЬqΌ0Bd!e +2z Ij@F$Hn\0ٖ0H6ŀ,fJ, Q5S*E<\4HJ[Q+w2NDY-JoUBߘjI(3T2e՝В:4͑8U|xN(\z%UVC2!Oe]2 ??ëO2A=yv+lkJ**sjVvc 2j<q=`~?+7i md9ҹBCszZP}8i  +2ˡ5.r+e8( ~pP`M̟! &5\<=mɇr)|n<ʘq 6WZed_u?eX|tX{_:,N|ߏRv5=*ףl<#Y#[{4n F@;锄9hsmhui w@ {"/0;|rr&X`oۻ*k٘GGw]Y(GPp'C ۜPVa>d<Ѵ`Yr aqX{F$| +UX{xRHm7o-tVj)`_z"W"L%-8ЖQN>vڲ=”pi-y}eaf@>!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 +HR(T0u +endstream +endobj +2411 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2410 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2409 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2408 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2407 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2406 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2405 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2404 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2403 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2402 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1839 0 obj +<>stream +xZ[o 41A`Xh /u)T%NiAv'}>g w\RZsoswgva 8u[_ _q<ƛ/&3JR˘u6sVSW:|Ӑgaw_a΅{✋)6|\^DV:{^|`F]n Ńעjk^ϫp2eٰYŸve)rNfg/{?̸S{6ł:RaťGY>xeL0 +Dzd:M%QWy #+FvT +nM +Yȹ>3hBXijNxS47qۏ)~'AN^LZB"*;>iZ$ 7Z't1bC ,[^z|Tbн2\.dޱ7㘧WWP=» VhHlgfV-c˨:@M ]<ظx1^>/Font<>>> +endobj +1627 0 obj +<> +endobj +2413 0 obj +<>stream +Htˎ0y +w,(vHf]&C#AߙAUY j;ooٓLkF9dkU1Ub6z?[ctloU= }ν69՗a_?`sٳ΃|Zv]{q}A0ŰX^QV"dT݈0?^\UaN26? ڮ){`hӔ~ǣٸ=SiZ%6״ӑZO>eiL&N&9+6,^ $v$THrH +r+# 'knB9E!ZrP +Z-v-G b\\@'D=M! +l ꔰ%PȞd: zD |(z/h<7C)) QF1#)J$=5H%yFEb#AJ)$h8(-@)?x>/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 +HW{PS?ޛ@bA$< (bъ$䥀+ZuZ-θ>T][vgtZ:c3;] ngG;wNw;sFED"[S9f_.5+kZsp,BM5-Ί*l!9WwqrP>F(tR:W +} ȮRA(;~uPvKe\M>.xeM{X"ܐ)l'C\n$Bk)}k(!G{S{~&R'=` +3P7˱{|6=C2'a +g/ ?~Kl|##G܌/ :ow#S"G^EGuGG1F_8~}' +\m^ ѽg&KC<E"<&y2$_Aɕqܔ܌ATObNس˱?J` B;;>)g&(Yf#e,*QZ֣ h#JQQI2QfFePNEͥgKƸ#蝋wƽ)G CK6c(Ded?a7ܾ ?v@o);G +Oe#ډ=1ףj"Z:er9LW"DFa(\%&&U"!iڑi݁ypw?E&bXti4!ba|~\,6mi7nfr\vT\LA;f-j`dtl3mitZm0? |v3Z.Wa~f,ʲ/ƱTm *\ @ilNn1q!ƛ͊H#ӔF)*Ujhɴfmn֪Tɩm.3m6(^z`Ngrge9ܷR<aiQۦM蘘4J/|CP3[Ǒp7oIIK_%^ 5hf[k=eټ4Kl GEoTX_z^ zc\%?;Ę\s T{jp /m@?`'K4 "[qo5\ZDX<Sj*&RwCՑάQsVehwfƏ0HFX0Bfocv˗#2Dld7 5|y0\fiǓ@up{*$'B'gDQ3wFD>Q {8Ss3T[+ɍ!"^t$̼?5Kbt8@, ibt脌mo,Rׅbw>Ux g)3@ܭި6;2v0h6X,e=V* s\^8:zoSx3))8xF`kOI .]/_\r*M]c0:a[ffWMïeyy+t]7x6us8iH|9>Ƿر9'I(#$ N !BHJa[RuSC!LT:N-$+# .? M_kӤi[{O.p ;>>#.Nc6FgF2)ȦwECz +R|'75)NR]x}ueB)xu&rه,ru?$` /!<badޛJ3`E.})mď62u$d(QnO|8pJ) 7* ȝD`/ךS(lfa-H8 98>,//__,/YE a{ a?{=+.X=|I5߁{@9WΈ6п_Z՗']:vC~>xt Jba!XϬ'@7n@EBo(vmF?,x ^(tǫt/Okٚ<׻ğD04ۻÆ% 0L>S~{j^ՠ*_4~*sQZbK?=r9u(l*ZF鬮v-9awqFkѪI=4PaXŵq՗A-sк$OVVN:ܓlF2MoTG42"B.&H%nCҊ +TBt="'$uha1EL닭㽄ߪ+T +EĄ3ErL;x!O^ȫ.Q=5AHdt3>_c[g#fdq;^i`ui ]~_Qk-&gVGq\sN!|Mի=1m`֟V;}uf-F¸q  ߽ \.!kTv[,F v!$3bafvOA'[J(G𻊐ZC(x:n};?,¤_"4M r|éY| Uß1!_Uwi0,Ê6B,s¹9mD묭u0TVޭ+D=>CȈhUzBRhC  +8Qm4co (nA9#3\O!o|"Wϼ7/D_DϾ]|XLr{We|fPR4+>nuT?d0dH.WSju=:rjD.%r"; UVc4g.~Z.?ƫ=/JFC}eѺm̺kgvwgh[gYVrs\3Iܹww9&ׯZ+%ƙ3tEP(B~Vh?KX |NjMHI^¡™pf #stIi* +\ҿQ,oi?5MHB;X,eĽ=gG~~<`ȋw9w\G!HsEХK-dnh(~=I:Q{Λ?/?EG>e}<BCsX4o{b Eq1=ШSҏF;h!-ѧ/g͙Cy{O'8Ҕ>DrbH: MM0E"D}ǧ6a6Qbx@Tb6N̦lHI)$:; put^ۙ +%ݘӊJ#bWEE%%EE,,.^QT89ZM'rL&eD/$h\X t-y|i4txj琨$T;F;ߜ,: > +Iѫ92ijs-1E'V2,=.w:{k6~\].S*hƜZm/}u1VtfrTRץT%&Y"*t:ә$L)ULn@}>VgsԈ(L"m'DU5Ŕ6YkegAٌ44bJxB2]m(:#CT΁;يfBlID?rgsS[GWcKثh~6Jm$< :?x>y;E+x4RMy:#/[-;*^dETY/zw{_j6 n ƕ/KA'8*)oc W/sF9-;j٨#-;JƝ;Z:qͰAMq7/@Q"pmi5q2:^̍[Vz=M/{!L7\lEwgeLF`SB H qG#Z:H]Ͽw_CGпi`1,~&/7wziIV,U"r\BZDm,I:B"mr0#v4K +1h*yBlDR2fh1JOr_is4c>Qhh +e&κbD,w9L8oTsD֍o)%X0Cϼebn4?9rmh+~?E^BggVK\L|="J$ nk\Ie_/ۏ*yW{}?m^wHJH0՗M{5lKiή-e`8z=Fٳ~r`4IܟohNhއ)GL4GlPL]W&O*F]wO'P,g'B2}p| a j1rx ZaۏqL>BB}00M q+p=1ȭp'&C$Ey^ FNC.t ;ˎrW΋FVIli N/r{ј>K\L2i} Wˤda@F f!25^q_~pzgc%ܴ[M% |[Z9|ƆJ3W_ZrYXHsANSUi TJRO*T 9 ǿvnK>{uIUuL c.7a a P91y?kvgvAAG_|cO {<Q(gHxeH+.R>>;˓SP{wwǢD~x(KzuZ{=҅3ng= z"O|tp\o,@(f7YԽ(jmWmFDb.œ)wUOJ\Y0ILSh@6G\9V`ct k2eҠs{#FFqQn_bcٵ7YMnDm̏FIt E֝9ߝ(Sg 31{(G|]%: +(C#V*xf<,~l6e{<3ccnL$x-( KZ*9QQ + 0Tj~EJIPTH4"<7gl P*w{v9nV68jfz ;XVWTt[o@mC +rRDJoVaZx"ZyB.z +]aN7z|'8|Ҩ9N 4@,3f =8sd9(D{Uׅg%>oѧ`JP-Z;h.$j2O^%mLH*/˅5a'/\t9˙BR +ڬF /0M(qٚGAk\OJIKsu9xɝھql6Wes<]z[2O>ϳQj7;oi +3sj3qYASd-Vu^S2{ ڗL%KʸO#y4̉iY_/?VRs\'˴CB%+mdr (eL:лl6>A1LO:L3T's }6[d`1)dφ/c&.cbb]H)LpX &=e + lEL&]QX '(fi@.]һ7/ے̲i/~O.iro/q{)DN#vEs͉wس36qD><'\ÒV}\k(g'Ƽng'[T1؇9LRj\ZCo"<^OR$ ++Q"sUvAQ:.qSA5G&. +[Tr1gsuNg;oDn3ԥL%h70Я뻡@V<~FXsň{F;nٵx>[Fus؊meP(gqͶ|R꼅Cд[u^Wu!{ע|HxbJ^ 3\ʜ"-΁$a1 :+t?x.~:[=j@ l +8+݀1eRV8t)UTFZ%2) :؍?fS{=x6c5ppPIʠ3M)Ѯ/A<)>=U{8p<]'"a|%oj;)}kxױqy\s볥DohsDh#ڂX̼2 aR~1RC-NS(]h%Av!,ZK%: Y]Ex6CAEȍz +ZV÷V6LDQ/%+ |@F NQfaXTC8A_H bk?"h=hoBQq7H> 传HP5j_5PwgI>h3ڠFV7$ιE-kO\'8KY3y=tLnfA$v#/{C9R.+[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 +HR(T0u +endstream +endobj +2420 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2419 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2418 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2417 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2416 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2415 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1838 0 obj +<>stream +xY[oFhHTZ\$%_4!$B!U.ECzۻ7$b6kx3ykT.:NqmOdFIjfjJgvtywnXo} BPͽqqA +ב^,_,QZ@kӶ2}0ZVU+u3[(_~W,uV1sg +vKiHmt!3!d-,rt!xZ#=J1E6F~Ekڄs5zQ!: +%gjNQƍ5=}rOM*%&QDY2Gndzi'7I]h|K2 |Mۜ<&;5oyr\IE`sR;UЫDSw 5g·xB(C]{cScULPǍѪxqOHrj1 r,ƃS/:èh41oY`"\4PTpBFPAa=Q> +Z gsЭ飙(TKһ^&zr3(D\'x(Fn=Y5wiu|t9qY\ջ&KLHӵ|xIB]dVZeT }d-хf^^:2 -+QBQ-%TT=QJ6bTZ#0{kyJD 42+ȦAƲc7-mY8(CT]x {В7 %2h-̫! +éUWVd 1lA{^#0+vQ_2l**8ja`-=`8.h1|k5o~w6":XioL2)/+'OsƨLlTA=7(qҌR}s4GmWI0l UaR!(X!F]?c?[3[i"~~钫U%^P΅6QɅnB] @=QMnKfM5Y\Lk[ 5A~H\k[5.5F@=(+5iS8*:ڤJ{cF餝2ٶւHU\em} ѷx&5Enb`s|P'$Ø%#Ǚ?ΓQ<'Crat +/[Jf8ꃅǁu; X~4SiL'vpnq_Γ }doivlKBO$9Фg^'mXv]|?9ho/abxnٸ#:ћOr%OWQTް )cF: N/p]M $lYc oe40L>/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 +HR(T0u +endstream +endobj +2428 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2427 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2426 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2425 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2424 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2423 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2422 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1837 0 obj +<>stream +xZIsm㊶-kְJDwLKN:PJr?ȿo`P913=&"8/E}pV'yOnj:Νww&՚m?/xJܧRi|r;x|Y"TJ4Je>GQXZ8U1lw?ϴu(4mN~'.h8G).(є @,N) +XLa +F$IJNvI5*֍e_EfJ&% Usݨk M*[p#;NHWL?Gu|F4lp' RC"9e2?rljTY|2P)Յ7& ~t-|?3b#5QtMUG_W59K*ZI*o +ѢEu>$g2rH_~*z_.6l: {,8ׯ*LWhH ::X.t:BCqr1F974Q19v?wr4j&I0|EF({L z;q삽b?k $Ebx *XRvb(ݜ"DZt`ͦxBs]"7 qk9YR蘑CFE3"ɯS*5fzu)ٓd睞SA5x?OTVѯ_w{NT|xS.+,׀SmѰ/if_.EZ seTkvfqP$H-}DzOlvndS@{-?_Ē=y`L>QOp~iฆ%Z~b?!Q(Lý,S;}6!oly|H4;Eƴ_e2n6anc~/\Ǎٚݛ/sX'4n*uCq 3P6~]QkWk9Nj~ݜxu%>cŹSyX)9"<8`q'%mix*wX}.|"-MrEɚNnAta +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 +HR(T0u +endstream +endobj +2435 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2434 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2433 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2432 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2431 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2430 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1836 0 obj +<>stream +xY[o 0A[԰l!R.%Ғ*H )<5ЇG7;{HFP;gprS5*Cjuq!Ɍ2f͜T)~vx5~ȳppkNY?yG8j\84witq?\_BuY.o|m[}ۆH#׮a,uV1sW&Q W&9res߳a(ťBp/ӳg4!1+~,rD^S 䣧_^U+I[m2hM=OdD rE]!K|4p̚+J /0X4+gJ8<\BS16b4$Y ׭p o}Ձ!5@{SqxjSNjsW2.SE݄,DC_-V ֕"pܐ?Fvpco6#yW㩌hr\rii,Ľ#_-l9nU +#|v VDG}bW?5t8nc _ts6L΢mő]$h0#U׻OϹ] y.M==?By1O~Ob<i.GE8ݟPbP+'P4 cl AC *i+q:ytZr s`Cao7I 16u\x">*F' +* +x#r,av8QNȝ) +;p + hn41;g Ƅ_GM_\wչ*~!sXc\Ί2"~(~܁Lw?Ap[2E,n 0$ Z_kt->)7ԗ 5՚r`34]9u+TDF-q%D̢}u5Ty*Q!5)#;r`DžLL"r IfsVJ[Aqp)%1,aWY=}$>4(^Lr8+C*vY\ HjGq\Yz-B(ͱ +%ci|Q;B(#6qD_;uRSoW6{)-8ʔvu)Yn^9ز^[[DV0,܍'ee[C5~KI"FR;8n)ZaKChpμ(|yW:_TFN۱TXP%mBv Di༨%δ*Xͮ(YoMcF; +eAd˥FW!Ø])kCrt`[HG3yЬU6Jdm-AK5mȒ(h^_i ۉOdC= XۉMċkx{M?mlK[x~a/ ѐ?jm\i1i;R@XiO7Kt|Z_w|mn RPg$캩`ªՒX^|L>fϱ/pa"u}?I}pqX%bC[jFA[VuZ>ϖ}HN74T8oJCsD_^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 +HR(T0u +endstream +endobj +2443 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2442 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2441 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2440 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2439 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2438 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2437 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1835 0 obj +<>stream +xY[oEc@*Ҳ(YHI75'nZW ^_PBHfv]{}i(7ΜM"c_dh}f0;#-El(5D֨XJꤊ56XC_o` cNJ9mÚ>f6.O+=NY>.<50mM.<6gke8Nyܳ}~]n 1y73&c%n-{v)d\Mru༏sotypm,%]r?bd!Hbco:LG*čA%>3 d=vtnH rH/H͚IsaJ*Li*W +Zm(z]uqĆZTXC"ynћBan7tmq7+&F-2fT -%/ì~G62z,N3 yk#' EJs)E- Tq[%n +' UCE"7?Fwe`|G w|OcEgKnwB>d0D2P1;Q?ӽ,z^_<9 )X3jBvy,!ǁrI0$I~a>On`z;p Cj.jjmmL%grM=3ɦ%̞0XRSM 6WFtݱ|,PD2r!oTIY4 ݰ̗q;3RP2ɉS&\ξ2qZn:]A<פkMhcq-mNRx +" +YXmؘUA%ڕV!mgԷQ)1VRH^1ây21G` \xۨm@JS Wu{RwBG3j/ijtʲ%wiߺ8u8+S|QHPƤFxyѻY126i.E@BY4>&H"qJj +ʣHsFMQA#P^w% ~FDXA2s#k\k%yP}%L X"b50L`}0FA@\gK0ѧSKcaEO GW<T[:',y8Dc$X" +Wv3 ft G29' L';]iUa)iօX:NZKl9|cbL̕ëRCvCj~ [-r0.ݭFhV$zΜ5jb~)/ +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 +HR(T0u +endstream +endobj +2447 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2446 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2445 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1834 0 obj +<>stream +xZYsTn3˸xm[j8 8x$1 ,pW~B~L[]gU2w9wN>}$o{<=$=MR(Z=0A|(=cP +%؍dTRU]*`I.2VڌTAc G? X%͹Z1D5H'ɨL/!y6ёRi޻SP:wȇue)iDMvY@qf]<:!ؑ/qiRg9d[!u}ձM"IDލ\,~$ a! ꕿ1"7 ^*(y~ %Qx2 ,&anD4hCs:Rٍ܋S/X7"'^Q>G!6"}ks1z:v07a#R>qLܸRz;ōV56Gt9^ OV0t3o:2Av| +}q[G:%%\JRp$UXs)f,#Rʄ0yQE2/Ű.Z8#IgI=C`1+8ISbjQYV}!VrPޗJ/Z8 +VT(q5Ͼ~Jg**sﯓ;{sfB G(|5xb#`-]' o)QO/=ӄGd&R9mG4dƨ&/,z,phfXԿaE*~ZvlWz*, F/;9eĞ2tFo]d&Ne,DB.c_Ϛ?*FVxFVAȟК2'%)Hp9 o".}Mx*Li$dW z G?c3G> GbyBnAUFnܒ;8C6>B!i~o\%9a.Ad u ]5_YQ5e. +{l'Zi ~ _g +ju P_x k\`f 1(/ʥ*?!+3VPjxX!n*>9v>Qm[h{ &sF)R2Yis'W P"{S8>BB>\ϞB3qc ^0|x(pYUy>`ռLQlQLfiK]B jdv'-(be,q jHtrMF rŔXd%r"^,:Z{AvT'وzm2=AS/^|/`;(0ES7UUi-lNL0neDuWEVo 8MvSܗϴ N0VJ{t,KVD6 *X\٨Ohӵz{/k1k 7 +ʢ\|[㮶T:#5_kҏpe3Wiy7nesރDbA1 5`[e]^ >;O@1d[ pq[gddaSjd=!z?j60\a`)ϥG2^v55rT1WCt3T.[g/>{/7MnDC#>HS)T؉=ޓ8BѧZۄO@]^[{7`c*T[^^Y*Hk#0e't:뤔+ 7Wg?Adž͝kǃha\㬽s!&wRؕiqa*SM_Va閃j|^'iMiI[z&sSDl,Y0C}*}78C~&o* JăzK֝vT9ׅ1T3f޲utXחep/֑UD@¨2=C'hP?]Y%r|JΑOnMj+Ӌ3Mc(iF`5RS,|[U".F6D,#m'u? TYRX2Z4^*d&ωg[Y EpVjĄe/-Cr?~MuG&]KB"N,>/Font<>>> +endobj +1635 0 obj +<> +endobj +2449 0 obj +<>stream +Hj0}B{ᴖbj[pbr$^Kv0^19ߟùߙ0>/CIDToGIDMap/Identity/FontDescriptor 1633 0 R/Subtype/CIDFontType2/Type/Font/W[189[344]]>> +endobj +1633 0 obj +<> +endobj +2450 0 obj +<>stream +HUMkQ=ofnRPq:m $MV*X(EeL4CKQDѝP@]7R -I-AA7w{}7s t&T\,{-oXra"ˍ\rI}TG{bPuB6.c }Yϱ]Ԥ%xESN;̧}>q)Wk0c2_v䈹ܸ||rl +xbbggӣRxqx';[oJ,!tjylzWnhRF$2H&fWWg(#ݸcgc qADQ9Tp yP`"2l-^Mvȡh"ljfXOk,:F`19p"FqbɨgY>VVѶ,ӯ3~y#*3BŗL,3qlcbHSҒ&1E5G۟E6@sI"-P>i1SuW@hf3dnxUfZOV.  +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 +HR(T0u +endstream +endobj +2462 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2461 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2460 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2459 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2458 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2457 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2456 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2455 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2454 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2453 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2452 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2451 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1833 0 obj +<>stream +xZYonP6#!d:#8 7CqJ2 [B?H + 'Q@@~L[ٝkwgI+hwzZ%"kzRghMVyxgRy&OQ=z/Eʓҋ]oBԈ`=9 pPuue=>V,Ioʲ+- FDVu,J}LnJI^F7ֿww Oqlx _l[<`vqf[1# FXow{ǤE>k)uwjUKdHT,{ߣ|} 'mbf&)aIbS!Xd)1#璷 9@FsC==@}NxwKO1{HZ"OH۸2IZHlc"#*7H-&7Kf{:C%{dG{BFGfD- OIGwil4(ľ*\M.2xdħ%^Fc՟&hPr(6y vDe>%u{5qD?]ϥ{E>5Up99]nzY@Zk5m ]^q@:j8% %VHSv8.sU੆|0ik;[!ǀ-]dJTppNohyK5YX_;dXR\as*_){Dr!6:]#a- \|gs!'Ϥ!MW>,F3Ui_fXi8ǩR弒LsdN׹ibXu2)_+o7ATj,I庿oIVɱ\ɯW8ݖEx\doC*Y>G%{+#;QvGHL܅HpWq=̯񼊗#UJU {Ec@>g&w)!6W,$J6uW3܍'.jhͯv6v[3K+3;rV˔%pQ?YGzTb:ti}6)=/\ЊHVlqQ iSbI0[7.1qҍCU"|]g-sqŃ-8|pbqŋ=䝕BVcQf[tnS+hVSŌBhn!^Q{j;n&rd\֤X;ǩJ^˻G%v?La%qz1'>~{Td qR;Oel&;2.uz78Ľj޴jHBIeiCrzVfωifPTƲ丞`@ $c6e!Xg\Dk 0Y x~ϭŐ\*C ׊ÒΎmj͝:uófpAY$>ofф]KphIZ.-qk +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 +HR(T0u +endstream +endobj +2474 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2473 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2472 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2471 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2470 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2469 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2468 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2467 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2466 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2465 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2464 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1832 0 obj +<>stream +xZ[sS5TZ\duK}cSKŽ/|V¦VAC^G;GXHa7AR_εOdz@79oM]};;;7o͚$qh:8$|onˀk/eѦHT7jiYmmޏYo)R-t[Vm. yʘ{ M"]P^ix^{ǁCcTU;ŠbK/ߋ'Ѷ%~=+NcK}(R=XK:@C9F"<Α-; ))&.]bhQ{|C! h_B&tq&2]G o5%EzIikmUxi|!.@'ELsD S@96!xw|`I4V:xlGa3,fOyh9D`J|W0~(N2"ef2<¼-{.3rC~sLwOoE34hΰLp'|"ytΡ"s}sWpyNNp, fH&vl>!S BeR4F^aO_,ܧkmvou*0-ct2$lu/>mpQ|7:@D*]\#:/`xhBw(tRqQUgovn4^ *DmkeR!$uy:g(%*+ +1=??UHtRFYisҙU:<<*m| Uwt ń=ȔBZ0psT%SZ0S1J~oez!q8elA4$br<( ?%9!N`I;B=FrӠ>(|6~4#4#풂oAmf2+bq8ls=̠)H/;6ȨĹ7#5b1LbWSɜҘ+.|zYbĪ7lN<|5q }4ԧC9l>krԇ,_zg?*9 +rK(7BZh2j/$/#1I3-L3Ubun\%ꗴX&ƚj1^yU?A{(9 Z)wsDȥ$c2aΟB4Y$/;:JBCzU*3%&.T^z8n'>6r +&sQ +"9>(5 -QU~bΜGza4A06os>cй0 Nt/Eab']9hM7Oַkdofdx؉eJ7.P *JXo򬶁]TkuR&Suǽmol +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 +HR(T0u +endstream +endobj +2484 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2483 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2482 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2481 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2480 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2479 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2478 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2477 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2476 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1831 0 obj +<>stream +xYYo.c \HJ\cLM b71N'0qѵuE,,}v>? w,?vLp3P]*Tv9|wjF^l\]Wd℆#W<0Ktl^0O[Gjc6ӷPUڢDeQ-bnju6%w7}X~&r*F` N-< yzoqlyͶpUw-|lQ2R{Qp=6┸MfJx  rp Dž+|{Khֻah>`7f<k,~t\zwܔ`r+ZW9*sNڶ_q޺nRv2S+fVWBC7ǰkw-sd=vÊJs5e78+ /'sc?}1KQ/q@+5GYl3b/i?UsMZEkX@Ͷ ;Ņ0_LFN;lߙIPxwQU胩%'"K˂bp ScYc-YI9)_(( BVXbœΰ5Sɷ!zfܤ:#kzޣ>Sb<~^pxxhxya +`+~6O\"lh)ZOu8pVusbd,K\&٘ֆsԼ)Ӻ Fo׳c޺Mvgf#Vk9 pB"`T>hy;w-A~3{{~j; +endstream +endobj +1716 0 obj +<>/Font<>>> +endobj +1631 0 obj +<> +endobj +2486 0 obj +<>stream +HO0| +){18&*%Umf{ѱ)1?|RUmh7aO>Oggޠ.JP7l 6fXcU4l;7O(Y}m 6p(}P4*dOZc!zU5X}5Iqjϛl0TGv&Ǟ}Ô\^7p٬`ә쵌n;v^+ S[W ㌻g`uu68R;vΫ. ԥP){oy& 8" ))HNd'QĤs$) )ҡARA5/?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{OwdRCCR(eH&I& .- +^--NK+{{y?g}لHit;;;\͂Z?ʂZe,ie2,E=E+ŷ8"ާF >eM`΃cݎX[`ttݎ[p;~ժg;VeQE6∲ٜ3,ґUC6-߼ SIdL<",MXSg3nǞm"m:A[٣M#rg]h{6PIpF#Q4,f-]޿f݆Mt#8<4l؉i3/[iǮ*ZD?;5ӘRjўFck59 EI)i FrzQٚ`x5[ix-LLK32I EYVO#w᝕axex׷qs{ed07V'lѼ 2+fF17iV+#;OOI1U{ARjj15jOK:ň{9ۀ9ׂ49rӞ\|ȏ(B("(b(( +|J4ʠ,ʡ<>FTD%|ʨTE5TG D-FE=|hh9 Z" FE;GtD't肮/_zk7 ; !p aG"h8o2֍00c0000q' IHLE +RtLtd`fbs0=cbc ,rJjZzlFM،-؊m؎?.6e/a? 0(8N$N4,<.".2*:nWpw_{xGx'xgxxLk[x,-'ɏhЇyXXEXX%XVҏ6biaYcyS+"+Vf*:k&k6.Sg6d#~٘MؔҖ `+2نmَفى+KvW {njp0C`(e?F2t2Xٟ88C88#GrG>888qgdNT0iL4Nggp&gqs9s>p!q1p)2. +*:n­;3Nn^~AaQqIiYy^E^e^U^u7;o6ɿxxO/||÷|ǿ^%Y!Oy[9Sɐr)() + +Jl***XTQ*UUT]5TST[uTW꫁>j&jfjjRZmV^QY_Tw}ꩯKߨ`ȡP)\~TTKrhihiF;(8M$MV╠D%)YS4U)JU5MӕY9y^@ HDKiVhVihi6h~&mm6mOڡvjvkj눎꘎NN..늮ꚮ~ouKuGOzzzzz+;XhbxZ! U϶m۶m۶m۶m۶m۵GD(FE8GDD$DFDE4DG D,FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?aP#Hf!aQ1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ999C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?OATQPpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ ` P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_su0ôl!ҡaёQ1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<ЃC>c>S>sKk[{~G~g~W~wOo_SU0WT(AdZaV^QYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[WA!0-vu8wGt$GvGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'7/@@@@@@[n۶m۶m۶m۶m۶BhAX@F Q 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ] = }111C1 1#1 +1c111 1S1 131 1s1 K ˱+ +k [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? A!a`xF`DFbdFaTFct`Lbla\c|&`B&bb&aR&cr`JbjaZczf`FfbffaVfcv`Nbna^c~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_c@`PpHhXxNDNdNTNtLl\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_SU0WT(VU8Ad^QYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[WA!ʡa0-wGt$GvGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'7/@@@@@@:|m۶m۶m۶m۶m6BhAXCxD@DD@FQ 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ] = }111C1 1#1 +1c111 1S1 131 1s1 K ˱+ +k [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? A!a`dFaTFct`Lbla\c|&`B&bb&aR&cr`JbjaZczf`FfbffaVfcv`Nbna^c~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_c@`PpHhXxNDNdNTNtLl\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_SU0WT(VU8WET$AdYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[WA!ʡa0-GvGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'7/@@@@@ mm۶m۶m۶m۶mJB"B# "#"""# +"B0X8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!aQ1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_?   ð Ȍ¨F3c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{srsrsGrGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? ()B(B)()"(")( $+芡؊JJJJJJJJʠʤʢʦʡʥʣʧ********򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz `P0pH(hi8c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{xyxyGxGyxy'x'yxygxgyxyxyxyWxWyxy7x7yxywxwyxyOO//oo__??B'ݶݶm۶m۶m۶m۶! +a Q 1 !FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?aPcp`HbhaXcxF`DFbdFaTFct`L"Hfq Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ999C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?OAT\!RZaV^QYQU]1SQPlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ ` P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_su0wt(vu8wGt$GvGu4Gw t,ôlq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<ЃGD!F (8J$J4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` a0`(a8F #1 +1c111 1S1 131 1s1 K ˱+ +k [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? !aQ1q LL¤LLLLôL¬ü,, de1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0q$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'7/)+B*B+*+"*"+*+b*b+*+ JPXITɔ\)RZiV^QYYUٔ]9S[yW_TPTX******򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ (8M$MM4M ,<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/?sppHrhqXsxGpDGrdGqTGstpLrlq\s|'0Lv:;:;S:S;:;3:3;:;s:s;: ;E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ>>>>>>>˾⫾᛾۾㻾~~~~~~~~, x@ 0`mm۶mv۶m۶mFP0pH(hX8xHDH$@R$Cr@JBjAZCzd@FdBfdAVdCv@NBnA^C~@ABaAQCq@IBiAYCyT@ETBeTAUTCu@MBmA]C}4@C4Bc4AS4Cs@KBkA[C{t@GtBgtAWtCw@OBoA_C @ `"C00#00c0000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?!aQ1q )LdLLTL4LtL L,l\<|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~A@qrsGrGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? )B(B)()"(")()b(b)()()$+@ILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_s0wt(vu8wGt$GvGu4Gw t,vuC>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~O/o_?O<@̮el۶mm۶m۶m݅D(FE8GDD$DF *!:b &b!6 .!> !!1 )!9B0) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ] = }11A!aQ1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_? ð ȌFe4Fg d,fe!1)9[%[5۰-۱=;#;3+;{'{7/?p 19C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O\!RZaV^QYQ芡؊JJJJ( +T +T*VU:WeT&eVeU6eWT.VU>WT!VU1W T)VU9WUT%UVUU5UW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU? ihiFhFihi&h&ihifhfihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9;C:C;:;#:#;1ӱq ЉIɜ0-ہNNNN........ʮ⪮ᚮڮ㺮nnnnnnnn 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'7/`C' fײDzm۶mm۶m۶m! +a hX8xHDH$HdHHTH @AZCzd@FdBfdAVdCv@NBnA^C~@ABaAQCq@IBiAYCyT@ETBeTAUTCu@MBmA]C}4@C4Bc4AS4Cs@KBkA[C{t@GtBgtAWtCw@OBoA_C @ BcbcFbFc bc&b&c +bcfbfcbcbc bcVbVc bc6b6c bcvbvcbNN .. +nn ^^ >> ~~18C0$C140,1<#0"#120Q1q Iə) 4LtL L,l\<|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~A `PpHhXxNDNdNTNtLl\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_S0WT(VU8WET$EV()b(b)()()()R(R) JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5HA!aQ1q I)iY9yZEZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?ȎGu4Gw t,vu>닾꛾~~ꟃ9C8C989#8#98Q1˱q ȉIɝ)ʩi Ӳ L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.n^>~A`PpHhXxODOdOTOtLl\|/B/b/R/rJjZzoFofoVovNn^~AaQqIiYy_E_e_U_uMm]}?C?c?S?sKk[{GgWwOo_ ?A0ml۶m˶m۶m۶uP0pH(@TDCt@LBlA\C|$@B$Bb$AR$Cr@JBjAZCzd@FdBf`" "#r"r#" + +JJ ʢʣ** +jj ZZ ڢڣ:: zzcb0C00#00c0000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?!ahX8xLDL$LdLLTL4LtL LL@faVfcv`Nbna^c~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_c@bsrsGrGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? )B(B)()"(")(@QMC1KGqO@ HDILɕB)JFiNAIQ,ʪlʮʩ\ʭ<ʫ|ʯ*B*"*b**R*2*r* +J*jZ:zjFj&jfjjVj6jvjN.n^>~A +` P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_s0wt(vu8wGt$Gv89c8c9898989S8S9893839aZYٝ9˹y]]ȅ]E]]%]ʥ]e]]]ɕ]U]]5]˵]u] ȍM-ʭmɝ]=˽}==A!aQ1q I)iY9y^E^%^e^^U^5^u^ M-m]=}>C>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~O/o_?AkٶXm۶]˶m۶m۶u!aQ舁؈HHHHHHHHȀȄȂȆDD.FE>GD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE? a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/13C2C3 23#2#3 +1q Iɘ)i阞Y٘ )ü,,,¢,,,,ò,ʬªڬúlll¦llllöl®þ 0(8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?SpPHRhQXSxEPDERdEQ*+b*b+*+*+*+R*R+*+2*2+* $+P9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz`P0pH(pTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsvôl:s:s;: KK˺˻++kk뺞뻁[[ۺۻ;;{{{z> ~~18C0$C140,1<#0"#120Q1q Iə)i陁Yٙ9 <|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~A `PpHhXxNDNdNTNtLl\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_S0WT(VU8WET$EV()b(b)()()()R(R)()2(2)()r(r) JGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5HA!aQ1q I)iY9yZEZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?ȎGu4Gw t,vu`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/13C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32AR4XX,¢,,,,ò,ʬªڬúlll¦llllöl®þ¡ (8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?SpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~DIV + ++PETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P4XC4T4\#񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz`P0pH(hX8xNDN$NdNNTN4NtN L,l\<|ipAraKK˺˻++kk뺞뻁[[ۺۻ;;{{{z{z{<ң~A!a@iFkjk&j&kjkfjfkjkjkjkVjVkjk6j6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~ꟃ9C8C989#8#989c8c989898Iɝ)ʩiəYٝ9˹y]]ȅ Ӳ]E]]%]ʥ]e]]]ɕ]U]]5]˵]u] ȍM-ʭmɝ]=˽}==ȃ=C==# hXxODOdOTOtLl\|/B/b/R/rJjZzoFofoVovNn^~AaQqIiYy_E_e_U_uMm]}?C?c?S?sKk[{GgWwOo_' f۶mתGmm۶m۶m!8B $B!4 ,!<" ""!2 *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0 EQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ] = }11 P pHhXxLDLdLTLtLl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}gd!f(8AR4K$K4˰,˱<+"+2*:k&k6.>!1)9[%[5۰-۱=;#;3+;{'{7/?p q0!aQ1q I)iY9y\E\%\e\\U\5\u\ M-m]=}GD!FE1G D) 4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` !1C1 1#1 +1c111 1S1 131 1s1 K ˱+ +k [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? !aQ،øLLL¤LLLLôL¬ü,,,¢,,,@hfe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? q0p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'7/)+B*B+*+"*"+U]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TR(**򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ  0 (8M$MM4M ,<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/?sppHrhqXsxGpDGrdGq:;c:c;:;:;:;S:S;:;3:3;:;s:s;: K Ӳ]e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓɞ⩞ᙞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~`Zmٶmcٶm۶m۶C0GD(FE8GDD$DF *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,!!QQ QUQ Q5Q QuQ M - +m ] = }11A!aQ1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_? ð ȌFe4Fg d,fegd!fe1g d)fe9$E<+"+2*:k&k6.>!1)9[%[5۰-۱=;#;3+;{'{7/?p 19C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O\!RZaV^QYQ芡؊JJJJJJJJʠʤʢʦʡʥʣʧ********@AdWUT%UVUU5UW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU? ihiFhFihi&h&ihifhfihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9;C:C;:;#:#;1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\hʮ⪮ᚮڮ㺮nnnnnnnn 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'7/`Zmv{d۶l۶m۶m[w!#B"B# "#"""# +1q Iɐ)iYِ9yPPEPP%PPePPPʨꨁڨhhhhhhhh耎肮聞胾  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?cp`HbhaXcxF`DFbdFa23c2c32323 23S2S3 233233 23s2s32  KK ˲˳+ YUXX5XXuXX ؘؐMؔ؜-ؚؒmؖ؞ؙؑ]ؕ؝=ؓ؛}ؗ؟8¡ñɜ©ٜù\\\¥\\\\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ÿ` + +P +0 +p +H( +PTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUR J*jjꪞ꫁ZZڪګ::zzkj4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[W!ʡaɑhX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J4LveWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_s@r{z{GzG{z{'z'{z{gzg{z{z{z{WzW{z{7z7{z{wzw{zOO//oo__???A0m۶=m-۶m۶mݟ ! +a hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*j@Fu@MBmA]C}4@C4Bc4AS4Cs@KBkA[C{t@GtBgtAWtCw@OBoA_C @ BcbcFbFc bc&b&c +bcfbfcbcbc bcVbVc bc6b6c bcvbvcbNN .. +nn ^^ >> ~~18C0$C140,1<#0"#120Q1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYIѬZ:zlFl&lfllVl6lvlN.n^>~A `PpHhXxNDNdNTNtLl\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_S0WT(VU8WET$EV()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**)P%YUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5HA!aQ1q I)iY9yZEZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?ȎGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5ekk븮빾[[۸۹;;{{x9ȃ=C==#=ʣ=c===ɓ=S==3=˳=s= ȋK˽+ʫkɛ[۽;˻{}}ȇ}G}}'}ʧ}g}}}ɗ}W}}7}˷}w}ȏO/ʯoɟ_?˿Akٶmٶe۶m۶mۺ 7!8B $B!4 ,!<" ""!2 Q 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q :zhFh&hfhhVh6hvhN.n^>~A` P pHhXxLDLdLTLtLl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}0!110)19S0%S150-1=30#3130+1;s0's170/1? 0(8K$K4˰,˱<+"+2*:k&k1 )YuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ99A!aQ1q I)iY9y\E\%\e\\U\5\u\ M-m]=}WT!VU1W T)VU9WUT%UVUU5UW T- +$ꨮꩾZZڨک::zzh)H5DC5L5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KG!ҡaёQ਎ᘎ؎㸎NNNNNNNN........ʮ⪮ᚮ@ôlvu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? yxyGxGyxy'x'yxygxgyxyxyxyWxWyxy7x7yxywxwyxyOO//oo__???A0m۶mGm.۶m۶m?!#B"B# "#"""# +1q Iɐ)iYِ9yPPEPP%PPePPPPUPP5PPuPhhhhhhhh耎肮聞胾  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?cp`HbhaXcxF`DFbdFa23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk Y ؘؐMؔ؜-ؚؒmؖ؞ؙؑ]ؕ؝=ؓ؛}ؗ؟8¡ñɜ©ٜù\\\¥\\\\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ÿ` + +P +0 +p +H( +PTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S J꫁ZZڪګ::zzkj4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[W!ʡaɑhX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:z4Lv}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_s@r{z{GzG{z{'z'{z{gzg{z{z{z{WzW{z{7z7{z{wzw{zOO//oo__??0`v-۶mٶ[m۶m۶߁C0GD(FE8GDD$DF *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,ʡ<*"*2*:j&j6.>!!!M - +m ] = }11A!aQ1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_? ð ȌFe4Fg d,fegd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#$E1)9[%[5۰-۱=;#;3+;{'{7/?p 19C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O\!RZaV^QYQ芡؊JJJJJJJJʠʤʢʦʡʥʣʧ********򪠊ʪꪡڪjj@Ad5V5U35W T+VU;WuT'uVuU7uWT/VU? ihiFhFihi&h&ihifhfihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9;C:C;:;#:#;1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ Ѝhnnnnnn 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 )9_%__5_ -=?#??3? +;'70`v-۶m6ȶl۶m۶m[w !aQ舁؈HHHHHHHHȀȄȂȆȁȅȃȇ((((((((򨀊ʨꨁڨhhhh@`4G D+FE;GtD'tFtE7tGD/FE? a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/13C2C3 23#2#3 +1q Iɘ)i阞Y٘9yXXEXX%XXeXXXXUXX5XXuXX ؘؐMؔHlllöl®þ 0(8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?SpPHRhQXSxEPDERdEQ*+b*b+*+*+*+R*R+*+2*2+*+r*r+* + +JJʪʫ**jjꪞ꫁Q\-RZmV^QY]U]=S[}W_4P񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz`P0pH(pTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsvpNrnq^s~pAraqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7saZ[[ۺۻ;;{{{z> ~~0(18C0$C140,1<#0"#120*1:c0&c160.1>0!110)19S0%S150-1=30#3130+1;s0's170/1? 0(8K$K4˰,˱<+"+2*:k&k6.>!1)9[%Illöl®þ¡ñɜ©ٜù\\\¥\\\\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ÿ +` + +P +0 +p +H(hX8xJDJ$JdJJTJ4JtJ ʨLʬ,ʪlʮʩ\ʭ<ʫ|ʯ*B*"*b**R*2*r* +J*jZ:zjFj&jfjj JZڨک::zzhihiFhFihi&h&ihifhfihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9:;C:C;:;#:#;:;c:c;:;:;:;S:S;:;3:3;:;s:s;: KK˺˻++kk뺞뻁[:`Vn6nvnN.n^>~A!aQ1q I)iY9y^E^%^e^^U^5^u^ M-m]=}>C>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~O/oO<@@˶m۶mCm۶m۶mm?A ! +a Q 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m@F;GtD'tFtE7tGD/FE?  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?aPcp`HbhaXcxF`DFbdFaTFct`Lbla\c|&`B&bb&aR&cr`JbjaZczf`FfbffaVfcv`Nbna^c~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[َفىم]ٍك=ًه}ُ999C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?OAT\!RZaV^QYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmVAdS{uPGuRguQWuSwPORoQ_S @ ` P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_su0wt(vu8wGt$GvGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu0-ѝ]=ӽ}<Ѓ !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#肮聞胾񘀉ɘ阁٘XXXXXXXX؀؄؂؆؁؅؃؇88888888󸀋˸븁۸xxxxxxxx `  P 0 p H(hX8xLDL$LdLLTL4LtL L,l\<|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlAR4;3+;{'{7/?p q0p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'7/)*+B*B+*+"*"+*+b*b+*+*+*+R*R+*+2*2+*+r*r+* + +JJʪʫ**jjꪞ꫁ZZڪګ:* N.n^>~A!aQ1q I)iY9yZEZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?Ȏ⨎ᘎ؎㸎NNNNNNNN........ʮ⪮ᚮڮ㺮nnnnnnnne;{{{z{z{GzG{z{'z'{z{gzg{z{z{z{WzW{z{7z7{z{wzw{zOO//oo__???Am۶m6Wܶm۶m۶m&??A ! +a Q 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ]@F7tGD/FE?  0 (8L$LL4L ,<,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?aPcp`HbhaXcxF`DFbdFaTFct`Lbla\c|&`B&bb&aR&cr`JbjaZczf`FfbffaVfcv`Nbna^c~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWٍك=ًه}ُ999C99#99c9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?OAT\!RZaV^QYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]UAduSwPORoQ_S @ ` P pHhXxMDMdMTMtLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_su0wt(vu8wGt$GvGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu;wwt'wvwu0-=ӽ}<Ѓ~A!aQ1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_?   ð Ȍ¨،øLLL¤LLLLôL¬ü,,,¢,,,,ò,ʬªڬúlll¦llllöl® $E{srsrsGrGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? ()B(B)()"(")()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**jjꨮꩾZZڨک::z(ꣾ񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz `P0pH(hX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.naZ{xyxyGxGyxy'x'yxygxgyxyxyxyWxWyxy7x7yxywxwyxyOO//oo__???A,۶m۶mٶm۶m۶} + CE0GD(FE8GDD$DFDE4DG D,FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE!00C00#00c0000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?A!aQ1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه} Hf? 0(8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?QPSpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_QO5@5H5DC5L5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KGA!ҡaёQ1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}ôls@`PpHhXxODOdOTOtLl\|/B/b/R/rJjZzoFofoVovNn^~AaQqIiYy_E_e_U_uMm]}?C?c?S?sKk[{GgWO<0m۶m۶msm۶m۶mI{GgWwOo (!8B $B!4 ,!<" ""!2 *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` 񘀉ɘ阁٘XXXXXXXX؀؄؂؆؁؅؃؇88888888󸀋˸븁۸xxxxxxxx `  P 0 p H(hX8xLDL$LdLLTL4LtL L,l\<|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~AR4q0p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'7/)*+B*B+*+"*"+*+b*b+*+*+*+R*R+*+2*2+*+r*r+* + +JJʪʫ**jjꪞ꫁ZZڪګ::zzk* A!aQ1q I)iY9yZEZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?Ȏ⨎ᘎ؎㸎NNNNNNNN........ʮ⪮ᚮڮ㺮nnnnnnnne{{z{GzG{z{'z'{z{gzg{z{z{z{WzW{z{7z7{z{wzw{zOO//oo__???A,۶m۶m6m۶m۶m} | + CE0GD(FE8GDD$DFDE4DG D,FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?  E!0#00c0000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?A!aQ1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ999C H0(8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?QPSpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ ` PQ5L5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KGA!ҡaёQ1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ~A!aB0Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/123C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{srsrsG2@Q1q I)iY9y\E\%\e\\U\5\u\ M-m]=}>닾꛾~~ꟃ89C8C989#8#989c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{xyxyGxiɞ⩞ᙞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~۶m۶m۶m۶m۶| | | + CE0GD(FE8GDD$DFDE4DG D,FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?  0 (E!000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?A!aQ1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ999C99#99c H8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?QPSpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ ` P pHhXQ5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KGA!ҡaёQ1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ> ~~0(18C0$C140,1<#0"#120*1:c0&c160.1>0!110)19S0%S150-1=30#3130+1;s0's170/1? 0(8K$K4˰,˱<+"+2*:k&k6.>!1)9[%[5۰-۱=;#;3+;{'{7/?p q0p(q8Gp$Gq4p,q<'p"Iќɜ©ٜù\\\¥\\\\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ÿ +` + +P +0 +p +H(hX8xJDJ$JdJJTJ4JtJ ʨLʬ,ʪlʮʩ\ʭ<ʫ|ʯ*B*"*b**R*2*r* +J*jZ:zjFj&jfjjVj6jvjN.n^>~A!aQ1q J&ihifhfihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9:;C:C;:;#:#;:;c:c;:;:;:;S:S;:;3:3;:;s:s;: KK˺˻++kk뺞뻁[[ۺۻ;;{{{z{z{GzG{z{':`I)iY9y^E^%^e^^U^5^u^ M-m]=}>C>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~Ol۶m۶m۶Cm۶m%5-=#3+;'7A!aQ1q Iɐ)iYِ9yPPEPP%PPePPPPUPP5PPuPP M-m]=}00C00#00c0000S0`LtLl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}gd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0(8N$NNe )8388s88 K˸+k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?DALB!JFaNAIEQMC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H5DC5L5B#5J5Fc5N5A5I5ESDI4M ,<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/?qPsppHrhqXsxGpDGrdGqTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsvpNrnq^s~pAraqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_s@`PpHhXxODOdOT Ӳ==3=˳=s= ȋK˽+ʫkɛ[۽;˻{}}ȇ}G}}'}ʧ}g}}}ɗ}W}}7}˷}w}ȏO/ʯoɟl n۶m۶m۶m۶mf `P0pH(hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!aQ1q I)iB0fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/123C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{srsrsGrGs rs'r's +rsg2@Y9y\E\%\e\\U\5\u\ M-m]=}>닾꛾~~ꟃ89C8C989#8#989c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{xyxyGxGyxy'x'yxygxiٞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~l۶m۶m۶?d۶m۶9%5-=#3+;'7A!aQ1q Iɐ)iYِ9yPPEPP%PPePPPPUPP5PPuPP M-m]=}00C00#00c0000S00300s0`|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}gd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0(8N$NN4N ,e )8 K˸+k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?DALB!JFaNAIEQMC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H5DC5L5B#5J5Fc5N5A5I5ES5M5C35K5GsDI<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/?qPsppHrhqXsxGpDGrdGqTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsvpNrnq^s~pAraqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_s@`PpHhXxODOdOTOtLl\ Ӳ= ȋ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#" + +JJ ʢʣ** +jj ZZ ڢڣ:: zzcbcbcFbFc bc&b&c +bcfbfcbc"EX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_?   ð Ȍ¨،øLLL¤LLLLôL¬ü,,,¢,,,,ò,ʬªڬúlll¦llllöl®þ¡ñɜ©ٜù\ $Ess rsWrWs rs7r7s rswrwsrOO // +oo __ ?? ()B(B)()"(")()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**jjꨮꩾZZڨک::zzhihiFhFihi&h&ihifhfihih(ZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz `P0pH(hX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.n^>~A!aQ1q I)iY9y^aZyxyWxWyxy7x7yxywxwyxyOO//oo__?3Pra7m1;ic:m\__߂߃??9:0s~p"H.⢺h.bX.x.KD.KⒺd.KRT.KҺt.2L.P +CKD'݈3/@_Fϗך-D1?"X ?P6.B0G" ""!2 *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;~CD.FE>GD!(((QeQQQ OTFTE5TG D-FE=G4D#4F4E34G D+FE;G8:#:3+;z'z7/?` a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1pXXXXXX؀؄؂؆؁؅؃؇88888p7iYy\E\e\U\uMm]}'l_}~/FR ~1#2#3 +23c2c32323 23S2S3 233233 27`Nbna^c~`Aba",b,,R,2,r, +J2*:k&k6.>!1)9[%[5۰-۱=فىم]ٍك=ًه}ُ999C99#99c9999S99399s9 .2. +*:n&nn6n.>!1牐'y*?<3!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$x|1> iYy\E\e\U|p q7q qwqO 53~ 7/o1 )c32323 23S2S3 233233 23s2s32bAbaaQcq`IbiaYcyV`EVbeVaUVcu۬Z:zlFl&lfllVl6lvlN.n^>~A!aQ1q I)iY9y\E\%\e\\U\5\u\ M-m]=}C>c>S>sT,AdE8xJDJ$JdJJTJ4JtJ ʨLʬ,ʪlʮʩ\ʭ<ʫ|ʯzKUHUDEULUB%UJUFeUNUAUIUEUUMUCojꨮꩾZZڨک::zzhihiFhFihi&h&ihifhfihihihiVhVihi6h6ihivhvihi鰎討N^^8c:aZ#vuw.......ʮ⪮'t-vu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? 0(8O$OO4O ,</"//2/ +*:o&oo6o.>!1 ;~}?'ԟsS>3>s> K+/oo7{/տw??__M#ŊB"GQ;ōEQ(Q8J%EɣQ(U:JE Q(S9eA@0e۵lײm˶ml۶mۻC2$G +D*FE:GdD&dFdE6dGD.FE>G(((((((򨀊ʨ P5PPuPP M-m]=}cbcbcFbFc bc&b&c +bcfbfcbcbc bcVbVk [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? !a 0#2#3 +23c2c32323 &cr`JbjaZczf`FfbffaVfcv`Nbna^c~,B,",b,,R,2,r, +J*ʿXY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ7p q0p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?[!RZaV^%Y"(")()b(b)()()(P2%W +T*VU:WeT&eVeU6eWT.VU>W*******򪠊ʪKT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_kjkjkFjFkjk&j&kjkfjfkjkjkjkVjVѿOkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?K!ʡa Ӳ8#:#;:;c:c;:;:;'srpJrjqZszgpFgrfgqVgsvpNrnq^s~.B.".b..R.2.r. +J*\]5]˵]u] ȍM-ʭmɝ]=˽}xyxyGxGyxy'x'yxygxgyxyxyxyWxWyћ[ۼ;ӻ{|Ї|G||'|ҧ|g|||ї|W||7|ӷ|w||ЏO/үoџ_?ӿ; B0A \>@@ D "(A Z= b8A ^?H$ $A`6Zmvmٶڲm۶%Cr@JBj4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏQQEQ Q%Q +QeQQQ QUQ Q5Q QuQ M - +m ] = }  0 (8L$LL4L ,<,",,2, +?XXX؀؄6c bcvbvcbNN .. +nn ^^ >> ~~3C2C3 23#2#$E3`Fe4Fg d,fe!1)9_%_5-=?#?3+;'B(B)()"(") JEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRj4JtJ ʨLʬ,ʪlʮʩ\ʭ<ʫ|ʯSUHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O  0 (8M$MM4M ,<-"--2- +?ZZZڠڤ6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~;C:C;:;#:#e;pGu4Gw t,vu`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7C0$C140,1<#0"#120*1:AR4`Lbla\c|&`B&bb&Iə)i陁Yٙ9y 0(8K$K4˰,˱<+"+2*:k&k6.>!1)9[%[5۰-۱=;#;3+;{'{7/? 0(?8q'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? +B*B+*+"*"+* $+P T,VU>鳾諾~~C8C989#8#989aZpLrlq\s|'pB'rb'Iɝ)ʩiəYٝ9˹y KK˸˹++kk븮빾[[۸۹;;{{ 0(?!1)9^%^5-=>#>3+;~'~7C0$C140,1<#0"#120*1:c0&c16AR4a\c|&`B&bb&aR&cr`Jbj4LtL L,l\<|YYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ 0(8N$NN4N ,<."..2. +?\Ws rs7r7s rswrwsrOO // +oo __ ?? +B*B+*+"*"+*+b*b $+PU>鳾諾~~C8C989#8#989c8c9aZq\s|'pB'rb'qR'srpJrj4NtN L,l\<|]ȅ]E]]%]ʥ]e]]]ɕ]U]]5]˵]u] ȍM-ʭmɝ]=˽} 0(8O$OO4O ,</"//2/ +?^W{z{7z7{z{wzw{zOO//oo__??!A t& A r%D 1A vA'  A q`]˶mXmsiٶm6w$HdHHTi Y ّ9 y + +0(8J$J4ʠ,ʡ<*"*2*oTG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?񘀉ɘ阁٘XXXXXkac6b6c bcvbvcbNN .. +nn ^^ >> ~~3C2C3 23#2#3 +23c2c32$E3`&d"&L¤LLL?i阞Y٘9y  KK ˲˳++ +fu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_?A!aQ1q I)iY9y\E\%\e\+kq=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'B(B)()"(")()b(b)() J%PB%Rb$JdJJTSFiNAIEYMٕC9KGyO + +JJʨʩ**oUW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU?񚠉ɚ隡ٚZZZZZRZkVik6j6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~;C:C;:;#:#;:;c:c;:e;p't"'NNNN?iљYٜ9ӹy KK˺˻++vupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_?A!aQ1q I)iY9y^E^%^e^+ʫky7x7yxywxwyxyOO//oo__??w" +BaA |!D +"QA z# +bqA ~A H$ +@m<ܲe۶m..6k˶m۶wI ɑ) + -!=2 #2!3 +!;r 'r!7 /!? + +0DE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?_0#00c0000S00300s00 K˰+`Vc bc6b،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_ P 0 p H(hX8xLDLL̀Iɘ)0 233233 23s2s32  OaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_cA!ʿ99#99c9999S99399s9 K˹+Wq5p-q=7p#7_­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ + + + +Ȋ芡؊JJĂ( +DILɕB)J()2(2)()r(r)() + +TU1W T)VU9WUT%UVUU5UW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU?_[4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RhVkjk6jڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_P0pH(hX8xNDNlIɜ)ҩ8:;3:3;:;s:s;: OqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_sA!==#=ʣ=c===ɓ=S==3=˳=s= ȋK˽+Wyxy7x7_>>>>>>>>˾⫾᛾۾㻾~~~~~~~~A d* A b)D тA f+ A a(H `A?A@0[om۶k˶m۶m !9R %R!5 -!=2 #2!3 +!;r 'r!7 /oGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/F?00C00#00c0000S00300s00 a bcVbVc bc6b6c bcvbvcbNN .. +nn ^^ >> ~~3C2C3 23#2#3 +23cX8xLDL$LJ̀3S2S3 233233 23s2s32f~`AbaaQcq`IbiaYcyV`EVbeVaUVcu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_ُ999C99#99c9999S99399s9 p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'B(B)()"(")()b(П؊JJJ( +L)R(R)()2(2)()r(r)(oWT!VU1W T)VU9WUT%UVUU5UW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/V?W_4P4XC4T4\#4R4Zc4V4^4Q4YS4U4]34S4[s4W4_ PXijkVjVkjk6j6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~;C:C;:;#:#;:;cX8xNDN$Nj;S:S;:;3:3;:;s:s;:v~pAraqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_==ȃ=C==#=ʣ=c===ɓ=S==3=˳=s= ȋxyWxWyxy7x7yxywxwyxyOO//oo__??w" +BaA |!D +"QA z# +bqA ~ H$ +IWපj9{ɶmۮζm۶kmaVC=OD!@08xEPP%PPePPPPUPP5PPuPP M-m]=}0P!D#1E⑀D P pHhXxLDLdLTLtLl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiY's|/qppWpuM7{ng{xGx'x_wx??xWx-=~ȤLLi1233233 23s2s32  $=",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~A a(F22L`"p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,~9< K+k_:o&o~=yw3=>#>>;s+o>H||$ ɃA U:H|  A S9d B ," *D1Al Ae,ղYva9-ЇJdJJJF+)2(2)()r(r)() + + *K******򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ*LP4XъQ%jjkFjFkjk&j&kjkfjfkjkjkjkVjVkjk6j6kjkvjvkj눎꘎NN>ѧL }󺠋˺?AEtm{ߛmv[ͬVm{l۶9x8NSt8Άs|.Krkzn[v{~xGqxgyx^Wuxކw}>OsH(hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ \ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhV +_E;GtD'tFtE7tG|}0=~! ?c(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%VX;bc6b6c bc؉]؍=؋} qqpGpp'ppgppppWpp7ppwppO/o_Q1q Iə)i陁Yٙ9љyYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ي_5k~öl®o{{sr9?g0(8N$NN4N ,<."..2. +*_kZznFnfnVnv;{q? oOO // +oo __ ??"(")()b(b)()()()R(R)()2(2)()r( J2r)() + +JJʨʩ**jjꨮꩾZZ+V}oV^QY]U]=SORoQ_S @ A?j'񚠉ɚ隡ٚZZZZZZ_Vk~ZuZ ڨMڬ-ڪmڮCjvih/!aQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}"YdbQ-EbYlcq-ŷYbKbI-%RYjKci- 2YfbY-eӂh23\X^gBV؊XQ+fv̎ ;i총vh]vͮ iݱv{h=̞ {i쵽h}#ydQ=Gcylq=ybOI='SyjOi= 3yfY=gӃrs\x^B^؋xQ/ŽR^xY/彂WJ^٫xUսZ^x]7F؛xSoͽV?A0~؆ml۶m۶m۶mvgY}k` 5&ԚYska-6Y{`u.պYwa=>Y`m !6Ԇpa#m16x`mM)6զta3mͶ96|[` m-%Ԗr[a+m5z`mm-նva;m=~;`#vԎq;a'픝3vy`]+vծua7ݶ;v}{`='Ԟs{a/핽7{`}/վwa??Ȉ舁؈HHH ɐ)iYA!;r 'r!7?ȃȇ( +JJ ʢʣ** +jj ZZ ڢڣ:: zzcbcbcFbFc bc&b&c +bcfbfcbcbc bcVbVc bc6b6c bcvbvcbNN .. +nn ^^ >> ~~㏇C{`C}>GhcaQ1q ؘؐMؔ؜-ؚؒmؖ؞ؙؑ]ؕ؝=ؓ؛}ؗ؟88C88#88c8888S88388s88 K˸+k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?B!JFaNAIEQMC1KGqO@ HDI)R(R)()2(2)(LeSvPNRnGyOU@S!VU1W T)VU9WUT%UVUU5UW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU?  0 (8M$MM4M ,<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/֟ D2apA B1DQhA F3qxA A0H$I':(fZ2~\lƲmK˶m۶;$E2$G +D*FE:ǟȀȄȂȆȁ y + +0(8J$J4ʠ,ʡ<*"*2*oTG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE?񘀉ɘ阁٘XXXXXkac6b6c bcvbvcbNN .. +nn ^^ >> ~~3C2C3 23#2#3 +23c2c32323 `R&cr`JbjaZcz L,lÌy  KK ˲˳++ +fu`Mbma]c}6`C6bc6aS6cs`Kbka[c{v`GvbgvaWvcw`Oboa_?A!aQ1q I)iY9y\E\%\e\+kq=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'B(B)()"(")()b(b)()()%U2%W +T*VU:ןʠʤʢʦʡ( +KGyO + +JJʨʩ**oUW T-VU=W5T#5V5U35W T+VU;WuT'uVuU7uWT/VU?񚠉ɚ隡ٚZZZZZRZkVik6j6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~;C:C;:;#:#;:;c:c;:;:;pR'srpJrjqZsz L,liy KK˺˻++vupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_?A!aQ1q I)iY9y^E^%^e^+ʫky7x7yxywxwyxyOO//oo__??w" +BaA |!D +"QA z# +bqA ~ H$ +I  +ٶekֲmlҲm۶m.)!9R %R!5 -!=2dD&dFdE6dGD.FE>`ȏQQEQ Q%Q +QeQQQ QUQ j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/o񘀉ɘ阁٘XXXXXkac6b6c bcvbvcbNN .. +nn ^^ >> ~~3C2C3 23#2#3 +23c2c32323 23S2S3 23`FfbffaVfcv`Nbna^#Hf,?YXEXX%XXeXXXXUXXkk [[ ۲۳;; {{?A!aQ1q I)iY9y\E\%\e\+kq=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'B(B)()"(")()b(b)()()()R(R)()2eT&eVeU6eWT.VU>AdʯSUHUDEULUB%UJUFeUNUAUIUEUUMjjꨮꩾZZڨک::zzo񚠉ɚ隡ٚZZZZZRZkVik6j6kjkvjvkj눎꘎NN..늮ꚮnn뉞Ꙟ^^>>닾꛾~~;C:C;:;#:#;:;c:c;:;:;:;S:S;:;pFgrfgqVgsvpNrnq^3Lv.?]Ѕ\E\\%\ҥ\e\\\ѕ\U\\kk뺞뻁[[ۺۻ;;{{?A!aQ1q I)iY9y^E^%^e^+ʫky7x7yxywxwyxyOO//oo__??w" +BaA |!D +"QA z# +bqA ~ H$ +I':(Z6mge۶lvkٶm۶# "#R"R# "#2"2# "#r"r#" + #@!FE1G D)FE9GTD%TFT_ꨁڨhhhhhhhh耎肮聞胾臿cbcbcFbFc bc&b&c +bcfbfcbcbc bcVbj5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_ P 0 p Q1q 210)19S0%S150-1=30#3130+1;s0's170/1? AR4baaQcq`IbiaYcyV`EVbeVaUjZ:zlFl&lfllVl6lvlN.n^>~?p q0p(q8Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)q9Wp%W_\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ + + + +?QYQU]1S[qW_ P+*+R*R+*+2*2+*+r*r+* + +$+P!VU1W T)VU9WUT%UVU_ꪡڪjjjjjjjjꠎꢮꡞꣾ꧿kjkjkFjFkjk&j&kjkfjfkjkjkjkVjj5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_P0pɑQ1˱q :89S8S989383989s8s989 aZraqQsqpIriqYsyWpEWreWqUjZ:znFn&nfnnVn6nvnN.n^>~xyxyGxGyxy'x'yxygxgyxyxyxyWxW_^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~A d* A b)D тA f+ A a( x۶m{{m۶mnc۶m;L$E2$G +D*FE:GdD&dFdE6dGD.FE>GD!FE1`@(R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!aQ1q I)iY9yXEX%XeX c%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6wppO/o_?,PXX g-EH٢XTf-ŴXX\g-%DؒXRKf-TXZKg-eLٲXVf-\X^gBV؊XQ+f fMVJZ)+meV*Z%lUUVjZ-muճZ#klM5ZZ+kmm:Z'l]uzZ/m}6 lCl 6F(mcl6&$lSlM w{A0x<OgE2xowC1|_oG30C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  4$Eg d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0(8N$NN4N ,<."..2. +ſk븞[۸;{xxGxx'xxgxxxxWxx7xx_;{|G|'|g||W|7|w|O/o_? + + + +Ȋ芡؊JJJJJJJJʠʤʢʦʡʥʣʧ****L(UB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H5DC5L5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ HDKL˵Bo*:m&mm6m.>!1 )9]%]]5] -cylq=ybOI='SyjOi= 3yfY=gsyny=^ ya/Ewyt{ /饼^{蕼W^ͫ{ 鵼^{o荼7̛{ o魼{蝼wͻ{齼|>̇|>|O>ͧ |ٶmޮͶmcm۶m6ilͱ6[hl-̖ +[ilhlmͶil;hv̎ ;i총vh]vͮ iݱv{h=̞ {i쵽h};i!aQ1q Iɐ)iYِ9yPPEPP%PPe`QPPPUPP5PPuPP M-m]=}00C00#00c0D111 1S1 131 1s1 K ˱+ +k [ ۱; {qqqGq q'q +qgqqq qWq q7q qwqO / +o _ ? !aQ1q Iɘ)i阞Y٘9yXXEXX%XXehIYXXXUXX5XXuXX ؘؐMؔ؜-ؚؒmؖ؞ؙؑ]ؕ؝=ؓ؛}ؗ؟88C88#88c8 d9999S99399s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O!RZaV^QYQU]1S[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZed(UVT^TQTYUTUT]5TST[uTWT_ PXMT\-RZmV^QY]U]=S[}W_4P4XC4T4\#4R4Zc4V +T5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KGCxH=p#xD=GhcxL=xxBO='dSxJO=t3xF=glsxN=| xA/䅽b^KxI/好r^{蕼W^ͫ{ 鵼^{o荼7̛{ o魼{蝼wͻ{齼|>̇|>|O>ͧ@`m۶˶ml۶m۶m̰6fkl-[jlV[klm6jlvklv;j츝vN;k]v.jݰvnk={j칽^{k}>j~k! +a Q 1 q I ɑ) +i Y ّ9 yQQQEQ Q%Q +Q(r(@ +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!aQ1D1000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?!aQ1q Iə)i陁Yٙ9yYYYEYY%YY,r,O#H +J*jZ:zlFl&lfllVl6lvlN.n^>~A!aQ1 d9888S88388s88 K˸+k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?B!JFaNAIEQMC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUF*r*/DI +J*jZ:zjFj&jfjjVj6jvjN.n^>~A!aQ1 +T5V4^4Q4YS4U4]34S4[s4W4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[Ẇ|@`|O>'|@`6?۶m^m۶϶m۶m[36fYͶ96|[` m-%Ԗr[a+m5z`mm-նva;m=~;`#vԎq;a'픝3vy`]+vծua7ݶ;v}{`='Ԟs{a/핽7{`}/վwa??!B"B# "#"""# +"#b"q Iɐ)iYِ9yPPEPP%PPePPP@ʨꨁڨhhhhhhhh耎肮聞胾񘀉ɘ ,c6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/1C2C3 23#2#3 +23c2q Iɘ)i阞Y٘9yXXEXX%XXeXXXD#Hʬªڬúlll¦llllöl®þ¡ñɜ© ,s6p.q>p!q1p)q9Wp%Wq5p-q=7p#7q3p+q;wp'wq7p/q? 0(8O$O4,!1)9_%_5-=?#?3+;'7/)B*B+*+"*"+*+b*@[qW_ PXITɔ\)RZiV^QYYUٔ]9S[yW_TPTXETTT\%TRTZeTVT^TQ$DIʪꪡڪjjjjjjjjꠎꢮꡞꣾ񚠉ɚ + ,khihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~y<{y}!>ԇp#}1>x}O)>էt`ٶٶOm۶nm۶m۶lͲ`mslͳ"[lKl-V*[mkl6&l[lmv.m{lv!;lGvN);mg쬝v.%lW]vn-mwݳ#{lO=^+{mo쭽>'l_}~/mCD(FE8GDD$DFDE4DG D,FE!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` a0`(a8F`$Fa4`,a<&`"&a2`*a:f AYl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}!1)9[%[5۰-۱=;#;3+;{'{7/?p q0p(q8Gp$Gq4p,q<'p"'q2p*q:g0AY l\|.B.b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_ST(VU8WET$EVEU4EW T,VUć0#|>8|O>ŧ43g_ !K|fhhVh ڠ-wh耎? zG z7/~E?O1`0񘀉ɘ阁٘XXX,2Db9V ++UX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwx،øLLL¤LLLLôL¬ü,,,¢,,,,ò,ď1+ +?au~X5Y9`e=g6d#6f6 b؜-ؚؒ_a[~؎فى=`ve7vg?boa_~?7r`8C99#99c9999S99399s9 \er`W2k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/oC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIcUVUU5}Tjjs}:zjFj&j* /ZZ7jVߩګ::{.n~/ꣾU~W?o WijkFjFkjk&j&kjkfjfkjkjk"TZ(TVihi6h6ihivhvihi鰎討NN|aDFaLƅaB&aJaFfaNaAXaIKò!* aUXքa]X'(\[V-rr̭-l˶l[Zm Î3 +Þ7 Áp0 +Ñp4 Ép2 +Ùp6 ?p!\ p%kzn[v{~xGqxgyx^Wuxކw}>O3" DD$DFDE4|舁؈ +_#AB$Bb$AR$Cr@JBjAZCzd@F| #+!;r 'r!7 /~@>GD!Fŏ(((((򨀊ʨ P5PPuPQ M-3~Akm ] = FE?  0 (8L$LL4L ٘XXXXXXXX؀ c6c bcvbvcbNN  K+Wq q7q qwqO / +o _0"#120*KFg d,fe~A!aQ1q I)i3=˳=s= ȋK˽+ʫk&oo x +ZlZ !{nٶVC[lnv [ְ-l;ΰ+{ް/p(Gp,'p*gp.p)\Wp-\7_n;nax'ixex^7mxއc>#"""# +"#b"b#"#"# @R$Cr@JBjAZCzd@FdBfdAVdCv|ȉ\ȍ<ȋ|ȏ(B(" +EQ Q%Q +5ʠ,ʡ<*"*2*:j&j6.>A4ķhM-mtAWtCw@OBoA_C @A!aQ1q I)iY9yX3a1`)a9VXX l&lƿ؂؆؁؅؃؇88888888󸀋˸븁pwppO/oQ1q I23S2S3 233233 2K`Nbna^c~`AbaW,b,,R,ͯYeYYYYUYY5YYuY !e#~l¦l@lllöl? {{sG`PpHhXxNDNdNTNtLl\|.BğK˹W*o\O p#7q3n6n.>!1 )9^%^^5^ ۼû|||§||||÷|ϊȊ芡؊JJJ/Tɔ\)RZiV^QYYUٔ]_*r*r+* + +RQSqPIRi}2*r* +J*jZ:zo@ ;5V5U3Ad5W T+VU;WuT'uA]U]=S[}W_4P?jkjkFjFkjk&j&kjkfjfkjk'EZ%ZeZEjVih~:C/mGIhivhvihi鰎討NN..鲮誮n-==#==3= +;}'}vGt$GvGu4Gw t,vu\åW?j_nNAxIxEx^MxޅC>ψȈ舁؈HHHH)iYِ_"r"r#+ȏ(B("(b((RQeQQQ QUQ Q5Q QuQ -1)9Z%Z5B0ڠ-ڡ=:;tD'tFtE7tGD/FE? |0C00#00c0000S00300s00 K˰+k#'uX_ [ ۱; {qq+(8~88 .e\Wq q?-=<#<<3< +;|'|fFd$FfFe4Fg d,fe!1)9_%_5-=?#?"(")()b(b)()()()P +T*VU:WeT&eVeU6eחʡʥʣJ + +JQiQYSyUPEUReUQUUSuPMRmQ]S}5PC}Fj&jfjjVj 6jvjNIE]MC=KG}O5@5H  0 (8M$MM4M ,<-"--2- +*I?kmFmfmVmvNn^~Aa#:c:NNП::󺠋tYWU]uпO7uKuGwuO@HDOLB/JFoNAIɑQ1˱q ȉIS8S989383989tt.vW篝\Ѕ\E\\%\ҥK˺˻++kk뺞뻁c7qS7sspKrkôlq[s{wwN.n^>~A?xxyGxGyxy'x'yxygxgyxyxyxyWxWyGO޿x7z7{z{wzwO<aP̶m-e-ZƪвljY-Z^ma˶kwaO@8p$ [8~T8 gp.p).+OF7n[v{~xGqxgyx^Wuxކw}>O3" ""!2 *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r D.FE>Ǘ(PPEPP%PP_ ʢʣ** +jjAc4AS4Cs@KBkhvh ] = }11=`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-~:36b6c bcvbv^~Aa#8c8p)Ɵ88󸀋pW7U\u7q qwqO / +o Q1q Iə)i陁Yٙ_0's170/1?d~ł,,¢,,,eXXXXUXX5XXuXX ؐ  [[ e[c{hvwN.n^>~A9C99#99c9999S99399s9 K˹+kG[۸;prWQq$O49^%˼¿[;{|G|'|g||W|7|w|OH(hX8xJDJ$JdJJTJ4JtJ ʨLʬ,ʪlʮB9KGyO ++T!VU1W T)**򪠊ʪꪡڪjjoXMT\-RZmڪ+$SGuRguQWuSwPORoQ_S @ `}!aQ1q I)iY9yZEZ%ZeZZUZ5ZN?'ڤڢڦڡڥE{W_tPtXꈎ꘎7C'uJ../]tUt]7Mm]}=C=c=S=sKk[{}G}gGpDGrdGqTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsv\<|/]_ KKvu9wWt%WvWu5Ww t-vu=w7t#nnnnno0-;;{{{z{PpHhXxODOdOTOtLl\|/B/b/R/rJjZu?y7go&oo6o.Vl2ljr-/,ҲU˶maGv?߰; {a_P8X8NT8΄\8.RZnV^QxYx^Uxބ]x>SH(hX8xHDH$I ɑ) +i_+GdD&dFdȆȁȅȃȇ((((((oPe-eQQQ QUQ Q5Q Qu#>!1)'4hhhh耎肮聞胾cbc~P pQ1q I)iY9yXEX%X? ˱+ +b5`-a=l&ll6l./vc?~AaQqIiYy\E\e\U\uMm]}gd!fe1g d)~,o,r, +J*jZ:Yـ ولMٌ?9f d+fe Hf;gvd'vfve7vgd/f/؟88CrsHhXxNDNdNTNtLl\|.B.b.Re\\Uk7p#7q3p+q;wp'wo{qOO // +oo __ ??+"*"+*+b*b+*+*+PR%SrPJRjQZӗJAIEY)r(r)() + +JJV}~PYSyUPEUReUQUUSuPMRmQ]zjFj&jfIZZڨ Jک::zz~ѯ4T4\#FjFkjk&j&kjkfjfkjkjk-rJҟZ5ZuZAIE[M۵C;KڣO_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QёQ1ӱq ЉI:;S:S;:WN L,ꯝٝ9˹y]]ȅ]E]]%]߸[˺˻++kkGs}7pC7rc7qS7On-ʭm Ӳɝ]=˽}u? =ңS/ _"2 *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 ++dGD.FE>GD!FE1G D)((򨀊ʨꨁڨ ;|Fh&hfhhVh6hvhN.n^>~#a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!~XXXX_+VbVc 7u/b6?lVlvNn^~AaQqIiYy\E\e\U\uMm]}~A@PpHhXxNDNdNTNtLlg_K~ů98 w?Gğ oO. +*ſZ\ M-m]=}~A`PpHhXxODOdOTOtLlg_K=< Ћwދ?G䟽oO/ +*Z^ M-m]=}>C>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~O""GD-"zDl n۶m۶m[n۶m۶mv0pH(hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^7/?` a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/123C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {AR4>~A!aQ1q I)iY9y\E\%\e\\U\5\u\ M-m]=}>닾꛾~~ꟃ89C8C989#8#989c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{e;ɞ⩞ᙞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~O<@@˶m۶m۶ٶm۶m۶k 0pH(hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~?` a0`(a8F`$Fa4`,a<&`"&a2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/123C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{AR4A!aQ1q I)iY9y\E\%\e\\U\5\u\ M-m]=}>닾꛾~~ꟃ89C8C989#8#989c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{e;ɞ⩞ᙞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~ x``v۶m۶mv۶m۶m۶FE8GDD$DFDE4DG D,FEGD!FE1G D)FE9GTD%TFTE5TG D-FE=G4D#4F4E34G D+FE;GtD'tFtE7tGD/FE? `0C00#00c0000S00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?A!aQ1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ99 )0(8N$NN4N ,<."..2. +*:n&nn6n.>!1 )9^%^^5^ -=>#>>3> +;~'~~7~/?QPSpPHRhQXSxEPDERdEQTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ DIV@5DC5L5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ HDKL˵B+JFkNAIE[M۵C;KG{Ou@uHuDGuLuB'uJuFguNuAuIuEWuMuC7uKuGwuO@HDOLB/JFoNAIE_MC?KGA!ҡaёQ1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ Ӳ`PpHhXxODOdOTOtLl\|/B/b/R/rJjZzoFofoVovNn^~AaQqIiYy_E_e_U_uMm]}?C?c?S?sKk[{GgWwOo_     'ݶm۶m۶bm۶m۶$B# "#"""# +"#b"b#"#"# "#R"R# "#2"2# "#r"r#" + +JJ ʢʣ** +jj ZZ ڢڣ:: zzcbcbB0Q1q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_?   ð Ȍ¨،øLLL¤LLLLôL¬ü,,,¢,,,,ò,ʬªڬúlll¦llllöl®þ¡FsGrGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? ()B(B)()"(")()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**jjꨮꩾZZڨک::zzhih $+񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz `P0pH(hX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.n^>~A!aixGxGyxy'x'yxygxgyxyxyxyWxWyxy7x7yxywxwyxyOO//oo__??BB' e۶m۶mv>۶m۶m۵!B# "#"""# +"#b"b#"#"# "#R"R# "#2"2# "#r"r#" + +JJ ʢʣ** +jj ZZ ڢڣ:: zzcbcbcFbB01q I)iY9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_?   ð Ȍ¨،øLLL¤LLLLôL¬ü,,,¢,,,,ò,ʬªڬúlll¦llllöl®þ¡EGs rs'r's +rsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? ()B(B)()"(")()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**jjꨮꩾZZڨک::zzhihiFhF $+񚠉ɚ隡ٚZZZZZZZZڠڤڢڦڡڥڣڧ::::::::󺠋˺뺡ۺzzzzzzzz `P0pH(hX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.n^>~A!aQixxy'x'yxygxgyxyxyxyWxWyxy7x7yxywxwyxyOO//oo__??Bl n۶m۶m۶ݶm۶mVaQ1q Iɐ)iYِ9yPPEPP%PPePPPPUPP5PPuPP M-m]=}00C00#00c0xLDLdLTLtLl\|,B,b,R,rJjZzlFlflVlvNn^~AaQqIiYy\E\e\U\uMm]}gd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0(8h888S88388s88 K˸+k븞[۸;{xxGxx'xxgxxxxWxx7xxwxxO/o_?DALB!JFaNAIEQMC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H5DC5L5B#5J5Fc5N%YM$MM4M ,<-"--2- +*:m&mm6m.>!1 )9]%]]5] -==#==3= +;}'}}7}/?qPsppHrhqXsxGpDGrdGqTGstpLrlq\s|'pB'rb'qR'srpJrjqZszgpFgrfgqVgsvpNrnq^s~pAraqQsqpIriqYsyWpEWreWqUWsupMrmq]s}7pC7rc7qS7sspKrkq[s{wpGwrgwqWwswpOroq_s@`PpHhX3Lv==ɓ=S==3=˳=s= ȋK˽+ʫkɛ[۽;˻{}}ȇ}G}}'}ʧ}g}}}ɗ}W}}7}˷}w}ȏO/ʯoɟ_?˿/$4,<?Am۶m۶m[n۶m۶m'P0pH(hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!aQ1q I`2`*a:f`&fa6`.a>`!a1`)a9V`%Va5`-a=6`#6a3`+a;v`'va7`/a? 0(8N$N4,<.".2*:n&n6.>!1)9^%^5-=>#>3+;~'~7/123C2C3 23#2#3 +23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{srsrsGrGs rs'rAR4)iY9y\E\%\e\\U\5\u\ M-m]=}>닾꛾~~ꟃ89C8C989#8#989c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{xyxyGxGyxy'x'e;ɞ⩞ᙞٞ㹞^^^^^^^^>>>>>>>>˾⫾᛾۾㻾~~~~~~~~O<@̮e۶m۶m{Xm۶mۮP0pH(@TDCt@LBlA\C|$@B$Bb$AR$Cr@JBjAZCzd@FdBfdAVdCv@NBnA^C~@ABaAQCq@IBiAYCyT@ETBeTAUTCu@MBmA]C}4@C4Bc4AS4Cs@KBkA[C{t@GtBgtAWtCw@OBoA_C @ ` P pbFbFc bc&b&c +bB00300s00 K˰+k[۰;{ppGpp'ppgppppWpp7ppwppO/o_?!ahX8xLDL$LdLLTL4LtL L,l\<|,B,",b,,R,2,r, +J*jZ:zlFl&lfllVl6lvlN.n^>~A!a@HhXxNDNdNTN#Hfsgrgsrsrs rsWrWs rs7r7s rswrwsrOO // +oo __ ?? )B(B)()"(")(@QMC1KGqO@ HDILɕB)JFiNAIEYMٕC9KGyOU@UHUDEULUB%UJUFeUNUAUIUEUUMUC5UKUGuUO@ HDMLB-JFmNAIE]MC=KG}O5@5H5DC5LQ1q I)i( +tLl\|-B-b-R-rJjZzmFmfmVmvNn^~AaQqIiYy]E]e]U]uMm]}=C=c=S=sKk[{}G}g}W}wOo_s0wt(vu8wGt$Gv89c8c9898989S8S989383989s8s989 KK˸˹++kk븮빾[[۸۹;;{{xyxy=#=ʣ=c===ɓ=S=0-AY9y^E^%^e^^U^5^u^ M-m]=}>C>#>c>>S>3>s> K+k[;{~G~'~g~~W~7~w~O/o_?A + x ]˶m۶mXm۶mۺC(FE8GDD$DF *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` a0`(a81#1 +1c111 1S1 131 !A9yXEX%XeXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_? ð ȌFe4Fg d,fegd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0g Gp$Gq4p,q<'p"'q2p*q:gp&g$E39s9 K˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O\!RZaV^QYQ芡؊JJJJJJJJʠʤʢʦʡʥʣʧ********򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ +(8M$MM4M ,AdihihihiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9;C:C;:;#:#;1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ!1 )9_%__5_ -=?#??3? +;'7/`AB' fײm۶m۶ll۶m۶B"B# "#"""# +1q Iɐ)iYِ9yPPEPP%PPePPPPUPP5PPuPP M-m]=}00C00񘀉ɘ阁٘ ,",,2, +*:l&ll6l.>!1 )9\%\\5\ -=<#<<3< +;|'||7|/?cp`HbhaXcxF`DFbdFa23c2c32323 23S2S3 233233 23s2s32  KK ˲˳++ +kk [[ ۲۳;; {{srsr3#88c8888S88388s8\\\¥\\\\õ\­ý<<<£<<<<ó<˼«ۼû|||§||||÷|¯ÿ` + +P +0 +p +H( +PTEStPLRlQ\S|%PB%Rb%QR%SrPJRjQZSzePFeRfeQVeSvPNRnQ^S~PARaQQSqPIRiQYSyUPEUReUQUUSuPMRmQ]S}5PC5Rc5QS5SsPKRkQ[S{uPGuRguQWuSwPORoQ_S @ ` P pjFjFkjk&j&kjkfjfkj J4_ PXKT˴\+RZkV^QY[U۴];S[{W_tPtXGtTt\'tRtZgtVt^tQtYWtUt]7tSt[wtWt_PXOT\/RZoV^QY_U]?S[W!ʡaɑhX8xNDN$NdNNTN4NtN L,l\<|.B.".b..R.2.r. +J*jZ:znFn&nfnnVn6nvnN.n^>~A!a@HhXxODOdOTOtLl\3Lv{z{z{WzW{z{7z7{z{wzw{zOO//oo__??_PA!Akٶm۶m^]e۶m۶! +a hX8xHDH$HdHHTH4HtH ȈLȌ,ȊlȎȉ\ȍ<ȋ|ȏ(B("(b((R(2(r( +J*jZ:zhFh&hfhhVh6hvhN.n^>~A!a@HhXxLDLdLTLtLl\|,B,@Fc bcVbVc bc6b6c bcvbvcbNN .. +nn ^^ >> ~~18C0$C140,1<#0"#120Q1q Iə)i陁Yٙ9yYYYEYY%YYeYYYYUYY5YYuYـ ولMٌق-ينmَفىم]ٍك=ًه}ُ999C9Q1q I)iY9y\EI b.R.rJjZznFnfnVnvNn^~AaQqIiYy^E^e^U^uMm]}>C>c>S>sKk[{~G~g~W~wOo_S0WT(VU8WET$EV()b(b)()()()R(R)()2(2)()r(r)() + +JJʨʩ**jjꨮꩾZZڨک::zzhihi5B#5J5Fc5N5A5I5ES5M5C35K5Gs5O@ H%YAZ%ZeZZUZ5ZuZ ڨMڬ-ڪmڮک]ڭ=ګ}گ:C:#:c::S:3:s: K+k[;{zGz'zgzzWz7zwzO/o_?ȎGu4Gw t,vuwt!vu1w t)vu9wWt%WvWu5Ww t-vu=w7t#7v7u37w t+vu;wwt'wvwu7wwt/vu? 0wGxGyxy'x'yxygxgyxyxe;ȋK˽+ʫkɛ[۽;˻{}}ȇ}G}}'}ʧ}g}}}ɗ}W}}7}˷}w}ȏO/ʯoɟ_?˿/(XP`Zm۶m۶ml۶m]D(FE8GDD$DF *!:b &b!6 .!> !!1 )!9R %R!5 -!=2 #2!3 +!;r 'r!7 /!? + +0(8J$J4ʠ,ʡ<*"*2*:j&j6.>!1)9Z%Z5ڠ-ڡ=:#:3+;z'z7/?` a0`(a81#1 +1c111 1S1 131 1s1 K !AXXUX5XuX ؈M،-؊m؎؉]؍=؋}؏8C8#8c88S838s8 K+k[;{xGx'xgxxWx7xwxO/o_? ð ȌFe4Fg d,fegd!fe1g d)fe9gVd%VfVe5Vg d-fe=g6d#6f6e36g d+fe;gvd'vfve7vgd/fe? 0g Gp$Gq4p,q<'p"'q2p*q:gp&gq6p.q>p!q1p)$E3˹+k빁[۹;{yyyGyy'yygyyyyWyy7yywyO/o_?O\!RZaV^QYQ芡؊JJJJJJJJʠʤʢʦʡʥʣʧ********򪠊ʪꪡڪjjjjjjjjꠎꢮꡞꣾ +(8M$MM4M ,<-"--2AdiVhVihi6h6ihivhvihi鰎討NN..鲮誮nn鱞詞^^>>鳾諾~~9;C:C;:;#:#;1ӱq ЉIɜ)ҩiљYٜ9ӹy\Ѕ\E\\%\ҥ\e\\\ѕ\U\\5\ӵ\u\\ ЍM-ҭmѝ]=ӽ}<Ѓ!1 )9_%__5_ -=?#??3? +;'7/`AB Ͷnm۶mvmՖj͊[ 5ܶ|σ8xHDH$HdHHTH4HtH ȈLȌ,@VdCvD"r"r#" + +JJ ʢPPPUPP5PPuPP M-m]=}00C00#00c0000S00300s00 K˰+k[۰;{ ppGpp'ppgppppWpp}M|q qwqc<'xO>_k|oc'|O?_k~oc>S>s/?g_o|˿7c|b!N!AH!IH!EHR!MH҅!C2!KYC=D!grB_+}oz'zgzA?^'_^~C*ZoVѿO˱q ȉIɝ)ʩiəlHpNrnq^s~pAraqQsqpIriqYs˻++kk뺞뻁[[ۺۻ;;{{{z{z{GzG{z{'z'{z{gzg{z{z{z{WzW{z{7z7{z{wzw{e{OO//;#okDM߶km#Jֽ+/NtdtTL5!b-#'\/MkĿҳ1 ċpt[AQ\Y-tw&RnS n3*5*DyALOCE@5*<fgf cPf@P A(&Q*>Rulv+{LΏݪJ%E:߯SGs{4)RKNWsm{f# )eOBW@{Ѡ pg)/,پ{s||#q7Z0ޖ+!y(lmvm#;zkֲ<'Pap@!B!B!B!fǃ zDGw5+C.(c\ʽ*K@UDg ^ 6+LxyPU/ܹpĠ5iC<|VY2O{plyzUJ*Mplyq<m\};,8\vBW7bČu%+5h%sy\#t-li7c]\H\dwJRƎ!8R>;t1U*{*k&mmQ([xpii +G|ћYGU(14 ƣfwv{{c8Nj$h>i8UGkiconZQ/gkm?swNyMIbԫ7*ߌNSX815ߍ< O@}wƇ^]Ar']7:O DY\i?]ǏJM_-57Eu%!L0Zx^#NjTNl4zylmW3B!B!<2yKemԮ1Ng_\d[ѿz\R^gLmjmu{Eɩ8=|] 9ڵF6J<1vPx+CH̶}c*ײݾ6kh-7ԑbjp=U;yܗC@3M'>w=7.1TB oOHr߲ٕȜRV2GV_Zәv iaBo3X7!B0~׍md[VFfGƳҡ ֍M7B aW|)} $H9/?ء,2 dhuID԰y +aF~4A !B!B~2c>-ė& zZ S8E+&w/]G!!P9hVڤ5L'~cјDK%ga `5| lUPkeI8 +2!! I!U@&T83a$+zo>T}VYӪ@lKB:V~)^jM)_micalp;$B&ѩrF"a Nf\հM 8pLNCE BAEM!B!B!_AAphPxge7rz#xZr?e]*%{n3h.ȞY3`q!B!B!B!B!B!B!LUV;sWo{(潚֖v?!<E34{fzX:2iN]\Ji+mZC$BKەb/SljPzn-ݖ0*Z5`҄&M4j|DδǨ>''\.bc?'z^e@͵6uC {onr:fA2{6K<<{wdU7{]eqM."u} N&n}t=u'w!H E|j + h-*GIk"{y C1-(_ kDFGP5!<֝i~C=+L%i؁ȟ{D-L&o&9r  7ɹp t8s-ӑLK ,ic¾;v+-Dnjf:[gw;/}KJ'_u&7orQ|} 7*0^krVE@JrZ24 KhHŨ=LlLpQ[V\`Kbftƨm\BΌOşţzwZ}XV+(E54& +.~ + +A I9 fC= +Ig0l&3;sehVpbl :7ֿ=U,(o07=y,VX|E_Є&aPG4;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 +HR(T0u +endstream +endobj +2494 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2493 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2492 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2491 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2490 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2489 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2488 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1830 0 obj +<>stream +xW[S7>$@`2սKaHm.Ng2NN6b{H:ߧsH9J#TN 朷F^'7 :v(Iв&5J2˹u6uV3W:[I~ODʧI`u=gwz-];KWB0ɕs2mh=9huюHߢcZBy"w ;w(3XlW.z4wN҇*wL2)J @-z 86Zql1 Zôz|^FXfI3̉07ILE/:?~5f9 n{@Q$a;EI//li3V (|'lGEq/(wY8愕8FapSxoSgv"-$7D!=\OĤ+x8g' -a\xfWXb~9;IELNBG +JRb(yIh>B_J`9rы1U09W6C4>ULh5Zc8k+ sZзv<-(03tq?Џxz?5Le%T/t suZ +hiB"v}0\U1c2@.&L4ǐٺ +QSHja}uaK$3Osr3&jmNȫγO"xpCh6:6$#C4ÞNjRFYtLph?u +V*h"&#۵r1X}6|)8/z!t6Yypy5D8(!hm%?BOHspV;8:~ 0G%2ŵgÍ^LUcP?ByPNHq'kD%P!!X3Ǵ'&5d5z8XP×Sb($$@?hR{O٣! >$7Clً|+Ů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 +HR(T0u +endstream +endobj +2497 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2496 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1829 0 obj +<>stream +xZ[o Tq#;N|p+WsٹIbEQRbHڧ{r릠is;߹Ιc= +,3*Cn%v_l wZT.2M6gSGfr +cg >43aPd'>oXfzLoHpҭop +C?Š߻{_nɘzߘWRFgFICMQqQpizWGg=&2\C}KrF&dFF9EO9'}C,dyOpu\y$P-xƹP0~=Kr + fd `&dF^;O+hEc)pj94A@s m#@=&st mC_pS=U&4 +-"|<ʖ񼶂3Se! a17 X(#mzl ZGzG? +]dB  {kub,cSqٻTlX0ϊaNah|V| m;L瞍xus2W:\J:j | )hg14Uj} +cɎВ&(]+mO6AW JÞcc$YU^<Zi .a~}t+@i:+ +"jg|6ۜ#'!.3rg%b7NGȽ)A4B9AF^@gOɗ 'p'7~F;Ke\5I4|Nޠ>>AYq0*fp:sȤˆҜj)k |^t0gg5 +ղчY^ L譱42ø9}g]B [^#tZFKĵh}@N!3!.)i{`jj .Y-v#xܪDplAF` +JY<~sdm(=5gn;4.1#Qg󂅏~?FݾnpǍD>vlڛޔ SB'K晡dj nyEDO5d3G}M5w0NR8bz}L%bU bn{|!K/걬k]sCI,EYovjC&>w]+jS[4l3F+(8Ԕ1Yn0~OpcF!;|y`A߂^2&8nQk߇6%2/2MnH` +hZ^)=OpGAUl/W6ooD}%'``&-xx(eH@{wD<&Q#!4Ba`fI󺭬(F3Z8w93I^"3#D +,ǝs҂ZyӔfZjH#"μ,v?Je rQ}љa*]Nkuѓ(IN8pN~qUӒ<ׇXd?Ebv?"*ȐvQk<-V0_ Zd0UФL䬰_/4CtpZ-/ta˻qU<:+.`})jvU-<Ǻݐ3XĞ{oggFM~U+NQ5d~K͡,kʿq"5wߗ(.hj/}-3Em%DE3E e(,@K3- yb E|[:vl|3%J' 'UUr+θBF +3F-߾y,!1e!9KlKjqYF!틺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 +HR(T0u +endstream +endobj +2502 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2501 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2500 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2499 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1828 0 obj +<>stream +xY[sng\X6TxlP!GV"yu5 Tăl 򐟞{.;םYƞٹ9߹NxplS:Qߌߎe~ߎqgMb1l⬦J1t?wco;_sʒoC8jcS ]t:c>ϟuI̯dJږ^_=Z#Jp2%kqagqK8sTH/Kߌw'<pI# [dL% 3]<l 99%Ȕ}3#8ϋB9˴n. VB@YͫHm./2.{^6 #N *TݨIOvwq,FYdJ! s2 +?wT烜Ǒ>~XޒjnU="kZûph7@#x<]!{$n؆YqM&ԣRΣ9Uz~7iYQkfq), Zvhj֬r)) !#hw_ +<ɧbp4ܨGI4h w g`S[#pиpu蒄f2ͥNZ-8)e8%4’ gB72>ʬ~UvӞpU=<@ YKy՞W7pz֐V44p.5NԚ&2g͎uAoc^)EE[Ew0y-IE=C -) /P'Y)9L(yۑI/̯AY}ōPwE˻HbU7]Krcʓ:ydnT]Z4.ښ؊U1R]dE4w }U^m=s{7(:ꍱ?Y+)]qUk0OKGfކi123(qzB8m'Jio__N_&D^I I9:j;t(SGnE%ѬHc2׭p P٢ŋ̎Oڵ$RdHɽZ}SN$Ju.?jp3||Uiݍ~R + J{3"V{)=ɸpoPqa4,Zԯ0㐥Rl,CTu%z:4t9CqSOFgD?T(uqlP|M&wȏkA\8j d)?X_R[Y< @ Ȥ,J ~3tCQ&U8~"_ur)[-I*TJnS;d1SF8unXlqU|aڏw"2u\y˹e,An$wM.àd dc/ЫcHQj c J bx1eԈլ3Slb/h8^3ν8f `{Kȍ 4k1ſ6(ҶhQVa٢HwAiC"ZS^26`@q|Id +zUKtSߜvnB:ɩn!q}rQHtbmel8s`FPQM`O*ӆ&䨹• lAu2I +YH*7s4w&f;K7@Fw++5m+>uHQMh=Cp= ٌP`/|6ԵMSZ/`Y-򝗵3DMkq)( 0a +nLI-MZayhyf-ͱH( <&WPm6!Ca $R˨dq2F!XUwGq q};XoZVjĕԳJ'q8˫f[+R3>/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 +HR(T0u +endstream +endobj +2512 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2511 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2510 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2509 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2508 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2507 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2506 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2505 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2504 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1827 0 obj +<>stream +xZ[o^ T6_ +RdF)S-*mFb&9߹<|9S5jßt? qd(ZƬ#guJ>csG_yF5 /p.D7\ xaj_@GskkK(˻d6q._}݄(}ṿx\t_)ߨgSg17̥BzF\4įF?&νL=IYHΒU2O˫_ _l\\Z:dc6yL:*(Uryӳ|@vi >-~R|ٗϓdA9-Yy3¤ +f"HπsM]G |. ^WNp~3ϓ{ Vb2B-:!S[18\5QN&P))zifm~ z&R ÛZl\Sw"=Ά18ݡ2;*S~= /8谠O֥FXa7Uɐ(aP7jJLmጄ(6FaYCfB?$W;wFi$! }Dx腤DyejLmq4IVBõq=QCf}!NN:^Տ0-*L8zBt|B}[nN–Ea2ux,ܯ(OifNf={6uQ`23sP)3"yh:}CᒛJjKAC !aΧI#A=?xA!4x`$oC.Е)Z;O;Ȗ2\R4ҍjBlŜYo(FY J ޕj]0Yf*Z_mAɅ2x>&#?h9 )WpR2g^:XʜS>.sV;+Ci]>PcН[{ -*uK+4nj3t8 |ܿzr޸dhΊF 3ZG@qj̝s9U)M_v"5(k;NZE;9W1K[EM^PjoC +ɤ%e>QZSuTnjHyь,t}"ƹ K#N[*_E6s~.o~g9alΰIy9Mb uFsj?#͐g.i}q}V~߇=-/%μ;T3_AI 7&_ rUX}Dvto:U|6S[EQ(oV2T대{̼P'WXQrSs.7ƹn'cUݾ OjxȾ# D7kPVZR&&1ڪKfQ ssN6 +Lt޿0S%4E3K/&mt >,o2.r>*Kn*[ᤈD[I=6=Z{TG،3⳻(b+;qБK K1w$FQ9Q9 +:)D#e +OܷɸgٻWmLtL=H9E99H~,ˀYgQVe?W]"s4iRfP6^˲ ӾRVC -)=ʋcg5~a %]] +P6zb=n]޹ӆU55~7WEh "FOD`VGj4gEӬ0Kx8wVXÜvM)$E8_b00.De_^呣H"2,pԟ+YH 'cfWG*P :'DQ{U$y;![Q6řҦ9. mA|eJ1{/`|{Iث=9..[fl8/twY^oɉk)iyJ UuA+TtmN1m;]#,fWot{'CX6d2vW)߼ẋv&k$ܻVݒ + n7so-SH悚|(-{^dh˿՘@ٙYwoӈE l.sfhKIj%/veS#qct[,<ȸU @淒UwoP ȝ*9rc3! I pԋj/9maՏ*vќ}Bc D@^/ۿ^@`dgAZAG-dJ2Du$SvCHRN +3("Y\^7o-ԥfHPMg!s{[[T8dI׮Zb#/MsQN +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 +HR(T0u +endstream +endobj +2521 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2520 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2519 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2518 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2517 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2516 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2515 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2514 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1826 0 obj +<>stream +xZIsn rHl-hGj\Tja*RR\e;ʇ\ou 03 H}g ǣprS5*Cju|X&3JR˘u6sVSW:C7õלð΅{HsW.#++X=ק`F]=)E<ª\˯y庺r wv8KUk\Uf@l{/E \x85qVhϳõ?#Ґx+;>|@]C= #2 W͇9ޙQPΜ:]EL%Y'GV䐜|JM< Od NdFwJ,:7Y65*+W*a48Yz8A?V\,6[Ƕ>` jtq3N`;vE'?ީޒ&O`w|FSŬ-t˕LKdeyNYɁ4Zн%O*6n!4)] +G Np! m| +stˏӭAb1YCHda&8'y M`:ih&} D-@.TӋVccqrוgѾ͇2TLҀ {`>a%-'x2w^k!ɕ/Y-unL#1\?1"5fہY R;x%priɑ]&w +1Gxm5R>V~r;Bw48wqs +d#48#:ZG+cڟ{;m+:>RP2NRXE$pW2qHh rNlDy%qaQ٦iAvʹ2ki\F6gCE4D0Aד]ڟ(xe{|!5*T08GwK M֤ߧ7N +Kk`6T2WmVaKЯ/t;f荗;g=Uqָtו +X%M8FDɛ<Ι/6s7JPNQ^lo#1`;Sr%Pz?|;q0Kqd=fI Zl~Fv@{%U9Ow7qyU&qF&-j]W Q>뙪e>ShHQnTB TV-z>Z@O%2 D&E Tzϵ1fU$[i'sx$6sf7vp}< ce+MNv'y+[4ҋd#++w2 +8 +kݪOʕboV.rN僦:F8mesX\9okSTy~uD q-bѡ'2QcX'c`SX͉UWɗ\_YR=hD<4"{`t<;wf)jهt=Nx-)Zy;w-A~(8c +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 +HR(T0u +endstream +endobj +2536 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2535 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2534 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2533 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2532 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2531 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2530 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2529 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2528 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2527 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2526 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2525 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2524 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2523 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1825 0 obj +<>stream +xYoDXH +z +()d2lMrlݴ] +"q21)N֨ߺ8XƗudMf1l欦J1tkgxKw ,nXo}s!޸{+gJg +yt̨u~ 7mm^*עb՞ϼ\_W{;9*Ƶc.*3RHlɤSJ/E .n( pQhϳݍ g\HCbVvr}|%gtMO:y e IkH'[&ǤG19vȀwDJ6(h>b,XfxFIK dZ\͓vP x頋!-_8uT>xOxDIm=8Ktz"mJ.9YK`wŌr4"ӝ&Nq|AIF>ƹ>"VO'xG1 y`TTˬ-sb/Uj-DSSlFPYqɽ~d$Khg "nBO:S=#lbS[}9G4 h&Bsl*=沕L(D Q}j9scjq*Vh8퉋UxFmg%S +5f 'z)`UYli_ҭmC*pjgao7*W:Om[ x9sb4L9r 'Ee=#KA @l ^ JnLᆰT +BG= :Ilא;*Q X# +:4Dբ\VLf!^D8CpߊR ]?OZUVtp0>Gc{^/uX 57#SyP!kk:*Q +AE e-O_My3ZtM7\6Xlh}^l̋w[rX+&6uyg҄DKJQi]-<W&8)xWb&\ +cI p=u@qw!>yl04prU3f*A(`M]Q :.-:YFluZNd:-^iAكhG;)MRg;UM+*ە &-ӇE:Ӟ*o>Uu-r4?3CQc _hz48`ªŜM6A;8o,Z*4oab80D?p lԌr㬖0U(o;",[-iyj-Eufǿ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 +HR(T0u +endstream +endobj +2546 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2545 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2544 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2543 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2542 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2541 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2540 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2539 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2538 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1824 0 obj +<>stream +xZow-h q k;hYY ; <$E ]rՒ"D.5g J9ũszfH/{|f5QZƬ*żO?O,\?>e/ώp.Ϝ q4w`yQUU}X<2_"s׶AJע|ɪ_k^YWU/e{LRg1q'xn=ʸĮlyL>9!c r od7Cv]7xWg;ܼpK/xQ]L!(H5P"gC5T3!_B.𯁺݆ٗF.Պ'2 PX!يt#'XmC<9%{cgV#| ?}n|>2wO1`lEǃxp dZyX + xv!q'oRԈr|6#~b+Er5He,ND(AHO#9\ 'wI9d J3m7Ҫq%FvW&E"X&  +B*TCPm#6hwid覌dx/OڵP8F,n<(N'&U-'ijҎZ\rj:U͠='8)lySP#Pi;ѫa5s.$FS~E>NKMS")\mbԓv}sdwsh<[Av{7)Kkvy?ADՇ7zPflf(-\] +dS\2LQ5BQE?!i5 mL oth@s!:xc4gVWUpF +9B53^z'TaK9y 1#5ͳsHPP \dHBT@Fqt`1MeVKɧdlDj0:a0\:f))3 $0"c4eb!WRYuHɑ*!v$mRQs;jėxɋB=9TAڵ"nbNw 5s%Z/ 쁫V{۸F`E}9<x+nG[@UO9PE"R d2BC&9.FB'*mv!8mg*ZW&V0Dm1KjZtG0B,LaE+pջ5i1U - RKBA>Zw' y/6IˤùdZ$Q,űpAq6Zd7 X/XOi>qꘪTp$on,U׃̪ۤyj4\[Tm^팤g̫0~^H^=GM#>n P3.kI$Niڬl#N`T'4qwcۿQ)3c|Z(Яɗ4R˜4H92`Y4p[1\]X(>0;o@!. 2K[1 N :kK5~a ªEE-7|>,kVjފXvXL[=e* ؠ삼lB!:eK>)P;oR,|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 +HR(T0u +endstream +endobj +2558 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2557 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2556 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2555 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2554 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2553 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2552 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2551 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2550 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2549 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2548 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1823 0 obj +<>stream +xZ[sngu +v21 V//CVhIJH**<s!޸8|8+W^&/+dĨez+@ Wn:Eq?*_c^畮cՃresçù*Ƶc.Q!.{ju0vwa%kH<==~wcOn1$~}L &/qDC'\KlqFC|4ѧەt+Bn%-Q /j]}XY[[x߬GP{ы&g|oߐ_{r0T/\֞PoRdJRZ@m!_"wD+ɺLun(-:;~¥*UzV$PI(YP}FRbO![W3<|vYCHĊ)E d9? acEܵn׉i$0so<{Rgee APwj^* Fz,&?;6_gK6}p/Y}fV7_|Rw +P%UҰP%U>5!jO7̇] ~uD謱$FC`YM K|>G,@"i+5oaӎ& to"ӳr_?Yj~Fb\x=Y,:h(AL8oJe nq2?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 +HR(T0u +endstream +endobj +2572 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2571 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2570 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2569 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2568 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2567 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2566 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2565 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2564 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2563 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2562 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2561 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2560 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1822 0 obj +<>stream +xZ[sEnJ`R`Cac'i{c96e[qD! UH ~sLFn&ܺ|&'W>>w:׎;E5Sew8ᒆ5$F%gWgL&]!#rH)Yk"8S҈zd8bP>9Ƙ!orup BOa } MqBaX81ݍRn7On4czs~8{7xq!LXsU .,"-@huzȨw'K>ڛsba-lNX4_n v/Rka =iłɃprc3,]eX0r\,RKI8_nw)M42d>l*e~G%P.m ]GR% Cf-{^EM ')i2C/eT( 7i., D\Px?:5ˇ^r#ɿSy"agɥ2DԖ”;W9c޾i/3 XM<~^a~R HmToQiReɚ|dC>|J~ k0-iϰ~#VE E]؅F!f*g;UWTRh0Yhd+Ӯ7aef317P+*Xrl T-O`e( \wȞōQESpCUNSàS6n([mP.O֔7ͷsfã 91LЄxfMTjԉ* G:Dkj]Ճ +RqYڅC{[ɒvYrL=+ۯ0^jy_:gSp P$sKQ[ )eїVSCSܩtAF肌9zAnG1 Ly.ߍ 3#|v07(S惙AM$l@ >WI!f5tk 9N/eyezK}Y5j+st3`;{D" Q'ɇߎRN$. PH#IIdE]<98,WMlu$E^el=d}1FT u|>8Lnxfhsy@]yV;^ * D\؝P[(j 3w2r8 ?*g9E۾LׯۇÛiSu5 +}kc,Vd^|f0%E? #$ZP .k5eȋԢJq\ٻՍA‘!jjSKT87|a f%m!,Wrm(]!&Tiw>F۲-cS V-SAseCie߃\bP]e=vrS 2g?]k苰;yz 4^*r;眯,\15K[uh 7L[Zl5gA>`RF.T)<غ7*uTn(oBxo +Niv< ~q\/aX{[ejsr˕w<ű^#?8w^|ׯ^.h֫$'L yۭt=i3,9Êڂ?ːdI`O>83v} %_BO(.'|ϺxϬoO;2ÊԨZrא-ݞsK1SuGXsoC5mEY[$jZf͌ĨIws˂Wצj)oeY-bR7,0kI:@n.T|S1!a5JSU)a_L !>F1hd|& iش}lcӜ(K.o/\9vъ +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 +HR(T0u +endstream +endobj +2581 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2580 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2579 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2578 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2577 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2576 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2575 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2574 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1821 0 obj +<>stream +xY[oDe@- T¥$d,iMKYM^?o q}|sf6õnNqꜷFe>R'_ 1&3JR˘u6sVSW:{p:|>Y^>S0[ \7.Ҝ p5w,B0CuY[ףdθVx-Qi>q2?[('KU;KUk\ƍ +yvly0z Foeg)!S엘{Lȣ-E//4r&|Cꌢ(vDZ#LrG[ ~;ij#xt ǒʽ1!:7ºp_%m/Wb# |ãý6moQ!I-W ze&DP%Ie%3`>dȷp6UD3spGsٜ*aV#DQ}D~VdDՊP<6ה[/@9 Sp -xׄ<^P0ca$Z4 ]̻yS//fU˵hA>],|kEi[4##03BCM +Ԭ`B fŨiͳ'1b\e +) %*+EU%O\ +F>-tGEQtf%%o52_}M/Gnj{ޕ>E,irLD蓔A1>m˾Cyƈ#&fMx;rT \rL.K=8xLإBK +{L$ӫKF)fnM`)$S\7CwQ+o\]ۜ6P'{/8VbT,n}^{3K\DV 9^ M :_\j`Ac)U=K~YQ-Anw8Tr4tzTn4br|,Jb?PMa(h]#ZQ)cTNIqvJ\H;Q(:WxY:y_y軓X6?ީ"M6ɧ$#5WATxҲ5\O"Sۅ B TƇ^OȏM5v+`v42M> `ytB;"2Ф0Xu?jZYdUZP_ZL?mx7u~݇pbzN7(JWݯh0>vYP/*Ѷ0x-@U"uc6i\P+0uYŎW%JNBŲ;-k%) 7#ՏXd&YX`V[v؄!N;nn4.i ەbUޏON'HWvvUgǓo*ܤ\G"S7խN,zsmC "]Fa} Y w[=\朗\ K%6 +j^L1*I{%1u7 mW-AV&գx0"46d~OL2/5Â,:_A=rpAZMFZ-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 +HR(T0u +endstream +endobj +2591 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2590 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2589 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2588 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2587 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2586 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2585 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2584 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2583 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1820 0 obj +<>stream +xZo pAbFu%@.%QIaPE~kYrXkrwv3 {guW] =,tU+g3wB82 ZmwՕY<"DOvv4@jt|I3bw)|=rk#~\E(1Xrj͍ޫU.WD}F{>d:=rc\r>8&  ATrr9!Is\sa_&/b|%mK%o6K< ։t(c%8JP.-B+S/,lQoc`{h6[W +8~N)1²- M\ K5#gMUi?4_JbdFɤ- ^Kvg"~X>HlDŬTNNvU*TkEnTDB1^ -JGlR+8J(JE0!%SO,NrZ1HB[o]0r"Q`mBct@LS^a'; &s4؊i ks\H~֐h{", +nFz|nT?Օ>yn;Ksta!^EDnup;B-;OyK֎> Y?r}gB.jΝwmu\B95j>b`V]BM"9(%ʔY<~͂:O{rS7mLf{HQC.-7pyM_C]`6* ƯwH OSֈi)Y\QP 晥ޘ()UQ!@oV[%,6Ť{¾nl\-wZ@\KEy[PT 顭6ڵN3ʫ0mkH1ꆠAcd<ÔXY UIG=Ly]];Q J`a\F/xq9C}cm)3䱥eM{8noL}x/qi/!72to 9^+VFsF,j]͆R' Q1?F5. "n!gSd{Fpid _8Y}CPW* IK$ + 5O;n1xmA_/sm:p*RzLf)XOec*#? l_i:W7dᒹ@_MIlg9>،Xq|e\Kڏv?gh 6eṡ>gpN7TY)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 +HR(T0u +endstream +endobj +2599 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2598 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2597 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2596 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2595 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2594 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2593 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1819 0 obj +<>stream +xZog +֬Ő bc9<(Lٖmq늺H;-#x;II:?|egJ[[-tvsdo3:RRcMfʥTOw/?vY^?4[o8+k5 PyIu 2/6A,Y/dqe$Wu8qJ_,O%n3gJywkrk$eR1js. +lvuP\\BjpAD)/ɟ)0t$- [s?9+DN"' pN w~-\t.%B(.rajy_c`IHsw(;IX BC\aGF0WFx{ӧN%rA,=,!a `A:c\;N ̇ sHlJY3(?1 ?^֣K`;p]كSxcCҧqYwD~5lCw~50 "Q3]z{٘öE#NCQZ3pHZiJadQlA #G BB*Q,O{̪ 9h`v&Lt|zH}Wx9Ox6ThQ/k=WCY:}%|U+Dg&&)p6à;߭ֆ cSaf^RVy;Uq"Q*i$8Iq.DKhnsǘwYDmcE aژN)v6uWjȀU8];ך綰+ZFiqVޮ "$S߮X8ɔDdZ~ExͪDī.\ D7 H~*IgQ!\Rk^qQ*ifBqP0҃tM*] +h௣:dC܇͙CHU#Vg΋ +D6J9$dzm%+_!]ep6+(j`Pۨۯ]@Z]_S밶bTS6|]m.])S+I0xa9/r|bJ+^MԛGV׉—-|nߒ{z䟒Mr1mi/UH)r~9 \ߑo}ߴouدlNKF&}$fkׯ-P׼@縻_N=OK C)N=1s5E(ZISqz +(H[CD|Rkw a8L|b &o-ύE.8w68M*|K)\0K?tjƸ_.X+M:1r7y>/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 +HR(T0u +endstream +endobj +2604 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2603 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2602 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2601 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1818 0 obj +<>stream +xZYo0#IJ2HxqeI-\L?AI!~OpwEZ ˹%+)>/JFuFoFGĨ:G2RCF)#VϏ?g?sWwas6Mhf.Rۤm빿?2bԷdzlpq6^u_ !L2?6վ<o FR,%(ʹqٻ˒ d*ϮG>)N⤘b^;b8?մ/4q./)d{{D*@ cڍ`NM5Z_A 9hvp +dNC9icSZͬ-F,iM=lMwFוֹ2`]'A] m49´BwƌGøu8*o̼I:<|m1;,}CWq4 "*vO ʙ!Th$Yl ~pֶurÐ9S2[vi-B|'"v'J: >^C*K5f%:KBy04a;B ۋd)u"4> 7skqum +!4+QGy7? +}8I:w{aȱ޷y \8JdnXurcϗ~1`A7OR*.W}ag$Q+_8S[bj9jOJo)$Mno @Jd9e @@V[[8ᚂbwS2\ 3M̛Jo] +FDZvCOC93,X'ORapkH1W0wHS $9ԛS}qjw:^42y4MCN?+"Ia l3Ҟ'u5l{jY!E;t>S}7r Ra-o^f*"fH&yL6j`jf燜EvPCI1O:+ڳSx!kg^` TU-v[%VIks:4K| Zs#"K92.yWeFuLg$ 6~H#A\OcB6Dj ~r +WGԙ^e?o|@>*R|ĔOY! +N'Wiziw=XBހ>CIśa+П#i0fhD MùO̽Pߵ6+hY8_TAœ|fMZN,b;W>j)l2fŕ_%RXGDN~ 8)09W^S_Ϣ.:ߊh->q/a#k6Hߑuj~WFuU[>X<"0dyC3 +͚6Udwۦg+'e]Ca=E~3\z XT"W)C$͝rT ]mc5SY.d6l[PlYQiCj jTNS'L;aUP}VS ìF:&0r&ZAk|XO!cUW4du_U\]'~=Yӗ +B[*ʫfga/pMij{@Mq +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 +HR(T0u +endstream +endobj +2613 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2612 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2611 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2610 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2609 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2608 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2607 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2606 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1817 0 obj +<>stream +xZ[o $0F!; [%܋@]](EI$}a$AmR_Uޗ$%923|:7+9-ovR`vHKA cƚEdN<׻Wݯ8eѫ?uz%1Ui\tG@l T&e2ߧ`Fm/[2!\6:l<*Iy齼G[\Pk$29in(#a5;3cQ.~/{rB\jAcNO".h!0+:$-2 }򌌷bIzCnm}q/(s)gV8^wI6YՆ7Lmd32 )>%Od)`qކ~Ϝ`LOz~G&U\*t,]<+a|3!egft~UWEbg\Xk\+[Yx,{#g*ɴ!xY&!q||d?1៳2ujT"[1cR}5%|F"<)l'&-eJ)*c)>ax_.cx5VcY A\5!rl{H84vS']  O\h +5TPs|x\=nk0M&[5`k|@1rc:]{3‰+WBxih"vQb+/`) =隂|.Fz7>Iҥ4Ij@?k2DAJ<{x̠yOU(KCns.h-vBRt5ϵ%u@t" z1`bJ*oaP EAk}HdfW2H+$V^ Y-0瘸* AԞB$v-kZ\0D->-G5ת6 =8oBaR>E<@'Ȯ!@,A` ,Q L(e%`;/j?cC0= x IO{$~,Dė%> vLbXD3\(bXDM0T1Cr9N3;s@ >Te6'6oHEkd.£aJT54PbYk5v4IO(<;Q?8Yy;&)8zN!9w'ͨ~5*c-ЮTd%gVi ݠRei~d+_3KE +#lɱ鴀WϝK + +1Bauer<ڱ4vܹ[ZGuU둛Rp@M&7Puc ꘲6^F!Q4sh\*=CGc7 v莴|)Nr˪rr%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 +HR(T0u +endstream +endobj +2619 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2618 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2617 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2616 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2615 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1816 0 obj +<>stream +xY[oW q<" \KWs<֡$ZR%RVTiQAvA}O7g/]RD;;|~f"^Y wVW|?j;Νww&ךm5 =Y|` z%BH5׃ > -|#V&{[|xdzm0}VnYnx>-ɟ+6Ĉ]B\Y/TA |QLf |1^'x7Iz[ C3Dx)9ٍ!~ =0|AJlJj KApis$wq.H#ZM#8On#vB+ kC}7"=vtbȷ ۄ+-]@PFZkUIdQ:5I%8e(\=m+*ĂctVt:!H!V:sEO.LɧGp_VA<& Pᶢ)yӌRBO/))`jkKC~XĘni:+rb֫ )$F?!RɚJbDY+DW6hDe!Tkun^!^dp!FFNZD[K;e{Ğ׃S.=RLFO(P.ȫTR&l@*͑fIjhv%sײ1}4iĠ?)HIڥxHE+T˦4k,ݯsS8$'NWj!adӟteQ!+ūT:)qKQCVmYvJU7>X}A-EFU"huʼ)5<+ў-zXďǙge]b_|/uc۪/¬ " Q#՗"%ElJ2#"=M,te}BTRK^ц"/ǘ`]G#j&R{VYgYB$?Mi(6 D`V/έWfe΃JuEyC!AyʚnKr-KQS|YOS9Wauӵ8cph4ZS2Vu=dMm9p'm IznbBI%[ v?>sC]gYop~U޿ï +:tѤ۱AǗ B@T}YTs'R{3_9rnU2ejv [{u6,=<Z`3hn; U\+uz|rK|[koBph- xD_@Xl1*A5RkTDf؆fuym`\n\w\ǣ'[>ɀݷ xI-[o.rRūOtOkd=`? oMp[JA%^@vX^RDs!16??gBPs>DŽ(߰iJY'pTCt&fQ̄or 4_4lq[=k>/􃱈c2wPR]MMm%΄tdM5O~#UÇi}h`mܑ~ ^Ǭ6F0k?9Md)-{'^N30(YΪ*&j*4?rd<문 4㒽weN\r8'Еx=fʈNvCgԄq<@vrK +/tZ5UO`ͭR+?(Nj.3pL +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 +HR(T0u +endstream +endobj +2626 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2625 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2624 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2623 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2622 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2621 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1815 0 obj +<>stream +xZ[oph R;I&mh>+%KtiRTy]i&@.9{㒲 +kM9ߜs;gxplS:Q__ ay7 Ѳ&3JR˘u6sVSW:oCrʲ1 [?}s!޸DsWQ^*_Uxʨc'Wde{">vTVRƄgTUd3.{x /0:[*բoѻA;Q^FK*H_ia! >8gr!0쒶d `r|RcR+erq }[X= 8"zc_i'ylܳS-%'qv'Wp5?q"ZժkCHʋ>Ľq+FN;WZ2GZ9O>]ҡRn -h7V;[\݇xָ%T@zAgRZJAW o +O`ڙRkqc!C䄠3JZ)*:t]EjL=duI$VRM2jj'g3 9ed@q5Esmnm(}E1_F'ȓ)j )jp%£Z8b0~s|L7T%%jqOȝ[5XjқeĐ="qˬ5,?U`gNw %eڏjDJѨV[U]e\i\ lG=Kaa\PHg,o &[ȟ6~M>zT¸ݟ7 @Un16*F2|b Uf5fkglSbD : cfm~J5egS(b0v(a2IL8k {~ɞU=<= +4%<Ȧn &M+FԶTK/%73x3ޔ.hnĜΑhSj^po6þo6S뽄)֖MytOzQI@'+r]yɑ0'WoԌ¶Է6t|rxMȨaSmH0H R[G;azKi^@1W9pNeK_v$ =UI[FaR M6d+aW(h(Itu)3@vբ>Y;*M`iiD*Í ++AV [ + 2\C"_|oCt\E {:œ녒FV4kQcb@{>/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 +HR(T0u +endstream +endobj +2637 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2636 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2635 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2634 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2633 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2632 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2631 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2630 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2629 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2628 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1814 0 obj +<>stream +xZIЅ>B(3D~h܏Q.očۮvy[`dqԪE>vm~2QXͰww  34~#2CћO%`lVl >V+\4:cGf^-RV0@.}YK+'@Âb9m3Hњ'{ xDOp9tFE-$MPJjEnSVe%6C\O}qvȎ"͢R8誚274e!7Hɘ8]}/ӭ<_Q#]j.\gYI +dpYnOΚ&$xF!2+uK\'OM٫dkܹ"IcrPq.]k +y$YeK19^ +;KތV1 %X/eE ˏvegծ`{A nMW9dw@kni8jIȢVrl%"cT1! (3(q(tX[]i3k-KB#@Rb@GIҽ:#>!t3&ɻ$TrNQm*L8]PzMi\+Zah4SΉOf F>妏uۗuJsƂ.e2dXᛖim5XC|8Eh\EU}O\rޏ[.𰁣n&O(7ӻG]˂,U`(sDE*?( q]Vݨ،vVʤQju uNKf%7vڮjfɼQF=җ\E*mYP5J)ܕ;pSKBH9™_+G#TUZe1ަUhHO&/VEnp>JB<Sl pS;qJRe#ܡQXjP.DE8]b׍2겲24wqJ*e2E<ی!e} ҄w,x;$ Q vy;CptѶBy& y;kN$ 2%wᛆfU ͸")Z+ThteCìu^%[u"$i_zݹUwDOjJ[[3B We.MW1DŽ +ņuWvL y* (E +z HӱBڄ9Inժw!.>Vq?#w6[7Ggg)4Zm +\oU׾ѰOKZ3B,G; RP߱9PBfw7ٺՐ +N[{F3jX={qXmz&W=tmOKL9.xhtSmѠ[o]OZt6ה݅!FoWf_'eZk5_L\@̗ |~Ѷreѹ;*XWI..חs~ł2,UTo>ǝ K3aQj]8 +qNt3V5 ?| +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 +HR(T0u +endstream +endobj +2648 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2647 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2646 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2645 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2644 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2643 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2642 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2641 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2640 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2639 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1813 0 obj +<>stream +xZYoTIk^:R5\$ČP}ILB7m<!HyȿW޾[w1fY:K}Lfǽt +Fw&>^]wehg[nf?G_fU"{~$R)nethN8ZHyKl>ݟ܅0*o9k_y}zNjԪܿeJWy~\5U6ʤ\lȎl<N6;>m#c=dS{k:~TEhćBI/%4"E[mAtRhD@A7̶&P+iu119(wrk\hd{ :F`B)?IaGe*çYF녖I&F##t!rB^j)cEP@z\jyeEPV[@VZjqEPVAZ +{yz\7`_,/rsl`uH KwWך4W"O=pos0Z))ʮ5:0P7[횅<@vfoD}iѿJ%kONo@MhT.fض'<`G'FM;)y{5py<& u_VE5LG_CUZ $Tq aǎV<><@`cuf.d7\s\~ k& ++%. ^/-=5V-2+OoV> 6ӛ?[ pirΦwS~3yazl +-p uk&rjHu{d gLS*oh_W-27a0H2 ng&wLjɧѹ|'GCle`\>'x,lx)VJX'֜i!#)զ4<)[{1-bQKu̖Pt4 v5O꫄Me(* UAZ7-o'T##jQ^!{8bWa G\mc 6nNKHnsFwGыP>J~8_![8YС#W%=#9+\gx߅2+VbߥFϬL6dt} +qxJVa(!ѼquB.T'%b~d()CZ-\L$@Wpw(>1\pÔW.kdah&Byɬ0jgU%굂웋ʵ԰JJޖ;9O?ےWkҗdSq}u]()n ue)bwQ*v12תJk:LfMz]c_/4Bʜ_.{=QKh34X޿HiK[Iyw WƜ39'EB~\fjqg͢=Xy\A`z}p^*ez8_^1oăDƴsտOfL^$Z`n""*hXpjFm[A)*G1 VsH9:hkL4oυvN1NGnHG7y ĖLV,my|B L43Gsr!.b4H{Lr/,¨'׃N}Jm^TQN +D'b*Rd9GY!|6]vsIY{w_Os+-IOhS ,9җzme G{B6ۃѿΎ|5iKP!ly>I4voNboPYk6js9 +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 +HR(T0u +endstream +endobj +2661 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2660 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2659 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2658 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2657 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2656 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2655 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2654 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2653 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2652 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2651 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2650 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1812 0 obj +<>stream +xZSouʖ$G, j>G `M%J* UvW!z~3;=B1=g ǃpqS5*֏-ju|Y^-W(GX73|@p>!]<VSvx(2a#:AZSsڟs: ~fbb[ݹ*0C`lf dq3N@Oc +xӭ jw|Kܾ" 8< #q UHIL¦IYA͋LKdx!r( _t4A31Qϡ usR/ZoQeq|~ l:@]+1h8w6iQQy:V_V:fB{ ?IQ BXW8,fܒf{1nFbVH[;$v{"Fzo(X1lzjJL3ݹ& ō^na/ufZ:FCakjfz^谨4z|'*_+Q{rB uwH[b)ؔ @g'suqIdM$}vMZPT~vsN!mvv++"(fglC"ۨ4Mx~е[dhSf4L=QsI;;Z7;iɿϜBk並Bz]dy Ԇkt˖; r|6|:*]ڨ9-=%Ͻ]u/s, O}JjPR|ZN*4!/Wa16U9to.e͛z8 コ>ȷq2FQP+Lf,bI|ϯcZ*abi"mFN-z9uY_N76?cͩZijUOZ]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 +HR(T0u +endstream +endobj +2675 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2674 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2673 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2672 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2671 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2670 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2669 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2668 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2667 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2666 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2665 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2664 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2663 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1811 0 obj +<>stream +xZo D0b7vËu}E8LHI0i!vyC~3;{ryl^g ')N֨짷wCjuXƓ8&3JR˘u6sVSW:|!ç?rʲ֗K8jk|@pyYMbq=Ͽ3_!s˶v8^zv&?P._|v1,}ϙ* v ç'ǯ<˸d\gK^c2bTLRlX$Sre3KoRQq@%c2!G~d@&rK`5)\+h +%)sFS\`oB lQ,FZubI"8c~Z(gɛHbamig{֐j=.'yt\^kR}-mÝi!D8õ+[6_3'gkW2iIJ.̢<.+\Ցk>otr%ȸUrOQ(hMי kdz{J. uF9%mNV&-7lwj=h+Mx=^p$Aj+쪺Z>iM Ԩ@*Ԭ@!Ԩ}z7t |h\&H&xfYVWd7R"iwQC-574=Q@)oRK JP1y|{t.68ϡ_D&q bBb9jQwKdEa+h*,ڿp6At]\C6]ɦ Pse጗ipT2/ϟd&yRB!`G|Çc{@|I~'Ϥ+ЋB3!.#{A]& ch/ɭPdfl%b[",W-r +"N9Ghv,lVR!3lm4T-9Ԁ[j@ſ~82ES+4%XPe , jlQ +)堶,V5n^^ָG!IEZpɣ2FΜY/M(S f~yt.$4S7hcmņ.GY&{NXqa)ydk£{8lHML8 ǭCO;AmF|F4*#uy_c + Cn:r"bច'̢ +q#i3^Y֬;g^v.(FA +|%4Nh0]J;ʕ57 A4ɷɧmkk'JM@Y 'y#P^n@[fF0p`0KXXJJ y0Pt1F%1 Y `5z3hY{Gnx՝ņFi ؉`-+w_-[*Xj#TH 0 C)V/.0PE(br_$L;|LıaP'XኸWXu8X-„،vwzav_k <\[ŨJhث%Kf fNDS*Y)-SNf:L GEnYR5AW4QJb`4A1@YhWdZ=#FǖsXc )!^NTڏc@GdgN^b #s18b2$fo˴`"UlFâ 4B4 ]|l=Q5k<*'3ُ͜u|~Tj™q| _OtqߔӞԌr㬖0{i&l-Ozj*0Zr|^: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 +HR(T0u +endstream +endobj +2688 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2687 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2686 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2685 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2684 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2683 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2682 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2681 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2680 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2679 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2678 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2677 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1810 0 obj +<>stream +xY[En*VQYpJY޾_²n, rAKy랙d.L"KCss>$*ru'a0aVw}rVY'dEkG:何o'tth-PꋤS4Rj7eyB6%[y5|>@*S0˴mnu){s(s3_ACr:$%&9"_#r9"v3FnM;F(P%jz + i%{D}L3jxMg57l +cPfht._% +SDMڻt?R'fⳂ8& `uY0#I1F,&U5ф܄) AF!"1U<lvVVрyBIW'~vrB\jr9rŧZ +aU&% hsaG:b|#TkJN¹ {2{ԺlCE;7o:XTb#|rRX5"A\cot0`o/F3 '7(I.ŵs=,EO OH. |'f ;Q i2fPQ|]3yǻ 3Eͷq/ +\K΄o1E^bl:NE @2ޗé؉<:<U\Ir3B^sj t d':ZDy\ ɓA\}${[id1(,T8 /,uXpEͨ#kWԒQd`a(iZ,( ZyT9=kt2eNbʔrc_M^{b|n$E4BV|'֬RlUU |i#% *?}moOaӄ+&jNb9UhA0 + b 7ۚ/NuHuݧ'ښ V5Ap3L?)b)8,TRRT93‘u+LX*(*/Wyf_LR\뫴@ܺNj=-ήբ=>/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 +HR(T0u +endstream +endobj +2705 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2704 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2703 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2702 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2701 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2700 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2699 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2698 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2697 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2696 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2695 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2694 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2693 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2692 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2691 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2690 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1809 0 obj +<>stream +xZn b'i$w;u%Y@EN{ً%柙=kIڎiϣ;z +,H!Xل((5;y C|3þ&:9$Fv{Z 1s,^Szr: >Ra\Ӻo>nLe܊J *PJ \pO6vHzsvS="᪌=m1^(F^۞ v%:d_GTy*=tliIx/?Gd![tB,cr'fB¸gQ,g^( *W4pcmee!%5Ko,EQ;)1&A 񗵧&7yEw.c?4P;κ;ySWcɔML2Gz1MwbiB@=.+g)me~"Aӓ>e-KHN=a4!IF\!l[xoMw1o?ѽgWxP[2 +r{| +Jw^;2Qʚ^~&B#oTDD\9+^Ҿ/R%J! ;y{ )ʙ0qB"/4:?0>8 p78>ú-*[3:M3fe]RE,Ǫ{[튚vfM 0'L*;GdU5Yo'-9$nM.܆$n)[_PZVN;f +sqcj@ aEk!qg9;g; .ǽ7TlLf5A&ws|>&qO6oD4Q5&)j3-|2VfB[ C%_49X=ӰżQ.VmYTڭ;d|GZ cnB,>lgr +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 +HR(T0u +endstream +endobj +2725 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2724 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2723 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2722 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2721 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2720 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2719 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2718 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2717 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2716 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2715 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2714 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2713 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2712 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2711 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2710 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2709 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2708 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2707 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1808 0 obj +<>stream +xZYo[Q +0NQ[AS۲lw4-ZW(GD"0H҃lv>@{ܹ+y/IEDw|̙0|UZVɟ^ICc~ /dt1cMbMJbNɻ?7}ϻ8e_~q΅)wچ1'!>ۼU$wA$W7d6qTO6TVU+qgrJ~Pke6R!HmuÄK<9鿸C܆fwȀ 69$2#6juEw9߲1OAd{s@ ,eav<0ð^^Byi쇅ߩ^JqQZP-vid8lrø +GzPM;B+]$IXHĩ $L6p{  +h] :@k;AAd1Vy70W#qYE 8S5c\xE@0Hg0Xauv )[O^#cmɔީTiFֻJֱs@j 6m1=*zVn -uXa9:{TϢEIea00Ƥ_a%K3m\G5 {`cbUM +ӎI Ol쭪ʠnߊ⴪̯BUfB{On[h.~8\)0<,[oi]<#6\\ۿ`oDPܫTUX+'(y~.lru.9aF'0:֓p>[J* K"Ш3wBFkyp;VjFIi clH*FGZ#_lHL}ҢS4IKtXRsQZr,WrFE7*0 ̦V7YfyB"±ɤ^yo:7U\NHЌmSuϦSj@h"54) oډC=H>/T''8+oq-ThV; +5 O1B/¢@=,Ȝ7s@tJ~M>kgCM73)ܬ_>ac܇\.m{a]>*4f\5Qe+x5 {k;4}Tuc3]rekB8 Ny[\6 +pYޕ]kueY縲Бn,K-v},+w."zjE2`yZ|R-K\ˇc '5]#,{us ^˛a[o[f^kWo#˵_4+L蔀Jx)9kD2jm.LYB0C3kʹ-BDh ajL7B7KQhNԫnB-m _Ku_ Z*|_r|/Dq(cupTGUfQ(tt5|G"h ꢲ6׼K: ;JXiKJE9ڍU+ j%dŞQ0?c*XFu5(Ef+UiOf+!bt,-UnQ8(2q3ac>|:bÜ(a1:}OKCU07;Y)aqq8JʅZ,e/I-lZX!{Aʒ' 'zsXxsM߶u񁋷015)=9p[ ˹i8e5m 8j䮩N{?uRkViO.&Y$SeZn.^FlHYNJ*ZةPEK6-".b[s%Viu&BgE +֞UJƕ-m &!&!Jd>Zsvh\BSIrFXÐϧfyƾF>r3ȔϤ< +1ˤ=NN%e2N֤rc>/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 +HR(T0u +endstream +endobj +2739 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2738 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2737 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2736 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2735 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2734 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2733 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2732 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2731 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2730 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2729 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2728 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2727 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1807 0 obj +<>stream +xZ[o^ _b//ERHKdMP.}O33;%גkZfe;gvB'>ݏ4j%&?}2.ě/23&JR-K!r??t><~wZVC(e*cnK'G$%'}wf7`O֍۷X}dqys\gf7IqFF B!fB-f'8&/yXyYLbYX38>yqo' \1HE)`?/OO8(s#dNڈl\lюaeIUU]G%|_eqGp-][ \z +~P=~pSesX5ܿ;k'a1Ԅ* V)A%?GlS4R٦p+49w +xfV\t.K U|- +}]KzG]mpЋxCN@5mEqG IJ8EoxP${g@b'tOF[%cV! Y=b +k+8$\ ?ppJH6<5lx[/k +"etSAd;>qk|;P$S4vǪ@ng R*k!YyYR00.B,~1xHъ @--!r!2j=Bv#ŗ[I)[ZFp"@ܲte8xeUwLwꙆ,l0Z&:R^uHHۜxM9r|ާh sWjVk^k{T]덺:u%h'W#ۆSzp[2 H'ddrrfnNzpLT4e_z_W,Q++ >\^4~5Ě%gQe d $[V_G +>1{T}\4&aLUP@؁m.ct(b9+cJc&SgXBUs{h$܀i R ?֎4nj bO§C\hM'tk_)Œ>b7G[%aYQb]A~;70R׋ +^bLَCbRX-(F'^ٞ_\)7 &\RB"$!$(Cj7jw%D[Pgdj@4Rʔ'p9=N43%Iw0`=[H3VȰTe/gu|J9*~3fSDQk6׺}>P@%1j? !%ъ*YnU +FmNw}x5QJII:+ 9:/`1%eO1cKP3j@3o0ć!ovz$&fmJ9Y8֍.[z[voo(3QV(S<$ᴀTB.\Y N(6YLwJ0Y1bPQ&ĹgjP®f. +Fm[A:~yof c9[<-\ݍa9ogW6PhoXPZZfoi7أ1>XOڍ8StsWGKJK#Z7<vZB7ha&/=Lw505DtbNORȲ]&W![x +:iyMqWg"_#e/l;in ދ+.݅mC7`w(ɳ -"Yyf5Ѕ%pXʢA朡Ğj7bӣ(djLj#Uxd.uAGʥ, ~>Hn:q@O'4ظ)jM_OC[kgoWt'0ބ>P*t\-'xgRJ\$D3R^H+* +ЯTK6RXӯ}_H(>4Ch&5KpmzPA8,d<ϓ| pe]n`F0JA~´M4{1?F̽6svPN"|@hozS6 j.%$#>=nqHnӁbUr<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 +HR(T0u +endstream +endobj +2759 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2758 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2757 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2756 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2755 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2754 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2753 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2752 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2751 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2750 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2749 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2748 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2747 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2746 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2745 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2744 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2743 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2742 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2741 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1806 0 obj +<>stream +x[o' E I-iv2J⸑;-$vc !)VE7̄M(~+-'4yLOFK F$_ɰp|ɎSx +~oqםo~;CB^X_/RPuC]W^Mf85B5 g\@SAٺށ79|Ply INԈ^"eJkEag`rq>a$&sDԙ&F^{w-*%WSf8mbp(DռZ*pϏᦫqMT4:G >[,਀Jܻ|l*}s1i;3yǨwبKPNLW痥x󢅜{F"8lEpJR-W ,p]IxO_}eqa`su/ ]ap&=ǘO; +S+K%fZR#Y.dƴ2拍O2eio-NgUoG(2ۻW"扞{jd>M@\f rXC+]Z̤<[GUrFXZG>џ˜~;MCI5i?mrS k9/ă7*-Nieiנ%x:׷tWfߢ$ɣzHw-&BЍ4:P\v?փ~XpRJFyW>r*N S-"#i9Z'(_n+'Yv fюXg6sl4f㪪zVI?V >$2'=0Iݒ#guXF38Ji +p +`n8{e| pC`u8$wT7֌w%=ޑq lUNPּX ÿa},}e$/L(Bqj-"od0]J~I)тSӂ4]hT_2C!Id\5 $ +r6摏eQ<jp>J:pЯ6" FL4L^`P(Q>+E~y0!DXiT\H@wϓ#ҖP6;8ǔv(wx@C]*SFYgNy!y!/AVV )SѤ&K&nRwWEY9-<U>TzwB÷aq't}z֟VKkUWg҆iǹ]{;jFTפܠ3Fq_1J7ܴ,6qgZUt\!O2^Ŧ{'OS 9γ /hxJBr \ *ai:P S\qþ '{CQQVUee ]FB5 +}fJVEϷ#)u瘳; tx]iBPmKEښvSRFvZmZGJ% +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 +HR(T0u +endstream +endobj +2778 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2777 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2776 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2775 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2774 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2773 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2772 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2771 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2770 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2769 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2768 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2767 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2766 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2765 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2764 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2763 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2762 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2761 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1805 0 obj +<>stream +xZ[o `uQˎGsٹEѺII$R"%9 Ӣm>5@?3gf]rIZirٝs|gazZgt65 +O#.k7;0fXhQ0W7j_WiͶp.Ui{^ܦ+[d:o"73`Fm'2.6Ϫ8%y+&||_;Q.N|yޞjMv8TH'휿m_pI:۟?%>i2"'Wd@sGNkx% 2)38wq2 ]\am:p#/:hZ0Y$9^l?gRRTn} Ľ-9' ZX o,3k;K+yZtG[-ֆzjƩPҺ ,:}]ue9vּdB;G:OF "!4p(o''Bԇ1UZ.}P)ujByG*J S0K-Iq,e ȟF};4S=BҲ[gp֖s\@ F(M +- Tc/"G>;WG%35@[&3?%4R[= Z 4mOHx ~M\NTw$5?!l5*Q|λ ڬ"֬ U" +[EΎdž# #Rr}Kl !! V+SO ^,R[6fZU\yzt +w卣VAT%I &g5=HD{:Sj{ @Nۼ/oo+l*tx|z) ]mP)4L| + ;amF{ЉJpUh_P'(ohts[U'0XQ (4'Hu{< Rf$@m:q@~fB^!KOZԎH.H"n0#P; (+|O9=ܒ&?AI\aE.(7ͺr PfQxu:itc)03\}r/.̯\' +8 -*LrW^)`rPj+ez=URo-{)( ;Ë +Ւ;fGb*YQ +W'הJ8 +EQU,̃#pl8e@\ @01t's8!t<^];%Y7rSG^%E ؛Ũb_V's'TH,yb=.d(~;{XM!C~UZ*jRUWH%yos RT=ɒݥubFb'΄֭816in}54'W!#{\)Y#l|>eg^!'1ls2gY@WJEhg +&Iy}G5G3A@ir=yX`jZ*>TMƙv>ڗ چC kh!)54x]o 0>zYKwVzz2Y3p;C=4nYZ`T))'^բ!ڏv^g|nڶ`a0V wפu+5oE=JKC ֎q_k!f6 0F 4291Le +ཨohIX-bXOn9Sx yPI>VaIZf>+ҁ0(kt/{~j!e0IpY'TG$ Oe+1{ ' ,4W1.M wNj~z!Kb˜w[" |*r@BOU8W5Pnp4 AV<&δb[U4V| +M:Z_ byKyc26P?#fgYܱ ],5 \w05ofde~ޅuAK +jU&ֲ8"UQ<Cj:W{B^}MFJs0f#z:Wqf'PwApӇޛHqe,HH+B3W{fJ 4[un# +SP /k+O7#%5UƑ.& o̬f4Zb}%&2̖T89}QOf5~%݌8vUX`͘C!dxQ!_􎦯gц%aiMi74-NZtEʑ^%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 +HR(T0u +endstream +endobj +2793 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2792 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2791 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2790 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2789 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2788 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2787 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2786 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2785 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2784 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2783 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2782 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2781 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2780 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1804 0 obj +<>stream +x[[o^ 1"N|0 +sAJIXd.eGyH:/v}CzϜ]^KP˽̜9ߙY،?XɈh9ǧSb,x)=RCff"RR'NM~egFOx!qNs5|`jf''$fɏ};+d1qtn&e)^GjsV;]gva7Ku߿VX#)Sӊ(Õc,޿>~9<5{aYJRTj+n=Ip|gr$V<1Q^ ']l9Z-(sF !+62֢ 9Y3u&#rm +E$qGvO^"#1Ydg Bߢw +#Mqt;YɵjH0 TZp= u=A: TX2M{+t%!p}x(aGBw\2 w= % +`<(c 7휸.ԋ*R3/_WifWIN2G5ڕSZƭn_Yd֔qJ xӼAy|uTh\e-| u+@8|~ۃHAxٮ>v"}®vo^E%ݕvΒ3ə0hh);`t9Tkt-h%8 HR>x ϋпC&-mi#8@E1B%E\ K/ړa%x*c4C2K|v֨RBxk<@-EaZ`1fQB2Ó|RU1 +21[(85^(QZxHW5[r04"r$[oEw#Y,+yYhum=6=|܋隢%#9sͱ o{Z|:=dž}U/߳WTZ <] XcWy EXq OkIhRy k&ޛogu:M/3[U$XJa%Y j 3PgU--OD7~s^mC5*hU$R2)XeS eo"4s ߕu`eQe1:ZKf|\Wzh+TZܥAAE=)ĉ ,[/U]$-6Xh$ZA +l]SM^ cAоa.$ RDBAһ,זэA;5֑Ւw *RK콨NͤDR%oN/06"!Q h' z}u\dRNNZ磤-kY qӒZ SUJ PcTU02ĥI`VocRwnUw5I' +ɹ1 ](I-guUkKO 3|/Y#5Fl-" v=WwPo-q٭׏ğA4.CyG?VǧF/I+ _c%+$}o&*`)%\8B/+[`Oo 2/jú}".KVgKs\ެ+JcEɴ&*'jV)Aqg,t 0b\m,n/ÊbwY@ k],+YiW|":I(5顥+NwdM)* >Q?܁uw8q7<] G$sP9)0.~+qqԠ_*|SY*vUU={x P9zkќ;"SN&m}~V wbې0Z7áSVI;2ҫˑ^%920`e_$;·S!'W쫱9 9wwb[8zH/vբ"VKi#RD*#||AZZ)J7:!:B:%Nb1qq3kf;h]mo7?Su8_;1rxA*^(\E0l&)U\fE1()6FPA=+T&j#wxcC2ǽ@1fKz˰bcdhAVz0%Zi8:7'!`wL(gVA & Kgm[kl$ ZU+]BYW\. [[pz/RK2$ +~). ZNA';<l/`QZNDf>ʾq0)#k9o2|W¦H]*JW\K|ZZT;٣. +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 +HR(T0u +endstream +endobj +2816 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2815 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2814 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2813 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2812 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2811 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2810 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2809 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2808 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2807 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2806 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2805 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2804 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2803 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2802 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2801 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2800 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2799 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2798 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2797 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2796 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2795 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1803 0 obj +<>stream +xZKs +J*K$R +G1]hޏ]H.H >$)Uvr!?==;v 1L{z P+-'0yL‹'/'Z +b(5LQDJꤚz1/?_:_cq#qNs37%|`hf RkF$*oleS|u )#oV]}ríI|b\̿5IN Ǖ\|<}uÄ ckrq3~Ur,erKV9YqLdsxz|t( Rhjx<)_䜂1Vr̳dPx bW azxր| %;Vqvn & 9 '4)z G? ߠfwWB(v=GV~1#H "4+^S8 }3)\{S0J>^]|4B1~NWv.f(tb4700*^(,5@fMlզuP9@J O9L . ;4l㐿5u3ekc9(VXh@Knoz*==5B޷`)h<)%PJ ;ӃW. +{q]3Nh}Bq) u(mrY?%-a +GܻPC1 +Bڨ7Dpʹx)X,jݶqyp@CmtZLXκ9o"K}EY]a,3eMY֜y^9|7y]AKRVZ[T4-#tlLq3$%΋:u5̙F:bܦ*Wr d]a +t&}5VPeJ + 19J pUYTwt2[0X@E?~13w]QȜ :4勋"K{Α02K꾛o՝n7f;Yv=@}pgs YuH";(b{|,9O)Ԧ=# P[ $ +#ڿ`\`iIȒj]ʩ>9-VҲVAc[=ѹW`%r%|uW . c\>뼞\c~S{+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 +HR(T0u +endstream +endobj +2834 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2833 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2832 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2831 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2830 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2829 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2828 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2827 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2826 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2825 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2824 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2823 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2822 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2821 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2820 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2819 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2818 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1802 0 obj +<>stream +x[[o TNФ Pðd= PAJZ$e>E@>?gn;!̹̹|xDF^/IQ~P݌_pHrV(V#D96\>csHFዿ~ЎWB Fj7zLMt|w] .o7Buz;'U9;Fx߱U~I>-[ +Nr*Pb~?|到1y0Z+³`CcAQt&N"[KɇgRaU(3Tx_MߜS4h~5|.|nv.A.Wp{^~, 4^pws &p>aOmJJ%7@F@"~ߧ (VԶ}1a-J;.98os<+yZD'{_wfa +ϜNb5B=RaȧMtu!0ך̀KtߧB\cӯ]>r.sڧ?Uq @]ӠS⥣sD;##ŲLI#SPfrtΆ-yQ $0J++Q / p7 Fux)jtdNG˴N5M/R(^ʘ ՜{Y07 vMK+g2c:r6qTw vSn){ѭXu2t@ +t+È7!s*T `+,ČBK!ALz傔{!Xe١*,.>"Bؽ}T ,\XӉg>KgADzw"wL8*CYS3K+FT6G sBfF7j*|#96wߝ ddtrO.mh; +[u +8L(` M\Vf{݂j%XXҞ๟]uoc_ge m[Gl[a2Q$1+gUN/w+D IWqr$(kѠ@l E +XxfqDuSxp:!g7@FZ9ޘola` S OI(]b&tX&N,o*ҝǦ7gKD3(eLU ŹN{( Y/[ӿLhRf(F1Wݜ8.e/6'2=guw5LnU޵Ji[ze +̰)ѫ u-:0tu(-OkQ8!$؏pɁBr! F7w +p|q$sMjE87>chAƉQmAG0Iau#n؝ft9z{(HS׋O#qƉjװQ=Lrь״R8iA:9Ij_XڿtI #zS($2GИ +A5j~ +Ƥ"HJz7qz*[ i;a*4R鹒jW+iiGI,NvweIw8fA}t9i4럖I^2%&@e4qVf:VreU+5ol^xO0j417*޶] _(y|ںi<Um\&0fO= '7|2i96Ali='b LD-Gjʓ\6ځY#T1FihVyYK@Pc{2ti; _Yd`.ciNiH>m֞R6'ڟL>F_Q*uU<ߨ=\Bh҈{MQ.,e%( Zt,"af"H}w ^\~JBP#FIJ^(~a쿷 +i!]LtSC 偺FVPA>zvY.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 +HR(T0u +endstream +endobj +2843 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2842 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2841 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2840 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2839 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2838 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2837 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2836 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1801 0 obj +<>stream +xZ'* ΰ]hIjt ] i?@ˇ(|).P)M ^iQ~?q)'~ΔL%3E*JdE__4~f$oC{2-2 j{n4apyDγ|WnW_Lop.~X;wN;ze4gŰ{28BR3&tz~aUzq;ER$d∑/82S8$#|'erǗArw͓5^}K9M&p~\F~ +%ɟ1۳1ְƑrLdbMȞ=8d9rň"9e"3 }!caj`mN.IZ&EgYJkFe)UA)jf,(\ΝFBZ3B^{G6Ku5!(%sdR_! mQ0t ^{3_T^DݗW@:;IAu6<$u$ӛYyffgTdBI؋o1[a +7m{吨g^Yn'Sfݒg=(#lDp3sV(<ZD7o7# Y}hMjF pwW mE +/}Q}zUI3Lrޗr*׹W7䃥zThHKL!,b}ea/<&uhP0 +҃}qe쓦@%\4K?.$B:[_Aܭ b4 gɵ8n:TZ#YlwwxΌΌFzK:^c+=Gk>Le9:v 6Oey]6JtD2nX֠H<HommDx3 ܐy`jl(.QskȬ: dk\3\$]xFʼY/K5uYMZg>x7#9S\\ u8bU9IfKXL}|$g|[ H~5, =J:++%] d-cRO+G&: 3J}'rS +?賃) +.m"v`?bҦMb8sލ!yu7蝋(~AɫH# 3GЖւ#ur@?߲sdz>k$nZbe&vi4%]cDГA>{/@j;3^[Y{4fZbNc\X<Ì^q t):wa;vޟ:N>/;0kjEp5~:c}F*)R}mw^#lZTȒ9/=ڷvj{tgKe"*}.9}/-!(# HqI{4x=sߗU1s~EYhTq7DPUD!&j⏯P '=m>ţB8 +D :]Q*Qty+TqT ^S6 .z#吠VTNuÌs]Y<#1f/-kпIEυw&;r @H +ūx3!(n4՛3/e f966gs6qgL<[O ;\DLnԄJ6F}tجW>6 x L0K[b7W<y ;FMFxe(/L]NzU:\G]H3ʧ)%nn3ȼtvstIY41!P  +x@ YJҹ@BE!O}]q|{r;2!S ܷU4y(UC: d:.O18j*F3mxU^Ei@q;>%T>6e*LF48}xfϱLF֡fA$ѣtmnph+7Zc'xFaG ۝-shm=)@ჇdLhi)ܱA=RL5Rl>;iVNܨ=8AAa8/%lwF͘xrgٝGiB3@%Yw=ӵ(y=i7Rf"5ydL*ηx9ϳB~ĉ^xm'kw@o UnU! +BY3ޥX'ɧyIƈw'8`e&'xLR~xRҌr}:0EY5V|V-İŨ:~Dyyן @#LyHܧBwHqg5aL؟=W=:pJ\62s'1;#lH2oQ{K} M^@&7;O貂=)>3Y_\6F~\ΉTڰBg1?U +!qG[۬^%g7lO[BsEVw`?\b7UMiZ Rmrِ +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 +HR(T0u +endstream +endobj +2853 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2852 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2851 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2850 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2849 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2848 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2847 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2846 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2845 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1800 0 obj +<>stream +xZI."#*վ\.3bF$gIcE +`%u5Ō#J\o_W ËS:Qw?xؼɚ(I-cYMb^C^LJ/U?c~s BPͽqxp ] Y]d.;_3oo5&_x-s+̓}rTk˛+3NT9*U7/o.F_V\R ĒdJܒ%K<^ 5~k#|_Ӛ +*Kt(^ sJ~&&(q WfR0߷)Q)j}F&A;$ oYmh-gG-Uf\XXjz{!bE*::J/UOLF1gb R7mϒpj-m˭h e9+ PEb"g#qՀN 8$u +L1E|keQSN5!PKp:ErSCRZm?^ 48x|# *`*s&.1׍71+kT—Exю?x|x{  {d` zy25ls8AU4{xNF&2uޡshK p:96"䄴1HψZc%x#86b@Fopi}Z!ml 6Æ:% Ć99Mv:K#@ Zۅ10mswYw'pzAGiiw{L뗱p-]u]vp +ZjgƩ )՟Wh55\!sXx[*w,Lv/iz$f䋺ösP3J>ޛQG-p7wKL| ]ggUpN&n +B 0vn=&3$;[ dkhQeqPPWc-ҤNyRBu1]B'@]Njv M)d'օQtg%2sq-If$I#0k (#1OrO\"e`JQH]lqc$"ΘzM6anMH~l3lKpȣB`Ѕ\U񾊰kaJ5^k4b6! +&bviPiDB>q\ ۩T~zYŬ#V2_)hg0f+eO/F +׽qd dc8Qz[{yDeuuc멂' ,mxz%.|(ӆ1CX]i4KN }M  1 +y?'w1 $l崕0~XL +^ÿ LH[Y-aެtnyȽYՑ}Xc,%`\ *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 +HR(T0u +endstream +endobj +2860 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2859 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2858 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2857 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2856 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2855 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1799 0 obj +<>stream +xZo? T؉qoER-H(mQ.}ޙݻݻ(;6-=YNؤ׷aˍZ?ގZI'ÑV%\6zb̅(9k&󿱼1>mcYe虻^43HOMrb1L:|M+yNlEo10+g%4?c]+- +&Ma&*L_ގrlnك({?\K0+Γ.!f7tv{|eْN^gs6z2XDn25H+\:_^8I%9P'c 8ZivWft5܏|/|ù)|=3xVXfw`$nYi6\l<Le'Bx y'*(W\ XFQ͑W^`CRے_ӕ-BLx*aYWt =sDn\YptJ3(I<@87Adtϔށ[w>W8VGܐrV>'rr ,q |!cXeF<>9 +n`<~ޑkϜSrm+ކ( q~쯐HGl;A}5F(Tnʑ_d=ziN`^vn-0{ mxT!_v$;s +#P>.URR2%<ҙ4't2L6V5xL" G&/l k??P VXU_zt3%F&L-D,AG\򜁹h,-XVsErb$Z0Qˬ1- +Н^){|G,ت\4i6[#!G|CgN9|h@FdjUGL]YiQ2W0ZLԁnC=x.[ЌrI* +27eay#?(g]uhN8dD ijco] 7tjћS9XC}/ؐZ[~dI)%;]HÊ֔po؃I@xzw +0d$Wa^Ma{Ԇ&z4gv/RU⻇3rhp- Rʢ u ” )! &h`݀dM칱CN +Kcgշ9M2.i,DtP(i1 +ڪX6(\tYQ +nӤSvs^'@+Ы,̯]iu0ϥ74o8U\I?BP܍֚zqR%x}GneبeY+"Q=ol4tpPZzCUlH5zH*F#2+BMQҾm0ZJ0iEpfE}r=r2 3JS4?ހ?;+嶵?:mW/SܧTuurOB<3]kh:l-*mm]ṌtQ/ppMhi/h^@6: OAk$;OVF6ZX +O7GٓSx=lJOTq쵃Pw0% \ݔw#oߣkRuPDβoϳrO]"ghY!pI]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 +HR(T0u +endstream +endobj +2876 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2875 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2874 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2873 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2872 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2871 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2870 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2869 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2868 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2867 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2866 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2865 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2864 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2863 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2862 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1798 0 obj +<>stream +x[[oT T6[bG~iH)K-RHڧ"=sff7.wC:%r;s.s.93!חJY댖8y7;~j)2CfhʤN/,? п~~p-x!q)1o3x̦'ʏHJ $(πXf&ĥۦpgUv>U!\uq\w1 E_kϘ̔!6qeܾ8jD3O!dBȘ~Մ\ܝ<Y4~'F)|wOMa)\3| +>q%/`櫸gX΀cn1x3 2<Јb2'STAKI>ȍ`%>w Z󚲴#P:9y(%>%xq[T%2'1 +!p]]rdk1([7c}u~ 18ˋwwSwP)Pa?Y (F+JU5?j|M=ָf>ʀ&Fe,*DF7$K6R(rw C<%6\X"AvTw'TLi >;a<$OӞTfQ&]w;+uB0ɩ-@|Ѐ  Xs ׫IE6 hqyU&}[IPEҍ2!4JeTu,֜G ep+ei;Bx0:Ǘ!)¦[=+0W6( mS 2'/yV$@WHv.J}=;+|l]<k1^łiB8rJK^`>ׯ%$SL^xA,| 4_u) Kg Wڄv4`WY)TE_9}/jj%-/?;âj +%.2X$~">63YTB+퓈k|جdXl%wvoBXT euV"S}XUvsK). uxVŠ=TR, + D.2B!Ѹh]zwzAD3A< ;'**ǵ[+e'm^}\JB)1uMfA!f(:o[B(8 J:уW\ENUWAh_Z:ڨk8mqvj3Z +>xد7 7OciF<_3M IB\qe1x_@>)HFee=%y$Dh9%4"dN)WKm09eU rgCbQL1_c@ϗ2J"Vϣ,dQ,V[H|U67eB& WٵÁBݧ:[\8(yD{6R*\/[%)7 XQ.[bOiocTq6\rƺ<-k }((N(.C~>+U*Gy]J%+~|[UwJQO-}Dƭdw'>^C)KcO`vӃNIOzjS6g MB@ FMIN ېtw' +'j})ܚV}o} [=Vo<ƀsCsqwaNy?q@a"eݐ+ߋ'm۟fBuk, B8=l|ZBQZ* =Lkxޮ)(H0%LthMM|M +(\p ]J $frrӀT[X[,MuqG0p9%R'R]gء=%C\ 8zkg[uG`d|/wK+NGظkߒJfF)I&p)˼2þHh"5&˩қ852 =i߾i%J8L7H$i~kL]yWVh mn<=8F7[`vP#Ն |uxh"֗ω$6N: |gsp# 'h31Afi`jˍSٹ! ]( &K;c/3*NiX`AA2ƢWh+'dLXusTR75HOvWɚDYkd^;F KuYxe,Bwƍpt@w C`;̗/[HrH‰o܂Kj]Q`t'AEՠwoY9Y'=̏@IBfM!Kl辏,eC) =UZamw4'Y{vxwpg2;SE<4@u,=7M36lmԮ;2B)θI}QЁ/bvꊵЅFjQZfB%#2؎xH\?u5&ihԼJqN_{Rь, /}Ŵϟ=UkYVo#,(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 +HR(T0u +endstream +endobj +2894 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2893 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2892 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2891 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2890 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2889 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2888 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2887 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2886 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2885 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2884 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2883 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2882 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2881 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2880 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2879 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2878 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1797 0 obj +<>stream +x[IoG.72cċd> +˵/A(J!lIIQ8;@.6)VM6]R3WykTߏ_jY}8&3JR˘u6sVSW:E>緟)~zs!8|}]9P>">| Qx[& n߬NkQi?v^v]~*Ƶc.*3R&ӜSj9|׽<S}8o}$~|b sn>__}qYLݼ<'OO7&fq&̹VveT.٬ m{l>YhK%DRz\{M;sŚ6x u>Cfdy +}|cDS|%.#Z,-*( H ,MfNJzcqjB9oY)kbMi*vPJ +>#jp[&5u٩sԑXAu$?:VGS3Ƒ<+q +.R=|'a%zo/+V[ ѣs\\Qj;: X>v{JfR8SF:W d_F.;t5Ds%nj߂R+0>50L?Զ>l^e1BB](gj%/#cх/0)AP J :EV$ PZ3u(Rj!*9pfVxeLi b+'t/d6n櫊nFu_ߠ#j'fBl !liӡ(b/R82ӰQ +%=núGj&A{<\rc½“xbuG;}i-wfZh:;ctk73jg(ɛܼ6(cZ:ӍcRl`u3*\nPy Z&X lZ{Ū0QZ&o麐}zQmC4Rr/;. DGstV nbƻg,߀+X’\7mPU>G;5V: +Ӂ4y88&Ѳ`H~AgmE:w1,sw6+~&-SwXhp3_a9ga]-PK@^ ݾd*H Wܻe#H!EL$S9E%SP>!a%[*"2۾֚S-Lao2aT(mYpdj){0/'}:I/\;=(wM@VgS f#_A`?jv=g I lPLld #12g.ϖq!7yVj`s[k2}xgQL[r`Z=̘cl njG -'.9ZUI/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 +HR(T0u +endstream +endobj +2954 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2953 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2952 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2951 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2950 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2949 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2948 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2947 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2946 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2945 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2944 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2943 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2942 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2941 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2940 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2939 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2938 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2937 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2936 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2935 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2934 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2933 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2932 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2931 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2930 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2929 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2928 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2927 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2926 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2925 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2924 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2923 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2922 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2921 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2920 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2919 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2918 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2917 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2916 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2915 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2914 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2913 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2912 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2911 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2910 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2909 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2908 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2907 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2906 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2905 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2904 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2903 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2902 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2901 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2900 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2899 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2898 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2897 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2896 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1796 0 obj +<>stream +xs85o KR>0ݖW-ɺ2!IK40[.eg`?}d;l'}c'y_CzrCR](˔iG3$7o{sgGR"M"IdI)U),߁T˯0gJd;60ͲH|NjW eaE憭eWQ<.7U;~ȏYyϗ[m2R3* \"̒q66b.Jb%eUtIT~a"d1Yx#8:}:~6dId%p}<#O^/W'nQK+͢Ln|%_WX?%UDJ9K]k2#6#2&srBnagn̅T"4YKS~Hhc>pSKb6yQ"c>P@f N a4 pϕ& `.lbݪ"~iM4H!1dAY"MDR70pfjuIwv@۞DKTwQJ,b-?yM~)cmO=5lCIjn?mzXL5d ڶMdRSK1ZS">fY5cMˑͭmmӴ#>mm^}-hV_jՕ:C{=|ȲׇRtIds0n^?mz!ρGC妘%튽ׯb6JU×OdOAy_mz:^mK+uYL^^\\V`仩o(Ae)m[+&3zM^ dB SDHmRnUl{^ ZC=$钞O L `qF.nk<\Å7zm 7DOUF< L%+aJmwӶ&ZLXrM}fǤh;^2V* +`ZRѝʸ$[3Z'5fhi59.UH条Vɠ%YeIGq6JnBM; 3seuem+0Ԧ*扃KXy-hm:f&tm1Vv;Q z.T6Vj[pzx!?A(=W9m~qb^ݔhg~ ?ͼxfeO\P4R1~9R>0 +#eR{en˷KC­2zѽ2vyoD:V.BHd\L4r=K.#^"pm)cܣGؾsetvT:RvD+c#݉s[U辏{elŹ2^;q]saicCT*!CJPH[!^a~9 /@b=Y/=RGZ͔H2}\Ye2-g)ZuQnJ(2SCșn\?{wo4b"<OM@.&lC0QJL<&1aD +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 +HR(T0u +endstream +endobj +3041 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3040 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3039 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3038 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3037 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3036 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3035 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3034 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3033 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3032 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3031 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3030 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3029 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3028 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3027 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3026 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3025 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3024 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3023 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3022 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3021 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3020 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3019 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3018 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3017 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3016 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3015 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3014 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3013 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3012 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3011 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3010 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3009 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3008 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3007 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3006 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3005 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3004 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3003 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3002 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3001 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3000 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2999 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2998 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2997 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2996 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2995 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2994 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2993 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2992 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2991 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2990 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2989 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2988 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2987 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2986 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2985 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2984 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2983 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2982 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2981 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2980 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2979 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2978 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2977 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2976 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2975 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2974 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2973 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2972 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2971 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2970 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2969 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2968 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2967 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2966 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2965 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2964 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2963 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2962 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2961 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2960 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2959 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2958 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2957 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +2956 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1795 0 obj +<>stream +xoF7@ +z5-l#qIfqOFG/o,3"No/J>;.kar?z-FgFICMjT1kR#ҏştŎ[m=cﮒK2f'RFiҫtw)3&ӫ>&/+^>_$GW+76 X/xCI1S)(CF  K2-]HvBfLs#yYhF͸aQ}=9/DqOA\_TJ.S^7 1ud/LgBk95bZD9G:&ݿ*pb_^+ٌ^XB&Q9$U /[gs|QeCa`iGo/jtQ37ލYuvیFXԪ.z^,%-x/WNC87pCG]46ʈF&NkEV_!of(]6Vfw,"H˴x5& %ML@  CEaQMإj|q QjRfI"6JF}Oj"t`P#F:]yԫEuX6㪁EKi4mF:s|>gHzg+gQnRv4jHY%Z!pF]O~])WGJĂ͸Z`QE3-8\y4ʢGb'0G“}dlg98ݜ. K>vY Dvͷdlc+<N. TMp2#>'c+vY DVÓNY Dg5NDÓuN9DVȂ5N9 tBE'tCW “d쪷:{ה]?٬i5US{dl][X+ؓDEf$SIcZ0!\j!Y%C&֥+4iq3?t@.&hk)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 +HR(T0u +endstream +endobj +3131 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3130 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3129 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3128 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3127 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3126 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3125 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3124 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3123 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3122 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3121 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3120 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3119 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3118 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3117 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3116 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3115 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3114 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3113 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3112 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3111 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3110 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3109 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3108 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3107 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3106 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3105 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3104 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3103 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3102 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3101 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3100 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3099 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3098 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3097 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3096 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3095 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3094 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3093 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3092 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3091 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3090 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3089 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3088 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3087 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3086 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3085 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3084 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3083 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3082 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3081 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3080 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3079 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3078 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3077 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3076 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3075 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3074 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3073 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3072 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3071 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3070 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3069 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3068 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3067 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3066 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3065 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3064 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3063 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3062 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3061 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3060 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3059 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3058 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3057 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3056 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3055 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3054 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3053 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3052 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3051 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3050 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3049 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3048 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3047 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3046 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3045 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3044 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3043 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1794 0 obj +<>stream +xZKs6ƌn4(Nqhڲ(~ٱsh:u.Igw"!J$E ,yc4gFI*Nf{JJǡTih%BΩ"gw; i﮽_-EQ(=f:P9(|M!zmyB$x+N1"λf_2+[nn YlEȷٳ*ԊS&4:b \~>;|8t6b*|޽"ɘL{!WdDBM=\q GGPrWCcۅ#('Ggp%=#rGW"wf_fG7pfHN hOUݎd*z(ޭH%}:k׃i4ic-^ێܟp4v-Z@ْ;C1==iQba;PPuvbf(mdH'?uek4{{D/~{|xjB3X +-|03My.Wvv~rv aĎCxu|9#B6l[e*d};0|+ee*rz 9':<Ŕxӳy͗0-]8'o"ٌ-MܕPh&dS!P"eGq,&,kW2^tg^+f\a +I%WѲ6=vBC-_4]޸I5MLz46[ / IxR9/ʥ۷תt,] AJd{l6DXUPS"[ط.X4Ϧ,"DmDW$UުʾVYBC} :Q"[Dط.+X(7w"E>4-~ >>/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 +HR(T0u +endstream +endobj +3210 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3209 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3208 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3207 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3206 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3205 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3204 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3203 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3202 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3201 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3200 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3199 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3198 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3197 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3196 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3195 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3194 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3193 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3192 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3191 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3190 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3189 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3188 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3187 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3186 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3185 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3184 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3183 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3182 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3181 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3180 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3179 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3178 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3177 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3176 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3175 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3174 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3173 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3172 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3171 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3170 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3169 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3168 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3167 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3166 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3165 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3164 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3163 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3162 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3161 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3160 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3159 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3158 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3157 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3156 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3155 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3154 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3153 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3152 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3151 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3150 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3149 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3148 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3147 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3146 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3145 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3144 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3143 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3142 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3141 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3140 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3139 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3138 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3137 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3136 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3135 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3134 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3133 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1793 0 obj +<>stream +xYs oVj'q,c>M( v\$AV˘)̗Y"~8Mou7)bgLSddy"_1gI/u1Γihx +=*wּy_D?wH 5-7]rt<,x0i(.q13@y +p]w53-XcE?ǐ^$SJy,L MY21 _ho!Q$4oǵuuH 13M5ϝf:1 )/0'!5$3ךS16Diw0 +Z*^&e ]ѻ faY&WC,rml_fұx+'^CvKЗn00wBM06#frhh `sfJ#!v{ldʴBc\%EgB?ö)DNk4Uܒ=rcS + +bNj&WmV>Im?~JJ^ӽbXi 蔬Ƞ3jKFIg4vOPW&NxK PbbAD%;Z9!Ft0[g.VTWr_Z;_c$ 0X;DwƆ#vz[ayRPPX,Y+`/]>_{sW^|l^mf&Jf>.>">86Ъ+gQ>|="f<7ڂzg)(+2Į{{ +GDe\d}InC!ÈjXOx!3>!$ھ@6Š l8sQؤqWC'5 LtߡZjC> ,#P4V.ˠ̻npר-EivR /:PB `]ˊԀgs|w"B)/. Ž,~W, EALX:?zDI:p&@V3*n>Na|TOb?5.?Wŧm"MrgؐiR)]6ͨxii@lZW2y0xPdM] (|\һ! !͗瘵H41b ▫Di%ZU ^<~[HpĔ UWȕkI`8swx5mSN\C+Ӧp.4"s/Ca{dCm6d#o ZtJ6T}b!~E I&}Άغqpݖ'EmҗWH{E"8SuWw nZ៑VU=Aj7] G(ݑ)JӾbůd&n,wS߷6#פf:*hcȑA/yUgHRQw+P6G7ױ$_A`gcko~?s:;)x"9ؓL{XѩUp(gC٭YQA0@ғ%恥% HSAWvB1rFɺҒe!9PW[vsݤ.1ㆂrGBDgV.E Z~DV(7ֹ3v//-5&cDtcMi vBB3 'A$/̯-Tl4/M=[օɼf{ +C\? GҋwC9!n~KXkUOK!sӎS='H\ /(60kkm`a dZ #6ɒT\jt%3nC=)Q\!tV9+ޮ=htjf$P>#F,HZ !YPE: +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 +HR(T0u +endstream +endobj +3216 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3215 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3214 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3213 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +3212 0 obj +<>/Subtype/Form/Type/XObject>>stream +HR(T0u +endstream +endobj +1792 0 obj +<> +endobj +3218 0 obj +<>stream +HyTSwoɞc [5laQIBHADED2mtFOE.c}08׎8GNg9w߽'0 ֠Jb  + 2y.-;!KZ ^i"L0- @8(r;q7Ly&Qq4j|9 +V)gB0iW8#8wթ8_٥ʨQQj@&A)/g>'Kt;\ ӥ$պFZUn(4T%)뫔0C&Zi8bxEB;Pӓ̹A om?W= +x-[0}y)7ta>jT7@tܛ`q2ʀ&6ZLĄ?_yxg)˔zçLU*uSkSeO4?׸c. R ߁-25 S>ӣVd`rn~Y&+`;A4 A9=-tl`;~p Gp| [`L`< "A YA+Cb(R,*T2B- +ꇆnQt}MA0alSx k&^>0|>_',G!"F$H:R!zFQd?r 9\A&G rQ hE]a4zBgE#H *B=0HIpp0MxJ$D1D, VĭKĻYdE"EI2EBGt4MzNr!YK ?%_&#(0J:EAiQ(()ӔWT6U@P+!~mD eԴ!hӦh/']B/ҏӿ?a0nhF!X8܌kc&5S6lIa2cKMA!E#ƒdV(kel }}Cq9 +N')].uJr + wG xR^[oƜchg`>b$*~ :Eb~,m,-ݖ,Y¬*6X[ݱF=3뭷Y~dó ti zf6~`{v.Ng#{}}jc1X6fm;'_9 r:8q:˜O:ϸ8uJqnv=MmR 4 +n3ܣkGݯz=[==<=GTB(/S,]6*-W:#7*e^YDY}UjAyT`#D="b{ų+ʯ:!kJ4Gmt}uC%K7YVfFY .=b?SƕƩȺy چ k5%4m7lqlioZlG+Zz͹mzy]?uuw|"űNwW&e֥ﺱ*|j5kyݭǯg^ykEklD_p߶7Dmo꿻1ml{Mś nLl<9O[$h՛BdҞ@iءG&vVǥ8nRĩ7u\ЭD-u`ֲK³8%yhYѹJº;.! +zpg_XQKFAǿ=ȼ:ɹ8ʷ6˶5̵5͵6ζ7ϸ9к<Ѿ?DINU\dlvۀ܊ݖޢ)߯6DScs 2F[p(@Xr4Pm8Ww)Km +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 +HWr8}@%II]3θdMyu6v\7 I -+_32_.dGR.>Ah#Uz4_1*UnGWQp25'ԛX44vǍvj" <^-xLfԳ:7~k='ԋ4Y_ + y, Ujyh֯Kd(po!D{7p⏻sɍS!b36ꓘOSCbaN{,"^*,ĘYr#FT]δ$9n~@8uzY-xRUs;QV (u!֊c]7Er1_hE~ɵT_\}b^RwyZ#y- _D-aپ!J .z/ e(L LJ|뱙y\CU,Nkg{Jq^̰gzkyl#%ۚ\G7 >ܜn! (.Cs5"TyY׀R \G׿HL&B9aTu`4bu}aJ@zf_e{F^ A:) ݔ ˍ +Ũ` +qc8AJ԰͞,K/L.,21蟵!IcU@+9$PC9Un`ić8rGL؉ɴ +ak j%ͿBa%CcLVmDr/g;'uJp暀vEs[/qҏ!`S3[W;8wB:T>2|>2( }kp>re9&J; qv{ٍ}"DMOw}#+QT/^6Jܾwځ)9w +(++Dfzuq}ߌs^|4#|wy%*^􃳓kTӏM?r(o@fL9S3gLsENC6q|mrbtˉMc,uEV*ZT>ԇrC,@m?G>sm<1֍'j<1϶[x;oAf~^[]laRba\} DOR K-]j1R K-fpVEuF*#&M? 6W-j1U W-{U(w*xe7@zUWSi[iU j pW}zӮw|/=~twu{R<5SFz~RV1>nΕ+%_n`@ fX jo%oDkh'6v%x-yDC3O4tL#/џ,%ųYxl#p4Sf͔2!Nah:X57[W7v~tw^d~y!wVz%0I`1I>IUKa MN\dOe9,6ݽ3`nc&b­ބ+p KXLp5L5S S t5L7 ӭV?%]y1UjMR_' Lql"5Np*QC|uxާB\ r5jFѮf PO$5ܦfÝ')QŘ6nz;5`G'LkI1fc<S%Zb~OEPË+/'I@`v{M俪lVp +p,޵*se~ċG{s;I`\"k){GcQ'[{sZ)˥,8 +@M!5("|~$'a7i޽~)ߍjGv0.yx;3oy9LT|Ժ{Ϳy򩝙 '#wݭ՘DŽ.M9ԎMO ~Zgv8!>C白!dk3B;'sokutS;t也vO6\u|et@v@jb's!t : R RkS&H&Hg4(W&C}Z AAzJ,1#Wڜ^^Lr1Xd^Xn: 2 2kdS66fZ+kioe)dxd'u <|~"TVd'Lh+ϛy`)_Z:']b dNK-1osK4QOў,F`-F`#2CXاm鴖~ C~c`Q^k* kS +<ЪmLSm*;l*{u b'!}+*@k;ۿJg8!6Blh#>'Uo7=7~Ǔ: Jy3@@@@CN3ިr=i}s v jv u -d8+E.~QTZ"eO|eJT| \ cŶ gL +p),)/,jUfM; s6Ty(Ȯl|6~ް׳*'YL%\<4'9Yȵ<8k#פD?Az9}Y>% +~T7 LJ2PZHX UM\V #YS&$tiކWaU8SŏAkWK)EKZqa3OxJUYƢvqG9>%A8I c=+P-B~G10F5p_ lǹ(|[{Sfaɜ2G&X|n<{ÓKqzvn -"CʥN|YvobyV挤_~h# &ԯgQ}y8;ܞΰSźkdZ62@5)~\s\&3uoovR>LTweC9-9c" Q 9AQxH79J(i4g(@y#u,:vW]U³KFWޏP^,$j}Hdց.>mL"u8p Mbԝ|BnG4<^r>fCooϦz^ɷH΢H˩X2@xH#6.Zg%sp lyZ/4LZ@JzMnEDNFFvv_o5><,󠱙x%P@7gXW+rD0#Qo+(,5C;CbbnT2F +{Y$Br=ilFn \ΏL8cf:ctZ%kIz U%#zCzkCӏhP@xАJPK,Ab::ӵr +pa&%! q8ղj_(ě +UC>lx.3xN?Q4ŜYu7w<4%`D[E8-!$7jxBZ -`Jx:͉kz 3 mЇCW#gD2Zu(+_&.g9AD*nL'd1k|5B# +7 s4ON Mݜ]fs9 НO+n٘,ClRf  ';O0#d"^{4Sp-W'^PX"(cM=1L|D%<eN.[N4hp/Hǭw}֭;>w +Y-]swjvQjۇsR%n#K$ވ(Q44kVO]}ŗ]1y יg''N?s?図ˣQFM4Bh5p 3,kѹ* +U^Xzw?]fF<Ņ3-o5D@-{#Av3xk#$o&";Þ&/b vZGP}h`E)!mL"_?w񷫳O_F_;bt|eoG/>C-H׮5[h݄Q4v#K<%[?D,@A s::It"@Þ+y=R ޣ{nP\0@%%'Dp}3R &,tLtč b1|7iH\E֥x^8zݦ!w?i+œ"k7tw/Nͭ۝zgӼ3Ij&[y3ZTA#Rw;(-u6v.LZ?;l/VK`xCU5nW]j0WX21I ++<'4x≮iTR0bzw.l D 98RD`7$MV0aJD_NEȹcSOJ֋׏t7,y|o9l#h 4F|7).q TN؋ L=<ߴi| SXx8&㴱R(b|bI_mǕ 0ODЄ(*N\"g aC,Rˆ+<˹F:)(p)pdj<[Z߷jG孯+Y]6&5j5{!VK['f*Q;n)~Hpc$JY4|뉶سOiaBqk1n'­'"/=2 +0Э \s<&7NQ){KV4ͻޘ˷o#9f`,)Dx8@vrйpjM}p{p Lrl.t$- K#+`[9M#'gNlS^yL1BnH!0i:MzDZ{Ʈ_!Tp[vc6ElŢ")ū#;sQ6nDǜ9UMu9d`1qne.)E 9Wr\MPM +QD#,#7eEW=德eIhvB#YI(ֲTa10ɂzܭI h ދ >{Dvp`_%gj@v*EuPy)̩LY\fKN@CJg_/Lj]`4G5v5/KbzkdY6w1cҏF=5//Tg]E,U?Bp*t&H4!wʼn"V vDBs)Ɍ3@z 62-\=nؤpSZ#*‡F-cWq &)dO2kb+fy> +TsA_+Q+qRᤵRu0C xr8 m^kp5pm,`zm93 i!& +5N0h(5p\kT=7z ҏiޔ[1;[@I[Y#d" U5h2Xh6knWp!o@ |CIvhc'̿;i2\gOW?oNgVfKx^m֩Ϡoةkyb;a:B`l~۳{[y%v@ @ELפT5&׍PWPGJWMM +R{hRyM'h@ۮosy_OYn/I @]1dOuRA+LԩHA%jͿ]\@˸!.?q '9a CJE A_z-}'9]ROj^Wy +٬Ԝe3t-Y*_(zpٔ?z3NQ$f*Mqyr/I XKx_\/4pr=ZEТ*+ތq,cC|_Q=N4Dalo5 nG *+/BFAHsY6 +}-c6hU 7~&GQ2m$qu70LS-Dna kfԁ +.xAHld]4}UHji=z P80B:8^#~ⲍ6IwBtܲ0),Zf>[6la70_o+[((c_h7fDDfᗩ"u]*ev @.`AKH_7} IOF،Yfu 7PA *UymI0@Gf<`t% +At +"[٘)B"6-`QluE)1N;{ Qj"ΖiIf,Gqˁm != Ø]fdc\ku\:HPI +#ӐfK]497hNk1g_*Iԯ4ֺy L<$e=ef +$Ve&s l^X>s*BʧpgCFZ׃Kg"gM/”6e}sY'gWENۼ{rJL@IapGsX!L`j![N6(*aVXҹGӖQ)C՟C șt ƛ^PLOY8mqed?6y]HPQS`ϷCoVL8#Q v5/^??}O3hH*NF$Q=,7?ހeXlanB9Y?ziLnsA sinHg5)\vCЩAEjCC7*+K7$bKn8;MYb qZgݼGDE0C3W%g)7R3?V$7s0UO?)+wH9Whb!Yf8 "HJR]i 4x3 )zk%ёgm +*X5 \ݎm`!rY9n}ɟk#݃ޝ|wP/%fuK@ރ9rp.3]*Yqtj~zs(ѱ=:2-\r7{SAm9 Hx:*Ǘ?Ј,ݷt3̨"!e-JҸ]f^?<2+Güzdmi\,1ãL)$.D$V-µZHԩZϾ r5YrIwZ]`O2/6apd߆Xr +*Jb6Kى9s۹ rF (/ĢV@, MHjUO=A>ugA~GAމuM*sG;_%$6@3:*cRB,tYCn92wu|zD+ EpON76Y+iwT|!={̾=A+9[t)Gl-O~ +[0D;W;U8q;\}" +̼uT7b ~W B͆bA.)w H2RF?0qMBTU@t;31k7*`-hĥX pמaIkYAW'Z?KAԐBENr;\Uu.<.qfSLPO|[XΏ*n.ye4?:_G6rzTw.;,S}sg.CϽw7]hޞOyN[a|w)\Vmo.ZWchy+xtÁ_ڀ@r|!bgˇsf +uY&ڰwY$XDXz.u_ѲחnzM >X亹w}mM"x*e,EŐJ_$ +ݝ??><ù7%! z@ 5mzi:}{yGNZ&-!'Vl$@9(8vx ΐk`lFǜ$H W`*qiZ5.eo\8[.TB} q6C9%&0x(iUVO4R^r(J}&7`r; oo 茨 CRb[z>2[ſteX Vӻ:xf9~{O=}$fx?WWm87&ߵ)U+[ۏr:ڦx3va碭s[ `Dm4^G7tsd` < + $\ڞ1Wb+-҅\cOp6eIM"Uu4rI]+J j9kei2UY:IxRN>p<I.5G̾:=eBAFRZV be +4W^/r v/Sgα4 +4EYnc+$½n0/TؖS?Nʉ|Y,*Ԣb w- G*H3,NR]SI2 b\}ߐTv,7 v{ڰ-'Wb_~xϦ9&:tșqph|/7S\hX/a xqMZtutG%ar$ m|y1$+{Lcth*@l{Ak`^Ǡa#g!# zoTqş+gm$b1YsJWجi-Q?R֕;2(bm@^cTƠImj r/0| OOD?7<'ajOGx>gFiOYq"7@"ab|)1hƧ삊nϋs>!E9~RilI;:f` 8V7 z:\k6wवï*֩BU{16ez#A:x**l\;P7|biu^5)&_;|Tlm5\hsxkpAFhS) L?KqPKT{zhgC:IpUsܶZ憎![p,mŊi)*AquM0c2~VCqC㘅XFBGl¨3tXoWt ~IOD'7ہ1ZA47ATd;=;> 8/*|-( 165yhLOj;eOm3&[[C V28tjn>ۓR.qL!mY-N ӅM.+aejᆲA50Yo'[&r)dZk$Ge9`hZzaiQzq_T[0un +tw?/An0ap +?˻(6a4ʗPƪy}i|m时>?r;a;4%v7}`n֨~7NXf:E/FȚ5E*Z!}/>F3| d^A"9sz;}Y٨) -m_5hCw #5E 149<-utp<%I3Ȼ,*7V 1YAٌ~ ^ېJ .=mZ D\cV%gI?UE;s+>s8sM^]{m.ׯ`h:A: +eћi jbD>KL$űegEquĵ{$,π%0ҫHl~3(n.q5[!W2[Rl8`57@_tkGGJ* C+ GkmBUͿ)<ƒ93=sf9?m`Vf$!qyCgbD)iaRT,1h%A +o90v%㸌.I͙NEp΃ U$L|Z tyu-6E6#2!\q'э+TB.1t(^h[{v73Nϼ3ŜvaEz/twi,x^]Iu PoLai[;?PC!$vP˚6PTf?ڊKGIN?OG*Iut:.͕^g2[KIyHhap}fAO=Ip%V:y|'6`YM(+L~~en7.W=yyZfRd=Db"՜%%2%U~Mu9Bc6J%P?YH]2#6a> z41y4R& KKiG[if eyt(Bd`@/۬$R5L-NB>и^e$^ZǯUd?etl֪ITuGJ`H').+dyhmEgfHwJKP`UN9^V}"ՠ>]QsѸ4#P$*3YML<'&t&2xMSN4]2f#cMWAQ&`T;pԀMooyP^w}9$3㎩^t|!xp f'>&(c:5E.hc^ߕݾbC28dDSQ_'P&"#E,ӕ9eq<"€Y-8']45@&M9Ԓ:uUs|68,\٥q@[OX)ڷQՉr[ŕ +KB@1[̢ ދ f&VC4ЉY U^$4!w u +&`ye>ƹWIh&wZSU +B:1[ElQɷ!zxuCcO^O+M"/X$a7?3w񛃞Ź91\Oɻߛ:㚫tVWan>;9|;azNpptT +bvN8SݩȲ>yЗ†2H[IħEXԇ>[hQHmf__|7^O'g$賃*%=ڢ$aan(JX->K[ʔ? *_9F]gȈɈ$gDxҋ^/DA`<#x- qO@+*9u6t{_^(FE4ʛh(DO .RX+|)1 +n,Fg +oMZ"!E&-ib %XV+G27L_!,`/r+L +^8y+]:H f2ԜZfF-0455FW{(q2"@9p#,\Kk[/ss) 5kT5<(,=AW2խUwh9ٱh8 :OUg$9+ml>vj@zݵ{0!ݨ =7l 3<tik.K{5w R%J$]ĊΒ.RIQv*Kr%& ZSvpgvfg{g lH`&u %4 rHFIX UGDB3_7nZC0ID^wi`&XE.vGF*DSvY59y&6wʯGjS<#nc bZ[&>zbOmU+FHZHT#VmRgv2seۜbeX`i[4r_`fʼQ5F\RF2Z 7A9ջkRMU> u/YAB:kˡ"G[ U[̫l |#qWp ?$+XCsԆ籚i0{ݱq;~[խ"MGx=Y^1 +"A[v YG ?ngW¡W%P|J/c B31Yfd#NH2ph h]Zʚ I${솉uQ<8`TSy>^sӮȢm i8 ^c +c:m}Cc̭;hXSlhF_+obpsw.kXdEj痂K]tQ693T9AwBu +$b'@r(ܞ( J'UN \4?XOMw|trˇF8%[0Qv?F%ҳWsé# Я^3s61+ᗣWWEwo\̱T[՗YBO@*=S"gF-3^%K֥kͤ:u󷥑$qE +1!{N۵tԎ +SIB#)݅` \@b̗N(ɐixE4$)>&t6#m,Vt='5b|i&D]B +3l>יGo v/_myތֶ2sVݲ b0{Bٹ'##w\ޣB-{ 7ol ~+sRjx/DPIK2yP}g L@7-9+HW!y媮k\F}DUh6%e)M8_cF+D؏ڑ1ߟ1h]z_GqtPWv..n\~ۻŀ(/OΎZJ;q._%sw:9_CT"j" մo`A.V!{*`zswhfe +:!SaHrf- b"OES(!$ +ctzײ[Npvբ CVsMW]iA(G{#Zo2ppW&hkCdn2e +Dc#8{{e>lbB1̲dVlNa6ye[ dt槾G{[x$53lgK7k3h8ُ.p Twq{1w}}aaEqJ-嶸Km!A`^g$wӨkN +gBu=PF"N9>܅^d>H@#A8z2-.|p*(ǡoƌ\NaTڭ u-LW/ +'Sn*2QJ<[KnC=ݔdce %2D?"N1ʘO4ʜH{̕48+K!T:D@!aZa?(t5PYEBA`Fހ!#z,r'Rs',ƫݪ}PFpSOopPv*l90A[@+y Ks~͍߽V!ᗣA+;7IG?;OċJ{g[eAp1ԃ&75Ɖ`V y6W8B\v{LП-Y, T fE] so>7f,LUS=(VOgt'z._\~݋],"+*;;kº|j)t;{XIlspF/Pfr6eZ!1K5G?|`g ~%űx9QO'θa=M,úZ%-,Vyp; +eI5=2M7m鼽ê[:=lJF뙫Haaw|!pÔ7IJ$^v~d*YZ0OiȞRq-5]N_E6dݲiQ'w@{|)Xhݛs>i.i[ga6\r/=n]OW[o~ x^R@(Q.Q:IFy)"b ^HlJ]ԑW3;3M9-{#"YU=MeRǨld9k:O>tQzuZ<{4z;m1Lc\6 >qiXTJW` PVCmvzɩTm(B:S_LRc xbJW+uFI%s+`h$_ܮ9Yղ˥}[}/k_WO+qbGo7CK- K_ El =67ER͠ sfXj8[|hrl ooqJ&TZTp<푱Q|c"[EgaTJ9NJ(?NG#EމlcR|\Zm}YZ] R6IzmRX"tg_U|upS1e0Ϥ +`@B.`ك$Q)q`gÊK6$d|CA$6A xO88N0in 'Bx +pM}j4;x};/oF~'H5z *m~! `=f3Gdb/~c옰nr]ݒ +K{[-KQ'Le_T!SG6=lj *sÃeJd09J݄G^E(yJP&?f +5Q2XE--<~㬯}@$)!3`g󕷑s?$oϑ:J~%>bK3Qqh^ '@cyIh4xqw0\.aiEBſFQ@I\!<4C` +@! +R ⦾vCenB +k]A8<§hp-@R D26HLEGι(Ξ?2^[N4QG)D(>}}=  C I;gT,u}!䥹!LOAZ6]H<D2;XKi7V΢jmFnhмxW4$sYL`psaa_DA\}B/NU]xa'<K,wDHv,ׯ`<~'TZGd(?죔3 m3 f{*lv?jy=Fe! ? +>Ip3`1v/L둯ë&z ' 63OܲtjF|5@R-h,ĥnQ-t.MR@"ϥGC 9zNk?'<ϙ7CojL<ágd؆iӝ y)\KXy/>gGѮ*?{pw?NL;ŕJQpS]FFLF0ǹotknƢ>%3lɎ;fݺn& K)B%(J&}@"!E_޾$ ~{a<+#Y\'K6ˡ@^(KҒ\M=.{ЬN(󝢺S}Y/Ka=sY-MVHH}|2}0(3x1 +%`h*g,)~º8pjq{m-|m$3M꾌e6cSy=5]g7+A} -L|lrͲĜ &j&QIgkni>W:Le}0mIc3XДDO3/2o%͞__o_dLi'!y+NN7GN}ߝD&;vSȯF#޽jyVto4$oK/jV)"OfR"h֌)򖌟1 9~Q ԉE#<1J4ҠAWJ:"HDe Nŀs8?͔u<`0"8RԪb5؍5%UMV n-Aű:XY] +BY}@]% 4릘*~?GYvzwP\"VGxtiT Rm˽V^Zmۻ amvkN5)}~@ƺQ[hٲ"TI*ot*0tZ&Yμ gPR8L9E!}aG|0j6)TTY/{DZK)K҈R4ZMaZ5*~nx"t )gdHShBJkBHp o xRߺ9W̒^S% S\2tzy /I*U1pI>X2}XW1Oj sD#(~6p(j(ԇTc*mǼD(?F55ea!meҀˁR9$CעSэය١ Zb6$C Kl:k-8mq7);̩ϬgTAwq ZMEnbVQ> !7@aœEQ@%7 ؄S AݨLh >pcΨc;B,Rlzt>prA|Lr4Mpy ǚȍ/5%qnU=4ySORPڄDr4g_ZMIggSIBD6??b{tZP'F}}DMG|l_xfn%Q-h>1mN;=Km]Ap44Ɔl٧rz{e1J4t΢qk^E48=f=&%·8Pƣ +z,BAhsmzln8Æ}qűْ͡9IF޺9֢9ّ&Y<s:}`lHgְ,l`4X1бP-Qov%NbeSOdO@hGYiZ~[)EkMƨL,PMEFsn ^Q` O^2x &%'"S1Д +¦O`XVƱ.x*͔Y]ˆtco;͆jJnlo섚J C%3^ ʁ#hL0'wK6=mY~TeznVu_Hԇt{hx梣2xœݶULmɊk&m^V;.krĕ'KЅYzZ;i-t]>:o +O>X@BS3 ғ=Y8O|'>X8øfo<.|[͌7Y5.Sc?65 +^fD":9_.1L5hBz!( ҅tbz[}~ +`!CKMBNНXˑ`Repﺿu/aF%O8 J 7.$+Mȓ+ZƝ- + tO1ѵ|51z<^T@{m44 T@΂;4+6̎MKaR ~U$ИQKXYtYX"s><:Ѳ2"SHY?{"{z>ߛ;2n̳-9 K$o.y AxD g?Q4YP 0(uB|DOm+5wk%t3F Vk[y;9lP*`djUf@hNCa%/'ԶA8bQM2}DTR7s  ְ{Z̏؝?k!jypmJٯƷBXRIyE7}1*K!w4Nj43 -ds1X3Sr(Y>x/9T.õ0_:OK|DEP{ ŤQr8OΜ* lPk`p>;~I3H85_F݀YggG{yq]~ԩˏL/;˕-8pTt{үo*DΝ1[zUiq|I9-y}H#C)W=";O=1 zg_"dJYH 9~vKf5cb}?hRYHT$åd&idaZ|aZD`Ժ*䗴,U*}0ھ^۫HTMJ{6RrK,S\=$&\.,Π8duV }KOtܓ`^{Z".mvFxҩlO^#$v'Nq݋d&m]>P'gwZ-n"|q-2wl*#lQS=%I7`Bt-fbkQve(cܗ3$/Ħr 2GU&hrRHvΟSVCث HmDpCπ{8~ΜA>#ĄN13Nxo:Oţy oe})@}={@ꛟ1 C mkki.tPK? a p9q8t~)Z\?pيi:SBC~zw( \Lm%#R4A N Q<*ӖB +PkqjDY^ۧ9LU A2L),p;48*@& ƥUBGfOIDUX=MZj#uuWAsWz()8O+Uܜ_nL!WQ?ioGEz_8{0P/L&,ԧ" Dt0'DE ӹfbBTKPh$DIU"+hTkAٕU~u4j݀>h%|+, 6T4担Pó:&#ED.eߓq_mmW]> + ˉhIj#zlZ1їeQcg]#J-X͌8W[Jt*s$Fi5.[O?㽱l "$I@U;"Zhp-tl +`^GU\V!.cp'<1pmRNS gm4f'#jHVjKOc+g1PL?nCɲI:&܏.5J`j\L} +'c֋p}܍sTe5 Tǻ.?L#a;rǪN5œ;/ 2H7A'X|UJ_ C]7HH LrOQ'Vl_qꔭfѬc;&e"H<ɑ䯤=P +cɢ=s(5dXZGЬlW=ꟓNoyW5b%Nʶs,G/ANn'RLsQm=f]-5][qؼ~ݹu?m.鮯؁SԷ+pZva'j5sK1x:?Jt,D#zl)"V;QyO-pĂE'Vb52G4jy%%bbʁα_9]ݔyC9t=:"+P5Dr-ɥX3_W +B"5Έ柌]%TĀ[Lj>_4]p,|!"0pGGNbnՉ9p5ԋ1[Qŝ_ʄZiL0EjyG1R =N`naMvO;%<_r( E 9v$uG?1g7gQ]7zg"+KYAj!5:h\z]w/yo7>_:h{C/f8{SHۗm4F9} 1[| %^ʳ0gՓSWa$MaROU-swԽZ="a<*[aPN"T+ܒ#l B"h|H! W"w>F8f oϒL`'ffcVN~RrD}6r]F/v*vuk 憕:@ x4(K_RwGf{z`s ݱ^KbIĐtskVڏY"€@behP^hS w c4:\cGGa+LH}{Vk&_Lbe5!RLF]Lq%U7嫋=j"jUY ݘdt hݓxoE˜CKc`rm@k.O*K]-rXԂTgtE*M$5oU f3Hօȱr>z%!Ҕc=,u,Bǒ<Š&Z_Ս|,M,YNAAo*ܲT+og%O#KRq? $CJCH~vDBvJk:Fu>|(~pLP^8=jUTY/6VjMD+tsxAmSk"B9=$YDdp:!leMTMz~qmttv3b}<)-sގلb[0/[۾v7:z@Rp1gEkiP)J0 +(܃U#9o}@Y3G5Y+.y [Oٝ0i:9kպ`83K<Ǒz3jZWC?+_D]ʹ!rFtbj'89Z:O%Xmz% +*YyS%rӎ_ĵ#RJ6 +3|!UDy0^[H5 ok0ʼn|G dL@0v$ejo ^lQBS{,xlL7(ga9A9PESB4:j2-q/TŶ`ڤ5$,'%Ś1"GtHK %aG'Q̪;wt9cYY48p7B|DTS镢*`ܭywWn%҃Mϱe S\F/iKxi)4-:.ٙ#G&Gm#j#ț`B֜Zז,i^6IjZw`RJБG8kWJk;b : pI8uQU)3HZ"EȂ;;P8;2zi}Pzns5$5Og|J[c(GuPtHiO?`T Oyߛ0-,ɓOjhنKжYސ?Fd21&kaݲLƻ/#wLjXķZP*v/޶q,2 RIz`%<0S%c'K䜞.,Q u%4J~el+"Qхds{odq|SnSdȚPUAdF7?.OT'L8=eae܃b̕HH_,ZbZ羋X3'[鉌l4&hN?Ҭ6tw(L5b]1hݧ9Ýk,@MeU^4G4qQ㖦1-D?>d2 pjA\#C3Jim|M>, P~QMQUpʁ o)UĠXϼw(UB8թ< LĐy(OvE$3<`ߦpaI7Cs<YW) _,wӃ]Vv2W;dvB44 (y~Fv.OkeU#4ziӧ[_U4`"l?G4cT/ء:GW}MR1^KUȐ̓'ց٬+^B❮-@jFXŋ8M͡__'3c,eY.+guWsAMහ.Y*)JyRITƜDW%]+I1^幈8-Xzϊ2a *Y<8Rcr29rT BBPq(ӣsuzrhp[0(<.N\>W4uȻwѡ`e߽m go)y(G7(N "R "PwgZH,)^ޯHihɪLtLOܧa՚FG`c&ؖGg>kBvg<3sg};u7Ot3* q#<yO;; jI!sB^gv[ EmI`rrB>,Jh؎ff^9^؉9{5`qTYZa)j3e4dS0Ox*r$e!Y@ {Ĵ-! 1$ k Y%[aRU"qԎx}0>v" A  +FT! Ⱥ13g +oFx߸9l~/^KUò, 瑱qVG $()c<)/,d"C7UɮvbrȲA bzڳ3g4i]RQT{!A&,G ßnG9Ba~ @m}GQ3r0Ĕ2ƍ<oÓmNS5"*~T ө̽*` Qb:{/,/dn]fy>W|m*]/$_enz1ChQvM3꯶LsS$ɓrWşh6+Wz`"XC=XE(C4c`$$ ۬" &׌ s_Eɔ4][uX\7^d䉎b"h<cY\>@uGugY9l f-оsŒ@0]M9U.M kWz[ cĉ唧N9iH)Oh4K}/&4)1t׍ + JA7-;6t򽱜]ȵMGt\艶Yg`b{qxPaW*X`c&RaGv O9?Ȁ8}J^onٶ*왜%Uy:J$hn',jIJO6&/2櫖f$X +4ɥI#rY'^L.桎K,A'p4piUeVsl07)"L7zA8N]O:7otmM?Y<8gEVYΗzC6ީ?n=jH af @]aN(|\,9.T~RLCkWB`Eep= y925E^A5[㥯rN˸ 9/37Gp:P|6  ZA1fezS/'yk#+#bXݬy3FafWݖKjvPisN6=#TLBds +r 䉽 R,qrs8ח #+|b~nlx`옮K"M귬ދϪ~LDΔA +ɑ6Js&-c/Q!9:E`ÝpVJ)2 }P d9!ڊ$Q3"!GNnXi/^d=g#u}TYdg 2.RKaI[:,F…Y"%Cfh_GU0J-9qɴ4wఋe)XhÃ}k3jcblipeS6!=Z66ZwMA'n_]N[ Blҳa(w. F̧p-Y["{AE5=h.q๋/qpg=Gjjg+/"K*tQn粛w`rslO?@\~؇|.}{ ~Sw)fK_|ܴg&"CNةcSD|H0` 1U_nXm!V tUƆ]VªhîM΢C6[J ߋ0+*v(7[(8w"'M44 {Wx?w8~qF+lO۴2Aɐ+o܁0-R;8O" j 2VKg;Pt^|FCDѰ"M=U5fz\`\&)Ts!;SPS{IR89:,EV"Ka#,ډMr摗FYOI׷QYjUeuAV' 5u,K< ;I.nW!>^mݼ!;^=*?_qz{fV9A`=qHui%s"N ):|LRBnwKxl +~+AA x^xzi6#0cW+ަ-~39 Ƅ^I3jU l+k͛vwhDxh@/?c {֚/XjϑI{Tǂқ͉Pn/xmm#қ֬Fb3xbmfC4fso)C9 + mPn%I{@l>j)PUsГ9i,8=U~L?-PGjHx:1 B?G+cFn{L5mܙn43W:r,rR[~?Z}IK_Uv%?HKo(vb;6.p +'T08%ҴGמK۲XQ֓ڦoĎSٙI8wZ&VLg$c&'AYEj?6R\Cm4XZ)GltiG|;Pȫ@m5&./4,(&yz8hipS µ:  tuZW*uMGHz_LVltG@GA߄ITHh<ӭ]x E+-3ldgVqyx<tMr~ iyù醅\[aɌ0KM]aUo%xg|+Z~~ CZZ =8 +dXGs.xRCw itJ}}u#I '֨ONxO)#ŁYj*\j0$0P=>>4}cLqe l 6 enZ2 e-"(p`gR1hx(D"QEhL#It"wwI6^L%ɶM i"/Ģrյ+XG7 3A⿆w ʫp3l^*/X,y Ù[ֲXj"rkmz Ih2 ?AO!DVt\+ub.k@ÖF\NkDޑ?C\.;Q;D@3:q"k  a[jQF_8XCʉjqt&rNd.3tFR>e3Lw艸<y"b2dcl&jA+åᯨ*_ v_]f5[ȬTEGT~A~.9Z -$`vZrN\<zpT.matóAF4%"%9)#.O |.J)%=JWg`aƈ``ۚY ٚ[`/BASY^r]KֱBҗT#* IO~2 2[-(F3h#XN~신Jt^_dlf&D"2/D?dh=Gn2c 겉ɫ&KddK7*x{3ρy6$y2ӥOc7$ FL J '@}>8% 8 2 z p1mt`"00ᩎ mWteN`]ǡbÈFqaڈe;w +ޙSq I\9/Kw_N"<$;Vr'8`=<- ?ʹU&؀5]Ū{oǹ-Uwס`}tPLM;"G Rӝ g۹ox@ ϘVCOX;,pC\ i!ymx"d.y-fL9~X}VXϟ.//WkiO]![;OпGGVnyE @({Sx3Zcgz4G]M'ArZFuEiaCFm[b\/9_ieW6URyP?Kg~MȿUP+rcHP-BmetRAU HM@kB8u 'FNӬ%鞚&œp66/*Jtz`\L¬Ojd;N lb?~TiB-l; @}N<]ٟ|ԃQ$p+vy _pzT fPugWdg=q)|kEf6<#` X@+ё3,@0J2;f3C.yPl.c׶]|"xNpt(&.s|qMUbL)NlB1ͼ=\ ZOeOfHȺ|ZPݒwZ}G֑YJP{oSw=TihS@  +J3)Kd).'Yg`2\r~Am;M^Y^0AS_f]9hvau)Q|-hg΄dFA+;AH>{|ts,pc@@2UFDrC)%㮘(EOv(<*45P-( SHW\8Y@w(mջg|΅1`[zRƙ%Q a(EX?0Pm@@p;HAtd l04'͆T")jk ,5clܠ:*ȹZ0 Ɩ\ x;%*y'~&ћ †AooPćz2ޓ+)[#'7KFF9ga1A2>V~kmXtH^QN!\z;7|r}MH p ൳* -rG8'VΞ3}iX[>w}{>-63i}/P)XT kl%ȶ7 XIUC]m 4y-*[c+bb[mK@La!Mu߼/{ 5ߩYRP9|wjU{GVϮOvqִLT9N`JbtlG;jA~vj@Wy\@_D7ƈJJ<pNv5W28ehaJa77MGE)w76R{+czR=KK-mQ#Nlvn-fA3At&5ty9w) B\7\s:Hp!c'`/=3q~t2Lu@OdN߽̎':EjR~0mjGfB*P%xLzQO$=%΁xlMG;9>dکcϯo$,!GOm=h﴿8&ZI/^Cp"6Cb֧r!q&=Zwd[,w%YΚ"8ܹrX4G"PSYyj P$+It%"ttu{n%ETorĝfJbu䲪|8\{0==UxEPL>C"w +3gq%켎JkRNZn(CL0/6Hl<$}l,U&ϫWN<(u4y3-ܜ2Au{вt;-I^B@J8,^TIB{3Y_ge2 f;n.vu힭]a])޶$}~EC L:mc@b?6ɖ ְI9}Uݤxȶ,bDWe39S)L² ]yS{=qS{_f5k'n\7OUO0;V_2o牶ľ_2 q d +_j#B3ޓIYrIKuY=SZy3_jw8àR${ ;^/1`Ƽ9iߵ* 9F?35 `-9&?ib# @P~+cngH&"*maRVuӗB&ytx z ީZJ &jJ1 R 6tHڴ DaAVCڥ)C*Kkxhn|3Z @2[HGK: z&Wz YzUWލo{9}#{&s%c4]۷#j.iiuԳNG5tenunt/UݎZf2 ;}G X!EEa"EI*WYwMn/&Wu{ɀőhѯ=QqKz H~nYX$:5F72, Fb%xg[_b!sè-}v=W]3~>?ԮRy*TV)Kc'?~8ZY^InE:Yh}sQ4^1Eeޡɕcg& .*y%y:6`hX!.v;2g#M?Au֜dЈP31|m߲Ip{hV-ѬdDGxp}\X '7:ү:v6¾i M>Ki8?^VkZm'ab~{1ZF24֬c@R&8 Fjejr9c(B绍bŒW^X߶D=p~"_G7c0ZpȠ\wxL:8fXStJB|u{.% ş^Đ]&?;-ʈ<FE cbJ15!Bp܀bD'Nt"dc{knB1-sڔt0*gtw)ޖ92rE__^^_mo-t)l<'OgIYML y ܗ'1ql -],_3Ň$Q[Yxً#E}Tf2V봁 0&Y1rȐm ]tI9cq \q'fHPkJه)rq:"[ w8@/&W1cDe`k󔞷?#ycjת^cNqtB$C UbclÙn[S DO86YDͰ/ ?D}H%F9u@U[O4L\v ˴X= PLZy<.wBMT~wNfLm oQP چk8~Uln !%/&$?(>)xJ$$ 4CjצYWf]mg3\x_Ȍ;IouқNSbEa0T*/>5]Ն^ɫrػ[4Nzs>\SKm Q5:kt GNĵ炾T)gs +>6QWM([ r`wPiEPrNu7,Nhx~t~&[4biGxo$P*|T(VUCr0>OIio_ ;4:$+t' +S](7%ve/0A Ĩm, FΖHo L$d䰙(Og6:9dMYsJɥѱ`i-՚LC/re0W)f[:BبU6h9RTpT =F0<^J=˸זk匵OLta@9T"3Ȱ} 2JjfjE(ChJL "ߜUdGqHZr/WNbmt LKVVXΫ 3>nrZnPnQq/څ}Ad[>ru\jY +UqO보{",z:/+idrWx /s }5 Քnl,Nإ8J$94|;^1}ƠR5 Ri$q*hЭ+Wێ i<3&^X۰Y[R۔4ɑߪ$X1#Q>S1(٨VӮƺ+4ơ't`hQj:EƂy4Up21av瀤ܧ/p ϱ\a #嬏nJ묟 ?sEƬѺ4#%j J謘#Nz<(1\Ȅ[uӋvm!`b+b5OmCXB>#blumF_6yu_ p )zp~qAܠH8pYJ1!J3 i,Wr(yKz.Aۅ87+u;ñ(#MfEnR1&ȍjTs&q" }G$ywnu']IЖ*!,W|5 +K H#9*f+S22=o$FacTJD.nw5 nz.1-ui.{f+_Gw.1׳ٖa<+L7i}5RP@3gAtWd)(HAEfz: qD̓z^Ϳh=^M",¾=+6n +K(GiQFpbE.d ^mpI8{[||N ["xCyfE $Y}wkbهc- \IMGNf涐\{݋`Cʙ!Yp!b@pM9f .37~%?gjR;%%_CCfgW<`a[:W5)Gy>naq]⦍V3֣c[|A>_/G3ropGs M,Mw2, Y`f@a] +UȃHwQm؁=(fܾ! +;P?p8 [.AL#5lSS|u>OZ&FTͩ'[vt|.9;G'ix Ac 2L {$C<Z!C0ӌn"<$K&z<,ڰ߽# a}L>"1+J槧A>T16zYY# 2Olꈓ6ԗS%|WEw9Ug3՜xfjG2Bbm[ҴN}5{ۅYY^o6qqټ:l'Y}w?Q(14rf b>k>*%sD SPY5eDnH0Vޠv /< +mn- 8^I|8sVE"zcb K'U6n +'϶e;vș&9/!`  p@WewA2MHm. hR.M/?>Y%NL=Ԟ?vnߎCV~e0tXUTB#TfeA1dY6mF,;lWE_%'mw݄e7 !3JAӽ}4f51=pT!gb!'Zn*bUkA(X`!0.9Q䐴9`$^(ÙԾ#2:apFWpCNxv1CC]>AS@UԝQةbf20ЖgF9#`^h%qR V0؅ƎCXiM\QeXnyұ## =HR$+ +I,!}qLI%*@Q} b["OXv.mS|btx.ͷ$g86y2 u&b 77F.K1"^I!%ރr4֕ú +RyX:H[y--g'"6ٰ@SQQةbׅË3t!rcC nyǴL\A z')rjCFj{ Mr j1a()d%gUr [thٜxe|&yd~+'+gXL}L 4j,]/ku.Rrv:w,n~. ŭbPIznv5ϱEɬ#ٱ[ 6t8 %Q̤WR!U%W:+d}!].io+VE`1?yУcSeVZj/Í=lҺ)~cg`α=W}RRf,﶑ȭE}Q$[d`5$ +Fvk9X:i#)S8`7}G1:GsW5ΒO\8 \4 #bN( +=sZ{d (?'kt)×(ڜlC}Dzz!'<;11 nߐt 2[1Sq˶3qr- 1jn͉+ d~+'+VTVp.@Bj&"hB=aITdÆ$/h"co0xd}ĮlHb4/}<7a%|BhIQB$pzXn Ѵof.u=ը`6(,vj&gݾA9GճXQ% l3?֚Q12cD.?E+UD`f%Qh%|x1[ 978lͰTz}]diJo$@H:mX;iޝa.l ^q\g`\F~xjN@# wr+RXN>WHhe!r+W1ɨرSO< Qw(ڗsQ\ۍ}APoe(x12(qp^ X? B9?X*Cdp;dp_j w&3{@*{Y;x7&{QW.VڜdLPH$/ȼIun˓ZGrCNxv"ap6ODl*aKѝS Ů - gF9BƈAt'uk#ڂ@[1SNRd1%0Ѓ"/ Fvk9 *2ZQ~sP9JfY),2y pR)d @&ʄt_,3ѓ/L C[ E g,%]! 5:Zl,LlծqV,#ѵ ? >pU|_G&p^ʌ4.Mo#^/ot|3:#Q,ޚ|{lqGWI,tՆ"˖/daG@\L7|W9 jJ1MK,iXZ/: 19} 'zӊ!16jNfAFbfBrs1k>#rHCPYRyxQvܜdLP⡤`[$/s W`â^5KY]]όr҅ȍ1}{$Du[[F+8zsb.+ (e%$J]t 8ؑX,~UEWR!+Ujwsy"Y5}q.6XO, 8ޒ :y]BHAx]̢W7VSBD +_q"y$\GR)t8#Pw&i!L8Q,`ѽ(+FB#OZد޶,W|>tl u[)#rdNKͰ3C;_IWŰ-9g9^yO:Y5g1UrSEN  ;jy ,A,sx# 9躴?3 .2cKy@jE w䑷qrd a7W\NUX_#IFϰ +]Os7D$5xAܕaN2otR )J;<1qd&KO3[_2z(|oηOWՏzښ@U,(g +N8HR?!X̊ny2z tpu&)ewU]| I.n/X-Eh|Q k+`xZ~4Z&'ZCSO۸+jY/?l}C=Ԟ ~G_,c whіxb.dFu}:-gu`mwg[^v/:E4i`sL d o'"bVM6oOxGkLD]nR:y;{foj-N-|-lPYE$%F &9o䪊p݌yu[_jlt7|fK% +՝UPk)-ڑVoyDKU>ޝOVy6Z-/+/ug'4I/7wgR;COM? fT<-ͨ v:w]6/k:Yk_I l}:mn-]yDHwĿKt[PktD4q[wս +q/tC4h,=\ o+L_Nɘ|P O;$#e YNS .qwA>H@0S\fh`7\1fp=d\E~ʅyA$OpHqP [N@ų귡!>8‡iIN4b1| F'c;tVbx'!Qoe5V-ZHGoގ)r.8U.B+L_N02XW?+4tq/̣/0tvQkLW?b؈jM'y\) `,7]`đ#wqWD3Iwշ Zgxxvzpوsh1h e6Ndd0G$<ގ}Xp$Ƈ/<sI;\_RXǗ_l‘|<>)HnT.,*w?"#?.i$b [\G\'CY+^U'noa;U3U|)͊"ůzj%†Oҥ}BF/"اdXMtOF"di;w662-; |;V?ՅWS/=}dcz\S?~PӮPr͛'@NuH R?,xfEW402b#rEipL/Nm8v/<+*.7!2HZpTDRܼ0LR0Qt5G sah( [fŒ+'R6sZM肪}Tql+Ͳߔ?B#qf.}tȸӨ/eY[BZm)HPj6* +ܦuRYNtƺFJ^Kj%H~);S@$U{?Wh<}XزM̌%>ͫ ׏Ӆ$B34׭1יWlMf_Juf< 2ʐ}ڰuΪWRB=/_m"I_*˶@=U^'{MZgFҬ Ȏ$ ΞT G~~Ed{iȖ^V'am1N">|bD7/43몜0+^r}٥NҘ4-"W@PQA"cFSÛ/>|/2~{b/gDɚhb~0'4_),BdS"QÈ3 +=u?ND:PO egå6N54@up̖QWh4#q%RɽٗmN#v+[9 (ͨvŠ7LE .lq,sr5)JCg > K8=*dedr![t~%%aPDr *x{Q翴c@CzRb?)Px *oJE\A,"`n!{ /.0x;:-Vo*9}7 +d*yԖf# lZg @o9D":(xT#y6.xv/+P ?};@URR?&*+kg̘j|ڼ|)s\Ϭ_knY$6L*nS H֖P/b5µBwy}߸ڜš`W<"dl8`3i Of &ݍJҌ3$"(f̝֦6#b̗ { T37U7rҺŻ$|ږ͌k)ִMS4+kX%m@lgaw96wcax Tu:e2c4/%\iOllxe78E^wz/L$L A4ic:YV1![a LRdL\+2" bKyZ׊L]I`7nࠃ3R~(B-1YaH!H`2~w-`S(?>شLJ"E+8qd҈szIhKJ{-Gis2 8F˚me")E׹^3l* Yy8; +;62DV;19=ɿqA,7C](ʓFQ=t "hSXB x|(<ʄרvm K9#."Ό;C/93>2_r~Z~fwM +xf|#gWf?<'fӳL⾉I܃`/FOOOTzGߨ{]5xEWzrz^*Wihz}AC@j_5_0.%cu_0F՘S//pY䪖^UU\'h!ݝ$-R+seH26'?Z#_tM5-hXBe4B"1='a7*|~4q?1r:~6?fG1h>?NpZMP(;HNT >%3PBqZkV&D $_H 'l rdyP s6=fG3 ;td.G8 ̶P99]1gU& +kWWc=W R}\e]?P +|w ~^ +z,kPk'aa'X1  +%WHl7e}"•v9[u9zt ~X6嚹08mBh6Dt5gCx`֡f6pq,]9+"7'P Q3pडljF5k6σ掮63hLTЅ6JC 6MṞ2vƝMxMf.}} ޳ͼŇKḷ.ޜsd8e8u~unfk'ܧ"_ kp## Yas[σ,M+Y qĂYG{GA^S]\cz:=| 'iЇSz7|~5>ƿ|8IRjtz};\"\RZŤ,G#A-knSA=^|-F&wBZ:.^$Θq6u ys(0և:0s`XNކ5=*ك!ڃ;R!F1¦U W!$8=#'fadm.(ul/Ӵq9ZдqeM+i84qpOpW쪺  0 G q$#2ķm}*GȗCM5|Q/_=Ũ!Ĝ5q5Q\`XK:'礆kTv%>A xŦЛֳӪI@4kaW|A߯`n8wv'2e1Eg A운2l^K(mBA`P{ll2jA%mԤ s8il _o hĬfe5DBFZA*UBJ2Q(XIsq$vE ;S䡆O9l&Ԃ_XNĆ5XYJ?Dǫ܃[A0;4gFUm + jx|^05 E/g]~3$NF.pM dS@, 48\ OC2dsܴ51+ϫcyu=ٛVz!]W~ǽ^Z' a55=GZlo~*uIz[lQ= 9NޤcTv %ǀICnZ*LZi_1٫M똃Yi_`&1?#cïke]`R]`-pK[V`|# V BR1X+P(jf +j[nGҾ$Uķv+Ԭ=0oIH@iHrs'!)<&e!vq$mZ15ÖgR"a<¶P--JnVlop$pHfB+h Gay-}[F5p&zI3 NF:&r(2G O~$*|b[sW?7?_8O[c8+S sOp$pLN㎳OI8VPcK\}%TaAUs +п/F`Q6>EtmROf* 4i*膹%A:ہx=Kcv0nA&u:ۤ.3t`l*;*mR:.l_g X[Ʀs֭RϹ.y-Swj*=@lbn:JlRJ?c#V?5t$;9< W[/'u23*$F;9zLXZ)zǼIzJ'i!defR|7û\4g +Og=z7uM{tDLi +bZKN9+ҮXdc{Z٥g Hk!yОLR,7!<5 ku0:`33+L~i윙 b)ǼeʹX.,dpePaD"MW(4^RMXnѿDbVrdƸc/9#L:G')hbBkf*ZAC{l )a 9CV6$ةM`f8VQSUAח 1b?~FRq7:iR`n': ؚ,u%M3pŮS-&mxͤ6 %EOVx`g((&5ЄZ~0EJ3]6R!.ߜ;S*{TfD PᏠ\$bɩKu2ed4 dpXK1VB;e]$XJMD.c[;CQP)O̱ʁ6|Bd`0⌋O< `Xi4P!dת'^Ř {y9a%ƉG@/zD]S EիPQ䴒27p\]q#н ` +ɻ,H߇D SR!iBE` S؄6qX:8]iaf,EbBbI<ؘuZ7'qHi}d N:X`.p2 +B—dDXͩͶC ex +N<%O[dTd<3bH yQL;V {`yA._^=7>woG#;I`)=?:U!'%#_[J/>)!8$^ZG-zf GADg!]Duܣ6KIWi:=7֣Z^\L3M.HqDzDݔ D{w .ȏ߁5%E4 5PtUXhtrOV!0;N. +Re&(ijBk%_lnji4ۥ͏K/^5?aV,/選.4:b' a 1Kjn1"%)ǗB-GMfw^`0n`LؤjdDvM/E"J\z8Œ\Z(N3T=؍QHKC9ҴQҟx7o>\$yұyӮl׹zuyqu1f?Pq{zsMG*JJڲN!Mo7{_!ct?~iFaKFx\W&t~Og],SDʭG7?m|:ZuD+rT6Z`ĠroO簘<ã/a\jxO&hB$.j\]s[H%-/?'-8~AyxﾵPx+YB{lYዦaW` KHo/Y/N\m|y_ D>DŽ'*U>!I@ +JkqY}葪]Aׯ}ǰp/oI ∠F_Bț1I.I VݏAHhdԭs7d"oՂaq-44[AoBRTZI$3*V|[!IP׻\FkS/5$h)B$fRv:! т7Q€(Ib@Htag3FnTVVݚ,0{n쪂I wE^7/_^;ݓ?J ӶZ4[b J1s+>|^7.p:N g9!z1| T5Wb -T de^U MJeG")V*Ogմ3-墅{kOlAE;pB#PdC|QXk[_r%nE z|b6%Y`jW¦#jMcOk]|iN:+ѱwHQO;i8$XD^T 6OLM,n"v5-xٙWy ŔtV!(/9 +U\H%u*p<]&-^9#KN8<*CbsG:0^[J:+&ѳ~0~K7{-{OF4 ˈiӸ=vn V MǑ 7ԁx˛̋$Hދ7UWսf4_[(n;KF4WUc(Upͮ%=zvaDDC0_=vDV}rXPYҹQ@Qh(~\=(!qJHjM^jGKndрb\+Mvplau.1r%V>jk&bsc.J%ִjtѨ6x",TS vǷmV{/vRUV*E?♃ q,Tl\%A$P$CIăD5NsFyە 0?/ImW>&[ MT8'c7͎D{7u=,:mnlFQ\[r)JtĊcz(X"!򌢝7 Ȣzz0;2 +/7l`؎87PdSK# 75!*d_J=|Cu2 N\=Uj҅4“ ]3UqVu|3/ ??O"DA9 ūK0lN\lj܅3n*`"᧓7Gr 5/6Vל%4#xtE$슑^AeMZ1^ {sH׺#F,cX0DADi$5lja莬.3il3ZSU2/̜,LweyԒoڄ>u物88>M;ß)]SVn O۱Mhِ%$d ;uuCO![ +u ש M.EbOHQ gEÜjTl$zʿ iNٕAgj̙V}S{QV +,EUW4@ EÑX +Q"# o5,sjXh6-<҇zmȿ$ z;۟ض0;_Dpr+ 68>iNNhNlQN+Tܲ7:wyz{s(4XK6ƾ8tſح>}kbPp4R'a'@1$+Nf$Rdce<ۡbK/m 7U5pQ+ :\[&4G6)J̎`d6lM'ni=۴8Av!0GL+p 3,ZF_T06M'4~8YG*HkOxc/]wWkxЪdˆ6ιUcc52PAn<H!Ur"#}iKM4ĂĠj54嵶#SH).eD=MMU^y 39[l<".OS]4Iv^{K^&.S9:1ӆGg ǿi_b'[0'w#=!p0Qӧ>2y+,]>B-A<״jP[],=׽Pe-G}lHC̝@dQUX|^:ԟ:R鑬T7.s1? yjpFdɌ(13{UNiJ_PT˔{u3RgjrW +ɾ1FfĀ9%VQHhD>x>@x31&SD"CX36ԉ$1r<2qLuHyz$H@DF;,y<"rP66MŌ[6ḆFqp9݉$iʡ G+r 4s +r<`t \yh< + e6SE ^ +&ˮ U+5ڦ%JdQgH;ꍩ pys +ϷxHk09B$C4~#a1H7, cJ֢)vT>4A֌1#̸kO'{KlodŻ+1އ.c6llF{.^#`'6o׮wPv N:Y,型7ntS5OW<(S>9L18HgK@G6N +?DI󍇸]*@ot8%A|Ivg%P\hyێNƁ2}I7=n7Gp [FD S92@p|kkLOL5WH᰺~6ej ~d |6*n1px?.}3L0I̓}YIH#9 n^|h<20F2U6ػޯp pz36{+-]h8nHQm $DÃfZï (LJcUwHK2l YE0xu&G0b-Ro('ؿR,,'P< J-tWȄ?tgxMUjgmǸz'h4I{Iå_Ufhwx fNB>!3ķTkS(͋7p̤`"T3Arn:ⓥAh.Q# }mNU0X#g5$*/N=f;#` 6 Rt-Y̝YG@fحa 21UoQLvY DGˮp,LYQWRb}B [u=bhK4H@Ĝ +*k"I1l/R[;W:"NswGSFLO,/Z#BZdxsZMxpm\-tbH9R] #-WOEx5{2w3=nj>|ҐOl?iH݃^ ɖYnFfz ~?Zԁ>/.K/1 &y?Qu_g<CE[<[Xj P7e&UZCڹFK T{W5h^j##WuSθ֍-xMG\xF Ѥ&yk/]V֝Ժ_);zb]Ob8J@hΥR|giCBZXj#c]]vYVxeK; +Ch_sca= &^/l>p,-\)Cu!E м;nf-Iyw d-z c͊݉xB݈bFoi%UK`- E/]ϑ_UO%{9\#:HykؚF]l̔BuF ˧(3$ +=!4:h6iL'&]Sf3lC=(;Ej^W| bLLVKR|)>t$*Rj+/L|9_ Û +v ?\[a[UCSDm'6{h4ǭťf$m?‹kI a`9KRեoo52.V"Lms{R~^ L~65#W UC<0<' ÝJce%9!nَ@ͣnmbKrӧAfCPh?"TsA)jl2Q]FcRM-@ մiD ON$l:sޒT,%9UΧH @0FDģ샐;$4>W<(@ +Ki #ހ2< my|P+C8[$Sx 0lp yk|8kj w:<:PMSP 1R&dĭqe|w +B{Ptts ]KE1>)%nC1:v}H EAXG@x)]^5g+Vf#(j켫j"rxuOPU"_^9цBÕ2y~>- 7WvơF蹑3׮skVA-|1A㮆m2Me/ F9aw T]t)jd8ƪWr8q0pă=`Y'5Z[`/ڂAA_zJ~:z6!<Hszi<M8*3܆"dzݏq )ŧK1Ȟ*\h8yFw^C`ҕ{ WNrg> =hεfƻ@ReChZj#BDHx/\hG<$] =} +D5&֠#Hԏy_lR6<"+]LdPp$9%p:2o.!"wv9 EK+:#77 m/1Fe GG*_lldǾ0QWy剟[j'a3͟v;?KU*r +rsˮ=kiO_ij36nx|Gc|8}`T 6@}Y S̈k$ys,G80#șH|>, +v`v@5&DdՏywdʂѾc?H?-ݿ^oȣ{U_z[]fF|SFD&TC^AC !@= dm8Y)?EĢc0|IMjPp`Vܵb I%b ,ImR 0ļNpVusf]j:ŏZ&O샾.w#ݽCÛMQ0fD k4XعekT(x5C+mpRfV@l KLӍ["1(z*(9:'lu2]pԢ--rG +|e"_ܵ\c. +ewVx$^t,ق%F}y$\65};࿓~Ƣ?ʯ^BZ R+jT>|قJlVE>A*}9m(sBcfB2~Hh¾][ +%aV}!'yYOҜt6EG<0X{[ @-i|Ooj3u`9}_)UG0e\ ý&aAZ2Z +LEzߔmwz+@CB4@~}ouy{X ߛ );(BnؕkIAwQ<. ϔ!ȸg<1 Y\hf\-ТxNM_zP-j,#U5 "#F׵MFGge:A,2} !m.5g'[6;,i3'Is)cyPshqikGW?Jͯ4V aO[* %̙wc3y1ڇuz-®4-=D>y Q_F)؎.#P*,w9'3zUZ@72HeL<_6%!k/JήdrGlh;<S! .H{Җ- ׉> +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 new file mode 100644 index 00000000..0b72c682 --- /dev/null +++ b/specifications/contacts/rfc9553.txt @@ -0,0 +1,4043 @@ + + + + +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 new file mode 100644 index 00000000..f1d6e3ab Binary files /dev/null and b/specifications/contacts/rfc9610.pdf differ diff --git a/specifications/contacts/rfc9610.txt b/specifications/contacts/rfc9610.txt new file mode 100644 index 00000000..8975e5ba --- /dev/null +++ b/specifications/contacts/rfc9610.txt @@ -0,0 +1,844 @@ + + + + +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 new file mode 100644 index 00000000..8b036313 Binary files /dev/null and b/specifications/core/rfc8620.pdf differ diff --git a/specifications/core/rfc8620.txt b/specifications/core/rfc8620.txt new file mode 100644 index 00000000..935ba474 --- /dev/null +++ b/specifications/core/rfc8620.txt @@ -0,0 +1,5043 @@ + + + + + + +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 new file mode 100644 index 00000000..3cd84ffd Binary files /dev/null and b/specifications/mail/rfc2369.pdf differ diff --git a/specifications/mail/rfc2369.txt b/specifications/mail/rfc2369.txt new file mode 100644 index 00000000..77a1f68f --- /dev/null +++ b/specifications/mail/rfc2369.txt @@ -0,0 +1,843 @@ + + + + + + +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 new file mode 100644 index 00000000..027b85fa Binary files /dev/null and b/specifications/mail/rfc5322.pdf differ diff --git a/specifications/mail/rfc5322.txt b/specifications/mail/rfc5322.txt new file mode 100644 index 00000000..f3306869 --- /dev/null +++ b/specifications/mail/rfc5322.txt @@ -0,0 +1,3195 @@ + + + + + + +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/rfc8621.pdf b/specifications/mail/rfc8621.pdf new file mode 100644 index 00000000..ae1c0acb Binary files /dev/null and b/specifications/mail/rfc8621.pdf differ diff --git a/specifications/mail/rfc8621.txt b/specifications/mail/rfc8621.txt new file mode 100644 index 00000000..9add50ee --- /dev/null +++ b/specifications/mail/rfc8621.txt @@ -0,0 +1,6051 @@ + + + + + + +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 "