September 2010 - Ietf-types

Re: Ietf-types Digest, Vol 88, Issue 15
by Ron Wilson 16 Sep '10

16 Sep '10

On Thu, Sep 16, 2010 at 6:00 AM, <ietf-types-request(a)alvestrand.no> wrote: > Date: Sat, 11 Sep 2010 08:42:13 -0400 > From: Nathaniel Borenstein <nsb(a)guppylake.com> > > In other words: iCal sucks but that's irrelevant. Multiple syntaxes suck, but sometimes they're necessary. If nothing else. failure to "standardize" an XML mapping will lead to many custom mappings - if for no other reason than that XML is all the rage. (At least until the next "XML" comes along. I remember when HDF was "it".)

1 0

[admin] ietf-types is moving
by Mark Baker 16 Sep '10

16 Sep '10

Hi everyone, In an effort to avoid problems inherent in manual spam filtering, we've decided to move ietf-types from Harald's server at alvestrand.no, to ietf.org. The email address for the list will remain the same, ietf-types(a)iana.org, but the subscription list and archives will move. Their new home will be; https://www.ietf.org/mailman/listinfo/ietf-types You might even have already received the "Welcome to ietf-types" email. Please feel free to contact me with any questions you might have about the move. Thanks. Mark.

1 0

Re: Registration of media type application/calendar+xml
by Keith Moore 11 Sep '10

11 Sep '10

On Sep 10, 2010, at 12:34 AM, Phillip Hallam-Baker wrote: > The objections raised by Keith do not appear to me to fall under any of the requirements for MIME type registration set out in RFC 4288. I didn't claim that they did. I'm just taking the opportunity to ask that the proposal be voluntarily withdrawn. > I disagree with the argument made in any case. > > If you want to have a system in which 95% of your data structures are in XML you probably don't want to have to introduce a separate syntax and you most certainly do not want to deal with a separate data model for dealing with calendaring. It's not at all clear that trying to coerce 95% of the data models in your system to be compatible with XML is a worthwhile goal. The XML data model is tortured. Trying to impose it on network protocols should be regarded as an act of violence. At any rate, this proposal doesn't change the iCalendar data model - it just makes it harder to use. If you have a beef with the iCalendar data model, feel free to try to come up with a better one. > The iCalendar format represents a 1990s style approach to the problem. There is no real separation of syntax from the data model. Software developed in that manner is notoriously difficult to get right for the reasons that Keith describes. XML has lots of problems of its own. I recently had to review a specification that referenced WS-i and WS-security and about a couple of thousand other pages of useless crap that went with it. All for the sake of being able to transmit about six meaningful name-value pairs from a client to a server. It was completely ridiculous. I'm no fan of the iCalendar format, nor the vCard and vCalendar formats that preceded it. But for all of its purported generality (and perhaps because of it) XML has turned out to be no better, and in many ways worse. It's amazing how hard people will work to make a simple idea complex, especially when the simple idea has become a bandwagon, or (in this case) a religion. In principle, it would make sense for things to have a uniform syntax. But XML gets this wrong in several different ways. The most obvious is that XML data structures don't map well onto data structures supported by programming languages. That's probably because SGML wasn't designed to do that - it was designed to mark up text. Another problem is that XML confuses typing and naming. Another problem (especially when mapping other structures to/from XML) is that the distinction between parameters and sub-elements is pretty much arbitrary. > XML is a substantial overhead if you are dealing with a single protocol but when you are dealing with multiple protocols the benefits are substantial and allow something like 70% of your coding effort to be pushed onto the platform layer. That means that you have 70% less new code and new code paths to contend with. If your programmer is spending 70% of his coding time dealing with a presentation layer, even one as convoluted as iCalendar, you should fire him. It's not like regular expression parsers are hard to come by these days. Nor are libraries that can parse standard formats hard to come by. Another of the big problems with the XML religion is that its adherents have the mistaken impression that defining the syntax is most of the work of defining a protocol - so that once you decide to use XML, most of the work is done. Apparently, semantics don't matter much. Another problem with XML is that it makes data models so easy to extend (just add more element definitions) that people often don't take due care in defining their data models. > One of the discoveries of the mid 1990s was that yacc and LR(1) grammars are no more useful for describing computer languages than they are for describing natural languages. That's a ridiculous statement. (Okay, maybe strictly speaking LR(1) isn't quite enough, but it's close enough for most computer languages that you can usually make an LR(1) parser work.) Computer languages don't need the same kind of expressive power that natural languages have. Natural languages have to allow for a certain amount of ambiguity, but that's a liability in computer languages. > The most useful feature of a computer grammar is regularity and consistency. XML enforces a high degree of consistency. It enforces consistency in syntax. Taken by itself, that's a good thing. But when you parse XML you don't get a very usable data structure. You get a mess. And once you do the work of transforming that data structure into an effective internal representation, you've negated whatever advantage you might have found in not having to have written a parser/generator for it. You haven't solved the problem of needing a parser and generator - you've just moved it. Instead of parsing text you're parsing a DOM structure. You've added an extra layer or two for no benefit. You're essentially arguing the syntax by which data is represented on the wire - the presentation layer - should constrain how data is represented internally in a system. And then you're arguing that the particular constraints imposed by XML are appropriate constraints. That's brain damage. > Now I would quite prefer to take about 50% or more of the XML spec and discard it. They did a good job of taking out the most insane features of SGML but there is much more cruft that could be cut out. But that does not change the fact that using XML as is produces clearer specifications that are more likely to be implemented without errors than with the 1990s approach. > As is often the case, you're simply and utterly incorrect. Let's stamp out XML in our lifetime. Even FORTRAN deserves to live longer. Keith

