My suggestion would be to send iCal attachments via email, this is already a well established conduit for receiving these sorts of notices and many mail clients can parse iCal natively. I fear many organizations can subscribe to an CalDAV end point, even if that's the proper way to 'subscribe' for notices in a pull vs. push model.
Do you have a draft to share of the common fields? --Matt On Tue, Mar 17, 2015 at 1:50 PM, Erik Klavon <[email protected]> wrote: > Hi Matt and Chris, > > Our focus so far has been on identifying common fields. Maintenance impact > is a common field we've identified. > > vCal/iCal/CalDAV are good suggestions. We'll look into these standards > when we take up the format question. If you know anyone who is has > experience with these protocols and might be interested in helping out > please send them my way. > > Thanks, > > Erik > > On Tue, Mar 17, 2015 at 1:36 PM, Chris Woodfield <[email protected]> > wrote: > >> Was about to chime in with a similar thought myself. Do we have to >> re-invent the wheel here WRT protocol? Can the “machine-parsable template” >> simply be CalDAV, with some standard logic around mapping calendar “Guests” >> to various services/circuits a customer may have with a vendor? >> >> -C >> >> On Mar 17, 2015, at 1:31 PM, Matt Peterson <[email protected]> wrote: >> >> This seems like a great idea, were you thinking of using vCal/iCal >> <https://en.wikipedia.org/wiki/ICalendar> and/or another format for >> sharing or describing these events? It would also be useful to have some >> attributes such as "you may be impacted by this work" vs "you will be >> impacted". >> >> --Matt >> >> On Tue, Mar 17, 2015 at 12:40 PM, Erik Klavon <[email protected]> >> wrote: >> >>> Greetings >>> >>> We all generate and consume communications on maintenance activities. >>> I’ve put in my time manually processing these communications, converting >>> time zones, adding entries to calendars, opening tickets, and – as with any >>> manual process – introducing the occasional error along the way. Much of >>> the time these notifications are carried in an email, the format of which >>> varies from sender to sender. I’d love to have some conventions for the >>> formatting of the information in these emails. Such conventions would make >>> it simple to create tools that eliminate the more boring and error prone >>> aspects of processing these emails. >>> >>> I’m shepherding a BCOP effort to identify common forms of notification, >>> their common content, and propose machine parsable templates for >>> notifications. Operators may include completed instances of these templates >>> in their notifications to aid in their digestion. Thanks to the work of >>> Randy Neals, who first championed this idea, we have a couple subject >>> matter experts from the community who have signed on to this effort. We’re >>> looking for additional people to get involved, especially people with >>> programming experience. Reach out to me if you’re interested. >>> >>> Erik >>> >>> >>> _______________________________________________ >>> BCOP mailing list >>> [email protected] >>> http://mailman.nanog.org/mailman/listinfo/bcop >>> >>> >> _______________________________________________ >> BCOP mailing list >> [email protected] >> http://mailman.nanog.org/mailman/listinfo/bcop >> >> >> >
_______________________________________________ BCOP mailing list [email protected] http://mailman.nanog.org/mailman/listinfo/bcop
