idnits 2.17.1 draft-dusseault-rvp-addr-00.txt: -(60): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(211): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** There are 86 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 114: '... - MUST NOT treat case as sig...' RFC 2119 keyword, line 116: '... - MUST treat case as signifi...' RFC 2119 keyword, line 118: '... - MUST NOT consider hostname...' RFC 2119 keyword, line 120: '... - MUST NOT consider the pres...' RFC 2119 keyword, line 122: '... - MUST NOT consider the expl...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '7' on line 330 looks like a reference -- Missing reference section? '6' on line 326 looks like a reference -- Missing reference section? '1' on line 306 looks like a reference -- Missing reference section? '4' on line 318 looks like a reference -- Missing reference section? '3' on line 314 looks like a reference -- Missing reference section? '2' on line 310 looks like a reference -- Missing reference section? '5' on line 323 looks like a reference -- Missing reference section? '8' on line 332 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Dusseault, Microsoft 2 Expires Sept 1998 Mohr, Activerse 4 Addressing and Location for RVP 5 draft-dusseault-rvp-addr-00.txt 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other documents 16 at any time. It is inappropriate to use Internet-Drafts as 17 reference material or to cite them other than as "work in progress." 18 To view the entire list of current Internet-Drafts, please check the 19 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 20 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 21 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 22 ftp.isi.edu (US West Coast). 24 Abstract 26 A core part of a presence and instant messaging protocol, such as 27 RVP [7], must be the ability to find users online. This draft 28 defines several aspects of finding a user online: 30 - Schema of RVP URL 31 - How to find a user�s RVP address (URL) 32 - How to find a RVP server 34 The problem may be generalized to finding a non-user object online. 35 In this draft, the client is the process which is searching for a 36 RVP object. This can be a RVP server acting as a client or on 37 behalf of a user. The server is the process which is responsible 38 for answering queries and receiving messages for a RVP object. A 39 RVP client may sometimes act as its own server. 41 1. URLs 43 RVP URLs are used in RVP requests and headers to indicate the 44 originator and target of an RVP message, and to specify redirection 45 addresses. Since the URL is only an address, an RVP message must 46 also include headers to specify the action, properties, and other 47 details of a request or a response. 49 The target of a RVP request is always a node in the RVP namespace. 50 Nodes are identified by URL syntax. The URL is only used to 51 identify a node, much as a HTTP URL identifies a directory or 52 document. The URL follows the syntax for hierarchical schemes set 53 out in RFC1738 [6]: 55 rvp://:/ 57 The scheme name is "rvp". The host component is used to resolve to 58 the server or servers which is responsible for the node named in the 59 path. The path is an identifier for a particular node in that 60 server�s namespace. The path needs to be unique for that host, but 61 not unique for all hosts. 63 Note that the path may be literally the path to the node in a 64 storage system, depending on the implementation, but this is not 65 required of implementations. 67 1.2 URL Format 68 RVP-URL = "rvp://" host [ ":" port ] "/" path 69 host = defined in RFC 1738 70 port = *digit 71 path = name | name "/" path 72 name = alphanumeric atom 74 Note that all URL reserved characters must be encoded. 75 Examples of user URLs: 76 rvp://rvp.widgets.com/users/juser 77 rvp://rvp.widgets.com/users/engineering/username 78 Examples of general-purpose node URLs: 79 rvp://rvp.widgets.com/engineering/SDE 80 rvp://rvp.widgets.com/engineering/SDE/announce 81 rvp://rvp.widgets.com/engineering/SDE/discussion 83 1.3. Default URLs 85 There are many cases where a user may have more than one RVP 86 address. In these cases, a user may have multiple URLs. 88 To make the case of multiple RVP addresses simpler for clients, the 89 concept of the "default" address is introduced. A "default" address 90 is one that the user has designated as the address that other users 91 should use to send instant messages or find out if the user is 92 online. 94 The default URL should be marked as such in VCard or LDAP entries. 96 1.4 Identity URLs 97 The RVP URLs which users share are "identity URLs", which serve to 98 both identify a person and provide the canonical location for 99 reaching them. 101 Internally, RVP also uses syntactically-equivalent "location URLs" 102 to describe the endpoints of communication. However, such URLs are 103 not useful or visible to end-users, and are hence not discussed 104 further here. 106 Identity URLs are used to initiate contact with others, identify the 107 originator of communications, and qualify access-privileges for RVP 108 objects. 109 For the purposes of comparing two RVP identity URLs, to determine if 110 they refer to the same RVP object, RVP applications must follow the 111 rules set forth in Section 3.2.3 of the HTTP/1.1 specification. 112 Fielding et. al. RFC 2068]. This implies that RVP applications... 114 - MUST NOT treat case as significant in the 'scheme' or 'host' 115 portions of an URL. 116 - MUST treat case as significant in the 'url-path' portion of an 117 URL, as per Section 118 - MUST NOT consider hostnames which resolve to the same IP address 119 as identical. 120 - MUST NOT consider the presence or absence of a trailing "/" to be 121 significant, if the 'url-path' portion is empty. 122 - MUST NOT consider the explicit specification of the default port 123 to be any different than implied specification of the default port. 124 For example, the following RVP identity URLs are prima facie 125 identical: 127 rvp://rvp.widgets.com 128 RVP://rvp.widgets.com 129 rvp://RVP.widgets.COM 130 rvp://rvp.widgets.com/ 131 rvp://rvp.widgets.com:XXXX 132 RVP://rvp.WIDgets.com:XXXX/ 134 The following two URLs MUST NOT be assumed to represent the same 135 identity: 136 rvp://rvp.widgets.com/bill 137 rvp://rvp.widgets.com/Bill 139 Similarly, the following two URLs MUST NOT be assumed to represent 140 the same identity, even if the current DNS resolution of 141 "rvp.widgets.com" is "207.8.29.7": 142 rvp://rvp.widgets.com/bill 143 rvp://207.8.29.7/bill 145 If a particular RVP server wishes to adopt a policy of case- 146 insensitivity or hostname-equivalence, it should choose a preferred 147 identity URL representation for each RVP object hosted. Requests for 148 that entity under acceptably-close "Subject" names MAY then generate 149 "301-Moved Permanently" replies which include the preferred name. 150 For example, a request for "rvp://207.8.29.7/BILL" might result in a 151 301 reply, with the new "Location" as "rvp://rvp.widgets.com/Bill". 153 2. Discovering RVP Addresses 155 2.1. Manual Transfer 157 The simplest way to obtain these URLs is for a user to communicate 158 the URLs using some out-of-band mechanism such as verbally, in an e- 159 mail message, on a web page, or by printing these URLs on a paper 160 business card. 162 When using this mechanism, the user obtains these URLs using an out- 163 of-band mechanism and enters these URLs into their client manually. 165 Manual transfer is the typical way for non-user addresses to be 166 discovered. 168 2.2. Personal Data Exchange Using A vCard 170 A more sophisticated way to obtain user URLs is for users to publish 171 vCards containing these URLs. The vCard object can be transferred 172 between one another. Since many e-mail clients allow a user to 173 automatically include a vCard with every message that the user 174 sends, this provides a simple transparent way for a user to 175 distribute their online presence URLs. 176 On the receiving end, an e-mail client that provides an integrated 177 vCard database can provide a way to lookup RVP URLs for users whose 178 vCards are stored locally. 180 2.2.1. vCard Schema Extensions 182 Since the vCard [1] specification doesn't specify how to encode RVP 183 URLs in a vCard, this section is provided as an extension to vCard 184 which specifies how to encode RVP URLs within a vCard. 185 Inside a vCard object, a new property is defined: "RVPURL". Any 186 vCard can have one or more of these properties, each representing a 187 RVP URL that is associated with the user. One of these properties 188 can be designated as the "default" by adding the "PREF" parameter. 189 Here is a simple example of a vCard containing a "RVPURL". 191 BEGIN:VCARD 192 VERSION:3.0 193 FN:Joe User 194 N:User,Joe 195 ORG:Microsoft Corporation 196 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; 197 Redmond;WA;98052-6399;USA 198 TEL;WORK;MSG:+1-206-936-2472 199 TEL;WORK;FAX:+1-206-936-7329 200 EMAIL;INTERNET:user@host1.com 201 RVPURL;PREF:http://rvp.host1.com/user 202 END:VCARD 204 Next step is to register this property with IANA. 206 2.3. Directory Lookup Using The LDAP v3 Protocol 208 Another way to obtain user URLs is to look them up in a directory 209 using the LDAP protocol. 211 If an user�s e-mail address or domain is known, then using DNS [4], 212 the attendee�s directory server can be found. From the directory 213 server, the client can look up the RVP URL. 215 Here�s how it works: the client first parses the domain name from 216 the rfc822 mailbox name. For the fictitious mailbox 217 "joeuser@host1.com", the domain name would be "host1.com". 219 Given the domain name, the client prepends "ldap.tcp" to the domain 220 name and formulating a host. Next the client queries the DNS server 221 for the SRV record for "ldap.tcp.host1.com". The mechanism for 222 adding "ldap.tcp" onto the original domain name is described in 223 detail in[3], [2]. The DNS server returns the IP address for the 224 associated server for "ldap.tcp.host1.com". 226 Once the IP address for the LDAP server has been obtained, the 227 client obtains a list of possible search bases by querying the LDAP 228 server with a NULL baseObject. The client iterates through each 229 baseObject and queries the server for all entries where the 230 attribute named "mail" [5] "equalityMatch"es the user�s email 231 address. From the first matching entry, the client obtains the RVP 232 URL. 234 If a user�s RVP URL can be found using directory lookup, they 235 should, in general, be considered "more up-to-date" than URLs in any 236 vCards that are stored locally. 238 2.3.1. LDAP Schema Extensions 240 In order to encode the RVP URLs in the directory, the following are 241 defined: 243 one object class: 244 @ RVPEntry 246 and two attributes: 248 @ RVPURL 249 @ RVPOtherURLs 251 The RVPURL attribute contains the user�s RVP URL. 252 The RVPOtherURLs is a multi-valued property containing other RVP 253 URLs that the user may have. There is no predetermined order to the 254 values in a multi-valued property. 256 TBD: Define precisely the RVPEntry object class and attributes. 258 3. Finding RVP Servers 260 3.1. DNS SRV Records 262 RFC 2052 [2] recommends use of DNS SRV records to discover the 263 responsible server for a service. 265 Given the domain name, which can be parsed from the URL, the client 266 prepends "rvp.tcp." or "rvp.udp." to the domain name. Next the 267 client queries the DNS server for the SRV record for 268 "rvp.tcp.host1.com". The mechanism for adding "rvp.tcp" onto the 269 original domain name is described in detail in [3], [2]. The DNS 270 server returns the IP address for the associated server for 271 "rvp.tcp.host1.com". The RVP packet is sent to this server. 272 DNS A records can be consulted if DNS SRV records are not present. 274 There is some discussion of whether use of DNS SRV records pollutes 275 the DNS namespace, but this issue is not well-understood yet. 277 3.2. Use Service Location Protocol 279 The Service Location Protocol version 2.0 [8] is in development but 280 may serve our needs in the future. A SLP URL for an RVP server 281 could look like: 283 Server:rvp://widgets.com 285 However, SLP may not be useful on the internet and this bears more 286 investigation. 288 Authors' Addresses 289 Lisa Dusseault 290 Microsoft Corporation 291 One Microsoft Way 292 Redmond, WA 98052 293 EMail: lisadu@microsoft.com 295 Fax: (425) 936-7329 296 Gordon Mohr 297 Activerse, Inc. 298 1301 W. 25th St 299 Suite 500 300 Austin, TX 78705 302 Email: gojomo@activerse.com 304 Bibliography 306 [1] Dawson F. and Howes T., 'vCard MIME Directory Profile', 307 INTERNET-DRAFT , 308 May 1998 310 [2] Gulbrandsen A. and Vixie P., "A DNS RR for specifying the 311 location of services (DNS SRV)", RFC 2052, 312 , October 1996. 314 [3] Leach P., �Locating Native Internet LDAP Servers�, 315 INTERNET DRAFT , 316 March 1997 318 [4] Mockapetris, P., "Domain Names - Implementation and 319 Specification", STD 13, RFC 1035, USC/Information Sciences 320 Institute, November 1987. 321 323 [5] Network Applications Consortium 'Lightweight Internet Person 324 Schema', April 1997, 326 [6] Berners-Lee T., Masinter L., McCahill M., "Uniform Resource 327 Locators (URL)", RFC 1738, Dec 1994. 330 [7] Calsyn M. and Dusseault L., "RVP: A Presence Information 331 Protocol", INTERNET-DRAFT , March 1998. 332 [8] Day M, Veizades J., Perkins C. and Guttman E. "Service Location 333 Protocol", INTERNET-DRAFT , 334 March 1998