Subject: [Ietf-calsify] Receiver Capability Description Considered Harmful

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Feb 10 08:29:11 2005

I'm somewhat concerned about any suggestion (below made by Doug, but 
he's by no means alone) that encourages the composer of an iTIP message 
to try to take into account the capabilities of the intended 
receiver(s):

> 2) We add a property to all iTIP replies that indicate the supported 
> features of the
>     side that is replying. We name this new property EXTENSIONS. And 
> it will be
>     a muilti valued   property that lists the RFC numbers of 
> extensions supported by the
>     sender of the object.  This property will go at the same level as 
> VERSION.

I am skeptical that we can ever make this sort of capabilities 
consideration work well in an email (imip) context.  There's no 
precedent for requiring email composers to ascertain the recipient's 
capabilities before deciding on the format of the message they're 
sending, and I'd prefer not to make the calendaring work depend on such 
a disruptive change to the email model.  Note that ESMTP is not a 
counterexample, because the only capabilities exchange happens 
synchronously at SMTP hops rather than when the message is being 
composed for eventual delivery to a (possibly offline) recipient. -- 
Nathaniel