From ef5b93d3b3038e25244cb0e828c736348d3c2ad4 Mon Sep 17 00:00:00 2001 From: Mike Douglass Date: Mon, 22 Apr 2024 00:54:09 -0400 Subject: [PATCH] Update generated files --- generated/draft-ietf-calext-vpoll.err.html | 308 ++++---- generated/draft-ietf-calext-vpoll.html | 658 +++++++++-------- generated/draft-ietf-calext-vpoll.rfc.xml | 348 +++++---- generated/draft-ietf-calext-vpoll.txt | 818 ++++++++++----------- generated/draft-ietf-calext-vpoll.xml | 392 +++++----- 5 files changed, 1308 insertions(+), 1216 deletions(-) diff --git a/generated/draft-ietf-calext-vpoll.err.html b/generated/draft-ietf-calext-vpoll.err.html index 47c7a7e..35d069d 100644 --- a/generated/draft-ietf-calext-vpoll.err.html +++ b/generated/draft-ietf-calext-vpoll.err.html @@ -21,147 +21,147 @@

Style

used for simple consensus scheduling but also have the generality to handle more complex cases. To provide an easy (and for many a2 -001073poll-modes +001083poll-modes Hanging paragraph in clause
<clause id="poll-modes" inline-header="false" obligation="normative">
 <title>Poll Modes</title>
 <p id="_0fc83bd6-312b-bbdc-dd0b-73cd5bd54b09">The VPOLL component is intended to allow for various forms of
 polling.  The particular form in efffect is indicated by the POLL-
 MODE property.</p>
2 -001082_poll_​modebasic +001092_poll_​modebasic Hanging paragraph in clause
<clause id="_poll_modebasic" inline-header="false" obligation="normative">
 <title>POLL-MODE:BASIC</title>
 <p id="_904f5c11-b6b5-dae1-60e1-f699173dd5ec">BASIC poll mode is the form of voting in which one possible outcome
 is chosen from a set of possibilities.  Usually this will be
 represented as a number of possible event objects one of which will
2 -001120new-participant-properties -Hanging paragraph in clause
<clause id="new-participant-properties" inline-header="false" obligation="normative">
-<title>New Participant Properties</title>
-<p id="_c2a2f6b6-d7da-939d-15a3-35694fb0f9f2">The following properties are defined to be used within PARTICIPANT and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.</p>
+001130new-participant-properties-for-itip
+Hanging paragraph in clause
<clause id="new-participant-properties-for-itip" inline-header="false" obligation="normative">
+<title>New Participant Properties for iTip</title>
+<p id="_e5771856-e31c-dcb4-94d1-bf73012dcba8">The following properties are defined to be used within PARTICIPANT during scheduling and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.</p>
 
 <clause id="new-prop-kind" inline-header="false" obligation="normative">
2 -001228_de6b4b9d-07ac-6201-2dbd-87870e895f1f +001240_de6b4b9d-07ac-6201-2dbd-87870e895f1f Table should have title
<table id="_de6b4b9d-07ac-6201-2dbd-87870e895f1f"> <thead> <tr> <th valign="top" align="left">RFC5545 ROLE</th>
 <th valign="top" align="left">PARTICIPANT-TYPE</th>
 <th valign="top" align="left">jsCalendar</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_c588917c-68af-ff99-37d7-f2365cfce4f7">CHAIR</p>
2 -001261_cdba8a49-5c4f-9267-509b-f707ab621832 +001273_cdba8a49-5c4f-9267-509b-f707ab621832 Table should have title
<table id="_cdba8a49-5c4f-9267-509b-f707ab621832"> <thead> <tr> <th valign="top" align="left">PARTICIPANT-TYPE</th>
 <th valign="top" align="left">jsCalendar</th>
 <th valign="top" align="left">RFC5545 ROLE</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_9e67fb22-224f-fe41-daf1-94540b29560f">OWNER</p>
2 -001513itip-with-participants +001553itip-with-participants Hanging paragraph in clause
<clause id="itip-with-participants" inline-header="false" obligation="normative">
 <title>iTip With Participants</title>
 <p id="_3c2dcc08-3e64-cdb6-7181-756d56694c76">The PARTICIPANT component introduced in <eref type="inline" bibitemid="RFC9073" citeas="RFC 9073"/> with the addition of some properties defined in this specification mirrors the participant object in <eref type="inline" bibitemid="RFC8984" citeas="RFC 8984"/>.</p>
 
-<p id="_f4172fe5-271c-d99b-a4ad-02eaf3d652d3">For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL defined here, only PARTICIPANT components MUST be used.</p>
2 +<p id="_d9f932c3-aa33-d975-9742-b19a34a63409">For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL, defined here, only PARTICIPANT components MUST be used.</p>
2 -001521_e06fd311-8303-7425-42b0-6d63a3041ad9 +001573_e06fd311-8303-7425-42b0-6d63a3041ad9 Table should have title
<table id="_e06fd311-8303-7425-42b0-6d63a3041ad9"> <thead> <tr> <th valign="top" align="left">Parameter</th>
 <th valign="top" align="left">iCalendar PARTICIPANT</th>
 <th valign="top" align="left">jscalendar participant</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_ef0cf81b-3540-5de8-8443-116395af5263">CN</p>
2 -001592itip-extensions +001644itip-extensions Hanging paragraph in clause
<clause id="itip-extensions" inline-header="false" obligation="normative">
 <title>iTIP Extensions</title>
-<p id="_542d896b-3841-0b40-740c-2b7d4b9ccf1f">This specification introduces a number of extensions to <eref type="inline" bibitemid="RFC5546" citeas="RFC 5546"/>.
+<p id="_0f3e07f1-12cd-9469-bc2b-917e930bbfab">This specification introduces a number of extensions to <eref type="inline" bibitemid="RFC5546" citeas="RFC 5546"/>.
 In group scheduling the parties involved are organizer and attendees.
-In VPOLL the parties are organizer and voters.</p>
2 +In VPOLL the parties are owner and voter participants.</p>2 -001606_2eb409ce-7960-66c1-e760-9eaa07d0a351 -Table should have title
<table id="_2eb409ce-7960-66c1-e760-9eaa07d0a351"> <thead> <tr> <th valign="top" align="left">Method</th>
+001658_7016578a-bd01-8f76-6903-6a65c235ce8f
+Table should have title
<table id="_7016578a-bd01-8f76-6903-6a65c235ce8f"> <thead> <tr> <th valign="top" align="left">Method</th>
 <th valign="top" align="left">Description</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_472c03d3-56dc-0e36-a25f-8bf12ebc446b">PUBLISH</p>
 </td>
2 -001665_806d9e24-9c75-e77a-eca1-f481315f5946 -Table should have title
<table id="_806d9e24-9c75-e77a-eca1-f481315f5946"> <thead> <tr> <th valign="top" align="left">Originator</th>
+001717_4e523422-a8ea-8824-1b8e-014f5ad7ee49
+Table should have title
<table id="_4e523422-a8ea-8824-1b8e-014f5ad7ee49"> <thead> <tr> <th valign="top" align="left">Originator</th>
 <th valign="top" align="left">Methods</th>
 </tr> </thead>
-<tbody> <tr> <td valign="top" align="left"> <p id="_f3343640-22a3-1b37-2128-da212d2e4be9">Organizer</p>
+<tbody> <tr> <td valign="top" align="left"> <p id="_5d040444-1ab1-2147-c6f0-fe34cfcd696d">Owner</p>
 </td>
2 -001680_​interoperability_​models +001732_​interoperability_​models Hanging paragraph in clause
<clause id="_interoperability_models" inline-header="false" obligation="normative">
 <title>Interoperability Models</title>
-<p id="_2d3913af-3cd0-565c-d120-9ece5f730512">Most of the standard iTip specification applies with respect to
-organizer and voters.</p>
+<p id="_c9c597ec-0dcd-4e0e-ea69-c4fd85504580">Most of the standard iTip specification applies with respect to
+owner and voters.</p>
 
2 -001729_20c2bd89-596c-b73f-e396-74a1ab0cb624 +001781_20c2bd89-596c-b73f-e396-74a1ab0cb624 Table should have title
<table id="_20c2bd89-596c-b73f-e396-74a1ab0cb624"> <thead> <tr> <th valign="top" align="left">Presence Value</th>
 <th valign="top" align="left">Description</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_030d12e4-b6d6-7ea0-c332-770075b364fa">1</p>
 </td>
2 -001758_cc41b643-75ca-cabc-4796-e13b424ac738 -Table should have title
<table id="_cc41b643-75ca-cabc-4796-e13b424ac738"> <thead> <tr> <th valign="top" align="left">Method</th>
+001810_dcd21a7b-9264-441c-d676-35c38514b725
+Table should have title
<table id="_dcd21a7b-9264-441c-d676-35c38514b725"> <thead> <tr> <th valign="top" align="left">Method</th>
 <th valign="top" align="left">Description</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_47877187-549a-becf-fd0c-8f0284f81d02">PUBLISH</p>
 </td>
2 -001825_method_​request +001877_method_​request Hanging paragraph in clause
<clause id="_method_request" inline-header="false" obligation="normative">
 <title>Method: REQUEST</title>
 <p id="_c38cbca1-7226-a385-ad3a-59c30c140768">The "REQUEST" method in a "VPOLL" component provides the following
 scheduling functions:</p>
 
2 -002333caldav-extensions +002367caldav-extensions Hanging paragraph in clause
<clause id="caldav-extensions" inline-header="false" obligation="normative">
 <title>CalDAV Extensions</title>
 <p id="_7c8823b4-cb28-9137-4ac5-73ef59415313">This specification extends <eref type="inline" bibitemid="RFC4791" citeas="RFC 4791"/> in that it defines a new
 component and new iCalendar properties to be supported and requires
 extra definitions related to time-ranges and reports.</p>
2 -002342_calendar_​collection­_​properties +002376_calendar_​collection­_​properties Hanging paragraph in clause
<clause id="_calendar_collection_properties" inline-header="false" obligation="normative">
 <title>Calendar Collection Properties</title>
 <p id="_a0606761-38ff-f79c-ff4f-ae1da346b26e">This section defines new CalDAV properties for calendar collections.</p>
 
 <clause id="_caldavsupported_vpoll_component_sets" inline-header="false" obligation="normative">
2 -002603_​caldavcalendar_​query_report +002637_​caldavcalendar_​query_report Hanging paragraph in clause
<clause id="_caldavcalendar_query_report" inline-header="false" obligation="normative">
 <title>CalDAV:calendar-query Report</title>
 <p id="_ec234fd7-7a00-c686-87a0-78bf4160f738">This allows the retrieval of VPOLLs and their included components.
 The query specification allows queries to be directed at the
 contained sub-components.  For VPOLL queries this feature is
2 -002782_d71909c9-9721-fa4e-84ec-ee478ba9df8b +002816_d71909c9-9721-fa4e-84ec-ee478ba9df8b Table should have title
<table id="_d71909c9-9721-fa4e-84ec-ee478ba9df8b"> <thead> <tr> <th valign="top" align="left">Property Parameter</th>
 <th valign="top" align="left">Status</th>
 <th valign="top" align="left">Reference</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_7234eea5-30a7-2f34-c03c-2dc3c8664a94">REQUIRED</p>
2 -002807_528080f9-471a-19f5-34e2-0ca06f0b828a +002841_528080f9-471a-19f5-34e2-0ca06f0b828a Table should have title
<table id="_528080f9-471a-19f5-34e2-0ca06f0b828a"> <thead> <tr> <th valign="top" align="left">Property</th>
 <th valign="top" align="left">Status</th>
 <th valign="top" align="left">Reference</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_fc4cf0b9-02d9-e1c0-ab81-d2f7cef06f7e">ACCEPT-RESPONSE</p>
2 -002872_51cd362e-4959-7b5e-dd1a-f7f780ae3880 +002906_51cd362e-4959-7b5e-dd1a-f7f780ae3880 Table should have title
<table id="_51cd362e-4959-7b5e-dd1a-f7f780ae3880"> <thead> <tr> <th valign="top" align="left">Poll mode name</th>
 <th valign="top" align="left">Purpose</th>
 <th valign="top" align="left">Reference</th>
 </tr> </thead>
 <tbody> <tr> <td valign="top" align="left"> <p id="_24e35e5a-64a8-b5ae-e940-3b12c6a5d3ba">BASIC</p>
2 -003119_open_​issues +003153_open_​issues Hanging paragraph in clause
<annex id="_open_issues" inline-header="false" obligation="informative">
 <title>Open issues</title>
 <p id="_dcc6896f-cf5f-7f4e-b0f3-db5f2ac71b86">public-comment: Not documented and was a parameter on something.
@@ -189,367 +189,367 @@ 

Metanorma XML Syntax

XML Line 000020:88 attribute "obligation" not allowed here; expected attribute "language", "numbered", "removeInRFC", "script" or "toc"
2
 
-XML Line 002897:84
+XML Line 002931:84
 attribute "inline-header" not allowed here; expected attribute "language", "numbered", "obligation", "removeInRFC", "script" or "toc"
2
 
-XML Line 002981:80
+XML Line 003015:80
 attribute "inline-header" not allowed here; expected attribute "language", "numbered", "obligation", "removeInRFC", "script" or "toc"
2
 
-XML Line 003049:40
+XML Line 003083:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003056:143
+XML Line 003090:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003056:143
+XML Line 003090:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003056:143
+XML Line 003090:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003056:150
+XML Line 003090:150
 element "p" missing required attribute "id"
2
 
-XML Line 003056:150
+XML Line 003090:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003058:28
+XML Line 003092:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003060:28
+XML Line 003094:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003062:28
+XML Line 003096:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003065:40
+XML Line 003099:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003080:143
+XML Line 003114:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003080:143
+XML Line 003114:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003080:143
+XML Line 003114:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003080:150
+XML Line 003114:150
 element "p" missing required attribute "id"
2
 
-XML Line 003080:150
+XML Line 003114:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003081:98
+XML Line 003115:98
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003083:28
+XML Line 003117:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003085:28
+XML Line 003119:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003088:40
+XML Line 003122:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003099:143
+XML Line 003133:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003099:143
+XML Line 003133:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003099:143
+XML Line 003133:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003099:150
+XML Line 003133:150
 element "p" missing required attribute "id"
2
 
-XML Line 003099:150
+XML Line 003133:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003100:94
+XML Line 003134:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003102:28
+XML Line 003136:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003104:28
+XML Line 003138:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003106:28
+XML Line 003140:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003109:40
+XML Line 003143:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003120:143
+XML Line 003154:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003120:143
+XML Line 003154:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003120:143
+XML Line 003154:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003120:150
+XML Line 003154:150
 element "p" missing required attribute "id"
2
 
-XML Line 003120:150
+XML Line 003154:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003122:28
+XML Line 003156:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003124:28
+XML Line 003158:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003127:40
+XML Line 003161:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003136:143
+XML Line 003170:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003136:143
+XML Line 003170:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003136:143
+XML Line 003170:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003136:150
+XML Line 003170:150
 element "p" missing required attribute "id"
2
 
-XML Line 003136:150
+XML Line 003170:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003138:28
+XML Line 003172:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003140:28
+XML Line 003174:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003142:28
+XML Line 003176:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003145:40
+XML Line 003179:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003152:143
+XML Line 003186:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003152:143
+XML Line 003186:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003152:143
+XML Line 003186:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003152:150
+XML Line 003186:150
 element "p" missing required attribute "id"
2
 
-XML Line 003152:150
+XML Line 003186:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003154:28
+XML Line 003188:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003156:28
+XML Line 003190:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003159:40
+XML Line 003193:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003166:143
+XML Line 003200:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003166:143
+XML Line 003200:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003166:143
+XML Line 003200:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003166:150
+XML Line 003200:150
 element "p" missing required attribute "id"
2
 
-XML Line 003166:150
+XML Line 003200:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003167:8
+XML Line 003201:8
 element "p" missing required attribute "id"
2
 
-XML Line 003167:8
+XML Line 003201:8
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003168:94
+XML Line 003202:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003170:28
+XML Line 003204:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003172:28
+XML Line 003206:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003175:40
+XML Line 003209:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003184:143
+XML Line 003218:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003184:143
+XML Line 003218:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003184:143
+XML Line 003218:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003184:150
+XML Line 003218:150
 element "p" missing required attribute "id"
2
 
-XML Line 003184:150
+XML Line 003218:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003186:28
+XML Line 003220:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003188:28
+XML Line 003222:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003190:28
+XML Line 003224:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003193:40
+XML Line 003227:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003200:143
+XML Line 003234:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003200:143
+XML Line 003234:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003200:143
+XML Line 003234:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003200:150
+XML Line 003234:150
 element "p" missing required attribute "id"
2
 
-XML Line 003200:150
+XML Line 003234:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003202:28
+XML Line 003236:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003204:28
+XML Line 003238:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003207:40
+XML Line 003241:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003216:143
+XML Line 003250:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003216:143
+XML Line 003250:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003216:143
+XML Line 003250:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003216:150
+XML Line 003250:150
 element "p" missing required attribute "id"
2
 
-XML Line 003216:150
+XML Line 003250:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003217:94
+XML Line 003251:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003218:94
+XML Line 003252:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003220:28
+XML Line 003254:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003222:28
+XML Line 003256:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003225:40
+XML Line 003259:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003234:143
+XML Line 003268:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003234:143
+XML Line 003268:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003234:143
+XML Line 003268:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003234:150
+XML Line 003268:150
 element "p" missing required attribute "id"
2
 
-XML Line 003234:150
+XML Line 003268:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003236:28
+XML Line 003270:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003238:28
+XML Line 003272:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003241:40
+XML Line 003275:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003248:143
+XML Line 003282:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003248:143
+XML Line 003282:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003248:143
+XML Line 003282:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003248:150
+XML Line 003282:150
 element "p" missing required attribute "id"
2
 
-XML Line 003248:150
+XML Line 003282:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003249:8
+XML Line 003283:8
 element "p" missing required attribute "id"
2
 
-XML Line 003249:8
+XML Line 003283:8
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003250:94
+XML Line 003284:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003252:28
+XML Line 003286:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003254:28
+XML Line 003288:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003257:40
+XML Line 003291:40
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003264:143
+XML Line 003298:143
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003264:143
+XML Line 003298:143
 found attribute "language", but no attributes allowed here
2
 
-XML Line 003264:143
+XML Line 003298:143
 found attribute "script",​ but no attributes allowed here
2
 
-XML Line 003264:150
+XML Line 003298:150
 element "p" missing required attribute "id"
2
 
-XML Line 003264:150
+XML Line 003298:150
 element "p" not allowed here; expected the element end-tag, text or element "add", "bcp14", "bookmark", "br", "concept", "date", "del", "em", "eref", "erefstack", "hr", "image", "index", "index-xref", "keyword", "link", "pagebreak", "review",​ "ruby", "smallcap", "span", "stem", "strike",​ "strong",​ "sub", "sup", "tt", "underline" or "xref"
2
 
-XML Line 003265:94
+XML Line 003299:94
 found attribute "format",​ but no attributes allowed here
2
 
-XML Line 003267:28
+XML Line 003301:28
 attribute "format" not allowed here; expected attribute "type"
2
 
-XML Line 003269:28
+XML Line 003303:28
 attribute "format" not allowed here; expected attribute "type"
2
 
 
diff --git a/generated/draft-ietf-calext-vpoll.html b/generated/draft-ietf-calext-vpoll.html
index 9be368a..c4dbfc6 100644
--- a/generated/draft-ietf-calext-vpoll.html
+++ b/generated/draft-ietf-calext-vpoll.html
@@ -1217,7 +1217,7 @@
 
 
 York & Douglass
-Expires 22 October 2024
+Expires 24 October 2024
 [Page]
 
 
@@ -1232,12 +1232,12 @@
 
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1279,7 +1279,7 @@

time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

- This Internet-Draft will expire on 22 October 2024.

+ This Internet-Draft will expire on 24 October 2024.

-
+
DTSTAMP
@@ -1759,109 +1762,100 @@

-
ORGANIZER
+
SUMMARY
-
-

The usual [RFC5545] property. In general this need not -be an organizer of any of the alternatives. In this simple -outline we assume it is the same.

+
+

The usual [RFC5545] property. This optional but +recommended property provides the a short title to the poll.

-
SUMMARY
+
DESCRIPTION
-
-

The usual [RFC5545] property. This optional but -recommended property provides the a short title to the poll.

+
+

The usual [RFC5545] property. This optional property +provides more details.

-
DESCRIPTION
+
DTEND
-
+

The usual [RFC5545] property. This optional property -provides more details.

-
-
-
-
DTEND
-
-
-

The usual [RFC5545] property. This optional property provides a poll closing time and date after which the VPOLL is no -longer active.

+longer active.

-
POLL-MODE
-
-
-

A new property which defines how the votes are used to +

POLL-MODE
+
+
+

A new property which defines how the votes are used to obtain a result. For our use case it will take the value "BASIC" -meaning one event will be chosen from the alternatives.

+meaning one event will be chosen from the alternatives.

-
POLL-COMPLETION
-
-
-

A new property which defines who (server or client) +

POLL-COMPLETION
+
+
+

A new property which defines who (server or client) chooses and/or submits the winning choice. In our example the value is "SERVER-SUBMIT" which means the client chooses the winner -but the server will submit the winning choice.

+but the server will submit the winning choice.

-
POLL-PROPERTIES
-
-
-

A new property which defines which icalendar +

POLL-PROPERTIES
+
+
+

A new property which defines which icalendar properties are being voted on. For our use case it will take the value "DTSTART, LOCATION" meaning only those properties are significant for voting. Other properties in the events may differ -but are not considered significant for the voting process.

+but are not considered significant for the voting process.

-
PARTICIPANT
-
-
-

There is one of these components for each voter with +

PARTICIPANT
+
+
+

There is one of these components for each voter with the PARTICIPANT-TYPE set to "VOTER". The CALENDAR-ADDRESS property identifies the voter and this component -will contain one VOTE component for each item being voted on.

+will contain one VOTE component for each item being voted on.

-
VOTE
-
-
-

A new component. There is one of these for each voter and +

VOTE
+
+
+

A new component. There is one of these for each voter and choice. It usually contains at least a POLL-ITEM-ID property to identify the choice and a RESPONSE property to provide a vote. For more complex poll modes it may contain other information such -as cost or estimated duration.

+as cost or estimated duration.

-
VEVENT
-
-
-

In our simple use case there will be multiple VEVENT sub- +

VEVENT
+
+
+

In our simple use case there will be multiple VEVENT sub- components defining the alternatives. Each will have a different -date and or time for the meeting.

+date and or time for the meeting.

-
+

EXAMPLE

VPOLL with 3 voters and 3 alternative meetings:

-
+
BEGIN:VCALENDAR
 VERSION:2.0
@@ -1871,7 +1865,6 @@ 

POLL-MODE:BASIC POLL-COMPLETION:SERVER-SUBMIT POLL-PROPERTIES:DTSTART,LOCATION -ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T000000Z SUMMARY:What to do this week @@ -1885,7 +1878,7 @@

CALENDAR-ADDRESS:mailto:eric@example.com END:PARTICIPANT BEGIN:PARTICIPANT -PARTICIPANT-TYPE: VOTER +PARTICIPANT-TYPE: VOTER,OWNER CALENDAR-ADDRESS:mailto:mike@example.com END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) @@ -1942,7 +1935,7 @@

