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

From: Daniel Migault <[email-masked]>
Date: Sat, 8 Oct 2016 19:59:46 +0200

Hi,

*reviewed *

*draft-ietf-calext-eventpub-extensions-00 Event Publishing Extensions to
iCalendar. *

*Please find my comment below. *

*BR, Daniel*

Section Introduction:

>From the introduction, my understanding is that the draft will describe two
new properties:

1) a new property to support HTML which is not mentionned, but I think
corresponds to "styled-Description"
2) a new property "STRUCTURED-DATA"

That is personnal but I would proably prefer to have all new properties
mentionedn in the introduction. That is:
   - Associate
   - Styled-Description
   - Structured-Location
   - Structured-Resource
   - Structured-Data

with a paragraph associated to each of them.

This text is not clear to me. I guess that is because I do not know what
"org.bedework.util.jms.events" is.

"""
   It is generally important to provide information about
   the organizers of such org.bedework.util.jms.events.
"""

While reading the introduction, I expected the ASSOCIATE to be something
similar as attendee. This is later clarified, but it might be good to
clearly mention the difference in the intro, so people read the document
with a good view of what an associate is.

"""
   In social calendaring it is
   often important to identify the active associates in the event, for
   example a school sports team, and the inactive associates, for
   example the parents.
"""

section 2. Typed References

The "TODO" text is not clear to me.
"""
   The [RFC5545] LOCATION property provides only an unstructured single
   text value for specifying the location where an event (or "TODO"
   item) will occur.
"""

My understanding of this section is that it cites alternative of the
proposed properties.

I am a bit confused then why ATTACH is not part of this section.

Each properties it would be helpful for the reader to mention the gaps and
how the new prperties of the document solve the gaps.

>From reading the section it looks to me that STRUCTURED-DATA is a more
generic way to do STRUCTURED-LOCATION. Can we expect overlaps between the
two properties and eventually see STRUCTURE-LOCATION deprecated one time in
the future ?

The section does not mention any properties associated to HTML content
properties. My undertanding of it is that iCal has not seen any need for
presentation until now, and leave presentation to the browser or
application. Is that correct ?

section 2.1.

Maybe iTip meeting should have a refrence to RFC5546

Section 4.

There are Components properties sdataprop is a new component

5.2.  Styled-Description

styleddescparam seems to have synthax problems.

     styleddescparam   = *(
                     ;
                     ; The following are OPTIONAL,
                     ; but MUST NOT occur more than once.
                     ;
                     (";" altrepparam) / (";" languageparam) /
                     (";" fmttypeparam) /
                     ;
                     ; the following is OPTIONAL
                     ; and MAY occur more than once
                     ;
                     (";" other-param)

---

From: Michael Douglass <[email-masked]>
Date: Wed, 19 Oct 2016 11:16:54 -0400

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

On 10/8/16 13:59, Daniel Migault wrote:
> Hi,
>
> /reviewed ///draft-ietf-calext-eventpub-extensions-00 /Event Publishing
> Extensions to iCalendar.
>
> /
> /Please find my comment below.
>
> /
> /BR,
> Daniel
> /
> /
>
> /
> Section Introduction:
>
> From the introduction, my understanding is that the draft will describe
> two new properties:
>

Reworked the intro and moved some of the text into the STRUCTURED-DATA 
description

>    the organizers of such org.bedework.util.jms.events.

Inserted by a 'helpful' IDE

>    example a school sports team, and the inactive associates, for

I've added some text to the intro.

One of the problems we face is retaining backwards compatibility. 
Personally I'd like to see us move towards the approach of marking an 
ASSOCIATE component as schedulable - this would result in that person or 
resource receiving an invitation.

Perhaps the ATTENDEE property could be derived from the ASSOCIATE and 
simply hold the state.

>    text value for specifying the location where an event (or "TODO"

Replaced with
specifying the location where an event or task will occur.

> Each properties it would be helpful for the reader to mention the gaps
> and how the new prperties of the document solve the gaps.
>
> generic way to do STRUCTURED-LOCATION. Can we expect overlaps between
> the two properties and eventually see STRUCTURE-LOCATION deprecated one
> time in the future ?

That's not the intent. STRUCTURED-DATA essentially extends the event or 
task class with extra meta-data. For example, if the event represents a 
soccer match the structured-data would reference an appropriate schema 
and provide additional fields, such as the home team - perhaps scores 
after the event and so on.

In essence the event becomes a soccer-match event.

The STRUCTURED-LOCATION is an attribute of the event - it doesn't change 
its class.

Part of what drove the desire for the STRUCTURED-LOCATION property is 
the possibility of having the event drive GPS systems. To do that we 
need to adequately identify the location-type - for example when driving 
to a venue the target is not the venue itself but parking which may be 
somewhat remote.

I'll add more to the description to try to clarify.

> application. Is that correct ?

There's been a long felt need for rich-text in event information - 
particularly in the public events area. Some systems even provide that 
through proprietary mechanisms. When calendaring was seen as simply a 
mechanism for putting together (corporate) meetings rich text was 
perhaps regarded as a luxury.

Even for personal events - or for corporate meetings - being able to 
create bulleted lists etc would be useful.

> Maybe iTip meeting should have a refrence to RFC5546

Done

> There are Components properties sdataprop is a new component

Not sure what the issue is here

>                      ; and MAY occur more than once

Fixed

>
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 19 Oct 2016 12:29:37 -0400

Hi Mike,

On 10/19/2016 11:16 AM, Michael Douglass wrote:
> I'll post a new draft in a short while: there are 2 issues at least 
> I'd like to address:
>
> 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?

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Michael Douglass <[email-masked]>
Date: Wed, 19 Oct 2016 15:15:23 -0400

> specified to warrant the change?  Do you have an example in mind that

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:
        [email-masked]
       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:[email-masked]
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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 19 Oct 2016 15:33:58 -0400

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:
> (An aside - I think the example is faulty - a ":" wheer there should 
> eb a ";")
>
> 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
>