Re: [calsify] review of draft-ietf-calext-eventpub-extensions-00

Michael Douglass <mikeadouglass@gmail.com> Wed, 19 October 2016 19:15 UTC

To: calsify@ietf.org
References: <CADZyTknz=cYREHPZunxmQHcT5+b=FfeWV3PQFxqoyzBv19rYUw@mail.gmail.com> <a2e1f1bb-91c1-f8f1-a843-8ecf69a2938f@gmail.com> <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu>
From: Michael Douglass <mikeadouglass@gmail.com>
Message-ID: <33aceebe-624b-dc74-c23b-3bbbc4968a95@gmail.com>
Date: Wed, 19 Oct 2016 15:15:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <4700015a-bb03-f5c8-564f-690adb93aff8@andrew.cmu.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/TK6EnAcZ1fMWoSZvzATM5cFuS2Q>
Subject: Re: [calsify] review of draft-ietf-calext-eventpub-extensions-00
Precedence: list


On 10/19/16 12:29, Ken Murchison wrote:
> Hi Mike,
>
>
> On 10/19/2016 11:16 AM, Michael Douglass wrote:
>> Thanks for the comments - and sorry for the delay.
>>
>> I've added my responses to your comments below.
>>
>> I'll post a new draft in a short while: there are 2 issues at least
>> I'd like to address:
>>
>> 1. Should the ASSOCIATE property really be a component?
>> Other extensions to the iCalendar data model are requiring us to
>> handle deeper nesting of components and in any case a component more
>> closely matches XML and JSON representations
>
> I'm not opposed to making ASSOCIATE a component, but what other
> meta-data would be needed for an ASSOCIATE beyond what is currently
> specified to warrant the change?  Do you have an example in mind that
> you could flesh out?

So this is from https://tools.ietf.org/html/draft-apthorp-ical-tasks-01


3.4.2. Relating comments to status

    The GROUP parameter is used with the STATUS or ATTENDEE properties to
    relate an associated COMMENT property. The COMMENT property can then
    be used to include additional human readable information about why
    the associated STATUS or ATTENDEE property changed.

       STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE
        =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
       COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown

       ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2:
        REASON="http://example.com/reason/van-break-down":mailto:
        xxx@example.com
       COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture

(An aside - I think the example is faulty - a ":" wheer there should eb 
a ";")

The problem we had to address here is that we wanted a bunch of 
properties to be related to a specific attendee - so we used the GROUP 
parameter.

Significantly more readable and probably easier to manipulate is the 
approach of putting all that inside a component

Inventing one...

BEGIN VATTENDEE
ATTENDEE:PARTSTAT=FAILED;MODIFIED=20130226T1104510Z:xxx@example.com
REASON="http://example.com/reason/van-break-down"
COMMENT;MODIFIED=20130226T110451Z:Puncture
END VATTENDEE


In fact any attendee attributes could be stored there. I think in vpoll 
we ended up adopting tha approach for the voter - which could also be an 
associate if we made it a component

[calsify] review of draft-ietf-calext-eventpub-ex… Daniel Migault
Re: [calsify] review of draft-ietf-calext-eventpu… Michael Douglass
Re: [calsify] review of draft-ietf-calext-eventpu… Ken Murchison
Re: [calsify] review of draft-ietf-calext-eventpu… Michael Douglass
Re: [calsify] review of draft-ietf-calext-eventpu… Ken Murchison
Re: [calsify] review of draft-ietf-calext-eventpu… Daniel Migault