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

[Paul Libbrecht <[e-mail]>]

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
>
>    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:
>       [e-mail]
>
>    Intended usage:  COMMON
>
>    Restrictions on usage:  N/A
>
>    Author:  See the "Author's Address" section of this document.
>
>    Change controller:  IETF
>
> Cheers,
> Neil.


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