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

From: Ryan Gunter <[email-masked]>
Date: Wed, 3 Jul 2019 14:41:03 -0600

Hello,

I wanted to inform everyone of a new draft my team recently submitted,
"Maintenance Notification Improvements Using iCalendar."

We would appreciate any feedback and hope this found useful by the
community.

https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 3 Jul 2019 17:12:29 -0400

Hi Ryan,

My initial reaction to reading this is that all of the new maintenance 
properties should be grouped under a single entity such as a 
STRUCTURED-DATA 
<https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6> 
property or a new MAINTNOTE sub-component, similar to PARTICIPANT.
<https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-8.1>

On 7/3/19 4:41 PM, Ryan Gunter wrote:
> Ryan Gunter | *Twitch* <http://www.twitch.tv/>|   Network Engineering| 
> +1.415.568.7607
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: "Thomas Schäfer" <[email-masked]>
Date: Thu, 4 Jul 2019 13:19:12 +0200

Hi Ryan,

what also come to my mind, when reading this is, that it looks to me, that there are redundant information included: X-MAINTNOTE-STATUS:IN-PROCESS.

The event includes a start and end-time and wouldn't it be assumed, that during this time period, the maintenance is in progress? The approach you took will need explicit changes to the event even if it happens as announced to update only the status of the maintenance.

Thomas

Gesendet: Mittwoch, 03. Juli 2019 um 23:12 Uhr

Von: "Ken Murchison" <[email-masked]>

An: [email-masked]

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

Hi Ryan,

My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

Hello,

I wanted to inform everyone of a new draft my team recently submitted, "Maintenance Notification Improvements Using iCalendar."

We would appreciate any feedback and hope this found useful by the community.

Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607

--
Ken Murchison
Cyrus Development Team
Fastmail US LLC

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

---

From: "Thomas Schäfer" <[email-masked]>
Date: Thu, 4 Jul 2019 13:23:57 +0200

Hi Ryan,

There is also a common mistake made in the examples in choosing simple numbers as UIDs of events: UID:42

The DEVGUIDE of CalConnect https://devguide.calconnect.org/Data-Model/UID/ describes this issue and how UIDs should always be generated and why.

Thomas

Gesendet: Mittwoch, 03. Juli 2019 um 22:41 Uhr

Von: "Ryan Gunter" <rgunter=[email-masked]>

An: [email-masked]

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

Hello,

---

From: "Tim Hare" <[email-masked]>
Date: Thu, 4 Jul 2019 20:48:39 -0400

I see this as looking for a specific “payload” of information for a VEVENT.  I would like to see a more general extension,  with a EVENTTYPE:  property that named a “schema” for DESCRIPTION: .    The calendar CUA could then invoke a “helper”/plug-in to process that schema;  if EVENTTYPE was not there, or the CUA was not EVENTTYPE-aware,  the client/UA would just display the text of DESCRIPTON: as happens now which would still show the structured fields, there just wouldn’t be anything to process them.

In your use case EVENTTYPE: would contain “Maintenance Notification” or “MAINTNOTE” and  the application would search for “Provider”,  “Account”,  “Maintenance ID”,  “Object ID”,  “Impact”, and “Status” within the DESCRIPTION text.   

Other types of specialized events could use different EVENTTYPEs – for example “OUTAGE” with schema for “Reason”, “Reported By”, “Resolved By”,  and “Resolution”.

Tim Hare

Interested Bystander, Non-Inc.

From: calsify [mailto:[email-masked]] On Behalf Of "Thomas Schäfer"
Sent: Thursday, July 4, 2019 7:19 AM
To: Ken Murchison <[email-masked]>
Cc: [email-masked]
Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar

Hi Ryan,

Thomas

Hi Ryan,

My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6>  property or a new MAINTNOTE sub-component, similar to PARTICIPANT. <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-8.1> 

Hello,

 

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

_______________________________________________
calsify mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Doug Royer <[email-masked]>
Date: Sun, 7 Jul 2019 12:05:45 -0600

Drop the "X-" in front of your property names in your draft, as when (if) this makes it to RFC status, they will be IANA registered.

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Ryan Gunter <[email-masked]>
Date: Mon, 8 Jul 2019 16:52:23 -0600

