idnits 2.17.1 draft-ietf-simple-presence-data-model-07.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1559. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 694: '...sion 1 UUIDs are RECOMMENDED, as they ...' RFC 2119 keyword, line 696: '...ersion 4 UUID is RECOMMENDED. This is...' RFC 2119 keyword, line 853: '... RECOMMENDED that a presence documen...' RFC 2119 keyword, line 877: '...all future presence attributes MUST be...' RFC 2119 keyword, line 993: '... specification SHOULD include and not the element. 879 Furthermore, the schemas defined here do not contain a 880 element for either the or elements. 882 3.8 Presence Document Properties 884 The overall presence document has several important properties that 885 are essential to this model. 887 Firstly, a presence document has a concrete meaning independent of 888 how it is transported, or where it is found. The semantics of a 889 document are the same regardless of whether a document is published 890 by a presence user agent to its compositor, or whether it is 891 distributed from a presence agent to watchers. There are no required 892 or implied behaviors for a recipient of a document. Rather, there 893 are well defined semantics for the document itself, and a recipient 894 of a document can take whatever actions it chooses based on those 895 semantics. 897 A corollary of this property is that presence systems are infinitely 898 composeable. A presence user agent can publish a document to its 899 presence server. That presence server can compose it with other 900 documents, and place the result in a notification to a watcher. That 901 watcher can actually be another presence agent, combining that 902 document with others it has received, and placing those results in 903 yet another notify. 905 Yet another corollary of this property is that implied behaviors in 906 reaction to the document cannot ever be assumed. For example, just 907 because a service indicates that it supports audio does not mean that 908 a watcher will offer audio in a communications attempt to that 909 service. If doing so is necessary to reach the service, this must be 910 indicated explicitly through reach information. 912 It is also important to understand that the role of the presence 913 document is to help a user make a choice amongst a set of services, 914 and furthermore, to know ahead of time with as much certainty as 915 possible whether a communications attempt will succeed or fail. 916 Success is a combination of many factors - does the watcher 917 understand the service URI? Can it act on all of the reach 918 information? Does it support a subset of the capabilities associated 919 with the service? Does the person information indicate that the user 920 is likely to answer? All of these checks should ideally be made 921 before attempting communication. 923 Because the presence document serves to help a user to choose and 924 establish communications, the presentity URI - as the index to that 925 document - represents a form of "one-number" communications. 926 Starting from this URI, all of the communications modalities and 927 their URI for a user can be discovered, and then used to invoke a 928 particular communications service. Rather than having to give out a 929 separate phone number, email address, IM address, VoIP address, and 930 so on, the presentity URI can be provided, and all of the others can 931 be learned from there. 933 4. Motivation for the Model 935 Presence is defined in [17] as the ability, willingness or desire to 936 communicate across a set of devices. The core of this definition is 937 the conveyance of information about the ability, willingness or 938 desire for communications. Thus, the presence data model needs to be 939 tailored around conveying information that achieves this goal. 941 The person data component is targeted at conveying willingness and 942 desire for communications. It is used to represent information about 943 the user themselves that affects willingness and desire to 944 communicate. Whether or not I am in a meeting, whether or not I am 945 on the phone - each of these says something about my willingness to 946 communicate, and thus makes sense for inclusion in a presence 947 document. 949 The service component of the data model aims to convey information on 950 the ability to communicate. The ability to communicate is defined by 951 the services by which a user is reachable. Thus, including them is 952 essential. 954 How do devices fit in? For many users, devices represent the ability 955 to communicate, not services. Frequently, users make statements 956 like, "call me on my cell phone" or, "I'm at my desk". These are 957 statements for preference for communications using a specific device, 958 as opposed to a service. Thus, it is our expectation that users will 959 want to represent devices as part of the presence data. 961 Furthermore, the concept of device adds the ability to correlate 962 services together. The device models the underlying platform that 963 supports all of the services on the phone. Its state therefore 964 impacts all services. For example, if a presence server can 965 determine that a cell phone is off, this says something about the 966 services that run on that device - they are all not available. Thus, 967 if services include indicators about the devices on which they run, 968 device state can be obtained and thus used to compute the state of 969 the services on the device. 971 The data model tries hard to separate device, service, and person as 972 different concepts. Part of this differentiation is that many 973 attributes will be applicable to some of these, but not others. For 974 example, geographic location is a meaningful attribute of the person 975 (the user has a location) and of a device (the device has a 976 location), but not of a service (services don't inherently have 977 locations). Based on this, geographic location information should 978 only appear as part of device or person, never service. Furthermore, 979 it is possible and meaningful for location information to be conveyed 980 for both device and person, and for these locations to be different. 982 The fact that the presence system might try to determine the location 983 of the person by extrapolation from the location of one of the 984 devices is irrelevant from a data modeling perspective. Person 985 location and device location are not the same thing. 987 [21] defines the XML element for conveying location 988 information, and indicates that it is carried as a child of the 989 element in a PIDF document. [21] was developed prior to this 990 specification, and unfortunately, its recommendation to include 991 location objects underneath runs contrary to the 992 recommendations here. As such, implementations based on this 993 specification SHOULD include location objects as part of 994 person and/or device components of the document, but SHOULD be 995 prepared to receive presence documents with that object as a child to 996 . A location object would be included in a person 997 component when the document means to convey the location of the user, 998 and within a device component when it means to convey the location of 999 the device. 1001 5. Encoding 1003 Information represented according to the data model described above 1004 needs to be mapped into an on-the-wire format for transport and 1005 storage. The Presence Information Document Format [1] is used for 1006 representation of presence data. 1008 The element contains the presence information for the 1009 presentity. The "entity" attribute of this element contains the 1010 presentity URI. 1012 The existing element in the PIDF document is used to 1013 represent the service. This is consistent with the original intent 1014 of RFC 2778 and RFC 3863, and achieves backwards compatibility with 1015 implementations developed before the model described here was 1016 complete. The element in the element is used to 1017 encode the service URI. Presence attributes representing dynamic 1018 status appear as children to the element, and attributes 1019 representing static characteristics appear directly as children of 1020 . It is not critical that a clean separation between dynamic 1021 and static information be made. It is only important that each 1022 presence attribute be specified to appear in either or 1023 . 1025 The "id" attribute of the element conveys the service 1026 occurrence. Each element with the same URI 1027 represents a different occurrence of a particular service. 1029 This specification introduces the element, which can appear 1030 as a child to . There can be zero or more occurrences of 1031 this element per document. Each one has a mandatory "id" attribute 1032 which contains the occurrence identifier for the person. Each 1033 element contains a element, which contains any 1034 number of elements containing dynamic status information. This is 1035 followed by any number of elements that indicate characteristic 1036 information. This is followed by an optional and optional 1037 . 1039 RFC 3863 defines a element which can be present as a child to 1040 . As it relates to the model defined here, this note 1041 element, if present in a document, applies to all person occurrences 1042 which do not have their own element. In other words, if a 1043 element has its own , that is the for that 1044 element. If a element does not have its own 1045 element, the element that is the direct child of is 1046 the for that . If there is no element 1047 underneath the element, and no element that is a 1048 direct child of , then that element has no . 1050 This specification also introduces the element, which can 1051 appear as a child to . There can be zero or more 1052 occurrences of this element per document. The element can 1053 appear either before or after the element; there are no 1054 constraints on order. Each element has a mandatory "id" 1055 attribute which contains the occurrence identifier for the device. 1056 Like , contains the element, which contains 1057 any number of elements containing dynamic status information, 1058 followed by any number of elements containing characteristic 1059 information. This is followed by , which contains the URN 1060 for the device ID for this device. This is followed by an optional 1061 and optional . 1063 A client that receives a PIDF document containing the and 1064 elements, but does not understand them (because it doesn't 1065 implement this specification) will ignore them. Furthermore, since 1066 the semantics of service as defined here are aligned with the meaning 1067 of a tuple as defined in RFC 2778 and RFC 3863, documents 1068 incorporating the concepts defined in this model are compliant with 1069 older implementations. 1071 It's important to note that the mapping of the presence data model 1072 into a PIDF document is merely an exercise in syntax. 1074 Presence documents created according to this model MUST be valid, 1075 with the following exception. A compositor is permitted to create a 1076 presence document which it cannot fully validate but which otherwise 1077 validates when processed according to the lax processing rules 1078 allowed by the schema of the compositor. However, it is not expected 1079 that entities receiving these documents would perform schema 1080 validation, rather, they would merely access the information from the 1081 document in the places they were expecting it to be. Implementations 1082 SHOULD be prepared to receive documents that are not valid, and 1083 extract whatever information from them that they can parse. 1085 5.1 XML Schemas 1087 The XML schemas are broken into a common schema, called common- 1088 schema.xsd, which contains common type definitions, and the rest of 1089 the data model, data-model.xsd. 1091 5.1.1 Common 1093 1094 1096 1098 1099 1100 Timestamp type 1101 1102 1103 1104 1105 1106 Device ID, a URN 1107 1108 1109 1110 1111 1112 Note type 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1127 5.1.2 Data Model 1129 1130 1134 1135 1136 1137 Device ID, a URN 1138 1139 1140 1141 1142 Contains information about the 1143 device 1144 1145 1146 1147 1149 1150 1152 1153 1154 1155 1156 1157 1158 1159 Contains information about the human 1160 user 1161 1162 1163 1164 1166 1167 Characteristic and status 1168 information 1169 1170 1171 1173 1174 1175 1176 1177 1178 1180 6. Extending the Presence Model 1182 When new presence attributes are added, any such extension has to 1183 consider the following questions: 1185 1. Is the new attribute applicable to person, service or device data 1186 components? If it is applicable to more than one, what is its 1187 meaning in each context? An extension should strive to have each 1188 attribute concisely defined for each area of applicability, so 1189 that a source can clearly determine to which type of data 1190 component it should be applied. 1192 2. Does it belong in a new namespace, or an existing one? 1193 Generally, new presence attributes defined within the same 1194 specification SHOULD belong to the same namespace. Presence 1195 attributes defined in separate specifications, but produced in a 1196 coordinated way by a centralized administration, MAY be placed in 1197 the same namespace. Doing so, however, requires the centralized 1198 administration to ensure that there are no collisions of element 1199 names across those specifications. Furthermore, if a new 1200 extension has elements meant to be placed as the children of 1201 another element at a point of extensibility defined by , the new extension MUST use a different 1203 namespace than that of its parent elements. 1205 3. Does the extension itself require extensibility? If so, points 1206 of extension MUST be defined in the schema, and SHOULD be done 1207 using the construct. 1209 7. Example Presence Document 1211 In this section, we give examples of different physical systems, 1212 present the model of that system using the concepts described here, 1213 and then show the resulting presence document. These examples make 1214 use of presence attributes defined in [19] and [20]. 1216 7.1 Basic IM Client 1218 In this scenario, a provider is offering a service very similar to 1219 the instant messaging services offered today by the public providers 1220 like AOL, Yahoo, and MSN. In this service, each user has a "screen 1221 name" that identifies them in the service. A single client, 1222 generally a PC application, connects to the service at a time. When 1223 the client connects, this fact is made available to other watchers of 1224 that user in the system. The user has the ability to set a textual 1225 note that describes what they are doing, and this note is seen by the 1226 watchers in the system. The user can set one of several status 1227 messages - such as busy, in a meeting, etc., which are pre-defined 1228 notes that the system understands. If a user does not type anything 1229 on their keyboard for some time, their status changes to idle on the 1230 screens of the various watchers of the system. The system also 1231 indicates the amount of time that the user has been idle. 1233 Whenever a user is connected to the system, they are capable of 1234 receiving instant messages. A user can set their status to 1235 "invisible", which means that they appear as offline to other users. 1236 However, if an IM is sent to them, it will still be delivered. 1238 This system is modeled by representing each presentity in the system 1239 with three data components - a person component, a service component, 1240 and a device component. The person component describes the state of 1241 the user, including the note and the pre-defined status messages. 1242 These represent information about the human user, so they are 1243 included in the person component. The service tuple represents the 1244 IM service. No characteristics are included. The service URI 1245 published by the client is set to the client's Address of Record 1246 (AOR). The device component is used to model the PC. The device 1247 component includes the element [19], since the idleness 1248 refers to usage of the device, not the service. 1250 The document published by the client would look like this: 1252 1253 1258 1259 1260 open 1261 1262 mac:8asd7d7d70 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 sip:someone@example.com 1277 1278 1279 1280 1281 1282 1283 1284 idle 1285 mac:8asd7d7d70 1286 1287 1289 It is worth commenting further on the value of having a separate 1290 device element just to convey the idle indicator. The idle 1291 indication of interest is really an indicator that the device is 1292 idle. By making that explicit, the idle indicator can be used by the 1293 presence server to affect the state of other services running on the 1294 same device. For example, let say there is a VoIP application 1295 running on the same device. This application reports its presence 1296 state separately, but indicates that it runs on the same device. 1297 Since it has indicated hat it runs on the same device, the presence 1298 server can use the status of the service to further refine the idle 1299 indicator of the device. Specifically, if the user is using their 1300 VoIP application, the presence server knows that the device is in 1301 use, even if the IM application reports that the device is idle. 1302 Typically, idleness is determined by lack of keyboard or mouse input, 1303 neither of which might be used during a VoIP call. 1305 In a more simplistic case, reporting the idle indicator as part of 1306 the device status allows that indicator to be used for other services 1307 on the same device. Taking, again, the example of the VoIP 1308 application on the same device, if the VoIP application does not 1309 report any device information, and a watcher is not provided 1310 information on the IM service, the presence document sent to the 1311 watcher can include the device status. Because of the usage of the 1312 device IDs and the device information, the presence server can 1313 correlate the device status as reported by the IM application with 1314 the VoIP service, and use them together. 1316 8. Security Considerations 1318 The presence information described by the model defined here is very 1319 sensitive. It is for this reason that privacy filtering plays a key 1320 role in the processing of presence data. Privacy filtering is the 1321 act of applying permissions to a presence document for the purposes 1322 of removing information that a watcher is not authorized to see. In 1323 more general terms, privacy filtering is a form of authorization. 1324 Privacy filtering can also ensure that a watcher cannot see any 1325 presence data for a presentity, and indeed, it can even ensure that 1326 the presentity doesn't know that it is being blocked. The SIP 1327 presence specifications (RFC 3856 [17]) require that such 1328 authorization processing be performed before divulging presence 1329 information. Specifications have also been defined for conveying 1330 authorization policies to presence servers [22]. 1332 Integrity of presence information is also critical. Modification of 1333 presence data by an attacker can lead to diverted communications, for 1334 example. Protocols used to transport presence data, such as SIP for 1335 presence, are used to provide necessary integrity functions. 1337 9. Internationalization Considerations 1339 This specification defines a data model which contains mostly tokens 1340 that are meant for consumption by programs, not directly by humans. 1341 Programs are expected to translate those tokens into language- 1342 appropriate text strings according to the preferences of the watcher. 1344 However, this specification defines a element that can contain 1345 free text. This element, and other ones defined by extensions to 1346 PIDF which can contain free text SHOULD be labeled with the 'xml: 1348 lang' attribute to indicate their language and script. This 1349 specification allows multiple occurrences of the element so 1350 that the presentity can convey the note in multiple scripts and 1351 languages. If no 'xml:lang' attribute is provided, the default value 1352 is "i-default" [5]. 1354 Since the presence model is represented in XML, it provides native 1355 support for encoding information using the Unicode character set and 1356 its more compact representations including UTF-8. Conformant XML 1357 processors recognize both UTF-8 and UTF-16. Though XML includes 1358 provisions to identify and use other character encodings through use 1359 of an "encoding" attribute in an declaration, use of UTF-8 is 1360 RECOMMENDED in environments where parser encoding support 1361 incompatibility exists. 1363 10. IANA Considerations 1365 There are several IANA considerations associated with this 1366 specification. 1368 10.1 URN Sub-Namespace Registration 1370 This section registers a new XML namespace, per the guidelines in [4] 1372 URI: The URI for this namespace is 1373 urn:ietf:params:xml:ns:pidf:data-model. 1375 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1376 Jonathan Rosenberg (jdrosen@jdrosen.net). 1378 XML: 1380 BEGIN 1381 1382 1384 1385 1386 1388 Presence Data Model Namespace 1389 1390 1391

