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

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

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>

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to

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