Hello everyone,

We really appreciate the feedback!  There are several things to digest and
research.  I will reply shortly with comments/questions.

Thank you!

On Sun, Jul 7, 2019 at 12:06 PM Doug Royer <[email-masked]> wrote:

>
> Drop the "X-" in front of your property names in your draft, as when (if)
> this makes it to RFC status, they will be IANA registered.
>
>
>
> --
>

---

From: Michael Douglass <[email-masked]>
Date: Mon, 8 Jul 2019 22:25:36 -0400

As Ken said earlier this is a perfect use for the new Structured-Data 
property defined in the eventpub-extensions draft

https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

(I will try to get a new version out this week)

The benefit of this approach is that it requires no further extensions 
to iCalendar - your maintenance data is carried as a payload with a 
known schema.

You're free to define this schema in whatever way seems appropriate but 
it would make sense to provide some indication as to how clients should 
handle it.

A question: is this more like a task than an event? There is a task 
extensions draft

https://datatracker.ietf.org/doc/draft-apthorp-ical-tasks/

currently expired but I think due to be revived. This defines an 
ESTIMATED-DURATION property so that the task dtstart/end defines a 
window within which the task should be accomplished.

On 7/8/19 18:52, Ryan Gunter wrote:
> Hello everyone,
>
> We really appreciate the feedback!  There are several things to digest 
> and research.  I will reply shortly with comments/questions.
>
> Thank you!
>
> +1..415.568.7607
> On Sun, Jul 7, 2019 at 12:06 PM Doug Royer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Drop the "X-" in front of your property names in your draft, as
>     when (if) this makes it to RFC status, they will be IANA registered.
>
>
>
>     -- 
>
>     [email-masked] <mailto:[email-masked]>
>     714-989-6135
>

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 8 Jul 2019 23:24:03 -0400

STRUCTURED-DATA and SCHEMA would satisfy, I think, what I was trying to say with EVENTTYPE in my previous post.

Tim Hare

From: calsify [mailto:[email-masked]] On Behalf Of Michael Douglass
Sent: Monday, July 8, 2019 10:26 PM
To: Ryan Gunter <rgunter=[email-masked]>; [email-masked]
Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar

As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft

The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema.

You're free to define this schema in whatever way seems appropriate but it would make sense to provide some indication as to how clients should handle it.

A question: is this more like a task than an event? There is a task extensions draft 

currently expired but I think due to be revived. This defines an ESTIMATED-DURATION property so that the task dtstart/end defines a window within which the task should be accomplished.

Hello everyone,

We really appreciate the feedback!  There are several things to digest and research.  I will reply shortly with comments/questions.

Thank you!

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

On Sun, Jul 7, 2019 at 12:06 PM Doug Royer <[email-masked] <mailto:[email-masked]> > wrote:

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 8 Jul 2019 21:44:04 -0600

> The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema.

You say "no further extensions". They would still have to be documented. So would that save any documentation work?
If released as an RFC, then the SCHEMA uri and content value would be documented. That seems identical in function  as placing them in their own property name.

The only difference is that STRUCTURED-DATA allows, and forces, iCalendar implementations to include parsers for each unique SCHEMA. And does that without *any* restriction to the content (VALUE) format.

Where as, by defining them as new properties, any compliant iCalendar implementation can parse them now, preserve them, even when they do not know what to do with them. They can even display them as KEY/VALUE pairs.

STRUCTURED-DATA just forces multiple and unlimited new and random data formats into the VALUE. While still requiring them to be documented and published. Seems like more documentation work, and more implementation work. With one new data type parser for each new SCHEMA published.

Why have 2+ data formats in the same object?

It looks to me as if STRUCTURED-DATA is just a way of passing opaque data that will contain proprietary information. This completely reverses the idea of a standard calendar object.

If your going to document a new data-set. Document it in iCalendar format. Not in unlimited, unrestricted and random formats.
  
--

---

From: Doug Royer <[email-masked]>
Date: Mon, 8 Jul 2019 21:57:01 -0600

