Re: Registration of media type application/calendar+xml

[Keith Moore <[e-mail]>]

[ietf-types removed to spare those who just want to read type applications.]

> We need to distinguish between alternate syntactic forms, versus alternate semantic environments.  Translating between versions of the former do not need to lose information.  Translating between versions of the latter almost certainly do.  Losing information is about differences in semantics.

I'm not convinced that there is a difference in practice between the two.  Different syntactic forms tend to get used in different environments, and to adapt to the requirements/conventions of those environments.  

calendar+xml is intended to be merely a syntactic alternative.  I just don't believe it is likely to stay that way.

> As I understand the calendar+xml, it is "merely" a syntactic alternative.  To the extent that it requires information loss when being re-encoded, yes that should be fixed.  But it's not likely to be difficult and the existence of two syntactic forms is not inherently problematic.  (We have lots of examples on the net of doing this quite nicely, at different layers of Internet architecture.)

please cite specific examples.  it might be instructive to see why they work or don't work well.

the best one that immediately comes to mind is raw IP vs. PPP with header compression.  I think it works because the latter representation is only used on the wire between two endpoints of a network link.  And if it fails to faithfully reproduce the packet, it's very clear where the problem is.  (there's no argument about which representation is correct - the original packet is always correct.).

> As for the more abstract discussion about whether it's good or bad to have an xml version, I'll strongly suggest that it is best conducted in a real bar bof with real alcohol.  (I'll be supporting its existence, FWIW.)  

I had to read that twice.  For a second I thought you were offering to support the existence of alcohol for the bar bof. 

> The xml version is an important fact of life.  Let's not pretend otherwise.

My standard response whenever anyone cites anything as "reality" or a "fact of life", is that that's what people always say when they can't cite any technical justification.  

Keith