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