Subject: Re: [dispatch] draft-mdolly-dispatch-oma-push

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 04 May 2010 16:31:54 +0300

Hi,

I have not seen any activity on this for a relatively long time. Note
also that we received the LS below some time ago:

https://datatracker.ietf.org/documents/LIAISON/file726.doc

Where are we with this?

Thanks,

Gonzalo

On 01/02/2010 6:57 PM, Adam Roach wrote:
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 12 May 2010 06:42:33 -0600

I sort of assumed from the Liaison that they did not want a response. If there is any key feedback to send, it is that the IETF has typically pushed back on drafts that wold change the review process for defining future Event packages - particularly approaches that changed i for one SDO and not for other SDOs. I'd be happy to send them a pointer to the RAI Review but I suspect they already have that. 

Thoughts on what we need to send if anything?

Thanks, 
Cullen <with my co-chair hat on>

On May 4, 2010, at 7:31 AM, Gonzalo Camarillo wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html