- Ietf-types - alvestrand.no

Registration of MIME media type application/vnd.broadshow.streampoint.producer
by Lee Atkinson 17 Dec '01

17 Dec '01

MIME media type name: Application MIME subtype name: vnd.broadshow.streampoint.producer Required parameters: none (Version number is stored within file) Optional parameters: none Encoding considerations: file format follows XML conventions Security considerations: files are transmitted via secure channels (either SSL or VPN) only. Does not contain any personal or sensitive data. Interoperability considerations: Published specification: The specifications for this content-type are proprietary. They are specified by Broadshow Ltd. The registration of this content-type is intended only to provide a convention for labelling this proprietary data type within the MIME/HTTP environment and does not specify any details about the content format or semantics, except to refer to the software and specifications provided by Broadshow Ltd. Applications which use this media type: Broadshow Streampoint Producer Additional information: Magic number(s): File extension(s): .bsproducer Macintosh File Type Code(s): Person & email address to contact for further information: Lee Atkinson, lee.atkinson(a)broadshow.com Intended usage: LIMITED USE Author/Change controller: Lee Atkinson, lee.atkinson(a)broadshow.com

1 0

Re: Request for MIME media type Image/Vendor Tree - vnd.
by Leon Bottou 17 Dec '01

17 Dec '01

Errata regarding the registration form for MIME type image/vnd.djvu, submitted via the online form at <http://www.iana.org/cgi-bin/mediatypes.pl>. * The MIME subtype name was spelled "vnd.vnd.djvu" and should read "vnd.djvu". * The magic number section was missing. Please find attached my corrected application. - Leon Bottou <leonb(a)research.att.com>

1 0

Seeking co-moderator for ietf-types list
by Harald Alvestrand 22 Nov '01

22 Nov '01

For some reason, the ietf-types list is the list I maintain that gets the most spam - up to 50 messages per day. All of it (I think) gets trapped by the subscriber-only filter. It is also a list where some mail from non-subscribers MUST get through (new submissions, for instance). The combination means that moderation needs to be efficient, and fast. I am finding that with the conversion of this list to Mailman, it is reasonably efficient (2 mouse clicks per message, basically), but given that I am the only one moderating, it is not fast. With Mailman and Web-based moderation, having multiple moderators without getting confused is easy; the Web interface does the synchronization. If there is a volunteer willing to do the mouseclicks when needed, I think the IETF-types would be better served by having 2 moderators than by having only one. Volunteers please email me directly. Harald Alvestrand, IETF-types moderator

1 0

RE: Registration of MIME media type application/vnd.nokia-mrv+xml
by Leon.Hurst＠nokia.com 07 Nov '01

07 Nov '01

again, the specs don't have to be public, but the specs should exist and be referenced. we don't want to register types that aren't yet defined. LH> Yes we have mature specs. and part of the purpose of the registration is to inform implementors, and the public, about the risks of using the type. so I don't really like statements of the form "users must determine the risks for themselves" but we don't have a mechanism for denying registrations in vnd.* space. LH> I think that a comment along the lines: "the content type should be discarded by systems which do not know what to do with it. Knowledge about this content type handling can be gained from existing (but currently unpublished specifications). Please check http://nokia.nokia.com for the specs which will be released in the near future" I wish there were some effective way to compel vendors to be responsible regarding the security risks to which they expose their customers. So far, we haven't found one. LH> Bottom line: If you dont know what to do with a content type then you should discard it. Leon.

2 1

RE: Registration of MIME media type application/vnd.nokia-mrv+xml
by Leon.Hurst＠nokia.com 07 Nov '01

07 Nov '01

perhaps the registration should simply say that it is not possible to evaluate the risks with this content-type since no information about the time has been disclosed; and users should therefore avoid using this content-type unless *they* have reliable information about the nature and format of this content-type which enables them to evaluate the risks associated with using it. LH> This is a very sensible approach. I hope you understand that there are many facts which determine when vendor related specs get published. In addition there are occasions when the MIME type needs registration prior to public distribution of the specs. Do other people have comments on Keith's suggestion. Many thanks, Leon.

2 1

RE: Registration of MIME media type application/vnd.nokia-mrv+xml
by Leon.Hurst＠nokia.com 06 Nov '01

06 Nov '01

