[Rai-discuss] draft-mdolly-dispatch-oma-push

[Adam Roach <[e-mail]>]

The area directors for RAI asked me to review 
draft-mdolly-dispatch-oma-push, specifically as they relate to the 
ongoing revisions to RFCs 3265 and 3427.

While there are some relatively minor issues with some of the 3265 
concepts used in this document, there is an overarching structural issue 
that needs to be addressed.

By my reading, what this document seeks to do is open a door for OMA to 
create new event packages without requiring any IETF review (and, even 
if such is not the intent, it would certainly be the outcome). This is 
achieved by using an event package type of "oma-push," and then using a 
new "Event" header field parameter of "event-app-id" to indicate the 
actual event package. In the language of object-oriented programming, 
this draft seeks to define an event package that is little more than a 
façade to wrap RFC 3265, with the only substantive difference being 
whether IETF review is required.

The nature of this proposed "event package" as a framework (as opposed 
to an actual event package as RFC 3265 defines that term) is revealed 
substantially by the contents of two of its sections: section 10 and 
section 12. In section 10, the draft tacitly indicates that it is to be 
applied to a broad range of events:

    The durations of push event subscriptions, and in general the
    conditions under which they are terminated, vary widely with the
    nature of the applications as they are assumed to be application-
    specific criteria.


Even more tellingly, section 12 simply indicates that the notification 
bodies can be carried either inline or via indirection, and gives no 
actual definition of body type or of body syntax. By contrast, consider 
the body of published event packages:

    * RFC4575 defines a new application/conference-info+xml for NOTIFY
    * RFC5362 defines a new application/resource-lists+xml for NOTIFY
    * RFC4235 defines a new application/dialog-info+xml for NOTIFY
    * RFC4730 defined a new application/kpml-request+xml for NOTIFY
    * RFC3842 defines a new appcliation/simple-message-summary for NOTIFY
    * RFC4354 defines a new application/poc-settings+xml for NOTIFY
    * RFC3856 uses application/pidf+xml (which was designed for this
      purpose) for NOTIFY
    * RFC3680 defines a new application/reginfo+xml for NOTIFY
    * RFC3515 uses message/sipfrag to convey the state of the indicated
      resource in a NOTIFY
    * RFC3910 defines a new application/spirits-event+xml for NOTIFY
    * RFC3857 defines a new application/watcherinfo+xml for NOTIFY


A legitimate event package would indicate specifically and completely 
what state is to be conveyed. It will also define or normatively 
reference a formally-defined syntax for conveying the state. The fact 
that the draft cannot provide such a description of state and a syntax 
for conveying the state is a good indication that it is not an event 
package, but actually an attempt to wrap RFC3265 in a parallel framework.

If the overall mechanism proposed by the current document is approved as 
an IETF-sanctioned event package, the net result will be a loophole that 
effectively eliminates section 4.1 of rfc3427bis entirely.

By my reading of subject matter covered by this document -- and with the 
caveat that I am not familiar with any of the OMA applications that the 
mechanism is intended to enable -- the only path forward that both 
achieves the goals stated in this document's problem statement and 
conforms to the restrictions put forth in RFC 3427 (and its draft 
successor) is to define each of the applications as a new event package. 
Unless I misunderstand the mechanism defined in OMA-TS-SIP_PUSH, there 
appear to be approximately 23 such applications presently defined [1]. 
For the sake of expediency, it may be sensible to have a single document 
that defines the RFC3265 event packages for all of them -- that is, a 
single draft with 23 distinct copies of the sections required by section 
4.4 of RFC3265.

/a

[1] A (partial?) list of defined applications appears to be published 
here: http://www.wapforum.org/wina/push-app-id.htm