Subject: [media-types] Notice of intended registration of "jscalendar+json"

From: "Neil Jenkins" <[email-masked]>
Date: Sun, 08 Mar 2020 13:00:39 +1100

In accordance with Section 5.1 of of RFC6838 <https://tools.ietf.org/html/rfc6838#section-5.1>, I wish to notify the list of the intended registration of a new media type in the standards track document JSCalendar <https://tools.ietf.org/html/draft-ietf-calext-jscalendar>. I welcome any comments or feedback. The intended registration is as follows:

   Type name:  application

   Subtype name:  jscalendar+json

   Required parameters:  type

      The "type" parameter conveys the type of the JSCalendar data in
      the body part, with the value being one of "jsevent", "jstask", or
      "jsgroup".  The parameter MUST NOT occur more than once.  It MUST
      match the value of the "@type" property of the JSON-formatted
      JSCalendar object in the body.

   Optional parameters:  none

   Encoding considerations:  Same as encoding considerations of
      application/json as specified in RFC8529, Section 11 <https://tools.ietf.org/html/rfc8529#section-11> [RFC8259 <https://tools.ietf.org/html/rfc8259>].

   Security considerations:  See Section 7 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-25#section-7> of this document.

   Interoperability considerations:  This media type provides an
      alternative to iCalendar, jCal and proprietary JSON-based
      calendaring data formats.

   Published specification:  This specification.

   Applications that use this media type:  Applications that currently
      make use of the text/calendar and application/calendar+json media
      types can use this as an alternative.  Similarly, applications
      that use the application/json media type to transfer calendaring
      data can use this to further specify the content.

   Fragment identifier considerations:  N/A

   Additional information:

      Magic number(s):  N/A

      File extensions(s):  N/A

      Macintosh file type code(s):  N/A

   Person & email address to contact for further information:
      [email-masked]

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See the "Author's Address" section of this document.

   Change controller:  IETF

Cheers,
Neil.

---

From: "Paul Libbrecht" <[email-masked]>
Date: Wed, 18 Mar 2020 22:35:36 +0100

Hello Neil,

While this is not yet part of rfc6838, I would like to suggest to modify 
the _Additional information_ part to include clipboard-oriented 
designations, so that a copy-and-paste and drag-and-drop exchange is 
standardised too. This has been done on a few occasions (e.g. SVG) but 
should only be done if the media-type makes sense to be exchanged 
between apps or windows within a computer with copy-and-paste or 
drag-and-drop gestures.

I only looked on macOS but got no introspectable data from the calendar 
app that looks similar to the jscalendar intent so I cannot recommend a 
precise name. I could imagine something such as the following to be 
useful:

- macOS UTI (according to [Apple’s 
doc](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html): 
`public.jscalendar` conforms to `public.json` (which I see quoted e.g. 
in 
[this](https://www.oreilly.com/library/view/learning-swift-2nd/9781491967058/ch04.html) 
book).

- Windows: `jscalendar` (in Windows, there is media-type no 
inheritance).

Would it make sense to you to enrich it this way?

Off list, you seemed to answer that this is sensible but that it would 
be good to have the opinions of others. I would be interested to the 
same indeed.

What are the others’ opinion on the media-types’ list?

Thanks in advance.

Paul

On 8 Mar 2020, at 3:00, Neil Jenkins wrote:

> In accordance with Section 5.1 of of RFC6838 
> <https://tools.ietf.org/html/rfc6838#section-5.1>, I wish to notify 
> the list of the intended registration of a new media type in the 
> standards track document JSCalendar 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar>. I welcome 
> any comments or feedback. The intended registration is as follows:
>
>    Type name:  application
>
>       application/json as specified in RFC8529, Section 11 
> <https://tools.ietf.org/html/rfc8529#section-11> [RFC8259 
> <https://tools.ietf.org/html/rfc8259>].
>
>    Security considerations:  See Section 7 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-25#section-7> 
> of this document.
>

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

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 23 Mar 2020 21:09:02 +1100

On Thu, 19 Mar 2020, at 08:35, Paul Libbrecht wrote:
> I would like to suggest to modify the *Additional information* part to include clipboard-oriented designations, so that a copy-and-paste and drag-and-drop exchange is standardised too.

I think it make sense that such information might be copy-pasted on drag-dropped. To be honest I don't understand enough about how these designations work to say what we should do here, but if someone on the list with more expertise in this area has a suggestion I'm happy to update the registration text.

Cheers,
Neil.