May 2004 - Ietf-types - alvestrand.no

For review: draft-ietf-xmpp-e2e-07
by Peter Saint-Andre 27 May '04

27 May '04

draft-ietf-xmpp-e2e-07 contains a content-type registration for "application/xmpp+xml", to be used by instant messaging and presence systems that conform to the Extensible Messaging and Presence Protcol (XMPP). The relevant text is section 9.1 of this I-D: http://www.ietf.org/internet-drafts/draft-ietf-xmpp-e2e-07.txt Feedback on this registration would be appreciated before this I-D is sent to the IESG for consideration (it has already been pointed out that the registrant should be the IESG, not the WG). Peter

2 2

Re: Thanks :)
by Parks 27 May '04

27 May '04

1 0

Re: Hello
by Parks 26 May '04

26 May '04

1 0

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