RE: Comments on CPIM draft 03

A few notes inline below. For the most part, this is just acknowledgment
that various editorial and content fixes suggested by John will be made.
Some points for continuing discussion as well, especially the last two
comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, August 16, 2002 6:20 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Comments on CPIM draft 03
> 
> 
> Jon,
> 
> Thank you for updating the CPIM draft.  I am particularly happy to see
> the current draft has a consistent story on URIs, and the Presence
> Service DTD no longer includes an unsubscribe operation.
> 
> I notice that the format of the document has changed, so that it is
> not obvious which sections of text remain the same.  You can
> facilitate better feedback from us by identifying changes, and the
> easiest way to do that is to send to the list a unified diff, "diff
> -u", which compares the source for version 02 with the one for version
> 03.
> 

I don't have the source for version -02, unfortunately. Other than editorial
corrections, I tried to note any substantial changes in my recent summary.

> Following Hiroyasu's suggestion, I will defer comments on notification
> authentication.  Enclosed are comments that are not ordered by
> importance.
> 
> 1. The title of Section 2.1 is now "Overview", but I think the
>    previous title of "Overview of Instant Messaging Service" is
>    better.  If "Overview" is really the desired title, than it should
>    also be the title of Section 3.1.
> 

Yes, it just looked redundant on the page as I was skimming through.
Obviously this isn't the sort of thing one feels strongly about - I'll
change it back.

> 2. On Page 11, the diagram for the unsubscribe operation is
>    erroneously formated.

Fixed.

> 
> 3. The unsubscribe operation has been removed, but Page 11 shows an
>    example of it.  I suggest changing that section to:
> 
>       The application may prematurely cancel a subscription by
>       invoking the subscribe operation with a duration of zero, e.g.,
> 
>              +-------+                    +-------+
>              |       |                    |       |
>              | appl. | -- subscribe 0 --> | pres. |
>              |       |                    | svc.  |
>              +-------+                    +-------+
> 
>              <subscribe watcher='pres:[email protected]'
>              target='pres:[email protected]'
>              duration='0' transID='3' />
> 

Fixed.

> 4. On Page 13, Paragraph -2 contains the phrase "Step 4.3 above does
>    not occur".  Where is Step 4.3?  I think it refers to the last
>    doubly indented paragraph on the page, so these paragraphs must be
>    labeled. 
> 

Fixed... also fixed a redundancy between the first two items under 4 on Page
13.

> 5. Section 4.3.2 on Page 17 has the sentence:
> 
>       End-to-end security for presence notifications and subscriptions
>       could be provided by any MIME-based security mechanism.
> 
>    How can one provide end-to-end security for subscription operations
>    without an agreed upon common format for the operations?  How can
>    one provide end-to-end security for notification operations without
>    an agreed upon convention for identifying presence services?
> 

Yes, well, this wasn't intended to be final text, just a placeholder -
agreed that it is quite possibly even less useful than the text that
appeared in -02. I think the questions you ask above derive from an even
more troubling open issue: if subscription and notification aren't
interoperable in a secure fashion, then is CPIM fulfilling the requirements
of RFC2779 (and its overall goal)?

Personally, I suspect that we'll end up with different security stories for
subscription and notification. Notification has some different security
needs than subscription; in particular, there are integrity and
confidentiality properties of notification that subscription doesn't share.
It can be argued that subscription has only a mutual authentication
requirement (5.1.2 in RFC2779 recommends but does not require e2e
confidentiality for subscriptions) - even if confidentiality is provided for
subscriptions, traffic analysis alone can always go a long way towards
determining that there is a subscription (encryption can't really prevent
that), but concealing the content of a notification is a different matter
(and it much more clearly required, following 2779 5.2.1). While mutual
authentication can be provided transitively (i.e. by intermediaries) without
any real difficulty, end-to-end confidentiality and transitivity don't mix.
And MIME-level security for notification could be staged around PIDF bodies.

I'll be sending out some more thoughts about this soon.

> 6. Section 3.4.3 and Section 3.4.4 refer to a subscription ID, but
>    never define what it is.  For an unsubscribe operation, I assume
>    the subscription ID is the transID of the subscription operation
>    that established the subscription, while the subscription ID
>    for a fetch operation is any transID not currently in use.  The
>    assumptions on IDs must be explicitly stated.
> 
>    Of course, we may want to be explicit about the role of
>    identifiers, as suggested by Thanos in
> 
>       http://www.imppwg.org/ml-archive/IMPP-WG/200207/msg00007.html
> 

Yes, I agree that this needs to be clearer. For the time being it is
probably simplest to just remove the term 'subscription ID' and use the term
'transID' in its place, with the semantics you suggest above. Whether or not
we need a subscription ID really hinges on the degree to which CPIM is
standardizing a practice for subscriptions. A subscription identifier would
probably only be meaningful in CPIM if the context of the whole subscription
operation in CPIM were a little more clear.

> Thanks,
> 
> John
> 



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