it doesn't say anything at all about what MRV document is, nor does it include a reference to the specification. as such the content type is ambiguous. LH> This is vendor specific MIME type. The spec are not ready for public consumption. the encoding considerations section is poorly worded. I'm not sure what a "a 7bit character set with an IETF character encoding mechanism" is. it would be sufficient to say that these documents need to be encoded in base64 for transmission over text-based email. LH> Agreed, will change. the security considerations section is vague. I can't tell what is meant by > Authentication: Optional part of a Digital Rights Management system in which > MRV is used. but any system which incorporates DRM is likely to have considerable security risks - including that identity of the reader will be inappropriately disclosed or leaked to other parties, or that there are circumstances under which a reader will be denied his legal rights to use the document by the DRM system (for instance, when fair use rights are violated). these risks need to be analyzed and disclosed. LH> Security models surrounding DRM are complex and endless. Security is a spectrum of threats and (less than 100% bullet proof) counter measures. Additionally each security infrastructure is highly. All the above types refer to documents which have an orthoginal security implementation. Each implementor is free to implement security levels appropriate for there application. > Threats: The MRV MIME content type definition provides for the inclusion of > arbitrary content information. Administrators for MIME implementations that > support this content type SHOULD take every standard precaution to assure > the activation of MRV content is NOT automatic, but is only performed after > confirmation by the recipient. In addition, administrators may want to > perform virus scans of MRV content information. this provides no information about how such threats may be ameliorated. furthermore, it is difficult to see how such threats could be ameliorated unless the specification for the encapsulation format were made public. 'confirmation by the recipient' is not sufficient to ameilorate such threats, because the recipient is not generally aware of the threats posed by the individual contents. LH> This is innacurrate. MRV and the other three types are non executable content. The only risk posed is the standard risk of being a host for a virus which is the same with all other document/MIME types? > Interoperability considerations: Implementations that have support for the > mandatory features of this content type will greatly increase the chances of > interoperating with other implementations supporting this content type. > Conformance to this content type requires an implementation to support every > mandatory feature. that's a meaningless statement in this context. LH> It is meaningful when the specs are published. this application should be denied or delayed until there is a published specification which may be reviewed, and until the security risks are adequately documented. LH> Do any of the answers I provide above help you? It is unlikely that the specifications will be published prior to MIME type registration. Thus, we decided to use a vendor mime type which is appropriate in this situation and does not require any approval. However, I would like to make the registration as meaningful as possible now with your help, given the constraint of an unreleased spec. Thank you for your comments and I look forward to hearing what you think. Cheers, Leon.

2 1

RE: Registration of MIME media type application/vnd.surety.tokenstore
by Greg Thompson 01 Nov '01

01 Nov '01

> -----Original Message----- > From: moore(a)cs.utk.edu [mailto:moore@cs.utk.edu] > > > Security considerations: Surety Token Store files contain no executable > > code. > > that's good to know, but it doesn't really say anything about > security risks. > is there any inherent risk to running software that uses such things? > for instance, does such software disclose information about the recipient > or the recipient's files, does it communicate with other network > sites without > the recipient's knowledge, does it alter recipient files, etc? > > especially given that you've said nothing at all about the > purpose of this type, > it's very hard to assess risk from the information provided. > > Keith fair enough. MIME media type name: application MIME subtype name: Vendor Tree - vnd.surety.tokenstore Required parameters: none Optional parameters: none Encoding considerations: Surety Token Store files contain binary data, and must be transferred in such a way as to guarantee that no loss of information takes place. Security considerations: Surety Token Store files contain "Tokens" used by the Surety Digital Notary Service. These Tokens are used in the course of conducting transactions with Surety Digital Notary Servers. No personal data is stored in a Token, and no part of a Token contains any executable code. Certain operations performed with Tokens within the context of an application developed to use these Tokens may contact servers over the Internet. These communications do not transmit any information about the user or the user's machine to the remote server, and only take place as a direct result of the user's actions. Interoperability considerations: The Surety Token Store file format is designed such that compliant files may be parsed and generated on any platform, independent of machine byte-ordering and word size. As such, they may be used with any supported product in the Surety Digital Notary Service on any supported platform. Published specification: none Applications which use this media type: Surety Digital Notary Service Additional information: Magic number(s): none File extension(s): .sts Macintosh File Type Code(s): none Person & email address to contact for further information: standards(a)surety.com Intended usage: common Author/Change controller: Written by Greg Thompson. This type may be revised by any employee of Surety, Inc.

1 0

Registration of MIME media type application/vnd.surety.tokenstore
by Greg Thompson 01 Nov '01

01 Nov '01

