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

[Doug Royer <[e-mail]>]

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