- Ietf-types - alvestrand.no

Transport Area requests Media Type review for application/poc-settings+xml
by Allison Mankin 06 Aug '05

06 Aug '05

The Transport Area requests a Media Type review for the proposed new media type application/poc-settings+xml, intended for the standards tree, and specified in http://www.ietf.org/internet-drafts/draft-garcia-sipping-poc-isb-am-03.txt The document has completed an RFC 3427 review by the SIPPING WG. Please provide any comments before August 22. Thanks, Allison

1 0

application/xhtml-voice+xml vs. application/xhtml-vocie+xml
by Bruce Lilly 03 Aug '05

03 Aug '05

draft-mccobb-xplusv-media-type-04 provides a registration template for type application/xhtml-voice+xml. The IANA registry now has an entry for application/xhtml-vocie+xml (i and c transposed in voice). Can this be fixed, please. Hopefully, nobody else has noticed the ...vocie... type and it can be safely elided...

8 14

Re: Registration of media type application/xhtml-voice+xml
by Martin Duerst 20 Jul '05

20 Jul '05

At 01:33 05/07/14, Gerald McCobb wrote: >I asked the IESG to postpone the publication of the >application/xhtml-voice+xml media type as an informational RFC. The >registration is not correct. It should be application/xhtml+voice+xml. >The application/xhtml+voice+xml media type was the original submission. > >There is an issue with the original submission: > >One of the reviewers pointed out that "a certain class of error could be >avoided by renaming this application/xhtml-plus-voice+xml... I don't know >of any other "+xml" [see RFC3023] media types that have a "+" in the >name... a poorly-constructed regexp looking for +xml along the lines of >/\+(.*)$/ would miss this one." I agree with that reviewer that the type should not contain '+' characters except before 'xml'. All other subtypes have used '-' as a separator. The '+' separator was specifically introduced to express the fact that the '+xml' part is something more than a simple subtype. Although there is probably nothing in RFC 3023 explicitly disallowing the use of '+' for "arbitrary use", I think that the whole rationale for '+xml' in Appendix A of RFC 3023 (in particular http://www.ietf.org/rfc/rfc3023.txt, A.12) seem to indicate that it shouldn't be done. >I believe this argument is not strong enough to prevent approval of the >application/xhtml+voice+xml media type: >2. The argument for having "+" in the subtype is unconvincing, given that >the simplest method to determine if something is XML is also the safest, >that is, if the last four characters are "+xml" or "/xml" then the >document is XML, otherwise it is not. If that has to be done with regexps, >instead of just examining the last four bytes, that would be /[/+]xml$/. >If type and subtype were split already it would be /\+?xml$/ for the subtype. I think the regexp example is only the tip of the iceberg. Not using the plus will allow better future extensibility. Regards, Martin.

3 2

ConfirmSystem: iana@icann.org [[15e0cfeddcc0a7fe]]
by iana＠iana.org 12 Jul '05

12 Jul '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=15e0cfeddcc0a7fe&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: "application/xhtml-voice+xml vs. application/xhtml-vocie+xml" and it arrived at IANA approximately at Tue Jul 12 13:08:25 2005. --------------------------------------------------------------- ConfirmSystem: iana(a)icann.org [[15e0cfeddcc0a7fe]] 1

1 0

New internet-Drafts for an extensible Inernet Message Format
by Bruce Lilly 12 Jul '05

12 Jul '05

Four related new drafts have been submitted discussing an extensible Internet Message Format to address a number of existing issues: o clutter in the header of the current (2822) format as received, which has led to implementations suppressing important content as well as clutter o ability to protect (sign and/or encrypt) the end-to-end content including the originator-supplied header fields o extensibility for further internationalization of content and/or for experimentation with new message formats o ability to reliably detect multiple list expansions, including the order of list expansions o avoiding a problem with current message/partial fragmentation and reassembly whereby the originator's Date field is altered and/or the partial message header Date fields do not accurately convey the RFC 2822-specified semantics all while maintaining backward compatibility and reliability. The drafts are draft-lilly-extensible-internet-message-format-p01-00 and -p02-00, -p03-00, and -p04-00. It is expected that there may be additional related parts (repositories for UAs, MSAs, filters, message stores, etc. to record non-originator content). -p02 is intended for Standards Track, which is not clearly indicated due to a typo; the others indicate their respective intended status in the page one heading per ID-Checklist suggestions. -p01 and -p04 contain MIME media type registration templates and -p03 contains some registration guidelines for related media type registrations. -p01 is an introduction. All four drafts are in a very early stage of development, rushed somewhat to meet the pre-IETF publication deadline. General discussion should probably take place on the ietf-822 list (where replies are suggested by the Reply-To field of this message), whereas media registration specific discussions should probably take place on the ietf-types list. The author of the drafts reads both lists, so cross-posting to both lists should be reserved for issues likely to be of interest to both lists. The author is expected to be incommunicado from tomorrow through July 19, so don't expect immediate responses.

1 1

Re: Old application/atom+xml issues
by Bill de hÓra 11 Jul '05

11 Jul '05

Robert Sayre wrote: > I worry that any statement like Bill's suggested text will confer > legitimacy on Atom 0.3 as long as the RFC is available. *Every* > current implementor is aware of the issue, so the short term benefit > of such text is pretty much nil. Long term, the text will actually be > harmful. +1 to this sentiment - I take it this means we're saying no to the interop text in the spec?

1 0

Re: Old application/atom+xml issues
by Sam Ruby 11 Jul '05

11 Jul '05

Robert Sayre wrote: > > So, -1 to mentioning Atom 0.3 at all. I agree with Robert. Note how Atom 0.2 isn't a problem at all... we can (and will) do the same thing with Atom 0.3. - Sam Ruby

1 0

Re: Old application/atom+xml issues
by Mark Baker 11 Jul '05

11 Jul '05

On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote: > The most we can do is to say that such things are invalid, and to work > with the producers to correct this. Sounds good to me. > The majority of the existing atom 0.3 feeds are produced by a relatively > few producers. I am confident that these producers will convert over > quickly. > > I am also committed to getting the word out quickly that atom 0.3 feeds > are not to be considered valid. In particular, I plan to update the > feedvalidator to note this as a problem (first as a warning, and later I > will change this to an error). Nice. Thanks for your vigilance, Sam. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

3 2

Re: Old application/atom+xml issues
by Mark Baker 11 Jul '05

11 Jul '05

On Tue, Jul 05, 2005 at 10:33:00AM -0400, Robert Sayre wrote: > On 7/5/05, Mark Baker <distobj(a)acm.org> wrote: > > > > I wanted to point out that comments I've made on the > > application/atom+xml media type registration template have not yet been > > incorporated into the syntax draft, nor have I received any feedback > > about why they needn't be. > > See comments from Tim here: > http://www.imc.org/atom-syntax/mail-archive/msg14423.html > > Sorry you didn't get direct feedback. :/ Ah, I should have thought to check the archives, thanks. It should have gone to ietf-types though, since that's where public review of media type registrations happen and where my comments were sent. I've CCd ietf-types on this message. Tim writes; > He's got a point on the namespace being mentioned, which creates some > semi-circular dependencies, sigh. As to whether it's currently in use, > largely due to lobbying from us, recent releases of both Apache and > IIS tie the application/atom+xml media type to the .atom extension, so > if people are creating 0.3 files and calling them whatever.atom, this > could be right. Having said that, I think we should push back. Because > any such current usage is unlicensed by any spec, & because we plan to > aggressively deprecate Atom 0.3 once we get 1.0 out and since I > suspect that 90% of 0.3 feeds come from one place we should have some > success. IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the "interoperability considerations" section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. As for the magic number, to keep it simple I'd suggest that none be defined by removing the "magic number" section. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com

3 2

Transport Area requests Media Type review for MPEG4 registration draft
by Allison Mankin 05 Jul '05

05 Jul '05

The Transport Area requests a Media Type review for for the registrations draft-lim-mpeg4-mime-03.txt, intended for the standards tree. The draft is submitted for Proposed Standard. Please provide any comments as soon as possible, and before July 20, 2005. Thanks, Allison Transport Area Director

1 0