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

[Ryan Gunter <[e-mail]>]

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.


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


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

> 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:
>
> 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
>
>
>
> Ryan Gunter  |   *Twitch* <http://www.twitch.tv/>   |   Network
> Engineering   |   +1.415.568.7607
>
>
> On Mon, Jul 8, 2019 at 9:57 PM Doug Royer <[e-mail]> wrote:
>
>> 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
>> <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.
>>
>> --
>>
>> Doug Royer - (http://DougRoyer.US)
>> [e-mail]
>> 714-989-6135
>>
>> _______________________________________________
>> calsify mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/calsify
>>
>
> _______________________________________________
> calsify mailing [e-mail]://www.ietf.org/mailman/listinfo/calsify
>
> --
> Ken Murchison
> Cyrus Development Team
> Fastmail US LLC
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>