Dear Marcos, I have some comments on the FPWD of the "Widgets 1.0: Updates" document.
Best Regards, Rainer a) Abstract: Replace "[...] the model makes use a simple XML documents [...]" by "[...] the model makes use of a simple XML document [...]". b) 2. Introduction: Replace "[...] a multi-step process where by a widget user agent compares [...]" by "[...] a multi-step process where a widget user agent compares [...]". c) 2. Introduction: Replace "[...] the widget user agent must attempt replace [...]" by "[...] the widget user agent must attempt to replace [...]". d) 2. Introduction: Replace "[...] via the rules define in this specification [...]" by "[...] via the rules defined in this specification [...]". e) 2. Introduction: Replace "[...] then that installed widget is said to be up-to-date." by "[...] then that installed widget resource is said to be up-to-date.". f) 2. Introduction: "It is expected that widget user agents will perform updates asynchronously by periodically checking for changes in either the HTTP response codes for the UDD (e.g. a changed HTTP Etag header or using If-Modified-Since) and by processing the UDD itself." This scenario is very likely in case of an implementation for a desktop computer or a set-top box. However, a push mechanism is well established in the mobile environment. Such a push mechanism consists of an SMS message that wakes up an application in a mobile terminal that retrieves any kind of content from a remote server. It could be applied to the automatic widget resource update mechanism as well. The widget resource author would send out notifications to his/her known customers/users via SMS. The widget user agent retrieves the UDD via HTTP. The advantage of this push mechanism is that it does not consume unnecessary processing resources in the mobile terminal and the remote server, does not consume unnecessary transmission capacity in the Web and updates a widget resource as soon as an update is available. The disadvantage is that it is not supported in the IP world. However, we could mention in the specification that a push mechanism could be applied as well. We could add the following sentence to the sentence above: "A push mechanism could be applied as well that pushes a UDD to the widget user agent as soon as an update is available.". f) 2. Introduction: Replace "[...] as it makes us of the URI to potentially retrieve [...]" by "[...] as it makes use of the URI to potentially retrieve [...]". g) 2. Introduction: "[...] and relay whether an update is available back to the instantiated Widget. Actually performing the update is left to the discretion of the widget user agent." Shall the instantiated Widget be able to initiate the update process after receiving the information that an update is available? Otherwise, it would not be under a Widget's control to start the actual update process. A Widget could be able to consider whether a mobile terminal is in roaming mode and whether its size is too big. If yes, it could postpone the update process to avoid unexpected costs for a user. As soon as the mobile terminal is attached to the home network, the Widget could ask the user to start the update process. h) 4.1 Example Update Description Document: The widgetupdate element supports two attributes that represent URIs. In section 2. Introduction, it is a "IRI from where the widget user agent can retrieve the potential update", for instance. If they are the same, then it should be either a URI or an IRI. i) 9. Security concerns: "It is conceivable that the automatic update model could be subject to a man-in-the-middle-attack, as with any unencrypted requests performed over HTTP. For this reason, it is recommended that automatic update are always performed over HTTPS." An unencrypted request performed over HTTP is not necessarily opening up a security hole. As long as a widget resource is cryptographically signed and the widget user agent validates the signature before installation, a widget resource's identity and integrity should be guaranteed. j) 10.1 Using an Update Description Document: Replace "widget engine" by "widget user agent". k) 10.1 Using an Update Description Document: Replace "text/xml" by "application/xml". l) 10.1 Using an Update Description Document: "So, the widget engine then checks that <update id> matches <widget id> and that <widget version> and <update version> are different. If so, then the user is informed that a new update is available." If the <widget version> is not the same like the <update version>, then this will not necessarily mean that a new update is available. The installed Widget Resource could have been retrieved from a web server providing the latest version. The UDD could have been stored on a memory card which could then be quite old. Then the widget user agent must be intelligent enough to compare whether the <widget version> is smaller than the <update version>. If yes, then a new update is available. The question is also whether we define a format for the version number. Is 1.0 "older" than 1.0a? ************************************* T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: [EMAIL PROTECTED] http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
