idnits 2.17.00 (12 Aug 2021) /tmp/idnits23613/draft-boehmer-simple-service-identification-00.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 16) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 18, 2004) is 6417 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: draft-ietf-simple-rpid has been published as RFC 4480 -- Possible downref: Non-RFC (?) normative reference: ref. 'UDDI' == Outdated reference: draft-ietf-simple-prescaps-ext has been published as RFC 5196 == Outdated reference: draft-ietf-simple-presence-data-model has been published as RFC 4479 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE B. Boehmer 2 Internet-Draft H. Tschofenig 3 Expires: April 18, 2005 Siemens 4 October 18, 2004 6 Service Identification 7 draft-boehmer-simple-service-identification-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 18, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 This document discusses the aspect of service identification in 43 presence documents. A solution is proposed which extends RPID by 44 utilizing the tModel service description provided by the Universal 45 Description, Discovery and Integration (UDDI) framework. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Discussion of possible Approaches . . . . . . . . . . . . . . 5 52 3.1 Deduction of Services . . . . . . . . . . . . . . . . . . 5 53 3.2 Enumeration of Services . . . . . . . . . . . . . . . . . 5 54 4. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 9. IPR Considerations with UDDI . . . . . . . . . . . . . . . . . 13 60 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14 61 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 63 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 64 12.2 Informative References . . . . . . . . . . . . . . . . . . . 16 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 66 Intellectual Property and Copyright Statements . . . . . . . . 18 68 1. Introduction 70 A lot of discussion [SIMPLE WG discussion] took place around the 71 identification of services with regard to the definition of the 72 presence data model [I-D.ietf-simple-presence-data-model] in the 73 SIMPLE WG. 75 An important concept is the requirement to inform a watcher about the 76 communication means of a presentity. This can be either "simple" 77 voice communication or may be based upon a highly complex 78 voice/-video interaction with a computer game. Providing this 79 information to the watcher allows him or her to make an appropriate 80 decision about the communication means to be used. Furthermore, 81 beside the communication aspect, certain services may maintain a rich 82 set of internal states being of interest for certain watchers, e.g. 83 high scores in games, entering of a certain person on a chat room, 84 etc. Thus, services may act as differentiated presence sources on 85 their own and, therefore, a means to represent this service and its 86 states is a relevant requirement. 88 Identification of services is, however, a highly non-trivial issue 89 due to a number of reasons. Many of them being already mentiond in 90 mailing list dicussions in the SIMPLE working group: 91 o A vast amount of services exists. In general, they are of more or 92 less proprietary character. This fact must be taken into account 93 as soon as services are considered. Especially, services may use 94 proprietary protocols or proprietary extensions of standardized 95 protocols. 96 o Services exist in different versions which generally do fully not 97 interwork. 98 o Standardization of services is too slow and will be therefore only 99 done for a small subset of services. For the IETF, this task is 100 even not on the agenda. 102 This document proposes an approach to service description based on 103 the UDDI framework. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Discussion of possible Approaches 113 [I-D.roach-simple-service-features] discusses two basic approaches to 114 deal with this issue. Either an enumeration of services should be 115 provided or services are deduced from low-level capabilities or 116 external information. 118 3.1 Deduction of Services 120 This approach assumes that a service may be derived from a set of 121 low-level attributes. Most important attributes discussed are: 122 o URI scheme, e.g. pres:, sip:, im:, etc. 123 o set of supported SIP methods 124 o capabilities listed in [RFC3840] and 125 [I-D.ietf-simple-prescaps-ext]. 127 This proposal has been discussed extensively in the SIMPLE WG [SIMPLE 128 WG discussion]. This approach has certain limitations we summarize 129 here: 130 1. There does not exist a unique URI scheme for each service. It is 131 even questionable whether such an approach would be feasible 132 since the routing network must each time be adapted to this new 133 URI scheme. 134 2. Proprietary services using an existing URI scheme cannot be 135 distinguished from standardized ones. The granularity of URI 136 schemes cannot be made fine enough to allow such distinction. 137 3. URI schemes may subsume more than one service, see the SIMPLE WG 138 mailing list discussions [SIMPLE WG discussion]. 139 4. Describing services based on a finite list of capabilities 140 implies already a certain degree of service standardization since 141 every service using more than those capabilities would obscure 142 this kind of service description. 143 5. Even in case of identical URI scheme, used protocol methods, and 144 codecs there might exist differences in behavior. This can only 145 be documented by additional specifications. 146 6. A given service may be realized in different manners. A typical 147 example are the IM and Presence services both being at least 148 implemented by the SIP/SIMPLE standard and the Wireless 149 Village/OMA IMPS standard. Thus, enlisting of SIP UA 150 capabilities is not sufficient to describe a given service. 151 7. Exchanging the set of capabilities increases the size of the 152 presence document. Especially for the wireless world this may 153 become an issue. 155 3.2 Enumeration of Services 157 The current discussion around the enumeration of services implies 158 that each service has a unique ID assigned to. This approach has 159 also some drawbacks: 160 1. Identifying a service by a unique ID in a pidf-extension requires 161 some kind of service standardization. It might be difficult to 162 address proprietary solutions and new services quickly. 163 2. Each combination of service capabilities leads to a new variant 164 of the service. Assigning a service ID to each of these variants 165 would lead to a combinatorial increase of service IDs. Thus, 166 defining a fixed set of service ID is not possible or difficult 167 to maintain. 168 3. Using the name of the service or, generally, proprietary 169 assignments of service IDs will prevent interworking between 170 technically equally services due to the different name space 171 used. 173 4. Proposal 175 This document proposes a solution combining aspects of both 176 approaches summarized in Section 3. Main idea is the introduction of 177 a unique reference to a service description. The reference is 178 generated at service development time by an appropriate entity. The 179 service description can be provided by a standardization body or as 180 proprietary solution by anybody. This combines the advantages of the 181 deduction of services (a complete description is provided via the 182 reference) and the enumeration of services in an easily extensible 183 solution. 185 As a basis, we rely on the Universal Description & Integration (UDDI) 186 infrastructure as defined in [UDDI]. The focus of UDDI is the 187 definition of a framework supporting the description and discovery of 188 1. businesses, organizations, and other services providers, 189 2. the services they are publishing, 190 3. the technical interface which may be used to access those 191 services. 192 Note that UDDI encompasses any kind of services and not Web Services 193 only. 195 The solution proposal introduces an extension to the presence 196 document providing a reference to a service description. This 197 description is a tModel as defined by [UDDI]. It is part of a 198 service description and MUST be registered with a public UDDI 199 registry such as uddi.microsoft.com or uddi.ibm.com. It may be 200 either maintained by a standardization body in charge of the service 201 specification or a company providing a proprietary service solution. 203 It introduces a new status element "serviceDescription" to the tuple 204 definition in [I-D.ietf-simple-rpid]. This serviceDescription is a 205 complex type and consists of three elements: a element, a 206 element and an optional element. is 207 an element containing a tModel key of the tModel describing the 208 service. The tModel key MUST follow the encoding rules given in 209 [UDDI] and MUST have the same value as the UDDI tModel attribute 210 "tModelKey" registered with at the UDDI registry. contains 211 the name of the service. It MUST be the same as given in the "name" 212 element of the UDDI tModel structure stored in the UDDI registry. 213 contains a short description of the service. It SHOULD 214 be the same as the description used in the UDDI "description" 215 element. 217 5. Discussion 219 The given proposal addresses some of the issues of service 220 description. 222 The presence document contains not the complete description but only 223 a reference to a full description. The presence document remains 224 light. By using the UDDI tModel approach an established solution can 225 be reused. 227 The services have a unique identifier. This is ensured by the tModel 228 key which is unique by specification and ensured by the UDDI 229 registries. 231 The technical description of services can be done thoroughly in the 232 overview document. Not only protocol message details but any kind of 233 additional information such as behavior of the service, codecs, 234 internal states (if needed as presence information) may be described 235 here. 237 The UDDI framework allows a flexible and - if needed - automated 238 management of service descriptions. This allows to deal with the 239 assumed strong dynamics in the (application) service area. Reuse of 240 this functionality seems appropriate. 242 Eventually (see the open issues section) the categorization scheme of 243 UDDI may allow the management of variants of one service. Each 244 variant can have its own tModel key but is maintained as variant of 245 the same basic service. This can also include proprietary variants. 247 6. Example 249 The sample XML document is based on the RPID extension 250 [I-D.ietf-simple-rpid]. The service status is set to "open" and an 251 appropriate icon is provided via . The service "foo 252 service" is described in a tModel which is identified by the 253 . 255 256 264 265 266 open 267 public 268 269 270 http://www.example.com/fooService/statusActive.gif 271 272 273 sip 274 sip:someone@example.com 275 2001-10-27T16:49:29Z 276 277 278 279 uuid:c8aea832-3faf-33c6-b32a-bbfd1b656294 280 281 282 example.com:fooService 283 284 285 The foo Service doing some nice things. 286 287 288 289 290 292 A sample tModel is given below: 294 295 example.com:fooService 296 The foo Service doing some nice things. 297 298 299 http://www.example.com/theFooService.htm 300 301 302 304 7. XML Schema 306 The schema definition relies on the RPID schema specified in 307 [I-D.ietf-simple-rpid]. The additions defined by this document are 308 identified. 310 311 318 319 322 323 324 Describes RPID tuple extensions for PIDF. 325 326 328 330 332 333 334 335 336 337 338 340 341 342 343 344 346 8. Security Considerations 348 TBD 350 9. IPR Considerations with UDDI 352 In the context of UDDI IPR statements exit. For further information 353 see the Intellectual Property Rights section at the UDDI Spec TC web 354 page [UDDI-IPR]. 356 10. Open Issues 358 It is an open issue whether the categorization scheme of UDDI can be 359 used to manage services and their variations. Such a categorization 360 could be used to manage variants of a service. Eventually, some 361 standardization work for the categoization has to be done. 363 This draft does not address how service-specific state is published 364 in presence documents. However, the presented approach could be 365 extended by adding presence states into the overview document 366 referenced by the tModel. 368 11. Acknowledgments 370 The authors would like to thank Christian Schmidt and Stefan Goeman 371 for their input to this draft. 373 12. References 375 12.1 Normative References 377 [I-D.ietf-simple-rpid] 378 Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. 379 Rosenberg, "RPID: Rich Presence: Extensions to the 380 Presence Information Data Format (PIDF)", 381 draft-ietf-simple-rpid-03 (work in progress), March 2004. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", March 1997. 386 [UDDI] Bellwood, T., Claement, L. and C. von Riegen, "UDDI 387 Version 3.0.1, UDDI Spec Technical Committee 388 Specification, Dated 20031014", October 2003. 390 12.2 Informative References 392 [I-D.ietf-simple-prescaps-ext] 393 Lonnfors, M. and K. Kiss, "User agent capability presence 394 status extension", draft-ietf-simple-prescaps-ext-01 (work 395 in progress), May 2004. 397 [I-D.ietf-simple-presence-data-model] 398 Rosenberg, J., "A Data Model for Presence", 399 draft-ietf-simple-presence-data-model-00 (work in 400 progress), September 2004. 402 [I-D.roach-simple-service-features] 403 Roach, A., "Identification of Services in RPID (Rich 404 Presence Information Data)", 405 draft-roach-simple-service-features-00 (work in progress), 406 February 2004. 408 [RFC3840] Schulzrinne, H., Rosenberg, J. and P. Kyzivat, "Indicating 409 User Agent Capabilities in the Session Initiation 410 Protocol (SIP)", RFC 3840, August 2004. 412 [SIMPLE WG discussion] 413 SIMPLE WG, "SIMPLE WG discussion on service 414 identification", mail thread, September 2004. 416 [UDDI-IPR] 417 "OASIS UDDI Specification TC, IPR disclosure page". 419 Authors' Addresses 421 Bernhard Boehmer 422 Siemens 423 Siemensdamm 50 424 Berlin, Berlin 13629 425 Germany 427 EMail: bernhard.boehmer@siemens.com 429 Hannes Tschofenig 430 Siemens 431 Otto-Hahn-Ring 6 432 Munich, Bayern 81730 433 Germany 435 EMail: hannes.tschofenig@siemens.com 437 Intellectual Property Statement 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Disclaimer of Validity 463 This document and the information contained herein are provided on an 464 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 465 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 466 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 467 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Copyright Statement 473 Copyright (C) The Internet Society (2004). This document is subject 474 to the rights, licenses and restrictions contained in BCP 78, and 475 except as set forth therein, the authors retain all their rights. 477 Acknowledgment 479 Funding for the RFC Editor function is currently provided by the 480 Internet Society.