OASIS Emergency Management TC

 View Only

Re: [emergency] FW: International Alerting - IETF

  • 1.  Re: [emergency] FW: International Alerting - IETF

    Posted 01-28-2005 17:18
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    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
    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>
    
    
    


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