Re: [emergency] Public as responders: Royalties

[Rex Brooks <rexb@starbourne.com>]

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