RE: Comments on CPIM draft 03

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email protected]]
> Sent: Friday, September 06, 2002 9:57 AM
> To: Peterson, Jon
> Cc: 'Athanassios Diacakis'; [email protected]; [email protected]
> Subject: Re: Comments on CPIM draft 03
> 
[snip]
> 
> > Once again, we can defer the question to the
> > presence protocol, which may or may not guarantee ordered delivery.
> 
> Everything in CPIM also exists in the underlying presence protocol. CPIM 
> is about specifying what has to be there.
> 

Well, either CPIM requires that attributes be a part of the underlying
protocol, or CPIM defines some object containing the information that must
be tunneled by the underlying protocol. The suggestion you make below that
the only reason to do the latter is to enforce security properties seems
right - and I think this methodology should be recorded in the CPIM spec.
But the latter view also doesn't require that the underlying protocol be
modified if it doesn't happen to support the identifiers described by CPIM
(which simplifies how a mapping should be performed at a gateway, and also
requires less of the underlying protocol). It's really important that we
decide when tunneling should or should not be used. In an earlier thread,
there was some talk that a tunneled subscription object might be necessary
(hence my speculation about SUBFMT).

There is even some ambiguity about what it would mean for a capability
identified by CPIM to exist in the underlying protocol. Should transaction
IDs themselves be interoperable (are they something that a CPIM gateway
would be able to statelessly take from one protocol and copy into the
corresponding field in another protocol)? Or does each protocol have its own
way to provide the properties that we associate with a transaction ID? I
don't think this is an entirely insignificant matter.

[snip]
> 
> Generally, matching responses to requests is something each presence 
> protocol needs to be able to do to function. I think we all agree its 
> useful in a real protocol. Having this identifier in CPIM means that any 
> CPIM compliant protocol has to have a way to match responses to 
> requests. All will, of course. So, I don't understand the big 
> problem here.
> 

Again, it's not just a question of whether or not the protocol must have
this property - I'm trying to figure out how to interpret the requirement
for this property.

[snip]
> 
> My understanding of CPIM is that any protocol compliant to CPIM must be 
> able to specify how to build a gateway to CPIM, mapping to/from every 
> parameter in CPIM. Thus, presence of a parameter in CPIM implies that 
> the protocol must support the equivalent semantic. Saying that CPIM has 
> a transaction ID simply means that any underlying protocol has to have a 
> way of mapping a response to a request it corresponds to. Whether thats 
> done using transaction IDs in the underlying protocol, by having the 
> protocol sequence the requests/responses so there is no ambiguity, or 
> something else, is not important.
> 

The implementation of CPIM gateways could have some dependency on which of
these two possibilities is intended. Increasing the number of identifiers
(beyond transaction IDs, to subscription and notification IDs) increases the
complexity of the mappings performed by CPIM gateways and it can be used to
argue for a SUBFMT. That's one of the reasons why I'm concerned about the
proliferation of identifiers in the core CPIM spec.

> > 
> > I think your argument above could be used against, say, the entire
MSGFMT
> > draft. We inherit a certain number of requirements from RFC2778/RFC2779,
and
> > they can either be fulfilled by the using protocol, or we can create
objects
> > in IMPP and carry require that the using protocol carry them around. 
> 
> IMPP is doing both. Its specifying CPIM as a set of common semantics 
> that must be present in any protocol. Its also specifying objects that 
> must be carried on the wire in order to support e2e integrity through 
> gateways. I don't see those as inconsistent goals.
> 

I understand your point that e2e security properties necessitate tunneling
objects. And furthermore...

[snip]
> 
> Clearly, To and From are replicated, but that is the nature of this 
> beast. SIP works the same way for signed sip messages using s/mime - 
> information is replicated in the headers and in the signed body. Here, 
> the signed body just happens to be using a slightly-different (but 
> parser compatible) format.
> 

Although some information has end-to-end integrity properties, it also
should be visible hop-by-hop - in both SIP and in CPIM, you need to know who
a request is for (i.e. the 'To' information) hop-by-hop. Some other
information, however, is clearly only e2e. Ideally, I think that a
particular attribute of an operation should be realized in CPIM either as a
requirement in the underlying protocol or as part of a tunneled object - I
think we would be ill advised to encourage the carriage of redundant
information except in those cases in which an attribute has both e2e and hBh
properties.

Just to be clear, what I'm trying to capture here is what these requirements
entail and how they should be understood. I don't think we need a SUBFMT
tunneled object, and I suspect that the subscription ID has been amply
motivated in this discussion. But more importantly, I think we'll also be
able to supply some text that says what the 'abstract operations' of CPIM
actually require of underlying protocols.

[snip]



  [reminder: [email protected] for non-technical discussions, please]