On 7/3/19 3:12 PM, Ken Murchison wrote:
> Hi Ryan,
> 
> My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6> property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

New MAINTNOTE component - great idea. Then existing implementation should still be able to parse and preserve the content without knowing or acting on the content.

--

---

From: Michael Douglass <[email-masked]>
Date: Tue, 9 Jul 2019 00:04:37 -0400

On 7/8/19 23:44, Doug Royer wrote:
>> The benefit of this approach is that it requires no further 
>> extensions to iCalendar - your maintenance data is carried as a 
>> payload with a known schema.
>
> You say "no further extensions". They would still have to be 
> documented. So would that save any documentation work?
> If released as an RFC, then the SCHEMA uri and content value would be 
> documented. That seems identical in function  as placing them in their 
> own property name.
>
> The only difference is that STRUCTURED-DATA allows, and forces, 
> iCalendar implementations to include parsers for each unique SCHEMA. 
> And does that without *any* restriction to the content (VALUE) format.
STRUCTURED-DATA DOES NOT force any client to parse the data. If it 
doesn't recognize the schema it's free to ignore it completely.
>
> Where as, by defining them as new properties, any compliant iCalendar 
> implementation can parse them now, preserve them, even when they do 
> not know what to do with them. They can even display them as KEY/VALUE 
> pairs.
>
> STRUCTURED-DATA just forces multiple and unlimited new and random data 
> formats into the VALUE. While still requiring them to be documented 
> and published. Seems like more documentation work, and more 
> implementation work. With one new data type parser for each new SCHEMA 
> published.
>
I see no requirement for publishing anything about the schema other than 
to reserve it. The only requirement for publishing is if the schema 
definer wishes 3rd parties to make use of it. It doesn't even have to be 
defined and published with the ietf. It's payload
>
> It looks to me as if STRUCTURED-DATA is just a way of passing opaque 
> data that will contain proprietary information. This completely 
> reverses the idea of a standard calendar object.
>
> If your going to document a new data-set. Document it in iCalendar 
> format. Not in unlimited, unrestricted and random formats.
So if somebody has XML or JSON data they wish to transport - already 
defined by a schema - they are required to recast that as iCalendar? I 
think not. Without STRUCTURED-DATA they'll just push it across as an 
x-prop or attachment then it's even more opaque.

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 9 Jul 2019 16:57:36 -0400

What is needed is documentation that says all calendar UAs are not required
to handle STRUCTURED-DATA and SCHEMA,  perhaps that if STRUCTURED-DATA is
used then DESCRIPTION  SHOULD be present to describe what the structured
data is so that any CUA can display _that_ text,  but consumers of the
calendar item that DO understand the SCHEMA can use it.   

In my view, defining new properties for every possible kind of VEVENT or
VTODO amounts to the same amount of work as defining a SCHEMA for that
structured data.  CUAs would fail, graciously, to process those properties
in the just about same way as they'd fail to handle the structured data.
The difference, to me,  is that using STRUCTURED-DATA and SCHEMA  means the
RFC isn't constantly updated for new use cases involving new kinds of data
that is related to the calendar event but not calendar data per se.

Tim Hare

-----Original Message-----
From: calsify [mailto:[email-masked]] On Behalf Of Doug Royer
Sent: Monday, July 8, 2019 11:44 PM
To: [email-masked]
Subject: [calsify] SCHEMA vs New Property

> The benefit of this approach is that it requires no further extensions to
iCalendar - your maintenance data is carried as a payload with a known
schema.

You say "no further extensions". They would still have to be documented. So
would that save any documentation work?
If released as an RFC, then the SCHEMA uri and content value would be
documented. That seems identical in function  as placing them in their own
property name.

The only difference is that STRUCTURED-DATA allows, and forces, iCalendar
implementations to include parsers for each unique SCHEMA. And does that
without *any* restriction to the content (VALUE) format.

Where as, by defining them as new properties, any compliant iCalendar
implementation can parse them now, preserve them, even when they do not know
what to do with them. They can even display them as KEY/VALUE pairs.

