- Ietf-types - alvestrand.no

Secured eMail vendor tree, registration for vnd.sema
by Rami Avidan 21 May '04

21 May '04

Dear all We have repeatedly sent in registration application mails with now response about the future needs and wants to achieve the vnd.sema registration. Please advice what steps We need to take to reach the desired outcome Many thanks Warm regards Rami Avidan Chief Operating Officer Chief Security Officer Secured eMail AB Off: +46 319 11 277 Fax: +46 319 11 340 Mob: +46 733157607 eMail: rami.avidan(a)securedemail.se Url: HYPERLINK "http://www.securedemail.se"www.securedemail.se Kungsporten 4e 427 50 Billdal Sweden Secured eMail is an encryption program created to secure email communication. It uses the most advanced standard of encryption, AES, together with the unique, patented System SKG method that generates code keys to lock the mail. Secured eMail enables electronic messaging to be a secured means of communication for large corporations, small organisations and the personal email user. For channel enquiries contact HYPERLINK "mailto:channel@securedemail.se"channel(a)securedemail.se. I M P O R T A N T N O T I C E This email and any attachments to it contain information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and is unlawful. If you have received this email in error please return it to the sender and delete the email from your records or call above phone number. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.678 / Virus Database: 440 - Release Date: 2004-05-06

3 2

[Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
by Eric A. Hall 20 May '04

20 May '04

As per RFC2048, I'm planning to propose an application/mbox media-type. The impetus for this is as follows: 1. Background and Overview UNIX and look-alike operating systems have historically made extensive use of "MBOX" mailbox files for a variety of messaging purposes. In the common case, these files are used to hold collections of electronic mail messages which users manipulate as "folders" of a private mail-store. These files are also frequently used by a variety of back-end email services, including delivery servers, filtering systems, and mailing-list programs. Over the last few years, the use of these files has also spread to other operating systems, with a variety of messaging tools on numerous platforms now providing direct access to MBOX files. The increased pervasiveness of these files has led to an increased demand for improvements in cross-system, network-wide interchange of these files. In turn, this requirement also dictates a need for a media-type definition for MBOX files in general. For example, some applications allow users to open MBOX files as discrete data-objects, but use platform- or product-specific mapping techniques to identify these files. Similarly, many mailing list archive programs provide access to MBOX files for historical messages, but will publish these files as text/plain or some other generic media-type, but which causes problematic end- of-line conversions when these files are transferred across a network, or which does not provide for local actions that should be performed against the data (such as prompting the user to import the mailbox data into a local mail-store). The definition of a standard media-type for these files would facilitate a more consistent behavior for these types of actions, and would further the cause of interoperability. Note that this specification does not define the MBOX data file as an authoritative Internet data-type or structure. Instead, it merely seeks to define a standard media-type definition for these files, so that their transfer may be more consistent. According to my reading of 2048 this should be pretty straightforward, although the lack of a clear authoritative spec may be problematic. Please review and advise. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

5 19

***UNCHECKED*** [spam] Hidden message
by Parks 06 May '04

06 May '04

1 0

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
by Chris Lilley 03 May '04

03 May '04

On Tuesday, May 4, 2004, 1:17:35 AM, Steve wrote: SD> I think mbox format that uses binary content-types is probably less SD> interoperable than one that uses text only. That amounts to an assertion that eol conversions and on-the-fly encoding conversion generally do more good than harm. It may be true, but it may not be. Tests using an mbox that contains messages in a variety of encodings (including some multibyte and code shifting encodings) would be needed to determin interoperability in practice. If conversion to a local eol convention is considered desirable, I would rather this was done by the mbox content type handler rather than bringing along the rest of the text/* baggage. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group

2 1

Re: [Fwd: I-D ACTION:draft-hall-mime-app-mbox-00.txt]
by Chris Lilley 03 May '04

03 May '04

On Monday, May 3, 2004, 11:12:15 PM, Steve wrote: SD> At 3:58 PM -0500 5/3/04, Eric A. Hall wrote: >>As per RFC2048, I'm planning to propose an application/mbox media-type. SD> Hmmmmm. We already have a type for a collection of messages SD> (multipart/digest). Absent argument to the contrary, I'd rather SD> encourage the use of that than to register one particular local form. Does mbox format follow the syntactic constraints of a digest? SD> I'm also a little concerned about the EOL issue you allude to. I SD> assume you mean to register these as LF delimitted, which will make SD> them binary files, and perhaps more problematic for many users to SD> deal with. I think it just means that they transfer intact. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group

1 0

For review: draft-baker-soap-media-reg-05
by Mark Nottingham 02 May '04

02 May '04

The only substantive change in this draft is the restriction of the content to XML 1.0 (i.e., XML 1.1 SOAP envelopes cannot be identified by this media type). http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-05.txt -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems

2 2

***UNCHECKED*** [spam] Re: Msg reply
by Parks 30 Apr '04

30 Apr '04

1 0

***UNCHECKED*** [spam] Re: Thank you!
by Parks 29 Apr '04

29 Apr '04

1 0

RE: DC Format for Quicktime Virtual Reality and Movies
by Misha Wolf 14 Apr '04

14 Apr '04

Greg, I may be completely misunderstanding you, but here goes ... The MIME media types are maintained by IANA at: http://www.iana.org/assignments/media-types/ I can see video/quicktime, but not the others you mention. Regards, Misha -----Original Message----- From: General DCMI discussion list [mailto:DC-GENERAL@JISCMAIL.AC.UK] On Behalf Of Greg Nehler Sent: 14 April 2004 18:22 To: DC-GENERAL(a)JISCMAIL.AC.UK Subject: DC Format for Quicktime Virtual Reality and Movies A couple of weeks ago I sent a query concerning stereolithography files (for 3-D printing). So far I've gotten no feedback. I hope someone is on the case, though. Anyway, since then I've come to realize that I should have asked the same question about Quicktime Virtual Reality and Quicktime Movies. I may be wrong, but it doesn't seem that the MIME list contains any term(s) that could be used for either of these new technologies. Does anyone know if any term is being proposed for QTVR or QTM, or if there is none, what term could be reasonably proposed for one or the other? The same still goes for stereolithography files, of course. Finally, is any maintenance of the MIME list being considered? Thanks, Greg Nehler CTS Metadata Services 107E Olin Library Cornell University Ithaca, NY 14853 Phone: (607) 255-5757 Email: gln1(a)cornell.edu ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

***UNCHECKED*** [spam] E-mail account security warning.
by noreply＠iana.org 05 Apr '04

05 Apr '04

Dear user of e-mail server "Iana.org", We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For more information see the attached file. For security reasons attached file is password protected. The password is "25036". Have a good day, The Iana.org team http://www.iana.org

1 0