File Descriptions Extension to the Presence Information Data Format (PIDF)
draft-garcia-sipping-file-desc-pidf-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 19, 2008.

Abstract

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. Presentities publish their presence information, typically towards presence agents. PIDF has been extended to provide rich presence information, including, for example, the location of the presentity, their activities, mood, the capabilities of their user agents, etc. Presentities are willing to provide the description of available files at watcher's disposal. This might be the case for photographs taken with a mobile device, a recorded lecture audio file, etc. This document extends the PIDF to provide the syntax and format for the description of files within the PIDF.

Table of Contents

1.  Introduction
2.  Terminology
3.  File descriptions in PIDF
4.  Security Considerations
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators, although the current trend allows to model a number of events in the presence information.

The Presence Information Data Format (PIDF) (Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, “Presence Information Data Format (PIDF),” August 2004.) [RFC3863] defines a common presence data format for Common Profiles for Instant Messaging (CPIM) (Peterson, J., “Common Profile for Instant Messaging (CPIM),” August 2004.) [RFC3860] and Presence (CPP) (Peterson, J., “Common Profile for Presence (CPP),” August 2004.) [RFC3859].

The PIDF has been extended and adapted to work with SIP. The Data Model for Presence (Rosenberg, J., “A Data Model for Presence,” July 2006.) [RFC4479] defines the underlying presence data model used by Session Initiation Protocol (SIP) (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The presence data model structures the presence information of the PIDF in three components: the person, the service, and the device.

On the other hand, there are scenarios where a user has a number of available files stored in an endpoint. The user wants to make some of these files for public or private disposal. One of these cases is, for example, when Alice takes some pictures with her camera phone and she wants to share them within a community.

This document extends the PIDF, or more precise, it extends the device component of the presence data model, to allow the inclusion of a description of available files. A presentity who publishes presence information can include a description of one or more files that are at a watcher's disposal for its downloading.

The extension allows the publication of files that are "available" at that particular device. For example, if a user has stored a few images in his phone, and he wants to advertise them through his presence information to his watchers, he would not use the service nor the person components of the presence data model because these images are not tied to any service or person. Rather, these images are only available in the particular device that the presentity is describing in the device component of the presence data model.

This can also be seen through a multiple device scenario. Assume a user who has some images stored in his phone. He is publishing his presence information from two devices: a laptop and a phone.

The presence publication done from his phone contains a <device> component (in the PIDF) that represents the phone itself. The file descriptors of those pictures are also included in the <device> element. On the other hand, the presence publication done from his laptop will not contain those files representing the pictures, since they are not available in the laptop. Then, a presence compositor can appropriately compose the presence information to watchers, potentially signalling the two devices for the same presentity, as separated devices, one including files for pictures.

The extension defined in this document is fully compatible at the data format with the 'file' event package (Garcia-Martin, M. and M. Matuszewski, “A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Files,” June 2007.) [I‑D.garcia‑sipping‑file‑event‑package].

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119] and indicate requirement levels for compliant implementations.

3.  File descriptions in PIDF

The 'file' event package (Garcia-Martin, M. and M. Matuszewski, “A Session Initiation Protocol (SIP) Event Package and Data Format for Describing Files,” June 2007.) [I‑D.garcia‑sipping‑file‑event‑package] defines a SIP event package for subscribing to changes to a group of files. The 'file' event package uses the XML 'file-metadata' document that is specified in the XML data format for describing files (Garcia-Martin, M. and M. Matuszewski, “An Extensible Data Format (XML) for Describing Files,” November 2007.) [I‑D.garcia‑app‑area‑file‑data‑format]. We embed a 'file-metadata' XML document in the 'device' component of the presence data model because files are highly coupled with the actual devices that the user is using. Unfortunately, the XML schema does not provide the means to normatively indicate that 'file-metadata' documents can be included in the 'device' component of the presence data model that is part of a PIDF document. However, we provide the following example:

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
    xmlns:fd="urn:ietf:params:xml:ns:file"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    entity="sip:someone@example.com" >
    <tuple id="sg89ae">
     <status>
      <basic>open</basic>
     </status>
     <dm:deviceID>mac:8asd7d7d70</dm:deviceID>
     <contact>sip:someone@example.com</contact>
    </tuple>
    <dm:person id="p1">
    </dm:person>
    <dm:device id="pc122">
     <dm:deviceID>mac:8asd7d7d70</dm:deviceID>

      <fd:file-set version="123">
       <fd:file id="id38sh12jd">
        <fd:identity id="id9d8c9">
         <fd:mime-type>image/jpeg</fd:mime-type>
         <fd:size>230432</fd:size>
         <fd:sha1>72245FE8653DDAF371362F86D471913EE4A2CE2E</fd:sha1>
        <fd:identity>
        <fd:instance id="idc989c00">
         <fd:name>coolpic.jpg</fd:name>
         <fd:description>
             This is my latest cool picture from my summer vacation
         </fd:description>
         <fd:user-gruu>
           sip:miguel.garcia@example.com;
               gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
         </fd:user-gruu>
         <fd:user-aor>sip:miguel.garcia@example.com</fd:user-aor>
         <fd:creation-date>
             2006-05-09T09:30:47+03:00
         </fd:creation-date>
         <fd:modification-date>
             2006-05-09T10:24:34+03:00
         </fd:modification-date>
         <fd:read-date>
             2006-05-10T14:24:32+03:00
         </fd:read-date>
         <fd:icon-ptr>
             http://www.example.com/coolpic-icon.jpg
         </fd:icon-ptr>
         <fd:keywords>
           <fd:keyword>summer</fd:keyword>
           <fd:keyword>vacation</fd:keyword>
         </fd:keywords>
        </fd:instance>
       </fd:file>
      </fd:file-set>

    </dm:device>
   </presence>

4.  Security Considerations

TBD

5.  IANA Considerations

There are no IANA considerations associated to this memo.

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.