STRUCTURED-DATA just forces multiple and unlimited new and random data
formats into the VALUE. While still requiring them to be documented and
published. Seems like more documentation work, and more implementation work.
With one new data type parser for each new SCHEMA published.

It looks to me as if STRUCTURED-DATA is just a way of passing opaque data
that will contain proprietary information. This completely reverses the idea
of a standard calendar object.

If your going to document a new data-set. Document it in iCalendar format.
Not in unlimited, unrestricted and random formats.
  
--

---

From: Michael Douglass <[email-masked]>
Date: Tue, 9 Jul 2019 18:18:43 -0400

> that is related to the calendar event but not calendar data per se.

Additionally - data that is incompatible with the iCalendar format can 
be transported easily.

And I don't think it's quite the same amount of work.

New iCalendar properties need to be generally useful in calendars and 
scheduling. Very specific properties used to address a need such as this 
are probably better contained in data with their own schema.

There's a whole other discussion as to whether or not these properties 
are generally useful - probably not as something only for maintenance.

As an aside having reread the draft - email is not the only possible 
transport mechanism. CalDAV or some other protocol might be appropriate. 
Any draft should probably allow for different ways of transporting the 
messages.

---

From: Doug Royer <[email-masked]>
Date: Tue, 9 Jul 2019 21:36:20 -0600

On 7/8/19 10:04 PM, Michael Douglass [Masked] wrote:
> I see no requirement for publishing anything about the schema other than to reserve it. The only requirement for publishing is if the schema definer wishes 3rd parties to make use of it. It doesn't even have to be defined and published with the ietf. It's payload

Yes, your proposing a free for all data object. Do whatever you want. The opposite of a standard object.

> So if somebody has XML or JSON data they wish to transport - already defined by a schema - they are required to recast that as iCalendar? I think not. Without STRUCTURED-DATA they'll just push it across as an x-prop or attachment then it's even more opaque.

They both are opaque data, except you saying it is different.

X-PROP and STRUCTURED-DATA are the same thing. Random non standard blobs of data to implementations that do not know what they mean. The ATTACH base-64 encoding/decoding value allows for any kind of data.

    X-MY-PROP;x-myparam-data-set-3:base-64-text

They both contain the same thing.

That was the debates with X-PROP. A standard way to parse random blobs of propitiatory data. It makes you want to standardize the data sets to use it across vendors.

And STRUCTURED-DATA is a name that implies structure. It is not. It could be unstructured data, blobs of weather data, blobs of random disk errors. It has no added value over X-PROP or ATTACH. The data could be base-64 encoded or not, it is just text.

Example:

   ATTACH;FMTTYPE=text/html;...:base-64 encoded html page, or URL or CID to that page

vs

   STRUCTURED-DATA:SCHEMA=http://www.w3.org/TR/html4;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content.

vs

  STRUCTURED-DATA:SCHEMA=http://MyPrepratorySchema;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content.

Use ATTACH with a CID value, pointing to MIME object and set the mime-type value.

Set the ATTACH fmttypeparam and CID part MIME-TYPE to text/xml or application/json (or whatever) and include anything you can transport.

Or set the ATTACH value to an external URL with ATTACH fmttypeparm set to the correct data type.

If you need to, define and register a new mime-type for your data (schema). Or use an x-mime-type with ATTACH with your preparatory data.

Did I miss something that STRUCTURED-DATA can do, that X-PROP or ATTACH can not do?
Creating it simply because you do not want to base64 encode text is a heavy solution when you can already ATTACH the value in binary, text, or whatever by using a CID URI or a URL URI all of which can contain plain text.

iCalendar is a MIME object.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Jul 2019 11:08:42 -0600

>> that is related to the calendar event but not calendar data per se.

The effect of SCHEMA would be to create an entirely new object identifier to replace mime-type.

If the data is proprietary, the X-PROP with an undocumented data type works now and no documentation needed. Implementations are free to ignore X-PROP.

If the data is to be shared between vendors, then documenting is what is needed, and is the reason for the IETF, RFCs, and standards. It can be released as a proposed standard, or informational.

The issue with maintenance is work flow, and not so much data values. They are proposing both the flow and the data. The draft needs work and feedback.

