MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [emergency] Public as responders: Royalties
Thanks, Carl,
The Mime Type or SOAP with attachments routes are what I would
propose after a discussion of the issue as presented by PPW first. So
I agree with you wholeheartedly, and I think that what we should
consider is still to move forward and go into public review, which is
a process that carries enough weight that, given adequate
notification, the TV people can get their needs addressed on the
basis that is best for all concerned.
Ciao,
Rex
At 10:33 AM -0600 10/9/03, Carl Reed wrote:
>On the issue of royalties . . . in a way this emerging discussion sounds
>very similar to discussions that occurred for a period of time in the IETF
>GeoPRIV Working Group. This group is concerned with privacy and location
>information in the mobile world. For a period of time they gnashed their
>teeth on trying to address all the possible implications of the various
>privacy laws around the world and thought perhaps that they could define
>some level of privacy policy. While this provided them a level of
>understanding regarding requirements for privacy and location it got them no
>closer to a specification solution. So they decided to step back one level
>of abstraction and have now defined a draft specification for encoding
>privacy rules as part of a payload (could be DHCP) in the Internet world.
>What this means is that they removed themselves from the legal and policy
>issues surrounding privacy and moved into an environment in which the
>application worries about all of this and is responsible for defining the
>privacy rules. In this way, the spec does not concern itself with a nations
>or organizations specific privacy policies.
>
>Also, in the OGC we have a similar situation. Many producers of geospatial
>information require pay for use. So how can we provide seamless access in an
>interoperable world of geospatial information sharing - such as in an
>emergency response situation? There are definitely royalty, copyright,
>legal, and payment issues. On thing we discovered is that we do not try to
>solve the royalty/copyright issue at the data access interface or payload
>level. This is silliness. Perhaps more importantly what we discovered is
>that not only do we have technical interoperability issues but also
>institutional and political interoperability issues. These two latter
>interoperability issues are related to but are independent of the actual
>interface specification or payload specification standard. The institutional
>and political issues of data sharing need to be ironed out by the
>constituents BEFORE an Emergency event occurs. In effect, the constituents
>need to have some level of "contract" that enables full and complete sharing
>of public, private, for fee, or free spatial data.
>
>So, I might suggest that 1.) the CAP interface/payload specification needs
>slots (MIME?) to accommodate the ability to reference something like an
>MPEG-4 but 2.) the actual requirements for dealing with royalty and
>copyright and for fee should be handled at the application level and is
>therefore 3.) not at the CAP spec level.
>
>Sorry for the long missive - I am usually short and blunt :-)
>
>Carl
>
>----- Original Message -----
>From: "Rex Brooks" <rexb@starbourne.com>
>To: "Bullard, Claude L (Len)" <clbullar@ingr.com>; "'Poindexter, Gary W
>(BearingPoint)'" <gpoindexter@bearingpoint.net>;
><emergency@lists.oasis-open.org>
>Sent: Thursday, October 09, 2003 9:48 AM
>Subject: RE: [emergency] Public as responders (was RE: [emergency]...PPW l
>etter re CAP)
>
>
>> I have been so wrapped up in the Broadcast Media discussion that I
>> almost missed this. I hope that this is the sort of concern we can
>> take up in the public comment period after we release CAP but now it
>> seems moot until that issue gets some kind of resolution since we
> > might not vote to release CAP, even though we had agreed to a
>> Committee Specification status back before the demonstration at the
>> Global Homeland Security Conference last month.
>>
>> This particular concern strikes me as something that should be added
>> to the list of items for consideration in v1.1 of CAP, if that is
>> even the correct place for it. I am beginning to think that Broadcast
>> Media ought to take compatibility with CAP as a priority
>> consideration for requirement in its own standard because I don't
>> think that any public service use of Broadcast Assets can be
>> separated from the quagmire of patents and royalties and when you add
>> liability considerations by even thinking about conferring official
>> Emergency Management Asset status on members of the public it just
>> grows more thorns.
>>
>> And, if we really need to focus on obtaining RFP-Requirement status
>> in governmental solicitations dealing with life and death issues,
>> then it really might be best to duck this whole area in favor of
>> fielding a standard that can stand up to large liability concerns.
>>
>> Ciao,
>> Rex
>>
>> At 9:04 AM -0500 10/9/03, Bullard, Claude L (Len) wrote:
>> >Right. This thread confuses me because it seems to indicate
>> >that civilian responders might be providing information directly
>> >to the public broadcast media and while that can happen, it is
>> >not typically part of emergency response asset management although,
>> >as in the case of citizens band and other weather disaster monitoring,
>> >it can be part of the warning and tracking reporting to the news
>> >outlets. I'd be somewhat wary of an official sounding alert message
>> >that goes directly from the public to the public through the broadcast
>> >media. That isn't what is being suggested is it?
>> >
>> >len
>> >
>> >
>> >From: Poindexter, Gary W (BearingPoint)
>> >
>> >Identifying assets and their
>> >attributes is essential. Identifying a path or multiple paths to/from an
>> >asset is essential. How an asset is used in an emergency situation is not
>a
>> >standards issue.
>> >
>> >To unsubscribe from this mailing list (and be removed from the
>> >roster of the OASIS TC), go to
>>
>>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgr
>oup.php.
>>
>>
>> --
>> Rex Brooks
>> GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>> W3Address: http://www.starbourne.com
>> Email: rexb@starbourne.com
>> Tel: 510-849-2309
>> Fax: By Request
>>
>> To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.
>>
--
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]