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

Hi,

Looks to me that issues have been at least partly solved... Do we think we
have received sufficient inputs to have a 01 version ?

Yours,
Daniel

On Wed, Oct 19, 2016 at 3:33 PM, Ken Murchison <murch@andrew.cmu.edu> wrote:

> OK, understood.  If future drafts will be using such a construct, we might
> as well introduce it in this draft.
>
>
>
> On 10/19/2016 03:15 PM, Michael Douglass wrote:
>
>>
>>
>> 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 mailing list
>> calsify@ietf.org
>> https://www.ietf.org/mailman/listinfo/calsify
>>
>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>