component containing their vote. In our simple case it will have the following properties and components:

-
+
DTSTAMP
@@ -1966,45 +1959,38 @@

-
ORGANIZER
+
SUMMARY

Same as the request.

-
SUMMARY
+
PARTICIPANT
-
-

Same as the request.

+
+

One only with a CALENDAR-ADDRESS identifying the voter replying.

-
PARTICIPANT
+
VOTE
-
-

One only with a CALENDAR-ADDRESS identifying the voter replying.

+
+

One per item being voted on.

-
VOTE
+
POLL-ITEM-ID
-
-

One per item being voted on.

+
+

One inside each VOTE component to identify the choice.

-
POLL-ITEM-ID
+
RESPONSE
-
-

One inside each VOTE component to identify the choice.

-
-
-
-
RESPONSE
-
-
-

One inside each VOTE component to specify the vote.

+
+

One inside each VOTE component to specify the vote.

@@ -2028,20 +2014,19 @@

-
+

EXAMPLE

REPLY VPOLL from Cyrus:

-
+
BEGIN:VCALENDAR
 VERSION:2.0
 PRODID:-//Example//Example
 METHOD: REPLY
 BEGIN:VPOLL
-ORGANIZER:mailto:mike@example.com
 UID:sched01-1234567890
 DTSTAMP:20120101T010000Z
 SUMMARY:What to do this week
@@ -2074,24 +2059,23 @@ 

3.4. VPOLL updates

-
-

When the organizer receives a response from one or more voters the +

+

When the owner receives a response from one or more voters the current state of the poll is sent to all voters. The new iTip method POLLSTATUS is used. The VPOLL can contain a reduced set of -properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, -ORGANIZER and one or more PARTICIPANT components each populated with zero or more VOTE components.

+properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, and +one or more PARTICIPANT components each populated with zero or more VOTE components.

-
+

EXAMPLE

-
-
+
+
BEGIN:VCALENDAR
 VERSION:2.0
 PRODID:-//Example//Example
 METHOD: POLLSTATUS
 BEGIN:VPOLL
-ORGANIZER:mailto:mike@example.com
 UID:sched01-1234567890
 DTSTAMP:20120101T020000Z
 SEQUENCE:0
@@ -2130,6 +2114,24 @@ 

RESPONSE:0 END:VOTE END:PARTICIPANT +BEGIN:PARTICIPANT +PARTICIPANT-TYPE: VOTER,OWNER +CALENDAR-ADDRESS:mailto:mike@example.com +BEGIN: VOTE +POLL-ITEM-ID:1 +RESPONSE:50 +COMMENT:Work on iTIP +END:VOTE +BEGIN:VOTE +POLL-ITEM-ID:2 +RESPONSE:100 +COMMENT:Work on WebDAV +END:VOTE +BEGIN:VOTE +POLL-ITEM-ID:3 +RESPONSE:0 +END:VOTE +END:PARTICIPANT END:VPOLL END:VCALENDAR

@@ -2158,20 +2160,19 @@

the winning choice and when it has done so set the STATUS to "SUBMITTED".

-
+

EXAMPLE

VPOLL confirmation:

-
+
BEGIN:VCALENDAR
 VERSION:2.0
 PRODID:-//Example//Example
 METHOD: REQUEST
 BEGIN:VPOLL
-ORGANIZER:mailto:douglm@example.com
 UID:sched01-1234567890
 DTSTAMP:20120101T030000Z
 COMPLETED:20120101T030000Z
@@ -2180,6 +2181,10 @@ 

SUMMARY:What to do this week STATUS:CONFIRMED POLL-WINNER:3 +BEGIN:PARTICIPANT +PARTICIPANT-TYPE: OWNER +CALENDAR-ADDRESS:mailto:mike@example.com +END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) END:VEVENT BEGIN:VEVENT.......(with a poll-item-id=2) @@ -3136,7 +3141,7 @@

-
+
pollc    = "BEGIN" ":" "VPOLL" CRLF
             pollprop
@@ -3149,7 +3154,7 @@ 

; The following are REQUIRED, ; but MUST NOT occur more than once. ; - dtstamp / uid / organizer / + dtstamp / uid / ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. @@ -3398,13 +3403,13 @@

-
+
-

-6. New Participant Properties +

+6. New Participant Properties for iTip

-
-

The following properties are defined to be used within PARTICIPANT and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.

+
+

The following properties are defined to be used within PARTICIPANT during scheduling and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.

@@ -3484,7 +3489,7 @@

This specification redefines the PARTICIPATION-TYPE property allowing it to take multiple values and extending those values to align with [RFC8984] roles and add a new "VOTER" role. There are also changes to the description to clarify it's use defining the roles that participant takes.

-
+
Property name
@@ -3534,8 +3539,10 @@

Note that the kind of participant, for example individual or group, is defined in the KIND property specified here.

-
-

Do we need a separate registry or should we extend that one?

+
+

Some of the roles are required for the participant to be a schedulable object. These are the roles that are shown below. +* +Do we need a separate registry or should we extend that one?

@@ -3670,8 +3677,8 @@

-
-

To map PARTICIPANT-TYPE or jscalendar roles to [RFC5545] ROLE values use the following.

+
+

The following table shows those roles that MUST appear in the PARTICIPANT-TYPE for group-scheduling. Additionally, the mapping PARTICIPANT-TYPE or jscalendar roles to [RFC5545] ATTENDEE and ORGANIZER values are shown.

@@ -4234,6 +4241,62 @@

+
+
+

+6.8. Expect reply +

+
+
+
Property name
+
+
+

EXPECT-REPLY

+
+
+
+
Purpose
+
+
+

If true, the organizer is expecting the participant to notify them of their participation status.

+
+
+
+
Property Parameters
+
+
+

Non-standard or iana parameters can be +specified on this property.

+
+
+
+
Conformance
+
+
+

This property MAY be specified once in the PARTICIPANT component.

+
+
+
+
Format Definition
+
+
+

This property is defined by the following notation:

+
+
+
+
+
+
+
+
expect-reply = "EXPECT-REPLY"
+              expect-replyparams ":"
+              ( "TRUE" / "FALSE") CRLF
+
+expect-replyparams = *(";" other-param)
+
+
+
+
@@ -4244,8 +4307,23 @@

The PARTICIPANT component introduced in [RFC9073] with the addition of some properties defined in this specification mirrors the participant object in [RFC8984].

-
-

For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL defined here, only PARTICIPANT components MUST be used.

+
+

For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL, defined here, only PARTICIPANT components MUST be used.

+
+
+

Note that extensions to the [RFC5546] specification for VPOLL will be dealt with in later sections.

+
+
+

A participant object that takes part in group scheduling MUST have the following characteristics:

+
+
    +
  • It MUST have a calendar address ([RFC5545] CALENDAR-ADDRESS, [RFC8984] calendarAddress). +
  • +
  • It must have one or more scheduling role defined. (PARTICIPANT-TYPE or [RFC8984] role) +
  • +
+
+

Scheduling with PARTICIPANT components behaves exactly as with ATTENDEE and ORGANIZER properties. When iTip specifies the setting of ATTENDEE or ORGANIZER parameters then the appropriate PARTICIPANT property will be set.

@@ -4454,10 +4532,10 @@

8. iTIP Extensions

-
+

This specification introduces a number of extensions to [RFC5546]. In group scheduling the parties involved are organizer and attendees. -In VPOLL the parties are organizer and voters.

+In VPOLL the parties are owner and voter participants.

For many of the iTip processing rules the voters take the place of @@ -4472,7 +4550,7 @@

There are some extensions to the behavior of iTip methods for a VPOLL object and two new methods are defined.

-
+

@@ -4558,8 +4636,8 @@

@@ -4611,7 +4689,7 @@

The following table shows the above methods broken down by who can send them with VPOLL components.

-
+

Table 4
-
-

The organizer returns a METHOD:REQUEST with the +

+

The owner returns a METHOD:REQUEST with the current full state, or a METHOD:CANCEL or an error if no matching poll is found.

@@ -4596,11 +4674,11 @@

-
+

Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE -(if not 0), UID, ORGANIZER and PARTICIPANTS.

+(if not 0), UID and PARTICIPANTS. One PARTICIPANT MUST be the owner.

@@ -4623,8 +4701,8 @@

Table 5
-
-

Organizer

+
+

Owner

@@ -4655,9 +4733,9 @@

8.2. Interoperability Models

-
+

Most of the standard iTip specification applies with respect to -organizer and voters.

+owner and voters.

@@ -4808,7 +4886,7 @@

The following summarizes the methods that are defined for the "VPOLL" calendar component.

-
+
@@ -4882,8 +4960,8 @@

@@ -4914,13 +4992,13 @@

8.3.2. Method: PUBLISH

-
+