MIME media type name: application MIME subtype name: Vendor Tree - vnd.surety.tokenstore Required parameters: none Optional parameters: none Encoding considerations: Surety Token Store files contain binary data, and must be transferred in such a way as to guarantee that no loss of information takes place. Security considerations: Surety Token Store files contain no executable code. Interoperability considerations: The Surety Token Store file format is designed such that compliant files may be parsed and generated on any platform, independent of machine byte-ordering and word size. As such, they may be used with any supported product in the Surety Digital Notary Service on any supported platform. Published specification: none Applications which use this media type: Surety Digital Notary Service Additional information: Magic number(s): none File extension(s): .sts Macintosh File Type Code(s): none Person & email address to contact for further information: standards(a)surety.com Intended usage: common Author/Change controller: Written by Greg Thompson. This type may be revised by any employee of Surety, Inc.

2 1

RE: Registration of MIME media type application/vnd.nokia-mrv+xml
by Leon.Hurst＠nokia.com 31 Oct '01

31 Oct '01

Sorry but I have only just been registered to this list so have missed all comments except for Dan's email below. I seems that the archive for this mailing list was not working when I accessed it. Could someone please direct me to the primary archive (not a mirror), so I can see everyones comments. Many thanks, Leon. -----Original Message----- From: ext Dan Kohn [mailto:dan@dankohn.com] Sent: 31 October, 2001 10:08 To: 'Keith Moore'; owner-ietf-types(a)dokka.maxware.no; Hurst Leon (NMP/Helsinki) Cc: ietf-types(a)iana.org Subject: RE: Registration of MIME media type application/vnd.nokia-mrv+xml In addition, the registrant should (re?)read section 7.1 of RFC 3023, and strongly consider referencing that document. - dan -- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> Essays announced on <mailto:dankohn-subscribe@yahoogroups.com> -----Original Message----- From: Keith Moore [mailto:moore@CS.UTK.EDU] Sent: Tuesday, October 30, 2001 09:44 To: owner-ietf-types(a)dokka.maxware.no Cc: ietf-types(a)iana.org Subject: Re: Registration of MIME media type application/vnd.nokia-mrv+xml there are lots of problems with this proposed registration. it doesn't say anything at all about what MRV document is, nor does it include a reference to the specification. as such the content type is ambiguous. the encoding considerations section is poorly worded. I'm not sure what a "a 7bit character set with an IETF character encoding mechanism" is. it would be sufficient to say that these documents need to be encoded in base64 for transmission over text-based email. the security considerations section is vague. I can't tell what is meant by > Authentication: Optional part of a Digital Rights Management system in which > MRV is used. but any system which incorporates DRM is likely to have considerable security risks - including that identity of the reader will be inappropriately disclosed or leaked to other parties, or that there are circumstances under which a reader will be denied his legal rights to use the document by the DRM system (for instance, when fair use rights are violated). these risks need to be analyzed and disclosed. > Threats: The MRV MIME content type definition provides for the inclusion of > arbitrary content information. Administrators for MIME implementations that > support this content type SHOULD take every standard precaution to assure > the activation of MRV content is NOT automatic, but is only performed after > confirmation by the recipient. In addition, administrators may want to > perform virus scans of MRV content information. this provides no information about how such threats may be ameliorated. furthermore, it is difficult to see how such threats could be ameliorated unless the specification for the encapsulation format were made public. 'confirmation by the recipient' is not sufficient to ameilorate such threats, because the recipient is not generally aware of the threats posed by the individual contents. > Interoperability considerations: Implementations that have support for the > mandatory features of this content type will greatly increase the chances of > interoperating with other implementations supporting this content type. > Conformance to this content type requires an implementation to support every > mandatory feature. that's a meaningless statement in this context. this application should be denied or delayed until there is a published specification which may be reviewed, and until the security risks are adequately documented. Keith

1 0

Changed list server software for ietf-types list
by Harald Alvestrand 31 Oct '01

31 Oct '01

I have changed the list software for the IETF-types list from majordomo running on dokka.alvestrand.no to Mailman running on eikenes.alvestrand.no You should not notice any change until you want to unsubscribe - although you will get a note every month telling you how to unsubscribe or change your subscription. The addresses that were previously on the "allowed to post" list are now added to the list as "nomail" members - there are 2 ways of achieving this functionality in Mailman, and this is one of them. Comments sought. The main reason for the change is to get an interface that is simpler for the list administrator to use when approving non-subscriber postings and deleting the (HUGE amounts of) spam sent to the list. Thank you for your patience. Harald Alvestrand

1 0