idnits 2.17.1 draft-garcia-sipping-file-desc-pidf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 16, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-garcia-sipping-file-event-package-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group M. Garcia-Martin 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track M. Matuszewski 5 Expires: May 19, 2008 Nokia 6 November 16, 2007 8 File Descriptions Extension to the Presence Information Data Format 9 (PIDF) 10 draft-garcia-sipping-file-desc-pidf-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 The Presence Information Data Format (PIDF) defines a basic format 44 for representing presence information for a presentity. Presentities 45 publish their presence information, typically towards presence 46 agents. PIDF has been extended to provide rich presence information, 47 including, for example, the location of the presentity, their 48 activities, mood, the capabilities of their user agents, etc. 50 Presentities are willing to provide the description of available 51 files at watcher's disposal. This might be the case for photographs 52 taken with a mobile device, a recorded lecture audio file, etc. This 53 document extends the PIDF to provide the syntax and format for the 54 description of files within the PIDF. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. File descriptions in PIDF . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction 71 Presence is defined as the willingness and ability of a user to 72 communicate with other users on the network. Historically, presence 73 has been limited to "on-line" and "off-line" indicators, although the 74 current trend allows to model a number of events in the presence 75 information. 77 The Presence Information Data Format (PIDF) [RFC3863] defines a 78 common presence data format for Common Profiles for Instant Messaging 79 (CPIM) [RFC3860] and Presence (CPP) [RFC3859]. 81 The PIDF has been extended and adapted to work with SIP. The Data 82 Model for Presence [RFC4479] defines the underlying presence data 83 model used by Session Initiation Protocol (SIP) [RFC3261] for Instant 84 Messaging and Presence Leveraging Extensions (SIMPLE) presence 85 agents. The presence data model structures the presence information 86 of the PIDF in three components: the person, the service, and the 87 device. 89 On the other hand, there are scenarios where a user has a number of 90 available files stored in an endpoint. The user wants to make some 91 of these files for public or private disposal. One of these cases 92 is, for example, when Alice takes some pictures with her camera phone 93 and she wants to share them within a community. 95 This document extends the PIDF, or more precise, it extends the 96 device component of the presence data model, to allow the inclusion 97 of a description of available files. A presentity who publishes 98 presence information can include a description of one or more files 99 that are at a watcher's disposal for its downloading. 101 The extension allows the publication of files that are "available" at 102 that particular device. For example, if a user has stored a few 103 images in his phone, and he wants to advertise them through his 104 presence information to his watchers, he would not use the service 105 nor the person components of the presence data model because these 106 images are not tied to any service or person. Rather, these images 107 are only available in the particular device that the presentity is 108 describing in the device component of the presence data model. 110 This can also be seen through a multiple device scenario. Assume a 111 user who has some images stored in his phone. He is publishing his 112 presence information from two devices: a laptop and a phone. 114 The presence publication done from his phone contains a 115 component (in the PIDF) that represents the phone itself. The file 116 descriptors of those pictures are also included in the 117 element. On the other hand, the presence publication done from his 118 laptop will not contain those files representing the pictures, since 119 they are not available in the laptop. Then, a presence compositor 120 can appropriately compose the presence information to watchers, 121 potentially signalling the two devices for the same presentity, as 122 separated devices, one including files for pictures. 124 The extension defined in this document is fully compatible at the 125 data format with the 'file' event package 126 [I-D.garcia-sipping-file-event-package]. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 133 [RFC2119] and indicate requirement levels for compliant 134 implementations. 136 3. File descriptions in PIDF 138 The 'file' event package [I-D.garcia-sipping-file-event-package] 139 defines a SIP event package for subscribing to changes to a group of 140 files. The 'file' event package uses the XML 'file-metadata' 141 document that is specified in the XML data format for describing 142 files [I-D.garcia-app-area-file-data-format]. We embed a 'file- 143 metadata' XML document in the 'device' component of the presence data 144 model because files are highly coupled with the actual devices that 145 the user is using. Unfortunately, the XML schema does not provide 146 the means to normatively indicate that 'file-metadata' documents can 147 be included in the 'device' component of the presence data model that 148 is part of a PIDF document. However, we provide the following 149 example: 151 152 157 158 159 open 160 161 mac:8asd7d7d70 162 sip:someone@example.com 164 165 166 167 168 mac:8asd7d7d70 170 171 172 173 image/jpeg 174 230432 175 72245FE8653DDAF371362F86D471913EE4A2CE2E 176 177 178 coolpic.jpg 179 180 This is my latest cool picture from my summer vacation 181 182 183 sip:miguel.garcia@example.com; 184 gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 185 186 sip:miguel.garcia@example.com 187 188 2006-05-09T09:30:47+03:00 189 190 191 2006-05-09T10:24:34+03:00 192 193 194 2006-05-10T14:24:32+03:00 195 196 197 http://www.example.com/coolpic-icon.jpg 198 199 200 summer 201 vacation 202 203 204 205 207 208 210 Figure 1: Example of file descriptions in PIDF 212 4. Security Considerations 214 TBD 216 5. IANA Considerations 218 There are no IANA considerations associated to this memo. 220 6. References 222 6.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [I-D.garcia-sipping-file-event-package] 228 Garcia-Martin, M. and M. Matuszewski, "A Session 229 Initiation Protocol (SIP) Event Package and Data Format 230 for Describing Files", 231 draft-garcia-sipping-file-event-package-00 (work in 232 progress), June 2007. 234 [I-D.garcia-app-area-file-data-format] 235 Garcia-Martin, M. and M. Matuszewski, "An Extensible Data 236 Format (XML) for Describing Files", 237 draft-garcia-app-area-file-data-format-00 (work in 238 progress), November 2007. 240 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 241 A., Peterson, J., Sparks, R., Handley, M., and E. 242 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 243 June 2002. 245 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 246 W., and J. Peterson, "Presence Information Data Format 247 (PIDF)", RFC 3863, August 2004. 249 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 250 July 2006. 252 6.2. Informative References 254 [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", 255 RFC 3859, August 2004. 257 [RFC3860] Peterson, J., "Common Profile for Instant Messaging 258 (CPIM)", RFC 3860, August 2004. 260 Authors' Addresses 262 Miguel A. Garcia-Martin 263 Nokia Siemens Networks 264 P.O.Box 22 265 Nokia Siemens Networks, FIN 02022 266 Finland 268 Email: miguel.garcia@nsn.com 270 Marcin Matuszewski 271 Nokia 272 P.O.Box 407 273 NOKIA GROUP, FIN 00045 274 Finland 276 Email: marcin.matuszewski@nokia.com 278 Full Copyright Statement 280 Copyright (C) The IETF Trust (2007). 282 This document is subject to the rights, licenses and restrictions 283 contained in BCP 78, and except as set forth therein, the authors 284 retain all their rights. 286 This document and the information contained herein are provided on an 287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 289 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 290 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 291 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Intellectual Property 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the procedures with respect to rights in RFC documents can be 303 found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Acknowledgment 320 Funding for the RFC Editor function is provided by the IETF 321 Administrative Support Activity (IASA).