Request for MIME media type Application/Vendor Tree - vnd.3gp p.sm s-tl

[Biot Olivier]

Hello Ned,

Thanks for the review remarks! See comments in-line.

|-----Original Message-----
|From: Ned Freed
|
|
|A couple of points in addition to the ones Larry already made...
|
|> [NOTE: this is the registration email as returned to me on 
|the 14th of July
|> from the IANA registration perl script]
|
|> Name : Olivier Biot
|
|> Email : olivier.biot at siemens.com
|
|> MIME media type name : Application
|
|> MIME subtype name : Vendor Tree - vnd.3gpp.sms-tl
|
|> Required parameters : none
|
|> Optional parameters :
|> none
|
|> Encoding considerations : binary
|> This media type may require encoding on transports not 
|> capable of handling binary.
|
|> Security considerations :
|> The Short Messaging Service Transfer Layer (SMS-TL) format 
|> may contain
|> executable code and user confidential information.
|
|There's also the issue of data integrity. Would someone 
|tweaking this stuff
|in transit be able to cause any problems? I assume the answer 
|is "yes" since executable code can be involved.

This is correct. Changing bits of bytes within the data do compromise the
message. I thought data integrity was beyond the scope of registering a MIME
media type, but I'll now add a note.

|There's also the issue of what, if anything, is done to prevent
|tampering or leakage. Is there a preferred mechanism for adding
|integrity/confidentiality services on top of this media type? Or does
|the type itself include facilities for this?

Normally the GSM SMS-TL traffic runs in a protected environment (carrier
network), where confidentiality is a key element. Hence I did not really
look at this aspect. Secure MIME, TLS, and signing are obvious means for
providing (relatively) tamper-proof solutions.

I will issue a new assignment proposal with the comments I received so far.

Many thanks for taking the time to review!

Best regards,

Olivier