Hi Matt, What we have so far is in this document:
https://cloud.box.com/s/rz2kimfnd8bhihrrjwah0wuwykmwfcls Erik On Tue, Mar 17, 2015 at 1:54 PM, Matt Peterson <[email protected]> wrote: > 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
