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]