Re: [calsify] New Draft - Maintenance Notifications Using iCalendar

[Ryan Gunter <[e-mail]>]

Doug,

I'm extremely appreciative of your response, it's very helpful.

Based on my previous draft, we have a very simple set of fields but enough
to provide context for an upcoming maintenance.  With this being said, the
addition of a new component seems like the better option.

For the new draft, would we revise it to 01, or create a new draft to
review?


Ryan Gunter  |   *Twitch* <http://www.twitch.tv/>   |   Network Engineering
 |   +1.415.568.7607


On Tue, Jul 23, 2019 at 1:54 PM Doug Royer <[e-mail]> wrote:

> On 7/23/19 9:02 AM, Ryan Gunter wrote:
>
> >
> > Is this suggesting to use the ATTACH property with a defined data set
> from schema.org <http://schema.org>, or otherwise?  If that's the case,
> we could work with schema.org <http://schema.org> to define these data
> sets?  The original hope of the draft was to agree upon a way to provide
> network maintenance information within the file.  If we went with the
> ATTACH or STRUCTURED-DATA route, would there be a way to define this data
> set or method within the IETF?  I just want to make sure I understand the
> boundaries and drive this effort correctly.
>
> One option is to create a new iCalendar component 'MAINTNOTE'  and include
> it inline, as in:
>
>         ...
>         BEGIN:MAINTNOTE
>         MAINTNOTE-PROVIDER:example.com
>         MAINTNOTE-ACCOUNT: Twitch
>         MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415
>         MAINTNOTE-OBJECT-ID: ABC123
>         MAINTNOTE-IMPACT: OUTAGE
>         MAINTNOTE-STATUS: CONFIRMED
>         END:MAINTNOTE
>         ...
>
> Which would be the 'iCalendar' way of doing it.
>
> Another option is if the data structure does not easily translate to
> iCalendar format, you could attach it with something like this for an
> included attachment (where text/maintnode would be replaced with whatever
> mime-type is assigned to identify your data):
>
>         ...
>         ATTACH;fmttype=text/maintnode;...:CID=maintnote-attach-id
>         ...
>
> Or for an external object:
>
>         ...
>         ATTACH;fmttype=text/maintnode;...:
> https://example.com/maintnote-attach
>         ...
>
> The advantage to ATTACH is that email and calendar tools like outlook,
> Thunderbird, and others will see the data as an attachment and allow the
> user to drag/drop it, without new code needing to be written just to pull
> it out, or to copy/paste it.  Outlook, Thunderbird, and many other calendar
> clients already know how to handle ATTACH, even when they do not know what
> the mime-type does.  Minimal changes to make a maintnode aware calendar
> client. Zero changes needed when the iCalendar application can already
> handle ATTACH, and copy/paste is what you need.
>
> And for custom iCalendar maintnode programs, MIME libraries already know
> how to handle mime multipart objects (CID or external). How an attachment
> is include in a mime object is already a standard. Custom maintnote
> processing code would just open the text/calendar MIME object and pull out
> the ATTACH;text/maintnote properties. Then call already implemented MIME
> libraries to extract the included maintnode attachments (a CID) and/or for
> fetching the URL provided for external maintnode attachments. Then your
> custom code does whatever it wants with the attachment and iCalendar data.
>
> The structured-data proposal has no advantages, and it would complicate
> recognizing the data as an attachment or extra data and require outlook,
> Thunderbird, and all other calendar clients be re-written to extract out
> the maintnote data from the iCalendar object, or someone would have to
> write a plug-in for all email clients and calendar clients to extract the
> data. (vs just using an copy/paste or using existing MIME libraries).
>
> As to schema.org. Any MIME object defined by them, can already be the
> content of an ATTACH iCalendar object. Just name the MIME-TYPE and provide
> the URL as the property value.
>
> It is not a schema.org vs IETF decision. You can (or not) define it with
> schema.org. You can ATTACH it as a defined schema.org object, or attach
> it as a non-schema.org object. Both with ATTACH. (Or go the MAINTNOTE
> component way).
>
> If it maps easily into iCalendar, use MAINTNOTE. If your data is part of a
> larger data set that is complicated, define it with schema.org, and
> iCalendar ATTACH it.
>
> Hope this helps.
>
> --
>
> Doug Royer - (http://DougRoyer.US)
> [e-mail]
> 714-989-6135
>