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

[Michael Douglass <[e-mail]>]

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).
>
>
> 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] 
> <mailto:[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 <http://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]
>>     <mailto:[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] <mailto:[e-mail]>
>>         714-989-6135
>>
>>         _______________________________________________
>>         calsify mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/calsify
>>
>>
>>     _______________________________________________
>>     calsify mailing list
>>     [e-mail]  <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/calsify
>
>     -- 
>     Ken Murchison
>     Cyrus Development Team
>     Fastmail US LLC
>
>     _______________________________________________
>     calsify mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify