On Sep 9, 2010, at 11:38 PM, Ned Freed 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.
I strongly disagree.
Whenever you define an alternate representation of something, there will
inevitably be skew between the original representation and the alternate
representation.
This is demonstrably false. The Sieve in XML representation specified in RFC
5784 provides a counterexample - the way the format and mapping is defined,
there's no way to represent anything in the XML variant that cannot be
represent in the regular variant, and vice versa.
RFC 5784 might well be a valiant effort toward that. But it has only been out
a few months, so I think the jury is still out as to how well it works in
practice.
I also think it helps that RFC 5784 specifically says it's not intended as an
alternate storage format for Sieve. I can certainly see some utility in being
able to use XML tools to manipulate things not originally written in XML.
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.
Even then, this would not address the degraded interoperability resulting from
the need to have multiple formats.
I have only done a cursory review of iCalendar in XML specification, but I
believe it covers this issue adequately, and according to the document, it
clearly intends to define a format that fully support round trips between the
representations. If you believe it does not, it is up to you to provide
specifics of how it does not, rather than asserting there's a problem without
any actual evidence.
I disagree, because there are interoperability problems resulting from the
introduction of an alternate format even if the mappings remain invertable in
the presence of 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.
Also demonstrably false, and once again RFC 5784 provides a counterexample.
When Sieve extensions are defined the only thing that ever needs to be updated
in the mapping to accomodate them is the list of controls, which is needed to
map to the XML format.
I think you've just illustrated my point.
Though really I'm not as worried about Sieve as I doubt that there's nearly as
much deployment of Sieve as there is of iCalendar. I think it's far more
likely that all Sieve implementations can be upgraded to support XML, if
there's a desire to do that, than that all iCalendar implementations can be
upgraded to support XML.
I also think that Sieve<>XML is inherently saner than iCalendar<>XML because
Sieve (being essentially a programming language) is already structured
similarly to the way XML is structured.
Again, if you believe that introduction of new iCalendar properties will
require updating the mapping to an unaceptable degree, it is up to you to cite
specific exmaples instead of just asserting there's a problem.
I think that the burden is on the proposers to justify producing an
incompatible alternative to a existing standard, which will definitely harm
interoperability.
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.
Yes, the existence of multiple formats can be an issue, but so can the
inability to easily manipulate application data in popular environments using
readily available tools. IMO the tradeoffs in this case are *overwhelmingly*
on
the side of being able to manipulate calendar data using XML tools.
If people want to define mappings between iCalendar and XML just for the sake
of being able to manipulate the data using XML tools, that doesn't bother me so
much. It's when people want to start exchanging calendar data using XML in
some cases and iCalendar in others that the interoperability problems start
cropping up. (Though I have to wonder how much it really helps to be able to
manipulate calendar data using XML tools, as calendar manipulations tend to be
fairly specialized to calendar applications.)
First of all, I'm actually kicking myself now that Sai and I didn't include a
registration for application/sieve+xml in RFC 5784. If we ever do a revision
I'll be sure to correct that omission.
Second and far more important, the ietf-types list is for preliminary reviews
only. In the case of a standards tree type like this that's being defined in
an
RFC, approval comes from the IESG, and that will happen as part of the review
and approval process for the actual specification. It is therefore entirely
appropriate for this registration to be posted to the list at this time so it
can be reviewed.
Yeah, I know...that's why I cc'ed the IETF list. I am not arguing that the
type registration itself is improper; I'm arguing that defining a new
representation of iCalendar is a bad idea and should be discouraged by the IETF
community. And for that reason I'm asking the document authors to put the type
registration on hold.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf