OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.


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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]