Namespace for Presence Data Model

1392

urn:ietf:params:xml:ns:pidf:data-model

1393

See RFCXXXX.

1394 1395 1396 END 1398 10.2 XML Schema Registrations 1400 This section registers two XML schemas per the procedures in [4]. 1402 10.2.1 Data Model 1404 URI: urn:ietf:params:xml:schema:pidf:data-model. 1406 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1407 Jonathan Rosenberg (jdrosen@jdrosen.net). 1409 The XML for this schema can be found as the sole content of 1410 Section 5.1.2. 1412 10.2.2 Common Schema 1414 URI: urn:ietf:params:xml:schema:pidf:common-schema. 1416 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 1417 Jonathan Rosenberg (jdrosen@jdrosen.net). 1419 The XML for this schema can be found as the sole content of 1420 Section 5.1.1. 1422 11. Acknowledgements 1424 This document is really a distillation of many ideas discussed over a 1425 long period of time. These ideas were contributed by many different 1426 participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat, 1427 Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam 1428 Roach, Hisham Khartabil, and Jon Peterson contributed many of the 1429 concepts that are described here. Example presence documents came 1430 from Robert Sparks' example presence documents specification, and 1431 ideas on defining services through characteristics, rather than 1432 enumeration, come from Adam Roach's service features draft. A 1433 special thanks to Steve Donovan for discussions on the topics 1434 discussed here, and to Elwyn Davies for his final review of the 1435 document. 1437 12. References 1438 12.1 Normative References 1440 [1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and 1441 J. Peterson, "Presence Information Data Format (PIDF)", 1442 RFC 3863, August 2004. 1444 [2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 1445 Preferences for the Session Initiation Protocol (SIP)", 1446 RFC 3841, August 2004. 1448 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1449 Specifications: ABNF", RFC 2234, November 1997. 1451 [4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1452 January 2004. 1454 [5] Alvestrand, H., "IETF Policy on Character Sets and Languages", 1455 BCP 18, RFC 2277, January 1998. 1457 12.2 Informative References 1459 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 1460 and Instant Messaging", RFC 2778, February 2000. 1462 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1463 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1464 Session Initiation Protocol", RFC 3261, June 2002. 1466 [8] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, 1467 August 2004. 1469 [9] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) 1470 and Uniform Resource Identifiers (URIs) for the Extensible 1471 Messaging and Presence Protocol (XMPP)", 1472 draft-saintandre-xmpp-iri-02 (work in progress), 1473 September 2005. 1475 [10] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message 1476 Service", draft-wilde-sms-uri-10 (work in progress), 1477 August 2005. 1479 [11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 1480 December 2004. 1482 [12] Klyne, G., "A Syntax for Describing Media Feature Sets", 1483 RFC 2533, March 1999. 1485 [13] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating 1486 User Agent Capabilities in the Session Initiation Protocol 1487 (SIP)", RFC 3840, August 2004. 1489 [14] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 1490 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 1491 Application (ENUM)", RFC 3761, April 2004. 1493 [15] Rosenberg, J., "The Session Initiation Protocol (SIP) and 1494 Spam", draft-ietf-sipping-spam-01 (work in progress), 1495 July 2005. 1497 [16] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 1498 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 1500 [17] Rosenberg, J., "A Presence Event Package for the Session 1501 Initiation Protocol (SIP)", RFC 3856, August 2004. 1503 [18] Rosenberg, J., "Obtaining and Using Globally Routable User 1504 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 1505 (SIP)", draft-ietf-sip-gruu-05 (work in progress), 1506 September 2005. 1508 [19] Schulzrinne, H., "RPID: Rich Presence Extensions to the 1509 Presence Information Data Format (PIDF)", 1510 draft-ietf-simple-rpid-09 (work in progress), September 2005. 1512 [20] Lonnfors, M. and K. Kiss, "User Agent Capability Extension to 1513 Presence Information Data Format (PIDF)", 1514 draft-ietf-simple-prescaps-ext-04 (work in progress), 1515 June 2005. 1517 [21] Peterson, J., "A Presence-based GEOPRIV Location Object 1518 Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), 1519 September 2004. 1521 [22] Rosenberg, J., "Presence Authorization Rules", 1522 draft-ietf-simple-presence-rules-03 (work in progress), 1523 July 2005. 1525 Author's Address 1527 Jonathan Rosenberg 1528 Cisco Systems 1529 600 Lanidex Plaza 1530 Parsippany, NJ 07054 1531 US 1533 Phone: +1 973 952-5000 1534 Email: jdrosen@cisco.com 1535 URI: http://www.jdrosen.net 1537 Intellectual Property Statement 1539 The IETF takes no position regarding the validity or scope of any 1540 Intellectual Property Rights or other rights that might be claimed to 1541 pertain to the implementation or use of the technology described in 1542 this document or the extent to which any license under such rights 1543 might or might not be available; nor does it represent that it has 1544 made any independent effort to identify any such rights. Information 1545 on the procedures with respect to rights in RFC documents can be 1546 found in BCP 78 and BCP 79. 1548 Copies of IPR disclosures made to the IETF Secretariat and any 1549 assurances of licenses to be made available, or the result of an 1550 attempt made to obtain a general license or permission for the use of 1551 such proprietary rights by implementers or users of this 1552 specification can be obtained from the IETF on-line IPR repository at 1553 http://www.ietf.org/ipr. 1555 The IETF invites any interested party to bring to its attention any 1556 copyrights, patents or patent applications, or other proprietary 1557 rights that may cover technology that may be required to implement 1558 this standard. Please address the information to the IETF at 1559 ietf-ipr@ietf.org. 1561 Disclaimer of Validity 1563 This document and the information contained herein are provided on an 1564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1571 Copyright Statement 1573 Copyright (C) The Internet Society (2006). This document is subject 1574 to the rights, licenses and restrictions contained in BCP 78, and 1575 except as set forth therein, the authors retain all their rights. 1577 Acknowledgment 1579 Funding for the RFC Editor function is currently provided by the 1580 Internet Society.