[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] FW: International Alerting - IETF
Kon Wilms wrote: > At a first glance this RFC appears to be full of holes It is not an RFC. It is an Internet Draft... As I understand it, the authors are quite interested in and willing to take input and incorporate it when offered. For instance, on seeing a pre-publication draft I suggested that they include a reference to CAP and they did even though they hadn't been aware of it before. They have made it clear that they expect to issue updates to this ID over time and I expect, given the excellent, long and widely respected history of the two authors that their final work product will be well worth having. I believe that it can only help the "Alerting community" if the "IETF community" becomes more involved in the process of ensuring that solid thought and design resources are focused on the technical issues in this space. We should encourage these efforts and offer to seek opportunities for synergy with them. bob wyman -----Original Message----- From: Kon Wilms [mailto:kon@datacast.biz] Sent: Friday, January 28, 2005 12:18 PM To: Sukumar Dwarkanath Cc: emergency@lists.oasis-open.org; brc@zurich.ibm.com; fred@cisco.com Subject: Re: [emergency] FW: International Alerting - IETF At a first glance this RFC appears to be full of holes, appearing to simply take free-form style alert messages and transport them over web, email and phone. Some notes: - The suggested HTTP polling mechanism for alert discovery is both inefficient and the wrong model. An event/push based protocol and transport is the desired model. Simply because a given transport is widely used does not make it suitable for a given task. I would say this style of delivery is suitable for a lowest-common-denominator approach. - The sample warning message is not machine parsable. With the indented paragraphs and varied usage of : and - to identify parameters, parsing would be an arduous task indeed. - The coordinate system lacks any depth and is badly formatted (a 3-character tab, or 3 spaces?) - For email delivery, who will hold the ball for responsibility in the SMTP server chain from source to destination if the message fails? Wrong network distribution model once again. - I see about 100 uses of the word 'might', which worries me. - The broadcast facts are incorrect, e.g. many STBs do not turn off when you press the power button. The mechanisms described apply mainly to NTSC broadcast encoding and not digital television services. - There is no mention of SMS formatting, flash SMS, or MMS. The two packet lengths given are not definitive - some systems have a maxlength of 32, some 140, 70, 160, etc. - There is no mention of how to accomplish delivery in an end-to-end model. No e2e model is defined in the spec, minus a list of a few transports, protocols and how one 'might' tie them together. - RFCs are taken very seriously in many circles. Therefore they should convey all the technical facts correctly and surely not make any guestimates. Sorry to be so blunt, but this doesn't exactly aid adoption of 'already specced and used in the real world' technologies ala CAP and friends (even though yes it does mention CAP). My suggestion would be that the RFC be modified to drop the messaging structure recommendations and instead focus on delivery models for existing message structures in a technical e2e framework approach. Cheers Kon On Fri, 2005-01-28 at 09:38 -0500, Sukumar Dwarkanath wrote: > I came across this yesterday, and thought I will bring it to the TC?s > attention. > > > > Sukumar > > > > > > ========================================================= > > > > 2. >From the Membership Director - David McAuley > > > > In addition, ISOC?s Chairman, Fred Baker, and former Chairman, Brian > Carpenter, have created an Internet Draft within the IETF process to > propose a way in which people could be warned of an impending event in > a geographic region. This is similar to and may use services such as > the US Emergency Alert System, but differs in that message > distribution is targeted only to the affected locality. A URL for this > Internet-Draft > > is: > > <http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro up.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]