The "PUBLISH" method in a "VPOLL" calendar component is an unsolicited posting of an iCalendar object. Any CU may add published -components to their calendar. The "Organizer" MUST be present in a +components to their calendar. An owner participant MUST be present in a published iCalendar component. "Voters" MUST NOT be present. Its expected usage is for encapsulating an arbitrary poll as an iCalendar -object. The "Organizer" may subsequently update (with another +object. The "Owner" may subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published "VPOLL" calendar component.

@@ -4971,13 +5049,13 @@

"Voter" to another CU.
  • For an existing "VPOLL" calendar component, change the role of -"Organizer" to another CU. +"Owner" to another CU.
  • -
    -

    The "Organizer" originates the "REQUEST". The recipients of the +

    +

    The "Owner" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs voting in the poll, the "Voters". -"Voters" use the "REPLY" method to convey votes to the "Organizer".

    +"Voters" use the "REPLY" method to convey votes to the "Owner".

    The "UID" and "SEQUENCE" properties are used to distinguish the @@ -5029,12 +5107,12 @@

    describes an update of the poll details, but not a rescheduling of the POLL.

    -
    +

    The update "REQUEST" method is the appropriate response to a -"REFRESH" method sent from a "Voter" to the "Organizer" of a poll.

    +"REFRESH" method sent from a "Voter" to the "Owner" of a poll.

    -
    -

    The "Organizer" of a poll may also send unsolicited "REQUEST" +

    +

    The "Owner" of a poll may also send unsolicited "REQUEST" methods. The unsolicited "REQUEST" methods may be used to update the details of the poll without rescheduling it, to update the "RESPONSE" parameter of "Voters", or to reconfirm the poll.

    @@ -5070,77 +5148,75 @@
    8.3.3.5. Delegating a Poll to Another CU
    -
    +

    Some calendar and scheduling systems allow "Voters" to delegate the vote to another "Calendar User". iTIP supports this concept using the following workflow. Any "Voter" may delegate their right to vote in a poll to another CU. The implication is that the delegate participates in lieu of the original "Voter", NOT in addition to the -"Voter". The delegator MUST notify the "Organizer" of this action +"Voter". The delegator MUST notify the "Owner" of this action using the steps outlined below. Implementations may support or restrict delegation as they see fit. For instance, some implementations may restrict a delegate from delegating a "REQUEST" to another CU.

    -
    +

    The "Delegator" of a poll forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include a "Voter" property with the calendar address of the "Delegate". The "Delegator" MUST -also send a "REPLY" method to the "Organizer" with the "Delegator's" +also send a "REPLY" method to the "Owner" with the "Delegator's" "Voter" property "DELEGATED-TO" parameter set to the calendar address of the "Delegate". Also, a new "Voter" property for the "Delegate" MUST be included and must specify the calendar user address set in the "DELEGATED-TO" parameter, as above.

    -
    +

    In response to the request, the "Delegate" MUST send a "REPLY" method -to the "Organizer", and optionally to the "Delegator". The "REPLY"

    +to the "Owner", and optionally to the "Delegator". The "REPLY"

    -
    -

    method SHOULD include the "Voter" property with the "DELEGATED-FROM" -parameter value of the "Delegator's" calendar address.

    +
    +

    method SHOULD include the "Voter" participant with the "PARTICIPANT-DELEGATED-FROM" +property value of the "Delegator's" calendar address.

    -
    +

    The "Delegator" may continue to receive updates to the poll even though they will not be attending. This is accomplished by the -"Delegator" setting their "role" attribute to "NON-PARTICIPANT" in -the "REPLY" to the "Organizer".

    +"Delegator" setting their "role" attribute to "INFORMATIONAL" in +the "REPLY" to the "Owner".

    -
    +
    -
    -8.3.3.6. Changing the Organizer +
    +8.3.3.6. Changing the Owner
    -
    -

    The situation may arise where the "Organizer" of a "VPOLL" is no -longer able to perform the "Organizer" role and abdicates without -passing on the "Organizer" role to someone else. When this occurs, +

    +

    The situation may arise where the "Owner" of a "VPOLL" is no +longer able to perform the "Owner" role and abdicates without +passing on the "Owner" role to someone else. When this occurs, the "Voters" of the "VPOLL" may use out-of-band mechanisms to -communicate the situation and agree upon a new "Organizer". The new -"Organizer" should then send out a new "REQUEST" with a modified +communicate the situation and agree upon a new "Owner". The new +"Owner" should then send out a new "REQUEST" with a modified version of the "VPOLL" in which the "SEQUENCE" number has been -incremented and the "ORGANIZER" property has been changed to the new -"Organizer".

    +incremented and the owner role assigned to the appropriate "PARTICIPANT".

    -
    +
    -
    -8.3.3.7. Sending on Behalf of the Organizer +
    +8.3.3.7. Sending on Behalf of the Owner
    -
    +

    There are a number of scenarios that support the need for a "Calendar -User" to act on behalf of the "Organizer" without explicit role -changing. This might be the case if the CU designated as "Organizer" +User" to act on behalf of the "Owner" without explicit role +changing. This might be the case if the CU designated as "Owner" is sick or unable to perform duties associated with that function. In these cases, iTIP supports the notion of one CU acting on behalf -of another. Using the "SENT-BY" parameter, a "Calendar User" could -send an updated "VPOLL" "REQUEST". In the case where one CU sends on +of another. In the case where one CU sends on behalf of another CU, the "Voter" responses are still directed back -towards the CU designated as "Organizer".

    +towards the CU designated as "Owner".

    @@ -5149,29 +5225,29 @@
    8.3.3.8. Forwarding to an Uninvited CU
    -
    +

    A "Voter" invited to a "VPOLL" calendar component may send the "VPOLL" calendar component to another new CU not previously associated with the "VPOLL" calendar component. The current "Voter" participating in the "VPOLL" calendar component does this by forwarding the original "REQUEST" method to the new CU. The new CU -can send a "REPLY" to the "Organizer" of the "VPOLL" calendar -component. The reply contains a "Voter" property for the new CU.

    +can send a "REPLY" to the "Owner" of the "VPOLL" calendar +component. The reply contains a "Voter" participant component for the new CU.

    -
    -

    The "Organizer" ultimately decides whether or not the new CU becomes +

    +

    The "Owner" ultimately decides whether the new CU becomes part of the poll and is not obligated to do anything with a "REPLY" -from a new (uninvited) CU. If the "Organizer" does not want the new -CU to be part of the poll, the new "Voter" property is not added to -the "VPOLL" calendar component. The "Organizer" MAY send the CU a +from a new (uninvited) CU. If the "Owner" does not want the new +CU to be part of the poll, the new "Voter" is not added to +the "VPOLL" calendar component. The "Owner" MAY send the CU a "CANCEL" message to indicate that they will not be added to the poll.

    -
    -

    If the "Organizer" decides to add the new CU, the new "Voter" -property is added to the "VPOLL" calendar component. Furthermore, -the "Organizer" is free to change any "Voter" property parameter from -the values supplied by the new CU to something the "Organizer" -considers appropriate. The "Organizer" SHOULD send the new CU a +

    +

    If the "Owner" decides to add the new CU, a new participant for the "Voter" +is added to the "VPOLL" calendar component. Furthermore, +the "Owner" is free to change any "Voter" participant property values from +the values supplied by the new CU to something the "Owner" +considers appropriate. The "Owner" SHOULD send the new CU a "REQUEST" message to inform them that they have been added.

    @@ -5185,13 +5261,13 @@
    8.3.3.9. Updating Voter Status
    -
    -

    The "Organizer" of an poll may also request updated status from one -or more "Voters". The "Organizer" sends a "REQUEST" method to the -"Voter" and sets the "RSVP=TRUE" property parameter on the PARTICIPANT CALENDAR-ADDRESS. The +

    +

    The "Owner" of a poll may also request updated status from one +or more "Voters". The "Owner" sends a "REQUEST" method to the +"Voter" and sets the "EXPECT-REPLY" property value to TRUE. The "SEQUENCE" property for the poll is not changed from its previous value. A recipient will determine that the only change in the -"REQUEST" is that their "RSVP" property parameter indicates a request +"REQUEST" is that their "EXPECT-REPLY" property indicates a request for updated status. The recipient SHOULD respond with a "REPLY" method indicating their current vote with respect to the "REQUEST".

    @@ -5219,24 +5295,24 @@

    Depending on the value of the "REQUEST-STATUS" property, no action may have been performed.

    -
    -

    The "Organizer" of a poll may receive the "REPLY" method from a CU +

    +

    The "Owner" of a poll may receive the "REPLY" method from a CU not in the original "REQUEST". For example, a "REPLY" may be received from a "Delegate" to a poll. In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This -uninvited "Voter" may be accepted, or the "Organizer" may cancel the +uninvited "Voter" may be accepted, or the "Owner" may cancel the poll for the uninvited "Voter" by sending a "CANCEL" method to the uninvited "Voter".

    -
    -

    A "Voter" MAY include a message to the "Organizer" using the -"COMMENT" property. For example, if the user indicates a low -interest and wants to let the "Organizer" know why, the reason can be +

    +

    A "Voter" MAY include a message to the "Owner" using the +"COMMENT" property in the PARTICIPANT component. For example, if the user indicates a low +interest and wants to let the "Owner" know why, the reason can be expressed in the "COMMENT" property value.

    -
    -

    The "Organizer" may also receive a "REPLY" from one CU on behalf of -another. Like the scenario enumerated above for the "Organizer", +

    +

    The "Owner" may also receive a "REPLY" from one CU on behalf of +another. Like the scenario enumerated above for the "Owner", "Voters" may have another CU respond on their behalf. This is done using the "SENT-BY" parameter.

    @@ -5251,7 +5327,7 @@

    shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present.

    -
    +

    Table 7
    -
    -

    A request is sent to an Organizer by a Voter asking +

    +

    A request is sent to a poll owner by a voter asking for the latest version of a poll to be resent to the requester.

    @@ -4896,11 +4974,11 @@

    -
    +

    Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE (if -not 0), UID, ORGANIZER and PARTICIPANT.

    +not 0), UID, and PARTICIPANT.

    - - - - - @@ -5372,89 +5435,89 @@

    @@ -5468,13 +5531,13 @@

    8.3.5. Method: CANCEL

    -
    +

    The "CANCEL" method in a "VPOLL" calendar component is used to send a cancellation notice of an existing poll request to the affected -"Voters". The message is sent by the "Organizer" of the poll.

    +"Voters". The message is sent by the "Owner" of the poll.

    -
    -

    The "Organizer" MUST send a "CANCEL" message to each "Voter" affected +

    +

    The "Owner" MUST send a "CANCEL" message to each "Voter" affected by the cancellation. This can be done using a single "CANCEL" message for all "Voters" or by using multiple messages with different subsets of the affected "Voters" in each.

    @@ -5493,7 +5556,7 @@

    shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present.

    -
    +
    Table 8: @@ -5340,31 +5416,18 @@

    -
    -

    ORGANIZER

    +
    +

    UID

    1

    -
    -
    -

    UID

    -
    -
    -
    -

    1

    -
    -
    -

    MUST be the UID of the original

    +
    +

    MUST be the UID of the original

    -
    -

    REQUEST.

    +
    +

    REQUEST.

    -
    -

    SEQUENCE

    +
    +

    SEQUENCE

    -
    -

    0 or 1

    +
    +

    0 or 1

    -
    -

    If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0.

    +
    +

    If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0.

    -
    -

    ACCEPT-RESPONSE

    +
    +

    ACCEPT-RESPONSE

    -
    -

    0 or 1

    +
    +

    0 or 1

    -
    -

    POLL-ITEM-ID

    +
    +

    POLL-ITEM-ID

    -
    -

    1+

    +
    +

    1+

    -
    -

    One per item being voted on.

    +
    +

    One per item being voted on.

    -
    -

    VFREEBUSY

    +
    +

    VFREEBUSY

    -
    -

    0 or 1

    +
    +

    0 or 1

    -
    -

    A voter may respond with a VFREEBUSY component indicating that the ORGANIZER may select some other time which is not marked as busy.

    +
    +

    A voter may respond with a VFREEBUSY component indicating that the "Owner" may select some other time which is not marked as busy.

    -
    -

    VAVAILABILITY

    +
    +

    VAVAILABILITY

    -
    -

    0

    +
    +

    0

    -
    -

    A voter may respond with a VAVAILABILITY component indicating that the ORGANIZER may select some other time which is shown as available.

    +
    +

    A voter may respond with a VAVAILABILITY component indicating that the "Owner" may select some other time which is shown as available.

    - - - - - @@ -5624,11 +5674,11 @@

    8.3.6. Method: REFRESH

    -
    +

    The "REFRESH" method in a "VPOLL" calendar component is used by "Voters" of an existing event to request an updated vpoll status from -the poll "Organizer". The "REFRESH" method MUST specify the "UID" -property of the poll to update. The "Organizer" responds with a +the poll "Owner". The "REFRESH" method MUST specify the "UID" +property of the poll to update. The "Owner" responds with a METHOD=REQUEST giving the latest status and version of the poll.

    @@ -5636,7 +5686,7 @@

    and a single VPOLL object. That object MUST contain the properties shown below and no others.

    -
    +
    Table 9: @@ -5590,27 +5653,14 @@

    -
    -

    ORGANIZER

    +
    +

    SEQUENCE

    1

    -
    -
    -

    SEQUENCE

    -
    -
    -
    -

    1

    -
    - - - - - @@ -5750,10 +5787,10 @@

    8.3.7. Method: POLLSTATUS

    -
    +

    The "POLLSTATUS" method in a "VPOLL" calendar component is used to inform recipients of the current status of the poll in a compact -manner. The "Organizer" MUST be present in the confirmed poll +manner. The "Owner" participant MUST be present in the confirmed poll component. All "Voters" MUST be present. The selected component(s) according to the poll mode SHOULD NOT be present in the poll component. Clients receiving this message may store the confirmed @@ -5768,7 +5805,7 @@

    This method type is an iCalendar object that conforms to the following property constraints:

    -
    +
    Table 10: @@ -5712,31 +5762,18 @@

    -
    -

    ORGANIZER

    +
    +

    UID

    1

    -
    -
    -

    UID

    -
    -
    -
    -

    1

    -
    -
    -

    MUST be the UID associated with original REQUEST.

    +
    +

    MUST be the UID associated with original REQUEST.

    - - - - - diff --git a/generated/draft-ietf-calext-vpoll.rfc.xml b/generated/draft-ietf-calext-vpoll.rfc.xml index 18fd88a..a4872a4 100644 --- a/generated/draft-ietf-calext-vpoll.rfc.xml +++ b/generated/draft-ietf-calext-vpoll.rfc.xml @@ -120,47 +120,44 @@ to maintain the state of the voting. For our simple example the following VPOLL properties and sub-components are either required or appropriate: -
    DTSTAMP
    The usual property. +
    DTSTAMP
    The usual property.
    SEQUENCE
    The usual property. See below for SEQUENCE behavior.
    UID
    The usual property. -
    ORGANIZER
    The usual property. In general this need not -be an organizer of any of the alternatives. In this simple -outline we assume it is the same. -
    SUMMARY
    The usual property. This optional but +
    SUMMARY
    The usual property. This optional but recommended property provides the a short title to the poll. -
    DESCRIPTION
    The usual property. This optional property +
    DESCRIPTION
    The usual property. This optional property provides more details. -
    DTEND
    The usual property. This optional property +
    DTEND
    The usual property. This optional property provides a poll closing time and date after which the VPOLL is no longer active. -
    POLL-MODE
    A new property which defines how the votes are used to +
    POLL-MODE
    A new property which defines how the votes are used to obtain a result. For our use case it will take the value "BASIC" meaning one event will be chosen from the alternatives. -
    POLL-COMPLETION
    A new property which defines who (server or client) +
    POLL-COMPLETION
    A new property which defines who (server or client) chooses and/or submits the winning choice. In our example the value is "SERVER-SUBMIT" which means the client chooses the winner but the server will submit the winning choice. -
    POLL-PROPERTIES
    A new property which defines which icalendar +
    POLL-PROPERTIES
    A new property which defines which icalendar properties are being voted on. For our use case it will take the value "DTSTART, LOCATION" meaning only those properties are significant for voting. Other properties in the events may differ but are not considered significant for the voting process. -
    PARTICIPANT
    There is one of these components for each voter with +
    PARTICIPANT
    There is one of these components for each voter with the PARTICIPANT-TYPE set to "VOTER". The CALENDAR-ADDRESS property identifies the voter and this component will contain one VOTE component for each item being voted on. -
    VOTE
    A new component. There is one of these for each voter and +
    VOTE
    A new component. There is one of these for each voter and choice. It usually contains at least a POLL-ITEM-ID property to identify the choice and a RESPONSE property to provide a vote. For more complex poll modes it may contain other information such as cost or estimated duration. -
    VEVENT
    In our simple use case there will be multiple VEVENT sub- +
    VEVENT
    In our simple use case there will be multiple VEVENT sub- components defining the alternatives. Each will have a different date and or time for the meeting.
    -EXAMPLEVPOLL with 3 voters and 3 alternative meetings:EXAMPLEVPOLL with 3 voters and 3 alternative meetings: component containing their vote. In our simple case it will have the following properties and components: -
    DTSTAMP
    The usual property. +
    DTSTAMP
    The usual property.
    SEQUENCE
    The usual property. See below for SEQUENCE behavior.
    UID
    Same as the request. -
    ORGANIZER
    Same as the request. -
    SUMMARY
    Same as the request. -
    PARTICIPANT
    One only with a CALENDAR-ADDRESS identifying the voter replying. -
    VOTE
    One per item being voted on. -
    POLL-ITEM-ID
    One inside each VOTE component to identify the choice. -
    RESPONSE
    One inside each VOTE component to specify the vote. +
    SUMMARY
    Same as the request. +
    PARTICIPANT
    One only with a CALENDAR-ADDRESS identifying the voter replying. +
    VOTE
    One per item being voted on. +
    POLL-ITEM-ID
    One inside each VOTE component to identify the choice. +
    RESPONSE
    One inside each VOTE component to specify the vote.
    Note that a voter can send a number of REPLYs for each REQUEST sent @@ -240,12 +235,11 @@ with a vote for only item 3, the final outcome is one vote on item 3.
    NOTE
    This is poll-mode specific behavior.
    -EXAMPLEREPLY VPOLL from Cyrus:EXAMPLEREPLY VPOLL from Cyrus:
    VPOLL updates -When the organizer receives a response from one or more voters the +When the owner receives a response from one or more voters the current state of the poll is sent to all voters. The new iTip method POLLSTATUS is used. The VPOLL can contain a reduced set of -properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, -ORGANIZER and one or more PARTICIPANT components each populated with zero or more VOTE components. +properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, and +one or more PARTICIPANT components each populated with zero or more VOTE components. -EXAMPLEEXAMPLE
    @@ -344,12 +355,11 @@ COMPLETION property is set to SERVER-SUBMIT the server will submit the winning choice and when it has done so set the STATUS to "SUBMITTED". -EXAMPLEVPOLL confirmation:EXAMPLEVPOLL confirmation:
    Format Definition
    This property is defined by the following notation:
    - -
    New Participant Properties +
    New Participant Properties for iTip -The following properties are defined to be used within PARTICIPANT and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component. +The following properties are defined to be used within PARTICIPANT during scheduling and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.
    Kind @@ -931,7 +945,7 @@ kindparams = *(";" other-param)]]> This specification redefines the PARTICIPATION-TYPE property allowing it to take multiple values and extending those values to align with roles and add a new "VOTER" role. There are also changes to the description to clarify it's use defining the roles that participant takes. -
    Property name
    PARTICIPANT-TYPE +
    Property name
    PARTICIPANT-TYPE
    Purpose
    This property is equivalent to the ATTENDEE ROLE parameter but includes more values to align with .
    Value Type
    The value type for this property is TEXT. The allowable values are defined below.
    Property Parameters
    Non-standard or iana parameters can be @@ -943,7 +957,9 @@ roles the participant takes.
    Note that the kind of participant, for example individual or group, is defined in the KIND property specified here. -Do we need a separate registry or should we extend that one? +Some of the roles are required for the participant to be a schedulable object. These are the roles that are shown below. +* +Do we need a separate registry or should we extend that one?
    Format Definition
    This property is defined by the following notation:
    @@ -995,7 +1011,7 @@ partvalueparam = *(";" other-param)]]>
    Table 11: @@ -5874,61 +5911,48 @@

    -
    -

    ORGANIZER

    +
    +

    SUMMARY

    1

    -
    -
    -

    SUMMARY

    -
    -
    -

    1

    -
    -
    -
    -

    Can be null.

    +
    +

    Can be null.

    -
    -

    UID

    +
    +

    UID

    -
    -

    1

    +
    +

    1

    -
    -

    SEQUENCE

    +
    +

    SEQUENCE

    -
    -

    0 or 1

    +
    +

    0 or 1

    -
    -

    MUST be present if value is greater than 0; MAY be present if 0.

    +
    +

    MUST be present if value is greater than 0; MAY be present if 0.

    information
    -To map PARTICIPANT-TYPE or jscalendar roles to ROLE values use the following. +The following table shows those roles that MUST appear in the PARTICIPANT-TYPE for group-scheduling. Additionally, the mapping PARTICIPANT-TYPE or jscalendar roles to ATTENDEE and ORGANIZER values are shown.
    PARTICIPANT-TYPEjsCalendarRFC5545 ROLE
    OWNER owner @@ -1151,13 +1167,41 @@ specified on this property. langparams = *(";" other-param)]]> + + +
    Expect reply + +
    Property name
    EXPECT-REPLY +
    Purpose
    If true, the organizer is expecting the participant to notify them of their participation status. +
    Property Parameters
    Non-standard or iana parameters can be +specified on this property. +
    Conformance
    This property MAY be specified once in the PARTICIPANT component. +
    Format Definition
    This property is defined by the following notation: +
    + + +
    iTip With Participants The PARTICIPANT component introduced in with the addition of some properties defined in this specification mirrors the participant object in . -For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL defined here, only PARTICIPANT components MUST be used. +For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL, defined here, only PARTICIPANT components MUST be used. + +Note that extensions to the specification for VPOLL will be dealt with in later sections. + +A participant object that takes part in group scheduling MUST have the following characteristics: + +
    • It MUST have a calendar address ( CALENDAR-ADDRESS, calendarAddress).
    • +
    • It must have one or more scheduling role defined. (PARTICIPANT-TYPE or role)
    • +
    + +Scheduling with PARTICIPANT components behaves exactly as with ATTENDEE and ORGANIZER properties. When iTip specifies the setting of ATTENDEE or ORGANIZER parameters then the appropriate PARTICIPANT property will be set.
    Attendee parameters mapping @@ -1197,9 +1241,9 @@ langparams = *(";" other-param)]]>
    iTIP Extensions -This specification introduces a number of extensions to . +This specification introduces a number of extensions to . In group scheduling the parties involved are organizer and attendees. -In VPOLL the parties are organizer and voters. +In VPOLL the parties are owner and voter participants. For many of the iTip processing rules the voters take the place of attendees. @@ -1209,7 +1253,7 @@ attendees. There are some extensions to the behavior of iTip methods for a VPOLL object and two new methods are defined. -
    MethodDescription
    PUBLISH +
    MethodDescription
    PUBLISH No changes (yet)
    REQUEST Each child component MUST have a POLL-ITEM-ID @@ -1229,7 +1273,7 @@ time. The VPOLL MUST have one voter only. There MUST be a single VPOLL component with UID matching that of the poll being cancelled.
    REFRESH -The organizer returns a METHOD:REQUEST with the +The owner returns a METHOD:REQUEST with the current full state, or a METHOD:CANCEL or an error if no matching poll is found.
    COUNTER @@ -1237,16 +1281,16 @@ error if no matching poll is found.
    DECLINECOUNTER Not supported for VPOLL.
    POLLSTATUS -Used to send the current state of the poll to +Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE -(if not 0), UID, ORGANIZER and PARTICIPANTS. +(if not 0), UID and PARTICIPANTS. One PARTICIPANT MUST be the owner.
    The following table shows the above methods broken down by who can send them with VPOLL components. -
    OriginatorMethods
    Organizer +
    OriginatorMethods
    Owner CANCEL, PUBLISH, REQUEST, POLLSTATUS
    Voter REPLY, REFRESH, REQUEST (only when delegating) @@ -1255,8 +1299,8 @@ send them with VPOLL components.
    Interoperability Models -Most of the standard iTip specification applies with respect to -organizer and voters. +Most of the standard iTip specification applies with respect to +owner and voters.
    Delegation @@ -1312,7 +1356,7 @@ appear in the iCalendar object. The following summarizes the methods that are defined for the "VPOLL" calendar component. -
    MethodDescription
    PUBLISH +
    MethodDescription
    PUBLISH Post notification of an poll. Used primarily as a method of advertising the existence of a poll.
    REQUEST @@ -1330,25 +1374,25 @@ range 0 to 100.
    CANCEL Cancel a poll.
    REFRESH -A request is sent to an Organizer by a Voter asking +A request is sent to a poll owner by a voter asking for the latest version of a poll to be resent to the requester.
    POLLSTATUS -Used to send the current state of the poll to all +Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE (if -not 0), UID, ORGANIZER and PARTICIPANT. +not 0), UID, and PARTICIPANT.
    Method: PUBLISH -The "PUBLISH" method in a "VPOLL" calendar component is an +The "PUBLISH" method in a "VPOLL" calendar component is an unsolicited posting of an iCalendar object. Any CU may add published -components to their calendar. The "Organizer" MUST be present in a +components to their calendar. An owner participant MUST be present in a published iCalendar component. "Voters" MUST NOT be present. Its expected usage is for encapsulating an arbitrary poll as an iCalendar -object. The "Organizer" may subsequently update (with another +object. The "Owner" may subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published "VPOLL" calendar component. @@ -1366,7 +1410,7 @@ property constraints defined in section .< The "REQUEST" method in a "VPOLL" component provides the following scheduling functions: -
    • Invite "Voters" to respond to the poll.
    • +
      • Invite "Voters" to respond to the poll.
      • Change the items being voted upon.
      • Complete or confirm the poll.
      • Response to a "REFRESH" request.
      • @@ -1376,12 +1420,12 @@ scheduling functions:
      • For an existing "VPOLL" calendar component, delegate the role of "Voter" to another CU.
      • For an existing "VPOLL" calendar component, change the role of -"Organizer" to another CU.
      • +"Owner" to another CU.
      -The "Organizer" originates the "REQUEST". The recipients of the +The "Owner" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs voting in the poll, the "Voters". -"Voters" use the "REPLY" method to convey votes to the "Organizer". +"Voters" use the "REPLY" method to convey votes to the "Owner". The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in @@ -1421,10 +1465,10 @@ as the value for the existing poll, then the "REQUEST" method describes an update of the poll details, but not a rescheduling of the POLL. -The update "REQUEST" method is the appropriate response to a -"REFRESH" method sent from a "Voter" to the "Organizer" of a poll. +The update "REQUEST" method is the appropriate response to a +"REFRESH" method sent from a "Voter" to the "Owner" of a poll. -The "Organizer" of a poll may also send unsolicited "REQUEST" +The "Owner" of a poll may also send unsolicited "REQUEST" methods. The unsolicited "REQUEST" methods may be used to update the details of the poll without rescheduling it, to update the "RESPONSE" parameter of "Voters", or to reconfirm the poll. @@ -1446,86 +1490,84 @@ voting is completed. The STATUS MUST be set to COMPLETED.
      Delegating a Poll to Another CU -Some calendar and scheduling systems allow "Voters" to delegate the +Some calendar and scheduling systems allow "Voters" to delegate the vote to another "Calendar User". iTIP supports this concept using the following workflow. Any "Voter" may delegate their right to vote in a poll to another CU. The implication is that the delegate participates in lieu of the original "Voter", NOT in addition to the -"Voter". The delegator MUST notify the "Organizer" of this action +"Voter". The delegator MUST notify the "Owner" of this action using the steps outlined below. Implementations may support or restrict delegation as they see fit. For instance, some implementations may restrict a delegate from delegating a "REQUEST" to another CU. -The "Delegator" of a poll forwards the existing "REQUEST" to the +The "Delegator" of a poll forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include a "Voter" property with the calendar address of the "Delegate". The "Delegator" MUST -also send a "REPLY" method to the "Organizer" with the "Delegator's" +also send a "REPLY" method to the "Owner" with the "Delegator's" "Voter" property "DELEGATED-TO" parameter set to the calendar address of the "Delegate". Also, a new "Voter" property for the "Delegate" MUST be included and must specify the calendar user address set in the "DELEGATED-TO" parameter, as above. -In response to the request, the "Delegate" MUST send a "REPLY" method -to the "Organizer", and optionally to the "Delegator". The "REPLY" +In response to the request, the "Delegate" MUST send a "REPLY" method +to the "Owner", and optionally to the "Delegator". The "REPLY" -method SHOULD include the "Voter" property with the "DELEGATED-FROM" -parameter value of the "Delegator's" calendar address. +method SHOULD include the "Voter" participant with the "PARTICIPANT-DELEGATED-FROM" +property value of the "Delegator's" calendar address. -The "Delegator" may continue to receive updates to the poll even +The "Delegator" may continue to receive updates to the poll even though they will not be attending. This is accomplished by the -"Delegator" setting their "role" attribute to "NON-PARTICIPANT" in -the "REPLY" to the "Organizer". +"Delegator" setting their "role" attribute to "INFORMATIONAL" in +the "REPLY" to the "Owner".
      -
      Changing the Organizer +
      Changing the Owner -The situation may arise where the "Organizer" of a "VPOLL" is no -longer able to perform the "Organizer" role and abdicates without -passing on the "Organizer" role to someone else. When this occurs, +The situation may arise where the "Owner" of a "VPOLL" is no +longer able to perform the "Owner" role and abdicates without +passing on the "Owner" role to someone else. When this occurs, the "Voters" of the "VPOLL" may use out-of-band mechanisms to -communicate the situation and agree upon a new "Organizer". The new -"Organizer" should then send out a new "REQUEST" with a modified +communicate the situation and agree upon a new "Owner". The new +"Owner" should then send out a new "REQUEST" with a modified version of the "VPOLL" in which the "SEQUENCE" number has been -incremented and the "ORGANIZER" property has been changed to the new -"Organizer". +incremented and the owner role assigned to the appropriate "PARTICIPANT".
      -
      Sending on Behalf of the Organizer +
      Sending on Behalf of the Owner -There are a number of scenarios that support the need for a "Calendar -User" to act on behalf of the "Organizer" without explicit role -changing. This might be the case if the CU designated as "Organizer" +There are a number of scenarios that support the need for a "Calendar +User" to act on behalf of the "Owner" without explicit role +changing. This might be the case if the CU designated as "Owner" is sick or unable to perform duties associated with that function. In these cases, iTIP supports the notion of one CU acting on behalf -of another. Using the "SENT-BY" parameter, a "Calendar User" could -send an updated "VPOLL" "REQUEST". In the case where one CU sends on +of another. In the case where one CU sends on behalf of another CU, the "Voter" responses are still directed back -towards the CU designated as "Organizer". +towards the CU designated as "Owner".
      Forwarding to an Uninvited CU -A "Voter" invited to a "VPOLL" calendar component may send the +A "Voter" invited to a "VPOLL" calendar component may send the "VPOLL" calendar component to another new CU not previously associated with the "VPOLL" calendar component. The current "Voter" participating in the "VPOLL" calendar component does this by forwarding the original "REQUEST" method to the new CU. The new CU -can send a "REPLY" to the "Organizer" of the "VPOLL" calendar -component. The reply contains a "Voter" property for the new CU. +can send a "REPLY" to the "Owner" of the "VPOLL" calendar +component. The reply contains a "Voter" participant component for the new CU. -The "Organizer" ultimately decides whether or not the new CU becomes +The "Owner" ultimately decides whether the new CU becomes part of the poll and is not obligated to do anything with a "REPLY" -from a new (uninvited) CU. If the "Organizer" does not want the new -CU to be part of the poll, the new "Voter" property is not added to -the "VPOLL" calendar component. The "Organizer" MAY send the CU a +from a new (uninvited) CU. If the "Owner" does not want the new +CU to be part of the poll, the new "Voter" is not added to +the "VPOLL" calendar component. The "Owner" MAY send the CU a "CANCEL" message to indicate that they will not be added to the poll. -If the "Organizer" decides to add the new CU, the new "Voter" -property is added to the "VPOLL" calendar component. Furthermore, -the "Organizer" is free to change any "Voter" property parameter from -the values supplied by the new CU to something the "Organizer" -considers appropriate. The "Organizer" SHOULD send the new CU a +If the "Owner" decides to add the new CU, a new participant for the "Voter" +is added to the "VPOLL" calendar component. Furthermore, +the "Owner" is free to change any "Voter" participant property values from +the values supplied by the new CU to something the "Owner" +considers appropriate. The "Owner" SHOULD send the new CU a "REQUEST" message to inform them that they have been added. When forwarding a "REQUEST" to another CU, the forwarding "Voter" @@ -1534,12 +1576,12 @@ MUST NOT make changes to the original message.
      Updating Voter Status -The "Organizer" of an poll may also request updated status from one -or more "Voters". The "Organizer" sends a "REQUEST" method to the -"Voter" and sets the "RSVP=TRUE" property parameter on the PARTICIPANT CALENDAR-ADDRESS. The +The "Owner" of a poll may also request updated status from one +or more "Voters". The "Owner" sends a "REQUEST" method to the +"Voter" and sets the "EXPECT-REPLY" property value to TRUE. The "SEQUENCE" property for the poll is not changed from its previous value. A recipient will determine that the only change in the -"REQUEST" is that their "RSVP" property parameter indicates a request +"REQUEST" is that their "EXPECT-REPLY" property indicates a request for updated status. The recipient SHOULD respond with a "REPLY" method indicating their current vote with respect to the "REQUEST".
      @@ -1560,21 +1602,21 @@ property. The "Delegate" SHOULD include the calendar address of the Depending on the value of the "REQUEST-STATUS" property, no action may have been performed.
      -The "Organizer" of a poll may receive the "REPLY" method from a CU +The "Owner" of a poll may receive the "REPLY" method from a CU not in the original "REQUEST". For example, a "REPLY" may be received from a "Delegate" to a poll. In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This -uninvited "Voter" may be accepted, or the "Organizer" may cancel the +uninvited "Voter" may be accepted, or the "Owner" may cancel the poll for the uninvited "Voter" by sending a "CANCEL" method to the uninvited "Voter". -A "Voter" MAY include a message to the "Organizer" using the -"COMMENT" property. For example, if the user indicates a low -interest and wants to let the "Organizer" know why, the reason can be +A "Voter" MAY include a message to the "Owner" using the +"COMMENT" property in the PARTICIPANT component. For example, if the user indicates a low +interest and wants to let the "Owner" know why, the reason can be expressed in the "COMMENT" property value. -The "Organizer" may also receive a "REPLY" from one CU on behalf of -another. Like the scenario enumerated above for the "Organizer", +The "Owner" may also receive a "REPLY" from one CU on behalf of +another. Like the scenario enumerated above for the "Owner", "Voters" may have another CU respond on their behalf. This is done using the "SENT-BY" parameter. @@ -1587,7 +1629,7 @@ and a single VPOLL object. That object MUST contain the properties shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present. -Constraints for a METHOD:REPLY of a VPOLL
      Component/PropertyPresenceComment
      METHOD +Constraints for a METHOD:REPLY of a VPOLL
      Component/PropertyPresenceComment
      METHOD 1 MUST be REPLY.
      VPOLL @@ -1599,36 +1641,34 @@ ignored by the recipient if present. Identifies the Voter replying.
      DTSTAMP 1 -
      ORGANIZER +
      UID 1 -
      UID -1 -MUST be the UID of the original -
      REQUEST. -
      SEQUENCE +MUST be the UID of the original +
      REQUEST. +
      SEQUENCE +0 or 1 +If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0. +
      ACCEPT-RESPONSE 0 or 1 -If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0. -
      ACCEPT-RESPONSE -0 or 1 -
      POLL-ITEM-ID -1+ -One per item being voted on. -
      VFREEBUSY -0 or 1 -A voter may respond with a VFREEBUSY component indicating that the ORGANIZER may select some other time which is not marked as busy. -
      VAVAILABILITY -0 -A voter may respond with a VAVAILABILITY component indicating that the ORGANIZER may select some other time which is shown as available. +
      POLL-ITEM-ID +1+ +One per item being voted on. +
      VFREEBUSY +0 or 1 +A voter may respond with a VFREEBUSY component indicating that the "Owner" may select some other time which is not marked as busy. +
      VAVAILABILITY +0 +A voter may respond with a VAVAILABILITY component indicating that the "Owner" may select some other time which is shown as available.
      Method: CANCEL -The "CANCEL" method in a "VPOLL" calendar component is used to send a +The "CANCEL" method in a "VPOLL" calendar component is used to send a cancellation notice of an existing poll request to the affected -"Voters". The message is sent by the "Organizer" of the poll. +"Voters". The message is sent by the "Owner" of the poll. -The "Organizer" MUST send a "CANCEL" message to each "Voter" affected +The "Owner" MUST send a "CANCEL" message to each "Voter" affected by the cancellation. This can be done using a single "CANCEL" message for all "Voters" or by using multiple messages with different subsets of the affected "Voters" in each. @@ -1644,7 +1684,7 @@ and one or more VPOLL objects. Those objects MUST contain the properties shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present. -Constraints for a METHOD:CANCEL of a VPOLL
      Component/PropertyPresenceComment
      METHOD +Constraints for a METHOD:CANCEL of a VPOLL
      Component/PropertyPresenceComment
      METHOD 1 MUST be CANCEL.
      VPOLL @@ -1658,26 +1698,24 @@ ignored by the recipient if present. MUST be the UID of the original REQUEST.
      DTSTAMP 1 -
      ORGANIZER +
      SEQUENCE 1 -
      SEQUENCE -1
      Method: REFRESH -The "REFRESH" method in a "VPOLL" calendar component is used by +The "REFRESH" method in a "VPOLL" calendar component is used by "Voters" of an existing event to request an updated vpoll status from -the poll "Organizer". The "REFRESH" method MUST specify the "UID" -property of the poll to update. The "Organizer" responds with a +the poll "Owner". The "REFRESH" method MUST specify the "UID" +property of the poll to update. The "Owner" responds with a METHOD=REQUEST giving the latest status and version of the poll. This method type has a "METHOD" property with the value "REFRESH" and a single VPOLL object. That object MUST contain the properties shown below and no others. -Constraints for a METHOD:REFRESH of a VPOLL
      Component/PropertyPresenceComment
      METHOD +Constraints for a METHOD:REFRESH of a VPOLL
      Component/PropertyPresenceComment
      METHOD 1 MUST be REFRESH.
      VPOLL @@ -1687,19 +1725,17 @@ shown below and no others. MUST identify the requester as a voter.
      DTSTAMP 1 -
      ORGANIZER +
      UID 1 -
      UID -1 -MUST be the UID associated with original REQUEST. +MUST be the UID associated with original REQUEST.
      Method: POLLSTATUS -The "POLLSTATUS" method in a "VPOLL" calendar component is used to +The "POLLSTATUS" method in a "VPOLL" calendar component is used to inform recipients of the current status of the poll in a compact -manner. The "Organizer" MUST be present in the confirmed poll +manner. The "Owner" participant MUST be present in the confirmed poll component. All "Voters" MUST be present. The selected component(s) according to the poll mode SHOULD NOT be present in the poll component. Clients receiving this message may store the confirmed @@ -1712,7 +1748,7 @@ shown below and no others. This method type is an iCalendar object that conforms to the following property constraints: -Constraints for a METHOD:POLLSTATUS of a VPOLL
      Component/PropertyPresenceComment
      METHOD +Constraints for a METHOD:POLLSTATUS of a VPOLL
      Component/PropertyPresenceComment
      METHOD 1 MUST equal POLLSTATUS.
      VPOLL @@ -1727,16 +1763,14 @@ following property constraints: 1
      DTSTART 0 or 1 -
      ORGANIZER +
      SUMMARY 1 -
      SUMMARY +Can be null. +
      UID 1 -Can be null. -
      UID -1 -
      SEQUENCE -0 or 1 -MUST be present if value is greater than 0; MAY be present if 0. +
      SEQUENCE +0 or 1 +MUST be present if value is greater than 0; MAY be present if 0.
      diff --git a/generated/draft-ietf-calext-vpoll.txt b/generated/draft-ietf-calext-vpoll.txt index 0fae4bf..f5b2a4b 100644 --- a/generated/draft-ietf-calext-vpoll.txt +++ b/generated/draft-ietf-calext-vpoll.txt @@ -5,7 +5,7 @@ Network Working Group E. York Internet-Draft Intended status: Standards Track M. Douglass -Expires: 22 October 2024 20 April 2024 +Expires: 24 October 2024 22 April 2024 VPOLL: Consensus Scheduling Component for iCalendar @@ -32,7 +32,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 22 October 2024. + This Internet-Draft will expire on 24 October 2024. Copyright Notice @@ -53,7 +53,7 @@ Copyright Notice -York & Douglass Expires 22 October 2024 [Page 1] +York & Douglass Expires 24 October 2024 [Page 1] Internet-Draft VPOLL April 2024 @@ -71,31 +71,31 @@ Table of Contents 3.3. VPOLL responses . . . . . . . . . . . . . . . . . . . . . 8 3.4. VPOLL updates . . . . . . . . . . . . . . . . . . . . . . 9 3.5. VPOLL Completion . . . . . . . . . . . . . . . . . . . . 11 - 3.6. Other Responses . . . . . . . . . . . . . . . . . . . . . 11 + 3.6. Other Responses . . . . . . . . . . . . . . . . . . . . . 12 4. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 12 4.1. Updated Participant Type Value . . . . . . . . . . . . . 12 - 4.2. Updated Relation Type Value . . . . . . . . . . . . . . . 12 + 4.2. Updated Relation Type Value . . . . . . . . . . . . . . . 13 4.3. Updated Status Value . . . . . . . . . . . . . . . . . . 13 - 4.4. New Property Parameters . . . . . . . . . . . . . . . . . 13 - 4.4.1. Required . . . . . . . . . . . . . . . . . . . . . . 13 + 4.4. New Property Parameters . . . . . . . . . . . . . . . . . 14 + 4.4.1. Required . . . . . . . . . . . . . . . . . . . . . . 14 4.4.2. Stay-Informed . . . . . . . . . . . . . . . . . . . . 14 4.5. New Properties . . . . . . . . . . . . . . . . . . . . . 14 - 4.5.1. Accept-Response . . . . . . . . . . . . . . . . . . . 14 + 4.5.1. Accept-Response . . . . . . . . . . . . . . . . . . . 15 4.5.2. Poll-Completion . . . . . . . . . . . . . . . . . . . 15 4.5.3. Poll-Item-Id . . . . . . . . . . . . . . . . . . . . 16 - 4.5.4. Poll-Mode . . . . . . . . . . . . . . . . . . . . . . 16 - 4.5.5. Poll-properties . . . . . . . . . . . . . . . . . . . 17 - 4.5.6. Poll-Winner . . . . . . . . . . . . . . . . . . . . . 17 - 4.5.7. Reply-URL . . . . . . . . . . . . . . . . . . . . . . 18 + 4.5.4. Poll-Mode . . . . . . . . . . . . . . . . . . . . . . 17 + 4.5.5. Poll-properties . . . . . . . . . . . . . . . . . . . 18 + 4.5.6. Poll-Winner . . . . . . . . . . . . . . . . . . . . . 18 + 4.5.7. Reply-URL . . . . . . . . . . . . . . . . . . . . . . 19 4.5.8. Response . . . . . . . . . . . . . . . . . . . . . . 19 - 4.6. New Components . . . . . . . . . . . . . . . . . . . . . 19 - 4.6.1. VPOLL Component . . . . . . . . . . . . . . . . . . . 19 + 4.6. New Components . . . . . . . . . . . . . . . . . . . . . 20 + 4.6.1. VPOLL Component . . . . . . . . . . . . . . . . . . . 20 4.6.2. VOTE Component . . . . . . . . . . . . . . . . . . . 22 5. Poll Modes . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. POLL-MODE:BASIC . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. Property restrictions . . . . . . . . . . . . . . . . 24 5.1.2. Outcome reporting . . . . . . . . . . . . . . . . . . 24 - 6. New Participant Properties . . . . . . . . . . . . . . . . . 24 + 6. New Participant Properties for iTip . . . . . . . . . . . . . 24 6.1. Kind . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Redefined participation type . . . . . . . . . . . . . . 25 6.3. Participation-status . . . . . . . . . . . . . . . . . . 29 @@ -103,25 +103,26 @@ Table of Contents 6.5. Participation delegated to . . . . . . . . . . . . . . . 30 6.6. Member of . . . . . . . . . . . . . . . . . . . . . . . . 31 6.7. Lang . . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 6.8. Expect reply . . . . . . . . . . . . . . . . . . . . . . 32 7. iTip With Participants . . . . . . . . . . . . . . . . . . . 32 - 7.1. Attendee parameters mapping . . . . . . . . . . . . . . . 32 - 8. iTIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 33 + 7.1. Attendee parameters mapping . . . . . . . . . . . . . . . 33 -York & Douglass Expires 22 October 2024 [Page 2] +York & Douglass Expires 24 October 2024 [Page 2] Internet-Draft VPOLL April 2024 - 8.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 8. iTIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.2. Interoperability Models . . . . . . . . . . . . . . . . . 35 8.2.1. Delegation . . . . . . . . . . . . . . . . . . . . . 35 8.2.2. Acting on Behalf of Other Calendar Users . . . . . . 35 8.2.3. Component Revisions . . . . . . . . . . . . . . . . . 35 8.2.4. Message Sequencing . . . . . . . . . . . . . . . . . 35 8.3. Application Protocol Elements . . . . . . . . . . . . . . 35 - 8.3.1. Methods for VPOLL Calendar Components . . . . . . . . 35 + 8.3.1. Methods for VPOLL Calendar Components . . . . . . . . 36 8.3.2. Method: PUBLISH . . . . . . . . . . . . . . . . . . . 37 8.3.3. Method: REQUEST . . . . . . . . . . . . . . . . . . . 38 8.3.4. Method: REPLY . . . . . . . . . . . . . . . . . . . . 42 @@ -164,8 +165,7 @@ Internet-Draft VPOLL April 2024 - -York & Douglass Expires 22 October 2024 [Page 3] +York & Douglass Expires 24 October 2024 [Page 3] Internet-Draft VPOLL April 2024 @@ -221,7 +221,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 4] +York & Douglass Expires 24 October 2024 [Page 4] Internet-Draft VPOLL April 2024 @@ -268,23 +268,20 @@ Internet-Draft VPOLL April 2024 UID The usual [RFC5545] property. - ORGANIZER The usual [RFC5545] property. In general this need not be - an organizer of any of the alternatives. In this simple outline - we assume it is the same. - SUMMARY The usual [RFC5545] property. This optional but recommended property provides the a short title to the poll. + DESCRIPTION The usual [RFC5545] property. This optional property + provides more details. + -York & Douglass Expires 22 October 2024 [Page 5] + +York & Douglass Expires 24 October 2024 [Page 5] Internet-Draft VPOLL April 2024 - DESCRIPTION The usual [RFC5545] property. This optional property - provides more details. - DTEND The usual [RFC5545] property. This optional property provides a poll closing time and date after which the VPOLL is no longer active. @@ -333,7 +330,10 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 6] + + + +York & Douglass Expires 24 October 2024 [Page 6] Internet-Draft VPOLL April 2024 @@ -346,7 +346,6 @@ Internet-Draft VPOLL April 2024 POLL-MODE:BASIC POLL-COMPLETION:SERVER-SUBMIT POLL-PROPERTIES:DTSTART,LOCATION - ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T000000Z SUMMARY:What to do this week @@ -360,7 +359,7 @@ Internet-Draft VPOLL April 2024 CALENDAR-ADDRESS:mailto:eric@example.com END:PARTICIPANT BEGIN:PARTICIPANT - PARTICIPANT-TYPE: VOTER + PARTICIPANT-TYPE: VOTER,OWNER CALENDAR-ADDRESS:mailto:mike@example.com END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) @@ -386,16 +385,15 @@ Internet-Draft VPOLL April 2024 VPOLL. POLL-ITEM-ID This provides a unique reference to the sub-component + within the VPOLL. It's value SHOULD be a small integer. -York & Douglass Expires 22 October 2024 [Page 7] +York & Douglass Expires 24 October 2024 [Page 7] Internet-Draft VPOLL April 2024 - within the VPOLL. It's value SHOULD be a small integer. - 3.3. VPOLL responses Upon receipt of a VPOLL REQUEST the voter will reply with a VPOLL @@ -409,8 +407,6 @@ Internet-Draft VPOLL April 2024 UID Same as the request. - ORGANIZER Same as the request. - SUMMARY Same as the request. PARTICIPANT One only with a CALENDAR-ADDRESS identifying the voter @@ -445,7 +441,11 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 8] + + + + +York & Douglass Expires 24 October 2024 [Page 8] Internet-Draft VPOLL April 2024 @@ -455,7 +455,6 @@ Internet-Draft VPOLL April 2024 PRODID:-//Example//Example METHOD: REPLY BEGIN:VPOLL - ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T010000Z SUMMARY:What to do this week @@ -482,39 +481,31 @@ Internet-Draft VPOLL April 2024 3.4. VPOLL updates - When the organizer receives a response from one or more voters the + When the owner receives a response from one or more voters the current state of the poll is sent to all voters. The new iTip method POLLSTATUS is used. The VPOLL can contain a reduced set of - properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, - ORGANIZER and one or more PARTICIPANT components each populated with - zero or more VOTE components. + properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, and + one or more PARTICIPANT components each populated with zero or more + VOTE components. EXAMPLE - - - - - - - - - - -York & Douglass Expires 22 October 2024 [Page 9] - -Internet-Draft VPOLL April 2024 - - BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD: POLLSTATUS BEGIN:VPOLL - ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T020000Z SEQUENCE:0 + + + +York & Douglass Expires 24 October 2024 [Page 9] + +Internet-Draft VPOLL April 2024 + + SUMMARY:What to do this week BEGIN:PARTICIPANT PARTICIPANT-TYPE: VOTER @@ -550,18 +541,35 @@ Internet-Draft VPOLL April 2024 RESPONSE:0 END:VOTE END:PARTICIPANT - END:VPOLL - END:VCALENDAR - - + BEGIN:PARTICIPANT + PARTICIPANT-TYPE: VOTER,OWNER + CALENDAR-ADDRESS:mailto:mike@example.com + BEGIN: VOTE + POLL-ITEM-ID:1 + RESPONSE:50 + COMMENT:Work on iTIP + END:VOTE + BEGIN:VOTE + POLL-ITEM-ID:2 + RESPONSE:100 + COMMENT:Work on WebDAV + END:VOTE -York & Douglass Expires 22 October 2024 [Page 10] +York & Douglass Expires 24 October 2024 [Page 10] Internet-Draft VPOLL April 2024 + BEGIN:VOTE + POLL-ITEM-ID:3 + RESPONSE:0 + END:VOTE + END:PARTICIPANT + END:VPOLL + END:VCALENDAR + 3.5. VPOLL Completion After a number of REPLY messages have been received the poll will be @@ -583,12 +591,38 @@ Internet-Draft VPOLL April 2024 VPOLL confirmation: + + + + + + + + + + + + + + + + + + + + + + +York & Douglass Expires 24 October 2024 [Page 11] + +Internet-Draft VPOLL April 2024 + + BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD: REQUEST BEGIN:VPOLL - ORGANIZER:mailto:douglm@example.com UID:sched01-1234567890 DTSTAMP:20120101T030000Z COMPLETED:20120101T030000Z @@ -597,6 +631,10 @@ Internet-Draft VPOLL April 2024 SUMMARY:What to do this week STATUS:CONFIRMED POLL-WINNER:3 + BEGIN:PARTICIPANT + PARTICIPANT-TYPE: OWNER + CALENDAR-ADDRESS:mailto:mike@example.com + END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) END:VEVENT BEGIN:VEVENT.......(with a poll-item-id=2) @@ -611,13 +649,6 @@ Internet-Draft VPOLL April 2024 A voter being asked to choose between a number of ORGANIZER supplied alternatives may find none of them acceptable or may simply not care. - - -York & Douglass Expires 22 October 2024 [Page 11] - -Internet-Draft VPOLL April 2024 - - An alternative response, which may be disallowed by the ORGANIZER, is to send back the respondees availability or freebusy or even one or more new, alternative choices. @@ -636,6 +667,13 @@ Internet-Draft VPOLL April 2024 participant type VOTER to provide information about the voter and to contain their votes. + + +York & Douglass Expires 24 October 2024 [Page 12] + +Internet-Draft VPOLL April 2024 + + Format Definition This property parameter is redefined by the following notation: @@ -662,18 +700,6 @@ Internet-Draft VPOLL April 2024 value indicates that the associated property references a VPOLL component which contains the current component. - - - - - - - -York & Douglass Expires 22 October 2024 [Page 12] - -Internet-Draft VPOLL April 2024 - - 4.3. Updated Status Value Status property values are defined in section 3.8.1.11. of [RFC5545]. @@ -697,6 +723,13 @@ Internet-Draft VPOLL April 2024 Description These values allow clients and servers to handle the choosing and submission of winning choices. + + +York & Douglass Expires 24 October 2024 [Page 13] + +Internet-Draft VPOLL April 2024 + + If the client is choosing and the server submitting then the client should set the POLL-WINNER property, set the status to CONFIRMED and save the poll. When the server submits the winning @@ -723,13 +756,6 @@ Internet-Draft VPOLL April 2024 value is TRUE, indicates the organizer requires all replies to be made via the specified service rather than iTip replies. - - -York & Douglass Expires 22 October 2024 [Page 13] - -Internet-Draft VPOLL April 2024 - - 4.4.2. Stay-Informed Parameter name STAY-INFORMED @@ -750,6 +776,16 @@ Internet-Draft VPOLL April 2024 4.5. New Properties + + + + + +York & Douglass Expires 24 October 2024 [Page 14] + +Internet-Draft VPOLL April 2024 + + 4.5.1. Accept-Response Property name ACCEPT-RESPONSE @@ -779,13 +815,6 @@ Internet-Draft VPOLL April 2024 acceptresponseparams = *(";" other-param) - - -York & Douglass Expires 22 October 2024 [Page 14] - -Internet-Draft VPOLL April 2024 - - 4.5.2. Poll-Completion Property name POLL-COMPLETION @@ -805,6 +834,14 @@ Internet-Draft VPOLL April 2024 Server initiated submission requires that the submitted choice MUST be a valid calendaring component. + + + +York & Douglass Expires 24 October 2024 [Page 15] + +Internet-Draft VPOLL April 2024 + + POLL-COMPLETION=SERVER-SUBMIT allows the client to set the poll- winner, set the status to CONFIRMED and then store the poll on the server. The server will then submit the winning choice and set @@ -833,15 +870,6 @@ Internet-Draft VPOLL April 2024 POLL-COMPLETION: SERVER-SUBMIT - - - - -York & Douglass Expires 22 October 2024 [Page 15] - -Internet-Draft VPOLL April 2024 - - 4.5.3. Poll-Item-Id Property name POLL-ITEM-ID @@ -861,6 +889,15 @@ Internet-Draft VPOLL April 2024 POLL-ITEM-ID property. Each set of components with the same POLL- ITEM-ID value represents one overall set of items to be voted on. + + + + +York & Douglass Expires 24 October 2024 [Page 16] + +Internet-Draft VPOLL April 2024 + + POLL-ITEM-ID SHOULD be a unique small integer for each component or set of components. If it remains the same between REQUESTs then the previous response for that component MAY be re-used. To @@ -890,14 +927,6 @@ Internet-Draft VPOLL April 2024 Conformance This property MAY be specified in a VPOLL component or its sub-components. - - - -York & Douglass Expires 22 October 2024 [Page 16] - -Internet-Draft VPOLL April 2024 - - Description The poll mode defines how the votes are applied to obtain a result. BASIC mode, the default, means that the voters are selecting one component (or group of components) with a given @@ -915,6 +944,16 @@ Internet-Draft VPOLL April 2024 pollmodeparams = *(";" other-param) + + + + + +York & Douglass Expires 24 October 2024 [Page 17] + +Internet-Draft VPOLL April 2024 + + 4.5.5. Poll-properties Property name POLL-PROPERTIES @@ -947,13 +986,6 @@ Internet-Draft VPOLL April 2024 Purpose This property is used in a basic mode VPOLL to indicate which of the VPOLL sub-components won. - - -York & Douglass Expires 22 October 2024 [Page 17] - -Internet-Draft VPOLL April 2024 - - Value type INTEGER Property Parameters Non-standard parameters can be specified on this @@ -970,6 +1002,14 @@ Internet-Draft VPOLL April 2024 Format Definition This property is defined by the following notation: + + + +York & Douglass Expires 24 October 2024 [Page 18] + +Internet-Draft VPOLL April 2024 + + pollwinner = "POLL-WINNER" pollwinnerparams ":" integer CRLF @@ -999,17 +1039,6 @@ Internet-Draft VPOLL April 2024 Format Definition This property is defined by the following notation: - - - - - - -York & Douglass Expires 22 October 2024 [Page 18] - -Internet-Draft VPOLL April 2024 - - reply-url = "REPLY-URL" reply-urlparams ":" uri CRLF reply-urlparams = *( @@ -1028,6 +1057,15 @@ Internet-Draft VPOLL April 2024 Format Definition This property is defined by the following notation: + + + + +York & Douglass Expires 24 October 2024 [Page 19] + +Internet-Draft VPOLL April 2024 + + response = "RESPONSE" response-params ":" integer CRLF ; integer value 0..100 @@ -1058,14 +1096,6 @@ Internet-Draft VPOLL April 2024 Component name VPOLL - - - -York & Douglass Expires 22 October 2024 [Page 19] - -Internet-Draft VPOLL April 2024 - - Purpose This component provides a mechanism by which voters can vote on provided choices. @@ -1087,37 +1117,7 @@ Internet-Draft VPOLL April 2024 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -York & Douglass Expires 22 October 2024 [Page 20] +York & Douglass Expires 24 October 2024 [Page 20] Internet-Draft VPOLL April 2024 @@ -1133,7 +1133,7 @@ Internet-Draft VPOLL April 2024 ; The following are REQUIRED, ; but MUST NOT occur more than once. ; - dtstamp / uid / organizer / + dtstamp / uid / ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. @@ -1173,7 +1173,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 21] +York & Douglass Expires 24 October 2024 [Page 21] Internet-Draft VPOLL April 2024 @@ -1229,7 +1229,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 22] +York & Douglass Expires 24 October 2024 [Page 22] Internet-Draft VPOLL April 2024 @@ -1285,7 +1285,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 23] +York & Douglass Expires 24 October 2024 [Page 23] Internet-Draft VPOLL April 2024 @@ -1320,12 +1320,12 @@ Internet-Draft VPOLL April 2024 winning entity to be distributed to the participants through iTip or some other protocol. -6. New Participant Properties +6. New Participant Properties for iTip The following properties are defined to be used within PARTICIPANT - and take the place of ATTENDEE and ORGANIZER properties and - parameters. These are not solely for VPOLL but may be used in any - future component. + during scheduling and take the place of ATTENDEE and ORGANIZER + properties and parameters. These are not solely for VPOLL but may be + used in any future component. 6.1. Kind @@ -1341,7 +1341,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 24] +York & Douglass Expires 24 October 2024 [Page 24] Internet-Draft VPOLL April 2024 @@ -1397,7 +1397,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 25] +York & Douglass Expires 24 October 2024 [Page 25] Internet-Draft VPOLL April 2024 @@ -1405,6 +1405,8 @@ Internet-Draft VPOLL April 2024 Note that the kind of participant, for example individual or group, is defined in the KIND property specified here. + Some of the roles are required for the participant to be a + schedulable object. These are the roles that are shown below. * Do we need a separate registry or should we extend that one? Format Definition This property is defined by the following @@ -1451,9 +1453,7 @@ Internet-Draft VPOLL April 2024 - - -York & Douglass Expires 22 October 2024 [Page 26] +York & Douglass Expires 24 October 2024 [Page 26] Internet-Draft VPOLL April 2024 @@ -1472,9 +1472,10 @@ Internet-Draft VPOLL April 2024 Table 1 - To map PARTICIPANT-TYPE or jscalendar roles to [RFC5545] ROLE values - use the following. - + The following table shows those roles that MUST appear in the + PARTICIPANT-TYPE for group-scheduling. Additionally, the mapping + PARTICIPANT-TYPE or jscalendar roles to [RFC5545] ATTENDEE and + ORGANIZER values are shown. @@ -1508,8 +1509,7 @@ Internet-Draft VPOLL April 2024 - -York & Douglass Expires 22 October 2024 [Page 27] +York & Douglass Expires 24 October 2024 [Page 27] Internet-Draft VPOLL April 2024 @@ -1565,7 +1565,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 28] +York & Douglass Expires 24 October 2024 [Page 28] Internet-Draft VPOLL April 2024 @@ -1621,7 +1621,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 29] +York & Douglass Expires 24 October 2024 [Page 29] Internet-Draft VPOLL April 2024 @@ -1677,7 +1677,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 30] +York & Douglass Expires 24 October 2024 [Page 30] Internet-Draft VPOLL April 2024 @@ -1733,11 +1733,33 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 31] +York & Douglass Expires 24 October 2024 [Page 31] Internet-Draft VPOLL April 2024 +6.8. Expect reply + + Property name EXPECT-REPLY + + Purpose If true, the organizer is expecting the participant to + notify them of their participation status. + + Property Parameters Non-standard or iana parameters can be specified + on this property. + + Conformance This property MAY be specified once in the PARTICIPANT + component. + + Format Definition This property is defined by the following + notation: + + expect-reply = "EXPECT-REPLY" + expect-replyparams ":" + ( "TRUE" / "FALSE") CRLF + + expect-replyparams = *(";" other-param) + 7. iTip With Participants The PARTICIPANT component introduced in [RFC9073] with the addition @@ -1747,7 +1769,35 @@ Internet-Draft VPOLL April 2024 For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such - as VPOLL defined here, only PARTICIPANT components MUST be used. + as VPOLL, defined here, only PARTICIPANT components MUST be used. + + Note that extensions to the [RFC5546] specification for VPOLL will be + dealt with in later sections. + + A participant object that takes part in group scheduling MUST have + the following characteristics: + + * It MUST have a calendar address ([RFC5545] CALENDAR-ADDRESS, + [RFC8984] calendarAddress). + + * It must have one or more scheduling role defined. (PARTICIPANT- + TYPE or [RFC8984] role) + + + + + + + +York & Douglass Expires 24 October 2024 [Page 32] + +Internet-Draft VPOLL April 2024 + + + Scheduling with PARTICIPANT components behaves exactly as with + ATTENDEE and ORGANIZER properties. When iTip specifies the setting + of ATTENDEE or ORGANIZER parameters then the appropriate PARTICIPANT + property will be set. 7.1. Attendee parameters mapping @@ -1785,20 +1835,20 @@ Internet-Draft VPOLL April 2024 Table 3 +8. iTIP Extensions + This specification introduces a number of extensions to [RFC5546]. + In group scheduling the parties involved are organizer and attendees. + In VPOLL the parties are owner and voter participants. -York & Douglass Expires 22 October 2024 [Page 32] - -Internet-Draft VPOLL April 2024 -8. iTIP Extensions +York & Douglass Expires 24 October 2024 [Page 33] + +Internet-Draft VPOLL April 2024 - This specification introduces a number of extensions to [RFC5546]. - In group scheduling the parties involved are organizer and attendees. - In VPOLL the parties are organizer and voters. For many of the iTip processing rules the voters take the place of attendees. @@ -1808,48 +1858,6 @@ Internet-Draft VPOLL April 2024 There are some extensions to the behavior of iTip methods for a VPOLL object and two new methods are defined. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -York & Douglass Expires 22 October 2024 [Page 33] - -Internet-Draft VPOLL April 2024 - - +================+================================================+ | Method | Description | +================+================================================+ @@ -1872,9 +1880,9 @@ Internet-Draft VPOLL April 2024 | CANCEL | There MUST be a single VPOLL component with | | | UID matching that of the poll being cancelled. | +----------------+------------------------------------------------+ - | REFRESH | The organizer returns a METHOD:REQUEST with | - | | the current full state, or a METHOD:CANCEL or | - | | an error if no matching poll is found. | + | REFRESH | The owner returns a METHOD:REQUEST with the | + | | current full state, or a METHOD:CANCEL or an | + | | error if no matching poll is found. | +----------------+------------------------------------------------+ | COUNTER | Not supported for VPOLL. | +----------------+------------------------------------------------+ @@ -1883,33 +1891,28 @@ Internet-Draft VPOLL April 2024 | POLLSTATUS | Used to send the current state of the poll to | | | all voters. The VPOLL can contain a reduced | | | set of properties but MUST contain DTSTAMP, | - | | SEQUENCE (if not 0), UID, ORGANIZER and | - | | PARTICIPANTS. | + | | SEQUENCE (if not 0), UID and PARTICIPANTS. | + | | One PARTICIPANT MUST be the owner. | +----------------+------------------------------------------------+ Table 4 - The following table shows the above methods broken down by who can - send them with VPOLL components. - - - - - - -York & Douglass Expires 22 October 2024 [Page 34] +York & Douglass Expires 24 October 2024 [Page 34] Internet-Draft VPOLL April 2024 + The following table shows the above methods broken down by who can + send them with VPOLL components. + +============+================================================+ | Originator | Methods | +============+================================================+ - | Organizer | CANCEL, PUBLISH, REQUEST, POLLSTATUS | + | Owner | CANCEL, PUBLISH, REQUEST, POLLSTATUS | +------------+------------------------------------------------+ | Voter | REPLY, REFRESH, REQUEST (only when delegating) | +------------+------------------------------------------------+ @@ -1918,8 +1921,8 @@ Internet-Draft VPOLL April 2024 8.2. Interoperability Models - Most of the standard iTip specification applies with respect to - organizer and voters. + Most of the standard iTip specification applies with respect to owner + and voters. 8.2.1. Delegation @@ -1948,20 +1951,24 @@ Internet-Draft VPOLL April 2024 8.3. Application Protocol Elements -8.3.1. Methods for VPOLL Calendar Components - This section defines the property set restrictions for the method - types that are applicable to the "VPOLL" calendar component. Each - method is defined using a table that clarifies the property - constraints that define the particular method. -York & Douglass Expires 22 October 2024 [Page 35] + + +York & Douglass Expires 24 October 2024 [Page 35] Internet-Draft VPOLL April 2024 +8.3.1. Methods for VPOLL Calendar Components + + This section defines the property set restrictions for the method + types that are applicable to the "VPOLL" calendar component. Each + method is defined using a table that clarifies the property + constraints that define the particular method. + The presence column uses the following values to assert whether a property is required or optional, and the number of times it may appear in the iCalendar object. @@ -2006,14 +2013,7 @@ Internet-Draft VPOLL April 2024 - - - - - - - -York & Douglass Expires 22 October 2024 [Page 36] +York & Douglass Expires 24 October 2024 [Page 36] Internet-Draft VPOLL April 2024 @@ -2040,15 +2040,14 @@ Internet-Draft VPOLL April 2024 +------------+------------------------------------------------------+ | CANCEL | Cancel a poll. | +------------+------------------------------------------------------+ - | REFRESH | A request is sent to an Organizer by a Voter | + | REFRESH | A request is sent to a poll owner by a voter | | | asking for the latest version of a poll to be | | | resent to the requester. | +------------+------------------------------------------------------+ | POLLSTATUS | Used to send the current state of the poll to | | | all voters. The VPOLL can contain a reduced | | | set of properties but MUST contain DTSTAMP, | - | | SEQUENCE (if not 0), UID, ORGANIZER and | - | | PARTICIPANT. | + | | SEQUENCE (if not 0), UID, and PARTICIPANT. | +------------+------------------------------------------------------+ Table 7 @@ -2057,10 +2056,10 @@ Internet-Draft VPOLL April 2024 The "PUBLISH" method in a "VPOLL" calendar component is an unsolicited posting of an iCalendar object. Any CU may add published - components to their calendar. The "Organizer" MUST be present in a - published iCalendar component. "Voters" MUST NOT be present. Its - expected usage is for encapsulating an arbitrary poll as an iCalendar - object. The "Organizer" may subsequently update (with another + components to their calendar. An owner participant MUST be present + in a published iCalendar component. "Voters" MUST NOT be present. + Its expected usage is for encapsulating an arbitrary poll as an + iCalendar object. The "Owner" may subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published "VPOLL" calendar component. @@ -2069,7 +2068,8 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 37] + +York & Douglass Expires 24 October 2024 [Page 37] Internet-Draft VPOLL April 2024 @@ -2101,11 +2101,11 @@ Internet-Draft VPOLL April 2024 "Voter" to another CU. * For an existing "VPOLL" calendar component, change the role of - "Organizer" to another CU. + "Owner" to another CU. - The "Organizer" originates the "REQUEST". The recipients of the + The "Owner" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs voting in the poll, the "Voters". - "Voters" use the "REPLY" method to convey votes to the "Organizer". + "Voters" use the "REPLY" method to convey votes to the "Owner". The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in @@ -2125,7 +2125,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 38] +York & Douglass Expires 24 October 2024 [Page 38] Internet-Draft VPOLL April 2024 @@ -2154,11 +2154,11 @@ Internet-Draft VPOLL April 2024 the POLL. The update "REQUEST" method is the appropriate response to a - "REFRESH" method sent from a "Voter" to the "Organizer" of a poll. + "REFRESH" method sent from a "Voter" to the "Owner" of a poll. - The "Organizer" of a poll may also send unsolicited "REQUEST" - methods. The unsolicited "REQUEST" methods may be used to update the - details of the poll without rescheduling it, to update the "RESPONSE" + The "Owner" of a poll may also send unsolicited "REQUEST" methods. + The unsolicited "REQUEST" methods may be used to update the details + of the poll without rescheduling it, to update the "RESPONSE" parameter of "Voters", or to reconfirm the poll. 8.3.3.3. Confirmation of a Poll @@ -2181,7 +2181,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 39] +York & Douglass Expires 24 October 2024 [Page 39] Internet-Draft VPOLL April 2024 @@ -2193,43 +2193,43 @@ Internet-Draft VPOLL April 2024 following workflow. Any "Voter" may delegate their right to vote in a poll to another CU. The implication is that the delegate participates in lieu of the original "Voter", NOT in addition to the - "Voter". The delegator MUST notify the "Organizer" of this action - using the steps outlined below. Implementations may support or - restrict delegation as they see fit. For instance, some - implementations may restrict a delegate from delegating a "REQUEST" - to another CU. + "Voter". The delegator MUST notify the "Owner" of this action using + the steps outlined below. Implementations may support or restrict + delegation as they see fit. For instance, some implementations may + restrict a delegate from delegating a "REQUEST" to another CU. The "Delegator" of a poll forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include a "Voter" property with the calendar address of the "Delegate". The "Delegator" MUST - also send a "REPLY" method to the "Organizer" with the "Delegator's" + also send a "REPLY" method to the "Owner" with the "Delegator's" "Voter" property "DELEGATED-TO" parameter set to the calendar address of the "Delegate". Also, a new "Voter" property for the "Delegate" MUST be included and must specify the calendar user address set in the "DELEGATED-TO" parameter, as above. In response to the request, the "Delegate" MUST send a "REPLY" method - to the "Organizer", and optionally to the "Delegator". The "REPLY" + to the "Owner", and optionally to the "Delegator". The "REPLY" - method SHOULD include the "Voter" property with the "DELEGATED-FROM" - parameter value of the "Delegator's" calendar address. + method SHOULD include the "Voter" participant with the "PARTICIPANT- + DELEGATED-FROM" property value of the "Delegator's" calendar address. The "Delegator" may continue to receive updates to the poll even though they will not be attending. This is accomplished by the - "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in - the "REPLY" to the "Organizer". + "Delegator" setting their "role" attribute to "INFORMATIONAL" in the + "REPLY" to the "Owner". + +8.3.3.6. Changing the Owner + + The situation may arise where the "Owner" of a "VPOLL" is no longer + able to perform the "Owner" role and abdicates without passing on the + "Owner" role to someone else. When this occurs, the "Voters" of the + "VPOLL" may use out-of-band mechanisms to communicate the situation + and agree upon a new "Owner". The new "Owner" should then send out a + new "REQUEST" with a modified version of the "VPOLL" in which the + "SEQUENCE" number has been incremented and the owner role assigned to + the appropriate "PARTICIPANT". -8.3.3.6. Changing the Organizer - The situation may arise where the "Organizer" of a "VPOLL" is no - longer able to perform the "Organizer" role and abdicates without - passing on the "Organizer" role to someone else. When this occurs, - the "Voters" of the "VPOLL" may use out-of-band mechanisms to - communicate the situation and agree upon a new "Organizer". The new - "Organizer" should then send out a new "REQUEST" with a modified - version of the "VPOLL" in which the "SEQUENCE" number has been - incremented and the "ORGANIZER" property has been changed to the new - "Organizer". @@ -2237,22 +2237,21 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 40] +York & Douglass Expires 24 October 2024 [Page 40] Internet-Draft VPOLL April 2024 -8.3.3.7. Sending on Behalf of the Organizer +8.3.3.7. Sending on Behalf of the Owner There are a number of scenarios that support the need for a "Calendar - User" to act on behalf of the "Organizer" without explicit role - changing. This might be the case if the CU designated as "Organizer" - is sick or unable to perform duties associated with that function. - In these cases, iTIP supports the notion of one CU acting on behalf - of another. Using the "SENT-BY" parameter, a "Calendar User" could - send an updated "VPOLL" "REQUEST". In the case where one CU sends on - behalf of another CU, the "Voter" responses are still directed back - towards the CU designated as "Organizer". + User" to act on behalf of the "Owner" without explicit role changing. + This might be the case if the CU designated as "Owner" is sick or + unable to perform duties associated with that function. In these + cases, iTIP supports the notion of one CU acting on behalf of + another. In the case where one CU sends on behalf of another CU, the + "Voter" responses are still directed back towards the CU designated + as "Owner". 8.3.3.8. Forwarding to an Uninvited CU @@ -2261,21 +2260,21 @@ Internet-Draft VPOLL April 2024 associated with the "VPOLL" calendar component. The current "Voter" participating in the "VPOLL" calendar component does this by forwarding the original "REQUEST" method to the new CU. The new CU - can send a "REPLY" to the "Organizer" of the "VPOLL" calendar - component. The reply contains a "Voter" property for the new CU. - - The "Organizer" ultimately decides whether or not the new CU becomes - part of the poll and is not obligated to do anything with a "REPLY" - from a new (uninvited) CU. If the "Organizer" does not want the new - CU to be part of the poll, the new "Voter" property is not added to - the "VPOLL" calendar component. The "Organizer" MAY send the CU a - "CANCEL" message to indicate that they will not be added to the poll. - - If the "Organizer" decides to add the new CU, the new "Voter" - property is added to the "VPOLL" calendar component. Furthermore, - the "Organizer" is free to change any "Voter" property parameter from - the values supplied by the new CU to something the "Organizer" - considers appropriate. The "Organizer" SHOULD send the new CU a + can send a "REPLY" to the "Owner" of the "VPOLL" calendar component. + The reply contains a "Voter" participant component for the new CU. + + The "Owner" ultimately decides whether the new CU becomes part of the + poll and is not obligated to do anything with a "REPLY" from a new + (uninvited) CU. If the "Owner" does not want the new CU to be part + of the poll, the new "Voter" is not added to the "VPOLL" calendar + component. The "Owner" MAY send the CU a "CANCEL" message to + indicate that they will not be added to the poll. + + If the "Owner" decides to add the new CU, a new participant for the + "Voter" is added to the "VPOLL" calendar component. Furthermore, the + "Owner" is free to change any "Voter" participant property values + from the values supplied by the new CU to something the "Owner" + considers appropriate. The "Owner" SHOULD send the new CU a "REQUEST" message to inform them that they have been added. When forwarding a "REQUEST" to another CU, the forwarding "Voter" @@ -2283,24 +2282,22 @@ Internet-Draft VPOLL April 2024 8.3.3.9. Updating Voter Status - The "Organizer" of an poll may also request updated status from one - or more "Voters". The "Organizer" sends a "REQUEST" method to the - "Voter" and sets the "RSVP=TRUE" property parameter on the - PARTICIPANT CALENDAR-ADDRESS. The "SEQUENCE" property for the poll - is not changed from its previous value. A recipient will determine - that the only change in the "REQUEST" is that their "RSVP" property - parameter indicates a request for updated status. The recipient + The "Owner" of a poll may also request updated status from one or + more "Voters". The "Owner" sends a "REQUEST" method to the "Voter" + and sets the "EXPECT-REPLY" property value to TRUE. The "SEQUENCE" + property for the poll is not changed from its previous value. A + recipient will determine that the only change in the "REQUEST" is + that their "EXPECT-REPLY" property indicates a request for updated + status. The recipient SHOULD respond with a "REPLY" method + indicating their current vote with respect to the "REQUEST". -York & Douglass Expires 22 October 2024 [Page 41] +York & Douglass Expires 24 October 2024 [Page 41] Internet-Draft VPOLL April 2024 - SHOULD respond with a "REPLY" method indicating their current vote - with respect to the "REQUEST". - 8.3.4. Method: REPLY The "REPLY" method in a "VPOLL" calendar component is used to respond @@ -2316,21 +2313,21 @@ Internet-Draft VPOLL April 2024 Depending on the value of the "REQUEST-STATUS" property, no action may have been performed. - The "Organizer" of a poll may receive the "REPLY" method from a CU - not in the original "REQUEST". For example, a "REPLY" may be - received from a "Delegate" to a poll. In addition, the "REPLY" - method may be received from an unknown CU (a "Party Crasher"). This - uninvited "Voter" may be accepted, or the "Organizer" may cancel the - poll for the uninvited "Voter" by sending a "CANCEL" method to the - uninvited "Voter". - - A "Voter" MAY include a message to the "Organizer" using the - "COMMENT" property. For example, if the user indicates a low - interest and wants to let the "Organizer" know why, the reason can be - expressed in the "COMMENT" property value. - - The "Organizer" may also receive a "REPLY" from one CU on behalf of - another. Like the scenario enumerated above for the "Organizer", + The "Owner" of a poll may receive the "REPLY" method from a CU not in + the original "REQUEST". For example, a "REPLY" may be received from + a "Delegate" to a poll. In addition, the "REPLY" method may be + received from an unknown CU (a "Party Crasher"). This uninvited + "Voter" may be accepted, or the "Owner" may cancel the poll for the + uninvited "Voter" by sending a "CANCEL" method to the uninvited + "Voter". + + A "Voter" MAY include a message to the "Owner" using the "COMMENT" + property in the PARTICIPANT component. For example, if the user + indicates a low interest and wants to let the "Owner" know why, the + reason can be expressed in the "COMMENT" property value. + + The "Owner" may also receive a "REPLY" from one CU on behalf of + another. Like the scenario enumerated above for the "Owner", "Voters" may have another CU respond on their behalf. This is done using the "SENT-BY" parameter. @@ -2349,7 +2346,10 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 42] + + + +York & Douglass Expires 24 October 2024 [Page 42] Internet-Draft VPOLL April 2024 @@ -2368,8 +2368,6 @@ Internet-Draft VPOLL April 2024 +-----------------+----------+-------------------------------------+ | DTSTAMP | 1 | | +-----------------+----------+-------------------------------------+ - | ORGANIZER | 1 | | - +-----------------+----------+-------------------------------------+ | UID | 1 | MUST be the UID of the original | +-----------------+----------+-------------------------------------+ | | | REQUEST. | @@ -2384,12 +2382,12 @@ Internet-Draft VPOLL April 2024 +-----------------+----------+-------------------------------------+ | VFREEBUSY | 0 or 1 | A voter may respond with a | | | | VFREEBUSY component indicating that | - | | | the ORGANIZER may select some other | + | | | the "Owner" may select some other | | | | time which is not marked as busy. | +-----------------+----------+-------------------------------------+ | VAVAILABILITY | 0 | A voter may respond with a | | | | VAVAILABILITY component indicating | - | | | that the ORGANIZER may select some | + | | | that the "Owner" may select some | | | | other time which is shown as | | | | available. | +-----------------+----------+-------------------------------------+ @@ -2400,20 +2398,22 @@ Internet-Draft VPOLL April 2024 The "CANCEL" method in a "VPOLL" calendar component is used to send a cancellation notice of an existing poll request to the affected - "Voters". The message is sent by the "Organizer" of the poll. + "Voters". The message is sent by the "Owner" of the poll. + -York & Douglass Expires 22 October 2024 [Page 43] + +York & Douglass Expires 24 October 2024 [Page 43] Internet-Draft VPOLL April 2024 - The "Organizer" MUST send a "CANCEL" message to each "Voter" affected - by the cancellation. This can be done using a single "CANCEL" - message for all "Voters" or by using multiple messages with different - subsets of the affected "Voters" in each. + The "Owner" MUST send a "CANCEL" message to each "Voter" affected by + the cancellation. This can be done using a single "CANCEL" message + for all "Voters" or by using multiple messages with different subsets + of the affected "Voters" in each. When a "VPOLL" is cancelled, the "SEQUENCE" property value MUST be incremented as described in Section 8.2.3. @@ -2443,8 +2443,6 @@ Internet-Draft VPOLL April 2024 +-------------+----------+-------------------------------------+ | DTSTAMP | 1 | | +-------------+----------+-------------------------------------+ - | ORGANIZER | 1 | | - +-------------+----------+-------------------------------------+ | SEQUENCE | 1 | | +-------------+----------+-------------------------------------+ @@ -2454,14 +2452,16 @@ Internet-Draft VPOLL April 2024 The "REFRESH" method in a "VPOLL" calendar component is used by "Voters" of an existing event to request an updated vpoll status from - the poll "Organizer". The "REFRESH" method MUST specify the "UID" - property of the poll to update. The "Organizer" responds with a + the poll "Owner". The "REFRESH" method MUST specify the "UID" + property of the poll to update. The "Owner" responds with a METHOD=REQUEST giving the latest status and version of the poll. -York & Douglass Expires 22 October 2024 [Page 44] + + +York & Douglass Expires 24 October 2024 [Page 44] Internet-Draft VPOLL April 2024 @@ -2482,8 +2482,6 @@ Internet-Draft VPOLL April 2024 +--------------------+----------+----------------------------+ | DTSTAMP | 1 | | +--------------------+----------+----------------------------+ - | ORGANIZER | 1 | | - +--------------------+----------+----------------------------+ | UID | 1 | MUST be the UID associated | | | | with original REQUEST. | +--------------------+----------+----------------------------+ @@ -2494,11 +2492,11 @@ Internet-Draft VPOLL April 2024 The "POLLSTATUS" method in a "VPOLL" calendar component is used to inform recipients of the current status of the poll in a compact - manner. The "Organizer" MUST be present in the confirmed poll - component. All "Voters" MUST be present. The selected component(s) - according to the poll mode SHOULD NOT be present in the poll - component. Clients receiving this message may store the confirmed - items in their calendars. + manner. The "Owner" participant MUST be present in the confirmed + poll component. All "Voters" MUST be present. The selected + component(s) according to the poll mode SHOULD NOT be present in the + poll component. Clients receiving this message may store the + confirmed items in their calendars. This method type has a "METHOD" property with the value "POLLSTATUS" and one or more VPOLL objects. Those objects MUST contain the @@ -2517,7 +2515,9 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 45] + + +York & Douglass Expires 24 October 2024 [Page 45] Internet-Draft VPOLL April 2024 @@ -2539,8 +2539,6 @@ Internet-Draft VPOLL April 2024 +-------------+----------+-------------------------------------+ | DTSTART | 0 or 1 | | +-------------+----------+-------------------------------------+ - | ORGANIZER | 1 | | - +-------------+----------+-------------------------------------+ | SUMMARY | 1 | Can be null. | +-------------+----------+-------------------------------------+ | UID | 1 | | @@ -2570,15 +2568,16 @@ Internet-Draft VPOLL April 2024 Namespace urn:ietf:params:xml:ns:caldav + Purpose Specifies the calendar component types (e.g., VEVENT, VTODO, + -York & Douglass Expires 22 October 2024 [Page 46] +York & Douglass Expires 24 October 2024 [Page 46] Internet-Draft VPOLL April 2024 - Purpose Specifies the calendar component types (e.g., VEVENT, VTODO, etc.) and combination of types that may be included in a VPOLL component. @@ -2629,7 +2628,8 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 47] + +York & Douglass Expires 24 October 2024 [Page 47] Internet-Draft VPOLL April 2024 @@ -2685,7 +2685,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 48] +York & Douglass Expires 24 October 2024 [Page 48] Internet-Draft VPOLL April 2024 @@ -2741,7 +2741,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 49] +York & Douglass Expires 24 October 2024 [Page 49] Internet-Draft VPOLL April 2024 @@ -2797,7 +2797,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 50] +York & Douglass Expires 24 October 2024 [Page 50] Internet-Draft VPOLL April 2024 @@ -2853,7 +2853,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 51] +York & Douglass Expires 24 October 2024 [Page 51] Internet-Draft VPOLL April 2024 @@ -2909,7 +2909,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 52] +York & Douglass Expires 24 October 2024 [Page 52] Internet-Draft VPOLL April 2024 @@ -2965,7 +2965,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 53] +York & Douglass Expires 24 October 2024 [Page 53] Internet-Draft VPOLL April 2024 @@ -3021,7 +3021,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 54] +York & Douglass Expires 24 October 2024 [Page 54] Internet-Draft VPOLL April 2024 @@ -3077,7 +3077,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 55] +York & Douglass Expires 24 October 2024 [Page 55] Internet-Draft VPOLL April 2024 @@ -3133,7 +3133,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 56] +York & Douglass Expires 24 October 2024 [Page 56] Internet-Draft VPOLL April 2024 @@ -3189,7 +3189,7 @@ Internet-Draft VPOLL April 2024 -York & Douglass Expires 22 October 2024 [Page 57] +York & Douglass Expires 24 October 2024 [Page 57] Internet-Draft VPOLL April 2024 @@ -3245,7 +3245,7 @@ Appendix A. Open issues -York & Douglass Expires 22 October 2024 [Page 58] +York & Douglass Expires 24 October 2024 [Page 58] Internet-Draft VPOLL April 2024 @@ -3301,7 +3301,7 @@ A.1. Advertising tasks -York & Douglass Expires 22 October 2024 [Page 59] +York & Douglass Expires 24 October 2024 [Page 59] Internet-Draft VPOLL April 2024 @@ -3357,7 +3357,7 @@ Appendix B. Change log -York & Douglass Expires 22 October 2024 [Page 60] +York & Douglass Expires 24 October 2024 [Page 60] Internet-Draft VPOLL April 2024 @@ -3413,4 +3413,4 @@ Authors' Addresses -York & Douglass Expires 22 October 2024 [Page 61] +York & Douglass Expires 24 October 2024 [Page 61] diff --git a/generated/draft-ietf-calext-vpoll.xml b/generated/draft-ietf-calext-vpoll.xml index 5370b44..5886db2 100644 --- a/generated/draft-ietf-calext-vpoll.xml +++ b/generated/draft-ietf-calext-vpoll.xml @@ -122,7 +122,7 @@ to maintain the state of the voting. For our simple example the following VPOLL properties and sub-components are either required or appropriate:

      -
      DTSTAMP
      +
      DTSTAMP

      The usual property.

      SEQUENCE
      @@ -132,65 +132,60 @@ behavior.

      UID

      The usual property.

      -
      ORGANIZER
      -

      The usual property. In general this need not -be an organizer of any of the alternatives. In this simple -outline we assume it is the same.

      -
      SUMMARY
      -

      The usual property. This optional but +

      The usual property. This optional but recommended property provides the a short title to the poll.

      DESCRIPTION
      -

      The usual property. This optional property +

      The usual property. This optional property provides more details.

      DTEND
      -

      The usual property. This optional property +

      The usual property. This optional property provides a poll closing time and date after which the VPOLL is no longer active.

      POLL-MODE
      -

      A new property which defines how the votes are used to +

      A new property which defines how the votes are used to obtain a result. For our use case it will take the value "BASIC" meaning one event will be chosen from the alternatives.

      POLL-COMPLETION
      -

      A new property which defines who (server or client) +

      A new property which defines who (server or client) chooses and/or submits the winning choice. In our example the value is "SERVER-SUBMIT" which means the client chooses the winner but the server will submit the winning choice.

      POLL-PROPERTIES
      -

      A new property which defines which icalendar +

      A new property which defines which icalendar properties are being voted on. For our use case it will take the value "DTSTART, LOCATION" meaning only those properties are significant for voting. Other properties in the events may differ but are not considered significant for the voting process.

      PARTICIPANT
      -

      There is one of these components for each voter with +

      There is one of these components for each voter with the PARTICIPANT-TYPE set to "VOTER". The CALENDAR-ADDRESS property identifies the voter and this component will contain one VOTE component for each item being voted on.

      VOTE
      -

      A new component. There is one of these for each voter and +

      A new component. There is one of these for each voter and choice. It usually contains at least a POLL-ITEM-ID property to identify the choice and a RESPONSE property to provide a vote. For more complex poll modes it may contain other information such as cost or estimated duration.

      VEVENT
      -

      In our simple use case there will be multiple VEVENT sub- +

      In our simple use case there will be multiple VEVENT sub- components defining the alternatives. Each will have a different date and or time for the meeting.

      -

      VPOLL with 3 voters and 3 alternative meetings:

      +

      VPOLL with 3 voters and 3 alternative meetings:

      -BEGIN:VCALENDAR +BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD:REQUEST @@ -198,7 +193,6 @@ BEGIN:VPOLL POLL-MODE:BASIC POLL-COMPLETION:SERVER-SUBMIT POLL-PROPERTIES:DTSTART,LOCATION -ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T000000Z SUMMARY:What to do this week @@ -212,7 +206,7 @@ PARTICIPANT-TYPE: VOTER CALENDAR-ADDRESS:mailto:eric@example.com END:PARTICIPANT BEGIN:PARTICIPANT -PARTICIPANT-TYPE: VOTER +PARTICIPANT-TYPE: VOTER,OWNER CALENDAR-ADDRESS:mailto:mike@example.com END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) @@ -253,7 +247,7 @@ within the VPOLL. It's value SHOULD be a small integer.

      component containing their vote. In our simple case it will have the following properties and components:

      -
      DTSTAMP
      +
      DTSTAMP

      The usual property.

      SEQUENCE
      @@ -263,23 +257,20 @@ behavior.

      UID

      Same as the request.

      -
      ORGANIZER
      -

      Same as the request.

      -
      SUMMARY
      -

      Same as the request.

      +

      Same as the request.

      PARTICIPANT
      -

      One only with a CALENDAR-ADDRESS identifying the voter replying.

      +

      One only with a CALENDAR-ADDRESS identifying the voter replying.

      VOTE
      -

      One per item being voted on.

      +

      One per item being voted on.

      POLL-ITEM-ID
      -

      One inside each VOTE component to identify the choice.

      +

      One inside each VOTE component to identify the choice.

      RESPONSE
      -

      One inside each VOTE component to specify the vote.

      +

      One inside each VOTE component to specify the vote.

      @@ -294,14 +285,13 @@ with a vote for only item 3, the final outcome is one vote on item 3.

      -

      REPLY VPOLL from Cyrus:

      +

      REPLY VPOLL from Cyrus:

      -BEGIN:VCALENDAR +BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD: REPLY BEGIN:VPOLL -ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T010000Z SUMMARY:What to do this week @@ -331,18 +321,17 @@ END:VCALENDAR VPOLL updates -

      When the organizer receives a response from one or more voters the +

      When the owner receives a response from one or more voters the current state of the poll is sent to all voters. The new iTip method POLLSTATUS is used. The VPOLL can contain a reduced set of -properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, -ORGANIZER and one or more PARTICIPANT components each populated with zero or more VOTE components.

      +properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, and +one or more PARTICIPANT components each populated with zero or more VOTE components.

      -BEGIN:VCALENDAR +BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD: POLLSTATUS BEGIN:VPOLL -ORGANIZER:mailto:mike@example.com UID:sched01-1234567890 DTSTAMP:20120101T020000Z SEQUENCE:0 @@ -381,6 +370,24 @@ POLL-ITEM-ID:3 RESPONSE:0 END:VOTE END:PARTICIPANT +BEGIN:PARTICIPANT +PARTICIPANT-TYPE: VOTER,OWNER +CALENDAR-ADDRESS:mailto:mike@example.com +BEGIN: VOTE +POLL-ITEM-ID:1 +RESPONSE:50 +COMMENT:Work on iTIP +END:VOTE +BEGIN:VOTE +POLL-ITEM-ID:2 +RESPONSE:100 +COMMENT:Work on WebDAV +END:VOTE +BEGIN:VOTE +POLL-ITEM-ID:3 +RESPONSE:0 +END:VOTE +END:PARTICIPANT END:VPOLL END:VCALENDAR @@ -404,14 +411,13 @@ COMPLETION property is set to SERVER-SUBMIT the server will submit the winning choice and when it has done so set the STATUS to "SUBMITTED".

      -

      VPOLL confirmation:

      +

      VPOLL confirmation:

      -BEGIN:VCALENDAR +BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example//Example METHOD: REQUEST BEGIN:VPOLL -ORGANIZER:mailto:douglm@example.com UID:sched01-1234567890 DTSTAMP:20120101T030000Z COMPLETED:20120101T030000Z @@ -420,6 +426,10 @@ SEQUENCE:0 SUMMARY:What to do this week STATUS:CONFIRMED POLL-WINNER:3 +BEGIN:PARTICIPANT +PARTICIPANT-TYPE: OWNER +CALENDAR-ADDRESS:mailto:mike@example.com +END:PARTICIPANT BEGIN:VEVENT.......(with a poll-item-id=1) END:VEVENT BEGIN:VEVENT.......(with a poll-item-id=2) @@ -938,7 +948,7 @@ vote on provided choices.

      -pollc = "BEGIN" ":" "VPOLL" CRLF +pollc = "BEGIN" ":" "VPOLL" CRLF pollprop *participantc *eventc *todoc *journalc *freebusyc *availabilityc *alarmc *iana-comp *x-comp @@ -949,7 +959,7 @@ pollprop = *( ; The following are REQUIRED, ; but MUST NOT occur more than once. ; - dtstamp / uid / organizer / + dtstamp / uid / ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. @@ -1117,9 +1127,9 @@ some other protocol.

      - -New Participant Properties -

      The following properties are defined to be used within PARTICIPANT and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.

      + +New Participant Properties for iTip +

      The following properties are defined to be used within PARTICIPANT during scheduling and take the place of ATTENDEE and ORGANIZER properties and parameters. These are not solely for VPOLL but may be used in any future component.

      Kind @@ -1161,7 +1171,7 @@ kindparams = *(";" other-param)
      Redefined participation type

      This specification redefines the PARTICIPATION-TYPE property allowing it to take multiple values and extending those values to align with roles and add a new "VOTER" role. There are also changes to the description to clarify it's use defining the roles that participant takes.

      -
      Property name
      +
      Property name

      PARTICIPANT-TYPE

      Purpose
      @@ -1184,7 +1194,9 @@ roles the participant takes.

      Note that the kind of participant, for example individual or group, is defined in the KIND property specified here.

      -

      Do we need a separate registry or should we extend that one?

      +

      Some of the roles are required for the participant to be a schedulable object. These are the roles that are shown below. +* +Do we need a separate registry or should we extend that one?

      Format Definition

      This property is defined by the following notation:

      @@ -1256,7 +1268,7 @@ partvalueparam = *(";" other-param)
      -

      To map PARTICIPANT-TYPE or jscalendar roles to ROLE values use the following.

      +

      The following table shows those roles that MUST appear in the PARTICIPANT-TYPE for group-scheduling. Additionally, the mapping PARTICIPANT-TYPE or jscalendar roles to ATTENDEE and ORGANIZER values are shown.

      @@ -1507,6 +1519,34 @@ specified on this property.

      langparams = *(";" other-param) + + + +Expect reply +
      Property name
      +

      EXPECT-REPLY

      +
      +
      Purpose
      +

      If true, the organizer is expecting the participant to notify them of their participation status.

      +
      +
      Property Parameters
      +

      Non-standard or iana parameters can be +specified on this property.

      +
      +
      Conformance
      +

      This property MAY be specified once in the PARTICIPANT component.

      +
      +
      Format Definition
      +

      This property is defined by the following notation:

      +
      +
      + +expect-reply = "EXPECT-REPLY" + expect-replyparams ":" + ( "TRUE" / "FALSE") CRLF + +expect-replyparams = *(";" other-param) +
      @@ -1514,7 +1554,19 @@ langparams = *(";" other-param)iTip With Participants

      The PARTICIPANT component introduced in with the addition of some properties defined in this specification mirrors the participant object in .

      -

      For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL defined here, only PARTICIPANT components MUST be used.

      +

      For all existing schedulable and publishable components, VEVENT, VTODO, VFREEBUSY, and VAVAILABILITY; the ORGANIZER and ATTENDEE properties MUST be supplied as appropriate. For new components such as VPOLL, defined here, only PARTICIPANT components MUST be used.

      + +

      Note that extensions to the specification for VPOLL will be dealt with in later sections.

      + +

      A participant object that takes part in group scheduling MUST have the following characteristics:

      + +
      • It MUST have a calendar address ( CALENDAR-ADDRESS, calendarAddress).

        +
      • +
      • It must have one or more scheduling role defined. (PARTICIPANT-TYPE or role)

        +
      • +
      + +

      Scheduling with PARTICIPANT components behaves exactly as with ATTENDEE and ORGANIZER properties. When iTip specifies the setting of ATTENDEE or ORGANIZER parameters then the appropriate PARTICIPANT property will be set.

      Attendee parameters mapping @@ -1591,9 +1643,9 @@ langparams = *(";" other-param) iTIP Extensions -

      This specification introduces a number of extensions to . +

      This specification introduces a number of extensions to . In group scheduling the parties involved are organizer and attendees. -In VPOLL the parties are organizer and voters.

      +In VPOLL the parties are owner and voter participants.

      For many of the iTip processing rules the voters take the place of attendees.

      @@ -1603,7 +1655,7 @@ attendees.

      There are some extensions to the behavior of iTip methods for a VPOLL object and two new methods are defined.

      -
      PARTICIPANT-TYPE jsCalendar
      +
      Method
      - @@ -1651,10 +1703,10 @@ error if no matching poll is found.

      -
      Method Description

      PUBLISH

      @@ -1637,7 +1689,7 @@ matching that of the poll being cancelled.

      REFRESH

      The organizer returns a METHOD:REQUEST with the +

      The owner returns a METHOD:REQUEST with the current full state, or a METHOD:CANCEL or an error if no matching poll is found.

      POLLSTATUS

      Used to send the current state of the poll to +

      Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE -(if not 0), UID, ORGANIZER and PARTICIPANTS.

      +(if not 0), UID and PARTICIPANTS. One PARTICIPANT MUST be the owner.

      @@ -1662,10 +1714,10 @@ of properties but MUST contain DTSTAMP, SEQUENCE

      The following table shows the above methods broken down by who can send them with VPOLL components.

      - +
      Originator
      - @@ -1679,8 +1731,8 @@ send them with VPOLL components.

      Interoperability Models -

      Most of the standard iTip specification applies with respect to -organizer and voters.

      +

      Most of the standard iTip specification applies with respect to +owner and voters.

      Delegation @@ -1755,7 +1807,7 @@ appear in the iCalendar object.

      The following summarizes the methods that are defined for the "VPOLL" calendar component.

      -
      Originator Methods

      Organizer

      +

      Owner

      CANCEL, PUBLISH, REQUEST, POLLSTATUS

      +
      Method
      - -
      Method Description

      PUBLISH

      @@ -1785,16 +1837,16 @@ range 0 to 100.

      REFRESH

      A request is sent to an Organizer by a Voter asking +

      A request is sent to a poll owner by a voter asking for the latest version of a poll to be resent to the requester.

      POLLSTATUS

      Used to send the current state of the poll to all +

      Used to send the current state of the poll to all voters. The VPOLL can contain a reduced set of properties but MUST contain DTSTAMP, SEQUENCE (if -not 0), UID, ORGANIZER and PARTICIPANT.

      +not 0), UID, and PARTICIPANT.

      @@ -1802,12 +1854,12 @@ not 0), UID, ORGANIZER and PARTICIPANT.

      Method: PUBLISH -

      The "PUBLISH" method in a "VPOLL" calendar component is an +

      The "PUBLISH" method in a "VPOLL" calendar component is an unsolicited posting of an iCalendar object. Any CU may add published -components to their calendar. The "Organizer" MUST be present in a +components to their calendar. An owner participant MUST be present in a published iCalendar component. "Voters" MUST NOT be present. Its expected usage is for encapsulating an arbitrary poll as an iCalendar -object. The "Organizer" may subsequently update (with another +object. The "Owner" may subsequently update (with another "PUBLISH" method) or cancel (with a "CANCEL" method) a previously published "VPOLL" calendar component.

      @@ -1827,7 +1879,7 @@ property constraints defined in section .

      The "REQUEST" method in a "VPOLL" component provides the following scheduling functions:

      -
      • Invite "Voters" to respond to the poll.

        +
        • Invite "Voters" to respond to the poll.

        • Change the items being voted upon.

        • @@ -1844,14 +1896,14 @@ scheduling functions:

        • For an existing "VPOLL" calendar component, delegate the role of "Voter" to another CU.

        • -
        • For an existing "VPOLL" calendar component, change the role of -"Organizer" to another CU.

          +
        • For an existing "VPOLL" calendar component, change the role of +"Owner" to another CU.

        -

        The "Organizer" originates the "REQUEST". The recipients of the +

        The "Owner" originates the "REQUEST". The recipients of the "REQUEST" method are the CUs voting in the poll, the "Voters". -"Voters" use the "REPLY" method to convey votes to the "Organizer".

        +"Voters" use the "REPLY" method to convey votes to the "Owner".

        The "UID" and "SEQUENCE" properties are used to distinguish the various uses of the "REQUEST" method. If the "UID" property value in @@ -1891,10 +1943,10 @@ as the value for the existing poll, then the "REQUEST" method describes an update of the poll details, but not a rescheduling of the POLL.

        -

        The update "REQUEST" method is the appropriate response to a -"REFRESH" method sent from a "Voter" to the "Organizer" of a poll.

        +

        The update "REQUEST" method is the appropriate response to a +"REFRESH" method sent from a "Voter" to the "Owner" of a poll.

        -

        The "Organizer" of a poll may also send unsolicited "REQUEST" +

        The "Owner" of a poll may also send unsolicited "REQUEST" methods. The unsolicited "REQUEST" methods may be used to update the details of the poll without rescheduling it, to update the "RESPONSE" parameter of "Voters", or to reconfirm the poll.

        @@ -1916,86 +1968,84 @@ voting is completed. The STATUS MUST be set to COMPLETED.

        Delegating a Poll to Another CU -

        Some calendar and scheduling systems allow "Voters" to delegate the +

        Some calendar and scheduling systems allow "Voters" to delegate the vote to another "Calendar User". iTIP supports this concept using the following workflow. Any "Voter" may delegate their right to vote in a poll to another CU. The implication is that the delegate participates in lieu of the original "Voter", NOT in addition to the -"Voter". The delegator MUST notify the "Organizer" of this action +"Voter". The delegator MUST notify the "Owner" of this action using the steps outlined below. Implementations may support or restrict delegation as they see fit. For instance, some implementations may restrict a delegate from delegating a "REQUEST" to another CU.

        -

        The "Delegator" of a poll forwards the existing "REQUEST" to the +

        The "Delegator" of a poll forwards the existing "REQUEST" to the "Delegate". The "REQUEST" method MUST include a "Voter" property with the calendar address of the "Delegate". The "Delegator" MUST -also send a "REPLY" method to the "Organizer" with the "Delegator's" +also send a "REPLY" method to the "Owner" with the "Delegator's" "Voter" property "DELEGATED-TO" parameter set to the calendar address of the "Delegate". Also, a new "Voter" property for the "Delegate" MUST be included and must specify the calendar user address set in the "DELEGATED-TO" parameter, as above.

        -

        In response to the request, the "Delegate" MUST send a "REPLY" method -to the "Organizer", and optionally to the "Delegator". The "REPLY"

        +

        In response to the request, the "Delegate" MUST send a "REPLY" method +to the "Owner", and optionally to the "Delegator". The "REPLY"

        -

        method SHOULD include the "Voter" property with the "DELEGATED-FROM" -parameter value of the "Delegator's" calendar address.

        +

        method SHOULD include the "Voter" participant with the "PARTICIPANT-DELEGATED-FROM" +property value of the "Delegator's" calendar address.

        -

        The "Delegator" may continue to receive updates to the poll even +

        The "Delegator" may continue to receive updates to the poll even though they will not be attending. This is accomplished by the -"Delegator" setting their "role" attribute to "NON-PARTICIPANT" in -the "REPLY" to the "Organizer".

        +"Delegator" setting their "role" attribute to "INFORMATIONAL" in +the "REPLY" to the "Owner".

        - -Changing the Organizer -

        The situation may arise where the "Organizer" of a "VPOLL" is no -longer able to perform the "Organizer" role and abdicates without -passing on the "Organizer" role to someone else. When this occurs, + +Changing the Owner +

        The situation may arise where the "Owner" of a "VPOLL" is no +longer able to perform the "Owner" role and abdicates without +passing on the "Owner" role to someone else. When this occurs, the "Voters" of the "VPOLL" may use out-of-band mechanisms to -communicate the situation and agree upon a new "Organizer". The new -"Organizer" should then send out a new "REQUEST" with a modified +communicate the situation and agree upon a new "Owner". The new +"Owner" should then send out a new "REQUEST" with a modified version of the "VPOLL" in which the "SEQUENCE" number has been -incremented and the "ORGANIZER" property has been changed to the new -"Organizer".

        +incremented and the owner role assigned to the appropriate "PARTICIPANT".

        - -Sending on Behalf of the Organizer -

        There are a number of scenarios that support the need for a "Calendar -User" to act on behalf of the "Organizer" without explicit role -changing. This might be the case if the CU designated as "Organizer" + +Sending on Behalf of the Owner +

        There are a number of scenarios that support the need for a "Calendar +User" to act on behalf of the "Owner" without explicit role +changing. This might be the case if the CU designated as "Owner" is sick or unable to perform duties associated with that function. In these cases, iTIP supports the notion of one CU acting on behalf -of another. Using the "SENT-BY" parameter, a "Calendar User" could -send an updated "VPOLL" "REQUEST". In the case where one CU sends on +of another. In the case where one CU sends on behalf of another CU, the "Voter" responses are still directed back -towards the CU designated as "Organizer".

        +towards the CU designated as "Owner".

        Forwarding to an Uninvited CU -

        A "Voter" invited to a "VPOLL" calendar component may send the +

        A "Voter" invited to a "VPOLL" calendar component may send the "VPOLL" calendar component to another new CU not previously associated with the "VPOLL" calendar component. The current "Voter" participating in the "VPOLL" calendar component does this by forwarding the original "REQUEST" method to the new CU. The new CU -can send a "REPLY" to the "Organizer" of the "VPOLL" calendar -component. The reply contains a "Voter" property for the new CU.

        +can send a "REPLY" to the "Owner" of the "VPOLL" calendar +component. The reply contains a "Voter" participant component for the new CU.

        -

        The "Organizer" ultimately decides whether or not the new CU becomes +

        The "Owner" ultimately decides whether the new CU becomes part of the poll and is not obligated to do anything with a "REPLY" -from a new (uninvited) CU. If the "Organizer" does not want the new -CU to be part of the poll, the new "Voter" property is not added to -the "VPOLL" calendar component. The "Organizer" MAY send the CU a +from a new (uninvited) CU. If the "Owner" does not want the new +CU to be part of the poll, the new "Voter" is not added to +the "VPOLL" calendar component. The "Owner" MAY send the CU a "CANCEL" message to indicate that they will not be added to the poll.

        -

        If the "Organizer" decides to add the new CU, the new "Voter" -property is added to the "VPOLL" calendar component. Furthermore, -the "Organizer" is free to change any "Voter" property parameter from -the values supplied by the new CU to something the "Organizer" -considers appropriate. The "Organizer" SHOULD send the new CU a +

        If the "Owner" decides to add the new CU, a new participant for the "Voter" +is added to the "VPOLL" calendar component. Furthermore, +the "Owner" is free to change any "Voter" participant property values from +the values supplied by the new CU to something the "Owner" +considers appropriate. The "Owner" SHOULD send the new CU a "REQUEST" message to inform them that they have been added.

        When forwarding a "REQUEST" to another CU, the forwarding "Voter" @@ -2004,12 +2054,12 @@ MUST NOT make changes to the original message.

        Updating Voter Status -

        The "Organizer" of an poll may also request updated status from one -or more "Voters". The "Organizer" sends a "REQUEST" method to the -"Voter" and sets the "RSVP=TRUE" property parameter on the PARTICIPANT CALENDAR-ADDRESS. The +

        The "Owner" of a poll may also request updated status from one +or more "Voters". The "Owner" sends a "REQUEST" method to the +"Voter" and sets the "EXPECT-REPLY" property value to TRUE. The "SEQUENCE" property for the poll is not changed from its previous value. A recipient will determine that the only change in the -"REQUEST" is that their "RSVP" property parameter indicates a request +"REQUEST" is that their "EXPECT-REPLY" property indicates a request for updated status. The recipient SHOULD respond with a "REPLY" method indicating their current vote with respect to the "REQUEST".

        @@ -2030,21 +2080,21 @@ property. The "Delegate" SHOULD include the calendar address of the Depending on the value of the "REQUEST-STATUS" property, no action may have been performed.

        -

        The "Organizer" of a poll may receive the "REPLY" method from a CU +

        The "Owner" of a poll may receive the "REPLY" method from a CU not in the original "REQUEST". For example, a "REPLY" may be received from a "Delegate" to a poll. In addition, the "REPLY" method may be received from an unknown CU (a "Party Crasher"). This -uninvited "Voter" may be accepted, or the "Organizer" may cancel the +uninvited "Voter" may be accepted, or the "Owner" may cancel the poll for the uninvited "Voter" by sending a "CANCEL" method to the uninvited "Voter".

        -

        A "Voter" MAY include a message to the "Organizer" using the -"COMMENT" property. For example, if the user indicates a low -interest and wants to let the "Organizer" know why, the reason can be +

        A "Voter" MAY include a message to the "Owner" using the +"COMMENT" property in the PARTICIPANT component. For example, if the user indicates a low +interest and wants to let the "Owner" know why, the reason can be expressed in the "COMMENT" property value.

        -

        The "Organizer" may also receive a "REPLY" from one CU on behalf of -another. Like the scenario enumerated above for the "Organizer", +

        The "Owner" may also receive a "REPLY" from one CU on behalf of +another. Like the scenario enumerated above for the "Owner", "Voters" may have another CU respond on their behalf. This is done using the "SENT-BY" parameter.

        @@ -2057,7 +2107,7 @@ and a single VPOLL object. That object MUST contain the properties shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present.

        - +
        Constraints for a METHOD:REPLY of a VPOLL @@ -2087,45 +2137,41 @@ ignored by the recipient if present.

        - - - - - - - - - - - - - - - - - - -
        Component/Property Presence

        1

        ORGANIZER

        +

        UID

        1

        UID

        -

        1

        +

        MUST be the UID of the original

        MUST be the UID of the original

        +

        REQUEST.

        REQUEST.

        +

        SEQUENCE

        SEQUENCE

        +

        0 or 1

        0 or 1

        -

        If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0.

        +

        If non-zero, MUST be the sequence number of the original REQUEST. MAY be present if 0.

        ACCEPT-RESPONSE

        +

        ACCEPT-RESPONSE

        0 or 1

        +

        0 or 1

        POLL-ITEM-ID

        +

        POLL-ITEM-ID

        1+

        +

        1+

        One per item being voted on.

        +

        One per item being voted on.

        VFREEBUSY

        +

        VFREEBUSY

        0 or 1

        +

        0 or 1

        A voter may respond with a VFREEBUSY component indicating that the ORGANIZER may select some other time which is not marked as busy.

        +

        A voter may respond with a VFREEBUSY component indicating that the "Owner" may select some other time which is not marked as busy.

        VAVAILABILITY

        +

        VAVAILABILITY

        0

        +

        0

        A voter may respond with a VAVAILABILITY component indicating that the ORGANIZER may select some other time which is shown as available.

        +

        A voter may respond with a VAVAILABILITY component indicating that the "Owner" may select some other time which is shown as available.

        @@ -2133,11 +2179,11 @@ ignored by the recipient if present.

        Method: CANCEL -

        The "CANCEL" method in a "VPOLL" calendar component is used to send a +

        The "CANCEL" method in a "VPOLL" calendar component is used to send a cancellation notice of an existing poll request to the affected -"Voters". The message is sent by the "Organizer" of the poll.

        +"Voters". The message is sent by the "Owner" of the poll.

        -

        The "Organizer" MUST send a "CANCEL" message to each "Voter" affected +

        The "Owner" MUST send a "CANCEL" message to each "Voter" affected by the cancellation. This can be done using a single "CANCEL" message for all "Voters" or by using multiple messages with different subsets of the affected "Voters" in each.

        @@ -2153,7 +2199,7 @@ and one or more VPOLL objects. Those objects MUST contain the properties shown below. All other properties or components SHOULD NOT be present and MUST be ignored by the recipient if present.

        - +
        Constraints for a METHOD:CANCEL of a VPOLL @@ -2187,31 +2233,27 @@ ignored by the recipient if present.

        - - -
        Component/Property Presence

        1

        ORGANIZER

        +

        SEQUENCE

        1

        SEQUENCE

        -

        1

        -
        Method: REFRESH -

        The "REFRESH" method in a "VPOLL" calendar component is used by +

        The "REFRESH" method in a "VPOLL" calendar component is used by "Voters" of an existing event to request an updated vpoll status from -the poll "Organizer". The "REFRESH" method MUST specify the "UID" -property of the poll to update. The "Organizer" responds with a +the poll "Owner". The "REFRESH" method MUST specify the "UID" +property of the poll to update. The "Owner" responds with a METHOD=REQUEST giving the latest status and version of the poll.

        This method type has a "METHOD" property with the value "REFRESH" and a single VPOLL object. That object MUST contain the properties shown below and no others.

        - +
        Constraints for a METHOD:REFRESH of a VPOLL @@ -2237,15 +2279,11 @@ shown below and no others.

        - - - -
        Component/Property Presence

        1

        ORGANIZER

        +

        UID

        1

        UID

        -

        1

        -

        MUST be the UID associated with original REQUEST.

        +

        MUST be the UID associated with original REQUEST.

        @@ -2253,9 +2291,9 @@ shown below and no others.

        Method: POLLSTATUS -

        The "POLLSTATUS" method in a "VPOLL" calendar component is used to +

        The "POLLSTATUS" method in a "VPOLL" calendar component is used to inform recipients of the current status of the poll in a compact -manner. The "Organizer" MUST be present in the confirmed poll +manner. The "Owner" participant MUST be present in the confirmed poll component. All "Voters" MUST be present. The selected component(s) according to the poll mode SHOULD NOT be present in the poll component. Clients receiving this message may store the confirmed @@ -2268,7 +2306,7 @@ shown below and no others.

        This method type is an iCalendar object that conforms to the following property constraints:

        - +
        Constraints for a METHOD:POLLSTATUS of a VPOLL @@ -2304,25 +2342,21 @@ following property constraints:

        - - - - - - - - -
        Component/Property Presence

        0 or 1

        ORGANIZER

        +

        SUMMARY

        1

        SUMMARY

        +

        Can be null.

        1

        +

        UID

        Can be null.

        -

        UID

        -

        1

        +

        1

        SEQUENCE

        +

        SEQUENCE

        0 or 1

        +

        0 or 1

        MUST be present if value is greater than 0; MAY be present if 0.

        +

        MUST be present if value is greater than 0; MAY be present if 0.