January 2005 - Ietf-types

Seeking co-moderators(s) of the ietf-types list
by Harald Tveit Alvestrand 10 Feb '05

10 Feb '05

Hello, Bill Carpenter, who has long co-moderated the ietf-types list along with me, has asked to drop out of the role. At the same time, two events have emphasized the need for a co-moderator: - A couple of requests and comments got severely delayed in the moderator queue - I've scheduled a vacation for the month of April Together, these things clearly indicate that someone needs to be on hand to moderate the list - both when I'm here and when I'm gone. The lists run on Mailman, behind a spam filter, and with an ancillary script that deletes the more obvious spam from the queue. Still, there's spam coming through - unfortunately. Volunteers? thanks in advance! Harald

4 5

[Fwd: I-D ACTION:draft-hall-mime-app-mbox-03.txt]
by Eric A. Hall 30 Jan '05

30 Jan '05

The ADs for the applications area are going to move this into last-call again, but we all want to run it back up the flagpole one more time. This version departs from earlier releases by specifying a "format" parameter to the application/mbox media-type, by defining a "default" value for the parameter, and by defining a default mbox database format that must be supported. The use of a format parameter allows different implementations to be documented, and for them to be specified in the transfer (eg, a "SunOS" format might specify the use of content-length and other things). Unrecognized formats are to be treated as application/octet-stream. The "default" format uses a sequence of 822 messages, with the exception that line-endings are LF instead of CR/LF (this only applies to the canonical database, and doesn't affect the transfer protocol or anything else). Inheriting 822 rules means that email addresses must be qualified, encodings must be specified, etc. All implementations have to support this default format, and unspecified formats must be treated as "default" (this is mostly for the benefit of protocols like HTTP, where parameters are not always (or even usually) defined. Another thing that is specified here is that separator lines (at the least) must be encoded to prevent local collisions, when an mbox attachment is saved into an existing local folder (messages can become irreversible mingled if some kind of escaping is not performed). There's one problem in this that I caught after submission, which is that ">From" escaping is specified, but shouldn't be. ">From" escaping is not needed for transfers, and it's mostly a local matter anyway (having to do with local parsing), and it's damn near impossible to deal with all the potential exceptions (such as doubled escapes against quoted text, for example), so it's really best not to specify anything. I'll roll this change into any other comments that I get for the -04 version. Anyway, any other comments are appreciated, as usual. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/

2 2

ConfirmSystem: iana@icann.org [[60b84673d8300f72]]
by iana＠iana.org 29 Jan '05

29 Jan '05

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=60b84673d8300f72&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Delivery service mail" and it arrived at IANA approximately at Fri Jan 28 20:51:00 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[60b84673d8300f72]] 1

1 0

ConfirmSystem: iana@icann.org [[1f8c0c2f29dfa1c5]]
by iana＠iana.org 27 Jan '05

27 Jan '05

Thank you for your message. The iana(a)iana.org address collects a tremendous amount of spam, and we have been forced to implement protective measures. In order to process your message we need to confirm that it came from a real email address. To confirm your message, you can either: 1) Reply to this message, without altering the subject line The "Re: " added by many mail clients is OK, but please note that this method is *not* foolproof. or 2) Visit the URL <http://confirm.icann.org/?s=1f8c0c2f29dfa1c5&l=iana@icann.org> If you want to be very sure that your message gets through, do both steps above -- it does no harm to confirm more than once. For your reference, the subject of the message you sent was: "{Filename?} Delivery by mail" and it arrived at IANA approximately at Thu Jan 27 09:00:57 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[1f8c0c2f29dfa1c5]] 1

1 0

Media Types review for application/simple-filter+xml
by Hisham Khartabil 27 Jan '05

27 Jan '05

The SIMPLE Working Group requests a Media Type review for the following new type: - application/simple-filter+xml This is intended for the IETF tree, and specified in section 8.1 of http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format -04.txt Thanks, Hisham Khartabil SIMPLE WG Co-chair

2 3

Media Type review request for application/dialog-info+xml
by Allison Mankin 25 Jan '05

25 Jan '05

The Transport Area requests a Media Type review for the proposed new type application/dialog-info+xml, intended for the IETF tree, and specified http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialog-package-05.txt (Section 8.1). We know of the following needed changes: 1. Author/Change Controller will be modified to "SIPPING Working Group delegated from the IESG" Please provide any comments as soon as possible. Thanks, Allison

5 7

RE: MIME Type Review for KPML MIME Types
by Eric Burger 24 Jan '05

24 Jan '05