> Additionally - data that is incompatible with the iCalendar format can be transported easily.

It already can, iCalendar is a MIME content type that can contain internal to the same MIME object - via CID, or external with a URL object sets. That is in the introduction of 5545.

A fact is that, some (many?) user interfaces do not take advantage of that may make it appear that a new object identifier is needed.

 From 5545:

	"...Note: While there is no restriction imposed on the URI schemes
          allowed for this parameter, Content Identifier (CID) [RFC2392],
          HTTP [RFC2616], and HTTPS [RFC2818] are the URI schemes most
          commonly used by current implementations. ..."

> And I don't think it's quite the same amount of work.

Same is relative to where the code is at, and the final version.

> New iCalendar properties need to be generally useful in calendars and scheduling. Very specific properties used to address a need such as this are probably better contained in data with their own schema.

There is no restriction on the type of attachments that can added.

The proposal to replace  Mime-Type identifiers inside of a MIME object, would be creating an entire new set of identifiers. Something that would be in parallel and out of step with how the IETF has decided to define object types.

The 'how to define any object in the world' debate has no solution. So the IETF decided on Mime-Type and a process to register new ones. And a process to use proprietary types of data. These defied mime types are known to many operating systems already. The IETF has a process in place to define new object types.

With many applications, I can copy/paste an attached object and the mime headers tell the drop point what the data is. It would be tossing all object identifiers new object identifiers.

> There's a whole other discussion as to whether or not these properties are generally useful - probably not as something only for maintenance.

Workflow is a great topic for iCalendar. Which I think is at the heart of their proposal. Perhaps their draft could be released (when ready) as an informational RFC, simply to document how it is done by several vendors. Then a parallel discussion about workflow would not delay them.

> As an aside having reread the draft - email is not the only possible transport mechanism. CalDAV or some other protocol might be appropriate. Any draft should probably allow for different ways of transporting the messages.

iCalendar is a MIME content type, that does not mean it must be transported via iMIP. And 5545 makes that point in the introduction section. And one reason that 2445 chose it as a MIME content type, was for attachments.

I can not think of any transport that can not transport a multipart MIME object.

I do not see any plus to internalizing any random kind of attachment, inventing a new object identifier, simply to make it a property value. If a need exists, use ATTACH with fmttypeparam set to a mime-type that has been defined or can be registered, and base64 encode it.

Or for  proprietary use, make up an X-PROP and include any proprietary value in any format needed.

--

---

From: Ryan Gunter <[email-masked]>
Date: Wed, 10 Jul 2019 16:04:57 -0600

Hello everyone,

Again, the feedback is appreciated.

The new Event Publishing Extensions draft does indeed have some useful
properties that would be serve the purpose of providing parseable
maintenance information. The suggestions provided 2 options, and I have
questions about both.

*STRUCTURED-DATA*
1.  Since the fields in the proposed draft are not part of any standard
schema, one would need to be defined.  I’m assuming another version of the
draft would define the schema for maintenances within the property?

*New MAINTNOTE Component*
1. My initial thought is this seems like a simpler solution.  Is it being
suggested this could possibly be included into the Event Publishing
Extensions draft, or something separate?
2. To ensure I’m understanding this correctly, would the component be
structured something similar to this?

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

On Mon, Jul 8, 2019 at 9:57 PM Doug Royer <[email-masked]> wrote:

> STRUCTURED-DATA <
> https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6>
> New MAINTNOTE component - great idea. Then existing implementation should
> still be able to parse and preserve the content without knowing or acting
> on the content.
>
> --
>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 10 Jul 2019 20:32:42 -0400

Hy Ryan,

If you go the MAINTNOTE component route, you can drop the MAINTNOTE- 
prefix on all of the properties.

