Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt

From: Adrian Apthorp <[email-masked]>
Date: Sat, 1 Sep 2018 19:11:40 +0800

Just going through one more time and I found a couple of things which 
would further improve the document.

1) Section 5.2.7 progress. The description of each of the status values 
sounds a bit strange

       *  "completed": The participant completed their progress.

       *  "in-process": The participant processes this task.

       *  "failed": The participant failed to complete their progress.

Shouldn't these be more like?

       *  "completed": The participant completed their task.

       *  "in-process": The participant has started this task.

       *  "failed": The participant failed to complete their task.

2) Looking at example 7.6, it would be great if this could be extended 
to give more complete examples of location, especially how to represent 
the airport names Frankfurt / Narita with their IATA codes FRA / NRT. 
Clearly quite a common use case.

On 30/08/18 17:05, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Calendaring Extensions WG of the IETF.
>
>          Title           : JSCalendar: A JSON representation of calendar data
>          Authors         : Neil Jenkins
>                            Robert Stepanek
> 	Filename        : draft-ietf-calext-jscalendar-06.txt
> 	Pages           : 53
> 	Date            : 2018-08-30
>
> Abstract:
>     This specification defines a data model and JSON representation of
>     calendar data that can be used for storage and data exchange in a
>     calendaring and scheduling environment.  It aims to be an alternative
>     to the widely deployed iCalendar data format and to be unambiguous,
>     extendable and simple to process.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-06
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Robert Stepanek <[email-masked]>
Date: Wed, 05 Sep 2018 15:53:36 +0200

Hi Adrian,

On Sat, Sep 1, 2018, at 13:11, Adrian Apthorp wrote:
> would further improve the document

Thanks! I have rephrased the Participant status descriptions and updated the 7.6 example with airport codes. Any decent map application should now show the start and end airports using the location names (see https://github.com/CalConnect/PUBLIC_DRAFTS/commit/73de023af949dadb11d94b6be7687e500ed2f213).

I'll wait with a RFC version update until end of this week in case further feedback comes up.

Cheers,
Robert

---

From: Adrian Apthorp <[email-masked]>
Date: Thu, 6 Sep 2018 20:01:54 +0800

Thanks. Is there no mechanism to use a separate attribute for the airport code rather than embed it in the name? From a machine processing perspective this is obviously preferable. Could linkIds be used for this?

> On 5 Sep 2018, at 9:53 PM, Robert Stepanek <[email-masked]> wrote:
> 
> Hi Adrian,
>

---

From: Robert Stepanek <[email-masked]>
Date: Thu, 06 Sep 2018 08:42:43 -0400

On Thu, Sep 6, 2018, at 14:02, Adrian Apthorp wrote:

> Thanks. Is there no mechanism to use a separate attribute for the 
> airport code rather than embed it in the name?

Not in this spec, no. In my opinion, this is a use case for vendor extensions (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-3.3). E.g. a property named "iata.org/locationId" could hold the airport code.

> From a machine 
> processing perspective this is obviously preferable.

Absolutely! It's just, I don't think this should go in the core spec.

>  Could linkIds be used for this?

In this case, I think the custom property would be more appropriate.

---

From: Marten Gajda <[email-masked]>
Date: Thu, 6 Sep 2018 23:46:59 +0200

> Thanks. Is there no mechanism to use a separate attribute for the airport code rather than embed it in the name? From a machine processing perspective this is obviously preferable. Could linkIds be…
I think the consent was to put such structured information into a linked
resource like a schema.org document, e.g. https://schema.org/Flight
This could be embedded with a data: URI of course.

Cheers,

Marten

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Adrian Apthorp <[email-masked]>
Date: Fri, 7 Sep 2018 22:58:32 +0800

Thanks. I wasn’t expecting this to be part of the core spec but know that it could be done given this is likely to be a fairly common use case. I thought it would be an example for LinkIds. But it seems there are different opinions on the approach.

A separate profile / spec for representing transportation details based on JsCalendar would be useful. In which cas I think UN Locodes are worth a look.

> On 6 Sep 2018, at 8:42 PM, Robert Stepanek <[email-masked]> wrote:
>