idnits 2.17.1 draft-ietf-acap-authid-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances 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 == Line 525 has weird spacing: '...te that refer...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 2002) is 7983 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1808 (ref. 'REL-URL') (Obsoleted by RFC 3986) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hole 3 Internet Draft: ACAP Authid Dataset Classes A. Melnikov 4 ACI WorldWide/MessagingDirect 5 Document: draft-ietf-acap-authid-03.txt June 2002 6 Expires in 6 months 8 ACAP Authorization Identifier Dataset Classes 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 29 The list of Internet-Draft Shadow Directories can be accessed at 30 . 32 A version of this draft document is intended for submission to the 33 RFC editor as a Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested. This 35 document will expire six months after publication. Distribution of 36 this draft is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society 2002. All Rights Reserved. 42 0. Administrivia 44 0.1. Open Issues 45 1) The calculation for resolving to a unique list of users from a set 46 of group references might need some discussion. 48 2) There is an unconsistency between userid.memberof and the group 49 entry syntax. userid.memberof uses relativeURL syntax, that coin- 50 cides with entry-path syntax. It is desirable to use the same syn- 51 tax for groupid-entry-ref/userid-entry-ref. However the syntax for 52 "entry" attribute doesn't allow slashes, so groupid-entry-ref and 53 and userid-entry-ref use "groupid." and "userid." as prefixes. 54 Suggestions are welcome. 56 0.2. Changes from revision 00 58 1) Added a glossary of terms section at the beginning. 60 2) Changed the group.members attribute of a groupid entry from a mul- 61 tivalued attribute to a subdataset attribute. This is to address 62 the scaling issues of very large groups, insertion and deletion. 63 Each entry in the subdataset refers to a member -- either a userid 64 or groupid. The namespace for userid and groupid is separated by 65 prefixing all userid member references with the "userid." prefix 66 string, and all groupid member references are prefixed with a 67 "groupid." string. 69 3) Punted on the issue of recursive or circular group references. It 70 is up to the agent using the group information to do spanning tree 71 calculations and/or set reductions to arrive at a unique membership 72 list. This MAY include the ACAP server itself if it uses the 73 authid dataset classes for authorization information. 75 0.3. Changes from revision 01 77 1) Some attributes were missing text whether they are single valued or 78 multi valued 80 2) Fixed typo in ACL definition. Fixed attribute names to conform to 81 ACAP spec. 83 3) Corrected userid.whitepage-info definition - relativeURL was used 84 instead of URL 86 4) Added text explaining that fully qualified userids/groupids must be 87 used in ACLs. 89 5) Added example 91 6) Added capability registration forms. Updated address and copyright 92 information. Some other minor editorial changes. 94 1. Introduction 96 Most distributed (client/server) applications require an authenti- 97 cation process between the client and the server before the server 98 will grant access to its managed resources. Many applications pro- 99 vide varying levels of access to server resources based on a combi- 100 nation of authentication credentials and access control rules. 101 The collection of information used to control access to resources 102 is called "authorization information". 104 The authorization identifer datasets contain lists of users and 105 groups of users that can be used by applications for authorization 106 purposes. Access control mechanisms can be abstracted from under- 107 lying authentication mechanisms and credential formats. They can 108 be extended to include group memberships in dynamic calculations 109 for access rights to resources or in definition of one time autho- 110 rization certificates. 112 The Application Configuration Access Protocol (ACAP) supports the 113 remote storage and access of many types of structured configuration 114 information. The authorization identifier datasets specification 115 describes the "userid" and "groupid" datasets which contain the 116 authorization information. It also describes ACAP server capabili- 117 ties that advertise a server's support for authorization user and 118 group semantics. 120 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 122 in this document are to be interpreted as described in [KEYWORD]. 124 The attribute syntax specifications use the Augmented Backus-Naur 125 Form (ABNF) notation as specified in [ABNF]. 127 3. Definition of Terms 129 Historically, different operating and network systems have used 130 authentication and authorization terminology interchangeably. They 131 often did not distinguish between authentication and authorization, 132 binding both into a single process. Terms like "userid", "user- 133 name", "login", "access" and others are used and mean somewhat dif- 134 ferent things in different systems. 136 Following is an introductory glossary of the terminology used by 137 this specification. The terminology is defined specifically for 138 Internet client/server applications, although the terminology could 139 be applied to any application. It reuses some historical terms, 140 but defines each with a specific role, scope and usage. 142 3.1. Authentication and authorization model 144 Granting access to server resources in a client/server application 145 is a two step process. Step 1 is called "authentication", Step 2 146 is "authorization". Step 1 is performed once per session and 147 establishes the identity of the individual that desires to access 148 server resources. Step 2 may be executed many times as access 149 rights for the authenticated client are calculated for different 150 resources managed by the server. 152 In the ACAP model, authentication information is held independently 153 of and bound to authorization information using the ACAP authoriza- 154 tion identifiers. 156 3.2. Glossary of Terms 158 authid 160 The "authentication identifier" used to uniquely identify the indi- 161 vidual connecting to a service. The syntax and semantics of 162 authids are specific to a particular authentication mechanism, net- 163 work, and/or host operating system. 165 userid 167 The "authorization user identifier" used to identify an individual 168 that a service will grant access rights to for its managed 169 resources. The syntax and semantics of ACAP userids are applica- 170 tion independent. 172 groupid 174 The "authorization group identifier" used to identify a set of 175 individuals and/or groups that a service will grant access rights 176 to for its managed resources. The syntax and semantics of ACAP 177 groupids are application independent. 179 rights 181 The type of access that an individual is granted to a resource. 182 The specific rights that can be granted to a resource is applica- 183 tion specific. 185 ACL 187 An "access control list" is a set of rules that binds an authoriza- 188 tion id (userid, groupid) to a set of rights. The form and con- 189 tent of ACLs are application specific. 191 authentication 193 The negotiation between a client and server application that unam- 194 biguously establishes the identity of the client and server par- 195 ties. 197 authorization 199 The calculation performed by the server to grant access rights to a 200 resource for an authenticated client. 202 4. Authorization user identifiers 204 An ACAP "userid" (user identifier) is an abstraction for an indi- 205 vidual user that accesses server resources -- an authorization 206 user. Typically, this is a person acting as him or herself, a per- 207 son acting in a role, or an application process. Access rights to 208 server resources can be granted or denied to a userid. 210 Authentication information is tied to a userid by an authentication 211 mechanism specific "authid" (authentication identifier). More than 212 one authid can be associated with a single userid. 214 Userids can be listed and displayed by a client without giving away 215 critical information on authentication information -- specifically 216 lists of authids. Using ACAP access control lists, the authids 217 tied to a userid MAY be searched by a client but SHOULD NOT be 218 retrievable by a client. 220 4.1. ACAP userid dataset class 222 Datasets whose names begin with "/userid/" contain "userid" entries 223 as defined in this specification. If present, an ACAP server 224 SHOULD calculate access rights for its own information resources 225 using the authorization information in this dataset. 227 4.2. Userid entry attributes 229 A "userid" entry defines an authorization user for an application. 230 It is used by the application to grant or deny access to applica- 231 tion resources. An application supporting ACAP "USER" authoriza- 232 tion semantics (as defined in section 5.) binds userids to its 233 resource access control rules. Resource access rights are calcu- 234 lated by applying, in an application specific way, the access con- 235 trol rules that are bound to the current user's userid. 237 4.2.1. Mandatory userid attributes 239 entry 241 The "entry" attribute MUST be defined for a userid entry. It's 242 value is a userid. The "entry" attribute is used by applications to 243 calculate access rights to server resources. This SHOULD include 244 the ACAP server itself. The syntax for the "entry" attribute is 245 defined in [ACAP]. 247 userid.authid 249 The "userid.authid" attribute MUST be defined for userid entry. It 250 MAY be multivalued. It contains a list of authentication mechanism 251 specific authentication identifiers that bind to this userid. 253 userid.authid ::= 1*TEXT_UTF8_CHAR 254 ;; multi-valued 256 4.2.2. Optional userid attributes 258 userid.displayname 260 The "userid.displayname" attribute MAY be defined for a userid 261 entry. It MUST be single valued. It contains a name string which 262 is suitable for presentation by an ACAP client. If present in a 263 userid entry, clients SHOULD present this value to the user rather 264 than the value of the "entry" attribute. It is assumed to contain 265 a more descriptive label for the user than the userid itself, e.g. 266 the user's full name. 268 userid.displayname ::= 1*TEXT_UTF8_CHAR 270 userid.description 272 The "userid.description" attribute MAY be defined for a userid 273 entry. It MUST be single valued. The value contains text that 274 provides an extended description of the user. This information can 275 be presented to a user to assist them in disambiguating userid 276 entries with similar (or identical) "userid.displayname" attribute 277 values. 279 userid.description ::= 1*TEXT_UTF8_CHAR 281 userid.whitepage-info 283 The "userid.whitepage-info" attribute MAY be defined for a userid 284 entry. It MAY be multivalued. The value contains one or more 285 URL's that reference whitepages information for the user. There 286 are no restrictions on the type of the URL, but it is most likely 287 that the URL will be either an ACAP URL pointing to an addressbook 288 dataset class entry or an LDAP URL pointing to a person entry. 289 This information can be presented to a user to assist them in dis- 290 ambiguating userid entries with similar (or identical) "userid.dis- 291 playname" attribute values. 293 userid.whitepage-info ::= URL 294 ;; as defined in [REL-URL] 295 ;; ACAP relative URL is defined in [ACAP] 297 userid.memberof 299 The "userid.memberof" attribute MUST be defined for an entry if the 300 server supports the ACAP "GROUP" authorization semantics. It MAY be 301 multivalued. The value of the attribute is the list of groupids 302 that the userid is a member of. It is provided as an optimization 303 convenience to the client in the presence of group authorization 304 semantics as defined in section 5. The value is readonly and MUST 305 be calculated by the server. 307 userid.memberof ::= relativeURL 308 ;; as defined in [REL-URL] 309 ;; ACAP relative URL is defined in [ACAP] 311 5. Authorization group identifiers 313 An ACAP "groupid" (group identifier) is an abstraction for a set of 314 users that access server resources -- an authorization group. A 315 groupid entry contains a list of userids that are members of the 316 group. Access rights to server resources can be granted or denied 317 to a groupid. 319 5.1. ACAP groupid dataset class 321 Datasets whose names begin with "/groupid/" are assumed to contain 322 groupid entries as defined in this specification. If present, an 323 ACAP server SHOULD support group authorization semantics defined in 324 section 5. 326 5.2. Groupid entry attributes 328 A "groupid" entry defines an authorization group for an applica- 329 tion. It is used by an application to grant or deny access to 330 application resources. An application supporting ACAP "GROUP" 331 authorization semantics (as defined in section 5.) binds groupids 332 to its resource access control rules. Resource access rights are 333 calculated by applying, in an application specific way, the access 334 control rules that are bound to the groupids that the current 335 user's userid is a member of. 337 Each "groupid" entry is a subdataset entry. Each entry in the 338 subdataset is called a "member" and references either a userid or 339 another groupid entry. 341 5.2.1. Mandatory groupid attributes 343 entry 345 The "entry" attribute MUST be defined for a groupid entry. Its 346 value is a groupid and it is used by applications to calculate 347 access rights to server resources. This SHOULD include the ACAP 348 server itself. The syntax for the "entry" attribute is defined in 349 [ACAP]. 351 subdataset 353 The "subdataset" attribute MUST be defined for a groupid entry. 354 Its value is a relative URL pointing to a dataset whose entries are 355 the members of the group. The syntax for the "subdataset" 356 attribute is defined in [ACAP]. 358 5.2.2. Optional groupid attributes 360 groupid.name 362 The "groupid.name" attribute MAY be defined for a groupid entry. 363 It MUST be single valued. It contains a name string which is suit- 364 able for presentation by an ACAP client. If present in a groupid 365 entry, clients SHOULD present this value to the user rather than 366 the value of the "entry" attribute. It is assumed to contain a 367 more descriptive label for the group than the groupid itself, e.g. 368 the group's organizational title. 370 groupid.name ::= 1*TEXT_UTF8_CHAR 372 groupid.description 374 The "groupid.description" attribute MAY be defined for a groupid 375 entry. It MUST be single valued. The value contains text that 376 describes the group. 378 groupid.description ::= 1*TEXT_UTF8_CHAR 380 5.3. Group member entry attributes 382 An ACAP group is a subdataset whose entries enumerate the member- 383 ship of the group. Each entry references a user entry in the 384 "/userid" dataset class, or a group entry in the "/groupid" dataset 385 class. 387 5.3.1. Mandatory member entry attributes 389 entry 391 The "entry" attribute MUST be defined for a member entry. In addi- 392 tion to the restrictions placed on "entry" by [ACAP], a member 393 entry is constrained to be of the form "userid." or 394 "groupid.", where "" is a userid entry defined in 395 the "/userid" dataset and "" is a groupid entry defined in 396 the "/groupid" dataset. The formal syntax for a member entry name 397 is: 399 groupid.member = userid-entry-ref / groupid-entry-ref 401 groupid-entry-ref = "groupid." entry-name 402 ;; entry-name refers to an entry in the 403 ;; "/groupid" dataset 405 userid-entry-ref = "userid." entry-name 406 ;; entry-name refers to an entry in the 407 ;; "/userid" dataset 409 Note that there are no restrictions on the membership of a group. 410 In particular a group may include itself as a member. Elimination 411 of recursive references to groups MUST be performed by the agent 412 responsible for calculating group membership attributes like that 413 defined in section 4.2.2, or by agents that use group information 414 in rights calculations. 416 6. ACAP authorization 418 The ACAP authorization information can be used by any application, 419 including the ACAP server itself. The following sections describe 420 the use of the authorization identifier datasets by an ACAP appli- 421 cation (client or server) itself. 423 Other applications are assumed to provide their own definitions for 424 use of ACAP authorization information. Specifically, they are 425 expected to define how they notify clients that their access con- 426 trol mechanisms make use of ACAP authorization information 427 datasets. 429 6.1. Userid access semantics 431 If an ACAP server supports the "/userid" dataset, then it SHOULD 432 use the authorization information provided by it for access control 433 purposes. After successful authentication to the ACAP server, an 434 authorization userid should be selected as the "current user" for 435 the ACAP server, either using the authid mapping information in the 436 userid entries, or using explicit userid information supported by 437 the authentication mechanism. ACAP ACL's are based on userids 438 rather than authids. Resource access rights are calculated rela- 439 tive to the current userid. 441 6.1.1. ACAP "USER" capability 443 If an ACAP server supports the "/userid" dataset and userid autho- 444 rization semantics, then it MUST express the "USER" capability in 445 an ACAP capability response. The "USER" capability informs an 446 ACAP client that it MUST use the "/userid" dataset contents for any 447 ACL management on the server. Fully qualified userids in the form 448 of userid-entry-ref (Section 5.3.1) MUST be used in ACLs. If a 449 server does not express the "USER" capability, then the client will 450 assume that the server uses authid information in ACL's. 452 USER capability registration can be found below: 454 To: iana@iana.org 455 Subject: Registration of ACAP capability 457 Capability name: 458 USER 460 Capability keyword: 461 USER 463 Capability arguments: 464 None 466 Published Specification(s): 467 This document 469 Person and email address to contact for further information: 470 See Authors' Addresses section of this document 472 6.2. Group access semantics 474 If an ACAP server supports the "/groupid" dataset, then it SHOULD 475 use the authentication information in it. ACAP ACL's can include 476 groupids in the ACL. Resource access rights are calculated rela- 477 tive to the current userid, and all groups that the current userid 478 is a member of. 480 6.2.1. ACAP "GROUP" capability 482 If an ACAP server supports the "/groupid" dataset and userid autho- 483 rization semantics, then it MUST express the "GROUP" capability in 484 an ACAP capability response. The "GROUP" capability informs an 485 ACAP client that it MUST use the "/groupid" dataset contents for 486 any ACL management on the server. Fully qualified groupids in the 487 form of groupid-entry-ref (Section 5.3.1) MUST be used in ACLs. If 488 a server does not express the "GROUP" capability, then the client 489 will assume that the server does not support group semantics, and 490 should not present group information in ACAP ACL management func- 491 tions. 493 In addition, the server MUST support calculation of the 494 "userid.memberof" attribute in the "/userid" dataset class entries. 496 GROUP capability registration can be found below: 498 To: iana@iana.org 499 Subject: Registration of ACAP capability 501 Capability name: 502 GROUP 504 Capability keyword: 505 GROUP 507 Capability arguments: 508 None 510 Published Specification(s): 511 This document 513 Person and email address to contact for further information: 514 See Authors' Addresses section of this document 516 7. Examples 518 Server expresses both USER and GROUP capabilities. 520 "/userid" dataset: 522 entry = "" 523 dataset.userid.displayname.acl = 524 ("groupid.anyonex" "groupid.topxrwia" 525 "userid.anyoner") ;; note that refers to the US- 526 ASCII ;; horizontal tab character 527 dataset.userid.authid.acl = () 529 entry = "r_migal" 530 userid.authid = ("roman" "roman.migal" "migal" 531 "roman@execmail.com") 532 userid.displayname = "Roman Migal" 533 userid.description = "Application Developer" 534 userid.whitepage-info = ("/addressbook/user/roman") 535 userid.memberof = "/groupid/anyone" 537 entry = "s_hole" 538 userid.authid = ("steve" "steve.hole" "steve@exec- 539 mail.com") 540 userid.displayname = "Steve Hole" 541 userid.description = "MessagingDirect CTO" 542 userid.whitepage-info = ("/addressbook/user/steve" 543 "ldap://directory.messagingdi- 544 rect.com/mail%3Dsteve.hole%40execmail.com") 545 userid.memberof = ("/groupid/top" "/groupid/execmail" 546 "/groupid/devel" "/groupid/anyone") 548 entry = "a_melnikov" 549 userid.authid = ("alexey" "alexey.melnikov" "alexei" 550 "alexei@execmail.com") 551 userid.displayname = "Alexey Melnikov" 552 userid.description = "Software Developer" 553 userid.whitepage-info = ("/addressbook/user/mel" 554 "http://sites.netscape.net/aamelnikov/index.html" 555 "ldap://directory.messagingdirect.com/mail%3Dalexey.mel- 556 nikov%40execmail.com") 557 userid.memberof = ("/groupid/devel" "/groupid/store" 558 "/groupid/anyone") 560 entry = "anonymous" 561 userid.authid = ("anonymous") 562 userid.displayname = "Anonymous user" 563 userid.description = "Used for accessing shared data" 564 userid.whitepage-info = () 565 userid.memberof = () 567 "/groupid" dataset 569 entry = "anyone" 570 subdataset = ("." 571 "acap://other.acap.server.com/groupid/all") 572 groupid.name = "All registered users" 573 groupid.description = "Note that this entry is different from 574 /userid/anyone" 576 entry = "devel" 577 subdataset = "." 578 groupid.name = "Software Developers" 579 groupid.description = "" 581 "/groupid/anyone" dataset 583 entry = "userid.r_migal" 585 entry = "userid.s_hole" 587 entry = "userid.a_melnikov" 589 "/groupid/devel" dataset 591 entry = "userid.s_hole" 593 entry = "userid.a_melnikov" 595 "/groupid/store" dataset 597 entry = "userid.a_melnikov" 599 "/groupid/top" dataset 601 entry = "userid.s_hole" 603 "/groupid/execmail" dataset 605 entry = "userid.s_hole" 607 8. References 608 [ACAP] Newman, C., Myers, J. G., "Application Configuration Access 609 Protocol", RFC 2244, July 1997. 611 [KEYWORD] S. Bradner, "Key words for use in RFCs to Indicate Requirement 612 Level", RFC 2119, March 1997. 614 [ABNF] Dave Crocker, P. Overell, "Augmented BNF for Syntax 615 Specifications: ABNF", RFC 2234, July, 1997 617 [REL-URL] Fielding, "Relative Uniform Resource Locators", RFC 1808, 618 UC Irvine, June 1995. 620 9. Security Considerations 622 This specification defines a protocol for storing, accessing and 623 managing application resource authorization information. It is 624 expected that this information will be used to grant and/or deny 625 access to users and groups for server based resources. 627 ACAP server access controls should be set correctly on userid entry 628 attributes. Clients SHOULD be able to search for userid entries 629 based on authentication identifier attributes, but SHOULD NOT be 630 able to retrieve any authentication identifier information. 632 This specification does not define any kind of process, mechanism 633 or protocol for authentication in distributed network applications. 634 Use of the data and protocol elements described in this specifica- 635 tion are to be used after successful authentication between the 636 client and server. 638 This specification does not discuss storage of any kind of authen- 639 tication credentials, in the form of private keys, shared secrets 640 or passwords in userid entries. The information in the authid 641 dataset is intended purely for authorization and access control 642 purposes. 644 10. Acknowledgments 646 The authors would like to acknowledge the contributions made to this 647 document. Randy Gellens, for editorial comment and feedback on the 648 group membership model. Chris Newman for editorial comment and clari- 649 fication of the security and access control rights issues for the ACAP 650 server itself. 652 11. Authors' Addresses 653 Steve Hole 654 mailto:Steve.Hole@messagingdirect.com 656 Alexey Melnikov 657 mailto:Alexey.Melnikov@messagingdirect.com 659 ACI WorldWide/MessagingDirect 660 900 10117 - Jasper Ave. 661 Edmonton, Alberta, T5J 1W8, CANADA 663 12. Full Copyright Statement 665 Copyright (C) The Internet Society 2002. All Rights Reserved. 667 This document and translations of it may be copied and furnished to 668 others, and derivative works that comment on or otherwise explain 669 it or assist in its implementation may be prepared, copied, pub- 670 lished and distributed, in whole or in part, without restriction of 671 any kind, provided that the above copyright notice and this para- 672 graph are included on all such copies and derivative works. How- 673 ever, this document itself may not be modified in any way, such as 674 by removing the copyright notice or references to the Internet 675 Society or other Internet organizations, except as needed for the 676 purpose of developing Internet standards in which case the proce- 677 dures for copyrights defined in the Internet Standards process must 678 be followed, or as required to translate it into languages other 679 than English. 681 The limited permissions granted above are perpetual and will not be 682 revoked by the Internet Society or its successors or assigns. 684 This document and the information contained herein is provided on 685 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 686 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 687 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 688 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 689 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.