On 7/10/19 6:04 PM, Ryan Gunter wrote:
> maintenance information. The suggestions provided 2 options, and I 
> have questions about both.
>
> *STRUCTURED-DATA*
> 1.  Since the fields in the proposed draft are not part of any 
> standard schema, one would need to be defined.  I’m assuming another 
> version of the draft would define the schema for maintenances within 
> the property?
>
> 1. My initial thought is this seems like a simpler solution.  Is it 
> being suggested this could possibly be included into the Event 
> Publishing Extensions draft, or something separate?
> MAINTNOTE-PROVIDER:example.com <http://example.com>
> On Mon, Jul 8, 2019 at 9:57 PM Doug Royer <[email-masked] 
>     > My initial reaction to reading this is that all of the new
>     maintenance properties should be grouped under a single entity
>     such as a STRUCTURED-DATA
>     <https://tools..ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6
>     <https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6>>
>     New MAINTNOTE component - great idea. Then existing implementation
>     should still be able to parse and preserve the content without
>     knowing or acting on the content.
>
>     -- 
>

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

---

From: Ryan Gunter <[email-masked]>
Date: Tue, 16 Jul 2019 10:17:08 -0600

Ken / All,

Thank you very much for the help.  This is my first IETF process so I'm
still learning.

Our team has been discussing the options, and the STRUCTURED-DATA field
might be better fit for our network maintenance use case.  Has there been
any discussion about coding support / libraries / tooling for this
property? Also, the draft indicates using standardized schemas from
schema.org or hosting your own is acceptable, however we were curious if
there were any thoughts on storing schemas specifically for STRUCTURED-DATA?

Since the Calendaring Extensions document is still in a draft state, is
there any current rough time frame for it being ratified? It looks to be in
the final stages after looking at the comments from v12.

On Wed, Jul 10, 2019 at 6:32 PM Ken Murchison <[email-masked]> wrote:

> Ryan Gunter  |   *Twitch* <http://www.twitch.tv/>   |   Network
> Engineering   |   +1.415.568.7607
>
>
>> https://tools..ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6
> calsify mailing [email-masked]://www.ietf.org/mailman/listinfo/calsify
>
> --
> Ken Murchison
> Cyrus Development Team
> Fastmail US LLC
>

---

From: Michael Douglass <[email-masked]>
Date: Tue, 16 Jul 2019 12:44:50 -0400

On 7/16/19 12:17, Ryan Gunter wrote:
> Ken / All,
>
> Thank you very much for the help.  This is my first IETF process so 
> I'm still learning.
>
> Our team has been discussing the options, and the STRUCTURED-DATA 
> field might be better fit for our network maintenance use case.  Has 
> there been any discussion about coding support / libraries / tooling 
> for this property? Also, the draft indicates using standardized 
> schemas from schema.org <http://schema.org> or hosting your own is 
> acceptable, however we were curious if there were any thoughts on 
> storing schemas specifically for STRUCTURED-DATA?
I hadn't thought so - I'd assumed that the process at schema.org might 
be appropriate. I don't suppose there's any problems with defining such 
schemas within the ietf but it migth be worth trying the schema.org 
approach first?
>
> Since the Calendaring Extensions document is still in a draft state, 
> is there any current rough time frame for it being ratified? It looks 
> to be in the final stages after looking at the comments from v12.
I'm hoping to get a new draft out when things get opened up again 
(20th). This will resolve issues over the changes to the SOURCE property 
(by dropping it in favor of STRUCTURED-DATA).
> On Wed, Jul 10, 2019 at 6:32 PM Ken Murchison <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hy Ryan,
>
>     If you go the MAINTNOTE component route, you can drop the
>     MAINTNOTE- prefix on all of the properties.
>
>
>>     The new Event Publishing Extensions draft does indeed have some
>>     useful properties that would be serve the purpose of providing
>>     parseable maintenance information. The suggestions provided 2
>>     options, and I have questions about both.
>>
>>     *STRUCTURED-DATA*
>>     standard schema, one would need to be defined. I’m assuming
>>     another version of the draft would define the schema for
>>     maintenances within the property?
>>
>>     1. My initial thought is this seems like a simpler solution.  Is
>>     it being suggested this could possibly be included into the Event
>>     2. To ensure I’m understanding this correctly, would the
>>     component be structured something similar to this?
>>
>>     BEGIN:MAINTNOTE
>>     Ryan Gunter | *Twitch* <http://www.twitch.tv/>|   Network
>>     Engineering| +1.415.568.7607
>>
>>
>>         maintenance properties should be grouped under a single
>>         entity such as a STRUCTURED-DATA
>>         New MAINTNOTE component - great idea. Then existing
>>         implementation should still be able to parse and preserve the
>>         content without knowing or acting on the content.
>>
>>         -- 
>>

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Jul 2019 12:46:19 -0600

