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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Feb 10 09:19:34 2005

I agree that this type of gleaning a remote participants capabilities is
typically handled via alternatives, rather than handshake.  Although, in
the crypto case, you explicitly don't know a recipients capabilities for
encryption until you receive a signed message containing their public
keys (or some other delivery/publishing of capabilities in PKIX).  This
precedent is for a very good reason, arguably - that security depends on
it.  In the crypto case, non-repudiation (for example) is not an
"alternative" but a requirement.

I understand Nathaniel's concern, but I also see (first hand in some
cases) how applications often use cues from their recipients messages to
respond to them.  The most basic form of this is replying to a message.
Whether the reply uses plain text or rich text (HTML) is based solely on
the sender's choice, and by implication, their capabilities.  There are
many other examples, but that is not to say that this is the best way to
distribute or guess capabilities.

camerost

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nathaniel
Borenstein
Sent: Thursday.10.February.2005 08.29
To: [email-masked]
Subject: [Ietf-calsify] Receiver Capability Description Considered
Harmful

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

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify