1 / 8

Presence Information Delivery Registration - Revision Proposal

This document proposes revisions to the presence information delivery registration process, suggesting the use of Q-values for MIME types and a new element under <presence> to signal tuple removal. It explores the option of utilizing the 'xcap' package for presence document changes and discusses the cons of this approach. The document explains the need for a distinct MIME type, handling of namespaces, identification of non-unique elements, and the complexity of the proposed solution. Feedback and review from the working group are welcomed.

olliej
Download Presentation

Presence Information Delivery Registration - Revision Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-simple-presinfo-deliv-reg-00 Mikko Lönnfors mikko.lonnfors@nokia.com IETF#57, Vienna

  2. Status • No comments received for this draft • Would be good if some people could review it • WGLC after review?

  3. draft-lonnfors-simple-partial-notify-02 Mikko Lönnfors mikko.lonnfors@nokia.com IETF 57, Vienna

  4. Changes since -01 • Use of Q-values with MIME types in Accept: header to indicate preferred Content type • Use of new <removed> element under <presence> element to signal removal of tuples

  5. Current solution • In current solution <tuple>s are considered as atomic data elements -> Updates are send in <tuple> level • Presence document level info is always included • Document format is similar to normal PIDF • Should not have any major open items

  6. One other alternative could be ‘xcap’ package • This was proposed in interim meeting • It might be possible to use ‘xcap’ package (or something similar) to deliver changes in presence document • The event package itself is not needed. Only the MIME type used to convey changes • Utilizes Xpath functions to identify element which has changed • Might allow sending smaller changes than current solution (in a level of any XML element/attribute)

  7. Cons in using ‘xcap’ • Will need its own MIME type because current ‘xml-change’ contains elements/attributes which cannot be used: • URIs, these are defined as HTTP URIs. Version info • Handling of namespaces. At least in cases where notification contains information from namespace which hasn’t been used in previous notifications • Identification of elements which don’t have unique identifier (in cases where element can have multiple instances) • More complex solution than existing one • PUBLISH uses <tuple> as atomic element. Not consistent with it.

  8. Way forward • Go forward with existing solution • If some other solution could be used please propose text • WG item? • Would be good if WG could review the document

More Related