On 7/16/19 10:17 AM, Ryan Gunter [Masked] wrote:
> Preview: Ken / All, Thank you very much for the help. This is my first --> SPAM? CLICK to BLOCK <https://dnt.abine.com/#/block_email/[email-masked]/[email-masked]>
> 
> This email is Masked using Blur - it was sent from ietf.org to [email-masked] (your reply stays Masked). To protect your privacy <https://www.abine.com/faq.html#caniaddcc>, do not forward this message, or add new recipients like CCs or BCCs.
> 
> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount. <https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header> ]
> 
> Ken / All,
> 
> Thank you very much for the help.  This is my first IETF process so I'm still learning.
> 
> Our team has been discussing the options, and the STRUCTURED-DATA field might be better fit for our network maintenance use case.  Has there been any discussion about coding support / libraries / tooling for this property? Also, the draft indicates using standardized schemas from schema.org <http://schema.org> or hosting your own is acceptable, however we were curious if there were any thoughts on storing schemas specifically for STRUCTURED-DATA?

Is this a workflow process that involves scheduling? Or are you looking for an XML/HTML (schema.org) web page solution? A massive percentage of the schema.org schemas are CSS or HTML content.

 From the NANOG mailing list, it looked as if you wanted to automatically track a log of calendaring events (past or future) and have a standard way to describe and parse the description to keep track of what was done or needs to be done. (looks like calendaring/scheduling to me)

If your content is primarily for automated display (html or otherwise) of data, then maybe schema.org web content will be what you want.

If your content is for processing and work flow (that may be displayed), then you may want an iCalendar (or other type) object.

The two are not incompatible, as schema.org ties to MIME-types (attachments). - See the schema.org contentType as one example. Structured-Data has no benefit over ATTACH. I think people misunderstand the ATTACH property.

The W3C (schema.org) and the IETF are in agreement on object identifiers. Schema.org allows for the definition of data sets, and they are tied to mime types when sent as separate, non-web-page objects.

Don't over complicate your data set. Define it, then map it to agreed on names, value types, and when needed specific acceptable values. Then decide if its values are primarily web-page-content, or a stand alone transported objects. And if stand alone objects tied to calendar date/time, then keep with the same format and do not invent another one, it will just complicate parsers.

--

---

From: Michael Douglass <[email-masked]>
Date: Tue, 16 Jul 2019 18:44:53 -0400

On 7/16/19 14:46, Doug Royer wrote:
>> Preview: Ken / All, Thank you very much for the help. This is my 
>> first --> SPAM? CLICK to BLOCK 
>> <https://dnt.abine.com/#/block_email/[email-masked]/[email-masked]>
>>
>> This email is Masked using Blur - it was sent from ietf.org to 
>> [email-masked] (your reply stays Masked). To protect your 
>> privacy <https://www.abine.com/faq.html#caniaddcc>, do not forward 
>> this message, or add new recipients like CCs or BCCs.
>>
>> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe 
>> at a discount. 
>> <https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header> 
>> ]
>>
>> Ken / All,
>>
> Is this a workflow process that involves scheduling? Or are you 
> looking for an XML/HTML (schema.org) web page solution? A massive 
> percentage of the schema.org schemas are CSS or HTML content.
>
> From the NANOG mailing list, it looked as if you wanted to 
> automatically track a log of calendaring events (past or future) and 
> have a standard way to describe and parse the description to keep 
> track of what was done or needs to be done. (looks like 
> calendaring/scheduling to me)
>
> If your content is primarily for automated display (html or otherwise) 
> of data, then maybe schema.org web content will be what you want.
>
> If your content is for processing and work flow (that may be 
> displayed), then you may want an iCalendar (or other type) object.
>
> The two are not incompatible, as schema.org ties to MIME-types 
> (attachments). - See the schema.org contentType as one example. 
> Structured-Data has no benefit over ATTACH. I think people 
> misunderstand the ATTACH property.

