From adam@nostrum.com Mon Feb 1 08:57:14 2010 Return-Path: X-Original-To: rai-discuss@core3.amsl.com Delivered-To: rai-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3B33A695A; Mon, 1 Feb 2010 08:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96a5YAN0T5uw; Mon, 1 Feb 2010 08:57:13 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 626113A67B4; Mon, 1 Feb 2010 08:57:12 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o11Gvj8R028218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 10:57:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B670809.2010903@nostrum.com> Date: Mon, 01 Feb 2010 10:57:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: IETF Dispatch Content-Type: multipart/alternative; boundary="------------000502060803010708050500" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: RAI Subject: [Rai-discuss] draft-mdolly-dispatch-oma-push X-BeenThere: rai-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: IETF Dispatch List-Id: Discussion list for Realtime Applications and Infrastructure List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 16:57:14 -0000 This is a multi-part message in MIME format. --------------000502060803010708050500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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 --------------000502060803010708050500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------000502060803010708050500--