OASIS Emergency Management TC

 View Only

Re: [emergency] Re: [emergency-comment] PPW letter re CAP

  • 1.  Re: [emergency] Re: [emergency-comment] PPW letter re CAP

    Posted 10-09-2003 16:55
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    emergency message

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


    Subject: Re: [emergency] Re: [emergency-comment] PPW letter re CAP


    At 8:03 AM -0700 10/9/03, Rex Brooks wrote:
    >Before Mr. Fulgate's letter on behalf of PPW, I had not heard a 
    >specific suggestion on how to deal with this issue.
    
    There was a specific proposal tabled at the "mini-f2f" in Stafford VA 
    in July.  That you weren't aware of it suggests that we probably 
    should have opened that discussion to the whole membership... but the 
    resistance I ran into at the meeting was so immediate and so vehement 
    that I'll confess I was a bit intimidated.
    
    The specific proposal, for the record, was that within the <resource> 
    block we include an optional <data> element which could hold a 
    Base-64 encoding of a binary asset, as an alternative to referencing 
    it in the <uri> element.  (This was actually the chief use-case for 
    adding the <mime> element to the <resource> block.)  It was suggested 
    that this element could be defined as deprecated except for use over 
    one-way data links of sufficient capacity, and with a warning that 
    receivers not designed for use over such links might not support this 
    option.
    
    >I also feel I should say that we are going to run smack into the 
    >ROYALTIES quagmire with the TV people,
    
    Why?  We don't need to specify the use of any proprietary format, any 
    more than we do now with the <uri> reference approach.  If a 
    particular implementer chooses to use such a format, then that 
    implementer has a royalties concern, as with our current <uri> 
    arrangement and as anywhere else.  But there are royalty-free formats 
    available for images and audio, so royalties issues would be 
    avoidable unless the implementer chooses to take them on.
    
    >Maybe the imminence of having a standard that does not address their 
    >needs will stimulate them to do something tangible about it.
    
    Not sure what else you'd like them to do, tangibly... they've written 
    us letters and PPW has instructed me to pursue this issue.  They've 
    offered to do implementations if we'll just give them a spec.  What 
    I'm afraid of is that we'll force them to take the tangible step of 
    abandoning CAP and setting up their own standard in some other venue.
    
    >The TV folks, not PPW, have to be responsible for their own bailiwick.
    
    If I understand you correctly you seem to be saying that you'd rather 
    see the TV folks create their own standard.
    
    That's an admissible argument, albeit one I don't personally 
    subscribe to.  The problems with that include: a) there'd be no 
    guarantee that their data set would align with ours, in which case 
    we'd have created an interoperabiltiy problem instead of solving one; 
    and b) given the enormous market power of TV in our society, there's 
    a very real possibility that their standard would overrun ours, in 
    which case all our hard work here would have been for naught.
    
    (We already have a small instance of that in Thompson/RCA's adoption 
    of the elderly SAME coding for their alerting TV sets.  Even the 
    Thompson folks agree that it's not a very good format, but they like 
    the liaibility shield of getting all their messages from the National 
    Weather Service so they took what was on offer.)
    
    After all, nobody's required to use OASIS standards in preference to 
    alternatives.  Uptake will depend on timeliness and usability 
    initially, and network "tipping"  based on market share shortly 
    thereafter.
    
    - Art
    


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