So how as an attachment would we represent the example:

STRUCTURED-DATA;FMTTYPE=application/ld+json;
  SCHEMA="https://schema.org/SportsEvent";
  VALUE=TEXT:{\n
    "@context": "http://schema.org"\,\n
    "@type": "SportsEvent"\,\n
    "homeTeam": "Pittsburgh Pirates"\,\n
    "awayTeam": "San Francisco Giants"\n
  }\n

>
> The W3C (schema.org) and the IETF are in agreement on object 
> identifiers. Schema.org allows for the definition of data sets, and 
> they are tied to mime types when sent as separate, non-web-page objects.
>
> Don't over complicate your data set. Define it, then map it to agreed 
> on names, value types, and when needed specific acceptable values. 
> Then decide if its values are primarily web-page-content, or a stand 
> alone transported objects. And if stand alone objects tied to calendar 
> date/time, then keep with the same format and do not invent another 
> one, it will just complicate parsers.
I don't see how this complicates parsers: the value of structured-data 
can be ignored if you're not interested and presumably you havea parser 
if you are.

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Jul 2019 17:05:20 -0600

On 7/16/19 4:44 PM, Michael Douglass wrote:
ject.
>     "@context":"http://schema.org"\,\n

Versus the current way, for which parsers already can read:

	ATTACH;FMTTYPE=text/SportsEvent;...:CID:sport-attachement1
	...
	ATTACH;FMTTYPE=text/Maintenance;...:CID:maint-attachement1

> I don't see how this complicates parsers: the value of structured-data can be ignored if you're not interested and presumably you havea parser if you are.

Because you now have to write new code, to do the same as ATTACH.

--

---

From: Ryan Gunter <[email-masked]>
Date: Tue, 23 Jul 2019 09:02:51 -0600

Hello,

Appreciate the replies.  Sorry for the delay.

Is this a workflow process that involves scheduling? Or are you looking for
> an XML/HTML (schema.org) web page solution? A massive percentage of the
> schema.org schemas are CSS or HTML content.
>

This involves scheduling. We looked through schema.org quite a bit and
noticed the same thing.  The idea is the additional fields were to allow
for easier machine parsing, while still functioning as a calendaring file.

> Structured-Data has no benefit over ATTACH. I think people misunderstand
> the ATTACH property.
>

Is this suggesting to use the ATTACH property with a defined data set from
schema.org, or otherwise?  If that's the case, we could work with 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.

On Tue, Jul 16, 2019 at 5:05 PM Doug Royer <[email-masked]> wrote:

> Structured-Data has no benefit over ATTACH. I think people misunderstand
> the ATTACH property.
> >
> identifiers. Schema.org allows for the definition of data sets, and they
> are tied to mime types when sent as separate, non-web-page objects.
> >>
> on names, value types, and when needed specific acceptable values. Then
> decide if its values are primarily web-page-content, or a stand alone
> transported objects. And if stand alone objects tied to calendar date/time,
> then keep with the same format and do not invent another one, it will just
> complicate parsers.
> can be ignored if you're not interested and presumably you havea parser if
> you are.
>

---

From: Doug Royer <[email-masked]>
Date: Tue, 23 Jul 2019 13:54:56 -0600

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

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.

--

---

From: Ryan Gunter <[email-masked]>
Date: Thu, 25 Jul 2019 09:44:51 -0600

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?

On Tue, Jul 23, 2019 at 1:54 PM Doug Royer <[email-masked]> 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.
>
> 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):
>
>         ...
> 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.
>
> --
>

---

From: Doug Royer <[email-masked]>
Date: Thu, 25 Jul 2019 10:32:01 -0600

On 7/25/19 9:44 AM, Ryan Gunter wrote:
> 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?
> 

The next would be -01

--

---

From: Ryan Gunter <[email-masked]>
Date: Thu, 25 Jul 2019 13:21:07 -0600

Thanks. I'll work on that.

On Thu, Jul 25, 2019 at 10:32 AM Doug Royer <[email-masked]> wrote:

> > 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.
> >