We did not, as message/* is for encapsulating user messages. KPML is an application PDU (application message). > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Thursday, January 20, 2005 5:43 PM > To: Eric Burger > Cc: ietf-types(a)iana.org > Subject: Re: MIME Type Review for KPML MIME Types > > > * Eric Burger wrote: > >KPML is in the process of WGLC in the SIPPING work group. > > > >KPML defines two new MIME types, application/kpml-request+xml and > >application/kpml-response+xml . > > > >We would greatly appreciate expert review of the definition > and usage of > >these new types. > > > >The draft lives at: > >http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-06.txt > > Did the Working Group consider using the message/* top-level type?

1 0

RE: Media Type review request for application/dialog-info+xml
by Scott Hollenbeck 24 Jan '05

24 Jan '05

Allison, I found a few small schema errors when running the schema from section 4.4 through the IBM Schema Quality Checker. They should be looked at (sorry if the diagnostic lines below get broken in strange ways): Initializing Schema Quality Checker. Please wait ... SchemaQualityChecker has been initialized PROCESSING test.xsd time : 2005-01-24T14:28:21 ... test.xsd (file 1 of 1) now being read ... ERROR file = file:test.xsd line 100 column 70 SEVERITY: 1 ERROR TYPE: 1 MESSAGE cvc-complex-type.2.4.a: Invalid content starting with element 'xs:attribute'. One of '{"http://www.w3.org/2001/XMLSchema":unique, "http://www.w3.org/2001/XMLSchema":key, "http://www.w3.org/2001/XMLSchema":keyref}' is expected. ------------------------------------------------------------------------ ERROR file = file:test.xsd line 100 column 70 SEVERITY: 1 ERROR TYPE: 1 MESSAGE cvc-complex-type.3.2.2: Attribute 'use' is not allowed to appear in element 'xs:attribute'. ------------------------------------------------------------------------ ERROR file = file:test.xsd line 85 column 41 SEVERITY: 1 ERROR TYPE: 1 MESSAGE The reference nameaddr uses the empty string as its prefix. But there is no namespace declaration which associates the empty string with a namespace. To fix the problem, you may add the attribute "xmlns" in the root element (<schema>) ------------------------------------------------------------------------ end time = 2005-01-24T14:28:24 -Scott-

1 0

Registration of MIME media type .pss
by Tony Mohr 21 Jan '05

21 Jan '05

To: ietf-types(a)iana.org Subject: Registration of MIME media type *.pss MIME media type name: Application MIME subtype name: .pss Required parameters: none Optional parameters: none Encoding considerations: ESS files are binary data and thus should be encoded for MIME mail transmission. The same guidelines that apply to application/octet-stream apply to this. Security considerations: none Interoperability considerations: none Published specification: The specifications for this content type are proprietary. They are specified by Essential Security Software, Inc. Applications which use this media type: Essential Security Software product, Essential Security Suite and Ecrypt-it. Contains encrypted information. Additional information: Magic number(s): none File extension(s): *.pss Macintosh File Type Code(s): none Person & email address to contact for further information: Tony Mohr tonym(a)essentialsecurity.com 425.454.2632 Intended usage: common (One of COMMON, LIMITED USE or OBSOLETE) Best Regards, Tony Mohr Essential Security Software Director - Business Development Desk: 425-454-2632 Cell: 425-443-6713 Email: tonym@essentialsecurity,com Web: <blocked::blocked::BLOCKED::http://www.essentialsecurity.com> www.essentialsecurity.com "Security Made Simple"

3 2

Re: [AVT] Updated 3GPP2 MIME ID: draft-garudadri-avt-3gpp2-mime-01.txt
by Harinath Garudadri 21 Jan '05

21 Jan '05

At 10:49 AM 1/16/2005, Colin Perkins wrote: >On 17 Dec 2004, at 22:19, Harinath Garudadri wrote: >> An updated version of the ID registering 3gpp2 MIME types is now >>available at >>http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime >>-01.txt. This version uses the correct template and incorporates some >>editorial changes. > >I have a few details that should be resolved: > > - Please move the paragraph defining "Conventions used in this >document" to > be part of the introduction, rather than being a separate section. >Also, > please remove section 6 and add the text as an unnumbered note in the > boilerplate at the start of the draft. Done. The latest draft can obtained from http://people.qualcomm.com/randy/draft-garudadri-avt-3gpp2-mime-02.txt if you need it before the ID appears at http://www.ietf.org/internet-drafts/draft-garudadri-avt-3gpp2-mime -02.txt > - Is there a need to register media types other than audio or video >(the > most obvious being "text/3gpp2", to allow a future timed text >format)? 3GPP2 timed text is same as 3GPP timed text. So, there is no need for other media types and we plan to use text/3gpp-tt >Otherwise this draft looks reasonable to me, although I'm not a MIME >expert. Once you've made these changes, you might consider asking for >review on the <ietf-types(a)iana.org> mailing list. I have copied <ietf-types(a)iana.org> in this thread. Is this adequate or do I need to do anything else? Thanks, hari. >Colin Dr. Hari Garudadri Qualcomm Inc. work : +1 858 651 6383 mobile : +1 858 229 2801

1 0