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: IETF work related to work of this TC

Dear TC members,


Is this TC meeting in Brussels?


Best regards,


Brett Trusko


From: Kon Wilms [mailto:kon.wilms@ndsamericas.com]
Sent: Wednesday, August 04, 2004 2:09 PM
To: 'emergency TC lists Oasis'
Subject: RE: [emergency] RE: IETF work related to work of this TC


Relating to IF –


We had the same type of transport wrapper and descriptor issue for the ATSC data broadcast standard. In the end the solution was to build it on subset building blocks. It may be worth a look to read these documents in the context of what concepts they themselves are re-using (S/MIME, SAP, etc.). A solution for creating a wrapper came from taking the smaller building blocks and creating a spec for transport over that.


Relating to geolocation and directing of EM messages to recipients –


In the broadcast world settopboxes and devices are addressed as ‘targets’. Each has a unique identifier and is aware of its location (via zipcode typically). Secure addressing of these devices is usually done by a keystream comprising of wrapping a symmetric key (or set of) within a PK encrypted packet with the target ID affixed. The target ID is directly associated with the PK at the transmission end. The receiver filters on its target ID, decrypts the packets, and uses the symmetric key to decrypt a secondary stream which carries the ‘real’ information (i.e. the CAP messages). Although there is a standard spec for transport, everyone does encryption differently (albeit everyone may use the same encryption standards (AES192, etc.).


I’m noting this because it should be kept in mind when looking at specifications for transmitting data over the internet, as some interface will be needed between the internet world and broadcast world, and when people start using specs that say ‘MUST use S/MIME’ which may not map to the broadcast realm, we start limiting the usability of the message because of restrictions brought about in the transport layer.


The transport SC also needs to possibly add to the list of requirements that interfacing be defined or guidelines given as to the hand-off of secure and targeted data between different flavors of delivery networks, and what the minimum requirements are for maintaining security and integrity of the data at the handoff, on the platform performing the translation, and at the retransmission of the data from said platform onto the next network segment.





-----Original Message-----
From: Carl Reed [mailto:creed@opengis.org]
Sent: Wednesday, August 04, 2004 9:16 AM
To: emergency TC lists Oasis
Subject: [emergency] RE: IETF work related to work of this TC


Yesterday during the GIS SC teleconference I mentioned that there are a number of IETF RFCs that could have an impact/synergy with the work of this TC. The majority of the work by the IETF membership WRT location has to do with either delivery of services in an EM siutation or 2.) protection of privacy and privacy encoding rules for location payloads on the internet.


I am enclosing information on a number of recent RFC submissions/updates.




Information contained in this email message is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster@nds.com and destroy the original message.

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