4 4

Registration of media type application/calendar+xml
by Steven Lees 10 Sep '10

10 Sep '10

To: ietf-types(a)iana.org Subject: Registration of media type application/calendar+xml Type name: application Subtype name: calendar+xml Required parameters: none Optional parameters: charset, method, component and optinfo as defined for the text/calendar media type Encoding considerations: iCalendar data is typically UTF-8 and thus the XML representation will follow that. As a result, for 7-bit transports, data in UTF-8 MUST be encoded in quoted-printable or base64. Security considerations: This extension does not introduce any new security concerns than those already described in iCalendar (RFC5545). Interoperability considerations: This media type provides an alternative syntax to iCalendar data based on XML. Published specification: This specification. (http://www.ietf.org/id/draft-daboo-et-al-icalendar-in-xml-06.txt) Applications which use this media type: Applications that currently make use of the text/calendar media type can use this as an alternative. Additional information: Magic number(s): None File extension(s): XML data should use "xml" as the file extension. Macintosh file type code(s): None specified. Person & email address to contact for further information: Steven Lees EMail: steven.lees(a)microsoft.com Intended usage: COMMON Restrictions on usage: There are no restrictions on where this media type can be used. Author: Cyrus Daboo EMail: cyrus(a)daboo.name Mike Douglass EMail: douglm(a)rpi.edu<mailto:douglm@rpi.edu> Steven Lees EMail: steven.lees(a)microsoft.com Change controller: IETF

10 13

Re: Registration of media type application/calendar+xml
by Peter Saint-Andre 10 Sep '10

10 Sep '10

On 9/10/10 11:21 AM, Keith Moore wrote: > >>>> An XML representation for iCalendar is vital if we are to keep >>>> iCalendar relevant in the web-based world. The drive for this >>>> work comes from a number of areas - in particular the smart >>>> grid effort sponsored by NIST will make use of this as part of >>>> the standards suite they are defining. >>> >>> Somebody needs to talk some sense into those people. Defining >>> another calendar format will only harm interoperability. It >>> doesn't save any calendar implementation from needing to >>> implement another parser, because if it wants to interoperate >>> with existing products or be able to read old events it's still >>> going to have to support iCalendar and probably vCalendar also. >>> So what's the _technical_ (not political) benefit from doing >>> this? >> >> First of all look at the mess we have got into with contacts (see >> recent discussion on the vcarddav WG mailing list). There we now >> have vCard, PoCo, OpenSocial and some new thing the OMA is doing >> (and their are lots of private apis too). Yet vCard has been around >> for a long time - why didn't those other folks just use that or at >> least propose fixes or extension to vcard that would satisfy their >> issues? Well, certainly in the case of PoCo one clear requirement >> was for a simple web/browser based solution - so they designed JSON >> and XML representations. > > Mumble. It's a lot harder to make a web browser do something useful > with a calendar object (no matter what the syntax) than it is to make > a web browser do something useful with contact information. > > And I *like* JSON. I think it's a good approximation to what XML > should have been. It's not clear to me how your personal preference for JSON over XML is relevant to registration of the application/calendar+xml media type or continued work on draft-daboo-et-al-icalendar-in-xml. However, given that you seem to object to the XML representation of vCards, calendaring objects, and just about anything else, I suggest that you start a thread about XML vs. JSON on the apps-discuss list rather than filling up the archives of the ietf-types and ietf(a)ietf.org lists. https://www.ietf.org/mailman/listinfo/apps-discuss Peter -- Peter Saint-Andre https://stpeter.im/

1 0

Re: Registration of media type application/calendar+xml
by Keith Moore 10 Sep '10

10 Sep '10

On Sep 9, 2010, at 10:22 PM, Cyrus Daboo wrote: > Hi Keith, > (cc'ing Apps area ADs - I believe Peter intends to "sponsor" this draft so he at least should be aware of our discussion here) > > --On September 9, 2010 9:44:07 PM -0400 Keith Moore <moore(a)cs.utk.edu> wrote: > >> This was a bad idea when it was first proposed (if I recall correctly) >> around ten years ago, and it's still a bad idea. > > An XML representation for iCalendar is vital if we are to keep iCalendar relevant in the web-based world. The drive for this work comes from a number of areas - in particular the smart grid effort sponsored by NIST will make use of this as part of the standards suite they are defining. Somebody needs to talk some sense into those people. Defining another calendar format will only harm interoperability. It doesn't save any calendar implementation from needing to implement another parser, because if it wants to interoperate with existing products or be able to read old events it's still going to have to support iCalendar and probably vCalendar also. So what's the _technical_ (not political) benefit from doing this? IETF's job is to provide technical leadership, not to follow bad advice. Instead of caving into them, what we need to do is publish a draft called "Translating Everything into XML Considered Harmful". >> Whenever you define an alternate representation of something, there will >> inevitably be skew between the original representation and the alternate >> representation. > > iCalendar is itself extensible in terms of the addition of new properties and parameters. The trivial mapping of the iCalendar object model to our XML schema allows such extensions to be trivially mapped. But your document doesn't define what the mapping is. And your mapping spec (not to mention implementations) will always lag extensions. >> This remains true even if you define mapping rules between the two (as >> you do in this document). The problem with mapping rules, which I >> believe I pointed out around ten years ago, is that the rules are >> specific to a particular version of iCalendar. If either iCalendar is >> extended, or the XML representation is extended, there's no guidance as >> to how to map the extended format into the other representation. > > If iCalendar is extended in such a way that it is no longer compatible with the XML mapping, then it would really be a completely new version that would itself not be compatible with the existing iCalendar v2.0. If that happens, well compatibility has clearly been thrown out the window. Sure, but if that should actually be needed, why do you want to make it even more difficult? If and when there were a need for an iCalendar 3.0 - i.e. an incompatible change because there was no way to shoehorn the new features into the old format - it might make sense to define _that_ to use XML. >> In addition, defining a new calendar format harms interoperability even >> if you can keep the two representations in sync. The reason is that it's >> no longer sufficient for a calendar application to support just one >> representation of calendar data. In order to reliably interoperate, it >> must at least able to read both, and it probably needs to be able to >> write both. That, and when sending calendar data to other applications, >> either both representations must be sent, or some way of negotiating >> which format to use is needed, or the user must be asked to choose which >> format to export. > > Correct - having two representations can cause problems like this. However, with the advent of HTTP-based calendar protocols, the content negotiation mechanisms in HTTP (e.g. Accept header) can be used to push most of the burden for this on servers rather than clients. Provided, of course, that HTTP-based calendar protocols are being used. But currently, all of the iCalendar content I receive is over email. Even if you have content-negotiation, having two formats still means there are two code paths, which introduces additional opportunities for failure. >> Please withdraw this proposal, or at least withdraw the types application >> until the proposal has enjoyed more review. > > Having a MIME type for this representation is critical to enabling content negotiation features. Let me be clear. I'm not saying just withdraw the MIME type application. I'm asking you to abandon the internet-draft also. Don't introduce an incompatible iCalendar format. Then you don't need content-negotiation for calendar data. > I feel strongly that this is a valid and useful proposal and we are already seeing uptake in the form of smart grid work and others. I don't doubt at all that there are people jumping on the bandwagon. That's not a sound justification for degrading interoperability of calendar products. > Whilst this is an individual submission, I would point you to <https://datatracker.ietf.org/doc/draft-ietf-vcarddav-vcardxml/> which is the product of the vCardDAV working group. That specification defines a mapping of vCard to XML which follows the same basic design of our iCalendar-in-XML work. One example of bad practice does not justify another. That is what is known as propagation of error. Keith

5 5

Re: Registration of media type application/calendar+xml
by Cyrus Daboo 10 Sep '10

10 Sep '10

Hi Keith, --On September 10, 2010 12:43:53 PM -0400 Keith Moore <moore(a)network-heretics.com> wrote: >> Fair enough. We can adjust e.g. Section 3.7 that talks about only X- >> extensions to also refer to any new iCalendar data objects. The basic >> premise being that new iCalendar data object names map directly to an >> XML element name. After each table in the previous sections we can add a >> reference to section 3.7 with a statement that that is how new items >> will be handled. > > That would help. But why do you need specific rules for any of the > iCalendar data object names? I can understand one or two exceptional > cases, but if the mapping you have is truly adaptable, it shouldn't need > many of those rules. OK, I'll discuss with my fellow authors to see what we can do to better clarify our intent. Maybe we actually state the naming/mapping rules at the very start of section 3 as the "fundamental" set of rules, but we still keep the tables in there as a useful reference back to the iCalendar spec. -- Cyrus Daboo

1 0

Re: Registration of media type application/calendar+xml
by Cyrus Daboo 10 Sep '10

10 Sep '10

Hi Keith, --On September 10, 2010 10:09:11 AM -0400 Keith Moore <moore(a)cs.utk.edu> wrote: >> That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. >> iCalendar components, properties, parameters and values all map to XML >> in a consistent manner with no need to "special case" based on type or >> value. > > But you're not doing that in the draft. You explicitly list every > keyword. Every time a new component, property, parameter, etc is added > to iCalendar, the mapping code will have to change also. The trick is to > be able to translate between formats, with no changes to the code needed > even when the format is extended. Fair enough. We can adjust e.g. Section 3.7 that talks about only X- extensions to also refer to any new iCalendar data objects. The basic premise being that new iCalendar data object names map directly to an XML element name. After each table in the previous sections we can add a reference to section 3.7 with a statement that that is how new items will be handled. >> Conversion to/from XML is trivial - I have coded at least one half of >> that and I know others who have done both ways.It should also be easy to >> put together an XSLT to go from XML to iCalendar - with the only >> possible difficulty being having to apply escaping and line folding as >> required by iCalendar. > > That would be great, again provided you don't have to explicitly list > every keyword. It still wouldn't convince me that XML iCalendar is > sufficiently valuable to be worth the degraded interoperability. But if > you're going to have two formats, being able to automatically convert > between them is the best way to do that. It has always been our intent to have a 1-to-1 mapping between the two. We in fact went out of our way to ensure that the XML schema would not restrict in anyway what could be done with new iCalendar data objects. -- Cyrus Daboo

2 1

Re: Registration of media type application/calendar+xml
by Cyrus Daboo 10 Sep '10

10 Sep '10

Hi Keith, --On September 10, 2010 1:40:16 AM -0400 Keith Moore <moore(a)cs.utk.edu> wrote: > But here's the acid test. If you can define a mapping from iCalendar to > XML that doesn't require any string constants to describe it (other than > for iCalendar keywords that imply nesting, and separators that are used > in a regular fashion in iCalendar), and if you can define the inverse > mapping from XML to iCalendar without naming more than a couple of > specific element or parameter names - then I'll concede that the mapping > will probably continue to work in the face of extensions to the iCalendar > data model. Otherwise, I'm highly dubious. That is precisely the goal of draft-daboo-et-al-icalendar-in-xml. iCalendar components, properties, parameters and values all map to XML in a consistent manner with no need to "special case" based on type or value. New components, properties, parameters, values, either registered with IANA or using X- prefixes map in exactly the same way. Conversion to/from XML is trivial - I have coded at least one half of that and I know others who have done both ways.It should also be easy to put together an XSLT to go from XML to iCalendar - with the only possible difficulty being having to apply escaping and line folding as required by iCalendar. -- Cyrus Daboo

2 1

Re: Registration of media type application/calendar+xml
by Cyrus Daboo 10 Sep '10

10 Sep '10

Hi Julian, --On September 10, 2010 12:11:27 PM +0200 Julian Reschke <julian.reschke(a)gmx.de> wrote: >> If your programmer is spending 70% of his coding time dealing with a >> presentation layer, even one as convoluted as iCalendar, you should fire >> him. It's not like regular expression parsers are hard to come by these >> days. Nor are libraries that can parse standard formats hard to come by. > > Can iCalendar be parsed reliably with regexps? (just asking). The Python vobject library that we use in our CalDAV server (http://calendarserver.org) does use regular expressions for parsing entire lines (after applying line "unfolding" of the overall text object), and then parsing out pieces of those. That is used for both iCalendar and vCard. -- Cyrus Daboo

1 0