idnits 2.17.00 (12 Aug 2021) /tmp/idnits37400/draft-hudson-impp-presence-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == 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 1) being 333 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 132 instances of lines with control characters in the document. ** The abstract seems to contain references ([XML]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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.) -- 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: '0-9' is mentioned on line 105, but not defined == Missing Reference: '0-9A-Fa-f' is mentioned on line 107, but not defined == Missing Reference: 'Geneva' is mentioned on line 326, but not defined == Unused Reference: 'Reqts' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'Type-feature' is defined on line 298, but no explicit reference was found in the text == Outdated reference: draft-ietf-impp-model has been published as RFC 2778 ** Downref: Normative reference to an Informational draft: draft-ietf-impp-model (ref. 'Model') == Outdated reference: draft-ietf-impp-reqts has been published as RFC 2779 ** Downref: Normative reference to an Informational draft: draft-ietf-impp-reqts (ref. 'Reqts') == Outdated reference: draft-ietf-conneg-feature-type has been published as RFC 2913 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Greg Hudson 2 Expires: August 11, 2000 ghudson@mit.edu 3 MIT 5 Proposed Format For Presence Information 6 draft-hudson-impp-presence-01.txt 8 1. Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Please send comments to the IMPP working group at impp@iastate.edu. 30 2. Abstract 32 This document proposes a syntax and initial tag set for presence 33 information to be used in the IMPP protocol suite. The encoding is a 34 subset of well-formed but not valid [XML] documents, such that it can 35 be parsed either by a simple hand-written parser or by an XML 36 implementation. 38 3. Terminology 40 The following terms are defined in [Model] and are used with those 41 definitions in this document: 43 PRESENTITY 44 PRINCIPAL 45 WATCHER USER AGENT 47 However, those terms are used in lowercase for improved readability, 48 since they are relatively distinctive. 50 The terms MUST, SHOULD, and MAY are used in uppercase with the meaning 51 defined in [RFC 2119]. 53 4. Syntax 55 [POINT OF CONTENTION: Some have argued that we should define our 56 syntax by referring to XML and adding restrictions so that we don't 57 accidentally introduce variations. My view is that this would force 58 implementors to consult the full XML spec; having a self-contained, 59 reduced grammar seems more conducive to implementations.] 61 [POINT OF CONTENTION: Several people think we should use the MIME type 62 application/presence-xml or try to get presence/xml to allow for 63 future media types which encode presence information differently. 64 Precedents like application/pip suggest to me that 65 "application/presence" is more along the lines of common practice than 66 creating a whole new hierarchy of different encodings.] 68 Presence information is a MIME [RFC 2045-2049] object of type 69 application/presence. The contents of the MIME object is a presence 70 document. The underlying character set for a presence document is 71 [Unicode], which will be represented in UTF-8 or as determined 72 otherwise by a charset parameter in the media type of the MIME object. 73 Following is an ABNF [RFC 2234] grammar describing the syntax for 74 presence information: 76 presence-doc = "" content "" 77 content = *(element / char-data / reference) 78 element = empty-tag / start-tag content end-tag 79 ; end-tag name must match start-tag name. 80 empty-tag = "<" name "/>" 81 start-tag = "<" name ">" 82 end-tag = "" 83 name = (Letter / "_" / ":") *NameChar 84 char-data = 1*DataChar 85 ; "]]>" may not appear, for compatibility 86 ; with SGML. 87 reference = char-ref / entity-ref 88 char-ref = "&#" 1*ASCIIDigit ';' / 89 "&#x" 1*ASCIIHexDigit 90 ; Must refer to a valid Char 91 entity-ref = "<" / ">" / "&" / "'" / 92 """ 94 The character classes Letter, Digit, CombiningChar, and Extender are 95 defined in [XML] Appendix B. The other character classes are defined 96 as follows: 98 NameChar = Letter / Digit / "." / "-" / "_" / ":" / 99 CombiningChar / Extender 100 DataChar = %x9 / %xA / %xD / %x20-25 / %x27-3B / 101 %x3D-D7FF / %xE000-FFFD / %x10000-310FFFF 102 ; Most valid Unicode characters 103 Char = DataChar / "&" / "<" 104 ASCIIDigit = %x30-39 105 ; [0-9] 106 ASCIIHexDigit = %x30-39 / %x41-46 / %x61-66 107 ; [0-9A-Fa-f] 109 A char-ref refers to a Unicode character by number, either in decimal 110 ("&#" prefix) or in hexadecimal ("&#x" prefix). An entity-ref refers 111 to a specific Unicode character by name, as follows: 113 entity-ref Character 114 ---------- --------- 115 < < 116 > > 117 & & 118 ' ' 119 " " 121 5. Syntactic interpretation 123 After parsing, a presence document consists of a tree of elements, 124 where each element consists of a name (or "tag"), text (the 125 concatenation of all char-data and reference productions in the 126 element's content, but not char-data and reference productions inside 127 sub-elements), and an ordered list of child elements. For example, 128 the presence document: 130 a<abbbcccddd 132 parses into a tree of three elements named "presence", "foo", and 133 "bar", and which can be viewed pictorially as: 135 presence 136 "aa<abbbddd 152 6. Tag set 154 Some tag definitions include a list of constraints on that element's 155 children. If an element's children do not meet the specified 156 constraints, the watcher user agent MUST discard that element. 158 Tag: presence 159 Context: (top level) 160 Sub-elements: date presentity location status contact 161 [XXX Do we want sub-elements here for personal 162 information, or is that out of scope for presence?] 163 Constraints: time and presentity must appear exactly once. 164 location and status must appear at most once. 165 Description: This tag introduces the presence document. Any text 166 in the element is discarded. 168 Tag: date 169 Context: presence 170 Description: The text of this element gives the date and time for 171 which the presence information is being reported. 172 [XXX Obviously we need to pick a standard format, but 173 the details are unimportant at this stage.] 175 Tag: presentity 176 Context: presence 177 Description: The text of this element specifies the identifier of the 178 presentity whose presence is being reported. 180 Tag: location 181 Context: presence 182 Description: The text of this element specifies the location of the 183 principal as a human-readable description. 184 [XXX Open issue: is it useful to define a 185 human-readable field like this and restrict it to flat 186 text? Or is it only useful if it can also be a video 187 clip or HTML or whatnot?] 189 Tag: status 190 Context: presence 191 Description: The text of this element specifies the current status 192 of the presentity. It must be one of "available", 193 "busy", and "idle". [XXX Should we be more precise 194 about what those values mean, or is it good enough 195 just to make sure programs use one of those three 196 words? Should we allow for more values in the future, 197 or is it better for interoperability not to make this 198 particular field extensible?] 200 Tag: contact 201 Context: presence 202 Sub-elements: address capabilities preference 203 Constraints: address must appear exactly once. capabilities and 204 preference must appear at most once. 205 Description: This tag introduces a means of communicating with the 206 principal. Any text in the element is discarded. 207 There may be multiple contact elements within the 208 presence document. 210 Tag: address 211 Context: contact 212 Description: The text of this element gives the communications 213 address as a URL [RFC 1738]. The URL type must 214 correspond to a communication means and not a document 215 type. [XXX How can we be more precise about this 216 distinction? Obviously we don't want HTTP URLs here 217 to be considered valid.] 219 Tag: capabilities 220 Context: contact 221 Description: The text of this element specifies the media features 222 which can be processed by a means of communication, 223 using the filter syntax defined in [RFC 2533]. 224 [XXX RFC 2533 filters are probably not all we need. 225 More delving into the CONNEG framework is required.] 227 Tag: preference 228 Context: contact 229 Description: The text of this element is an unsigned integer giving 230 the preference of a contact relative to other 231 contacts. When selecting between contact addresses to 232 use to contact a principal, addresses with lower 233 priorities should be considered more desirable than 234 addresses with higher priorities. If no preference 235 element appears in a contact address, it should be 236 considered less desirable than any contact address 237 with a preference element. 239 7. Examples 241 The following presence document might be given as presence information 242 for a presentity which might be identified as joe@example.com. Note 243 that clarifying whitespace in the presence document must be used with 244 some care; it is fine to have extra whitespace directly within a 245 "presence" or "contact" element where it will be ignored, but it 246 should not be included in elements such as "address" in which text is 247 significant and extra whitespace is not specifically allowed. 249 250 joe@example.com 251 2000-02-11 17:34:12 252 idle 253 Out to lunch at Mel's Diner 254 255
im:joe@example.com
256 257 (& (pix-x<=1024) (pix-y<=768) 258 (color<=256)) 259 260 1 261 262 263
mailto:joe@example.com
264 265 267 8. Extensions 269 New element tags can only be standardized in the form of a 270 standards-track RFC. Element names beginning with "x-" may be used 271 for experimental purposes for all three kinds of extensions. New 272 element names should avoid the use of the ":" character, since it may 273 be used in the future for XML namespaces. 275 9. Security considerations 277 Watcher user agents should be careful to present communications 278 addresses to users when users choose to send a message to a 279 principal, so that users cannot be easily fooled into sending 280 authenticated messages to their work supervisors other unintended 281 parties. 283 10. IANA considerations 285 The current extensions proposal does not place any load on the IANA. 287 11. References 289 [Model] 290 M. Day, J. Rosenberg, H. Sugano. "A Model for Presence." Work in 291 progress, draft-ietf-impp-model-03.txt. 293 [Reqts] 294 M. Day, S. Aggarwal, G. Mohr, J. Vincent. "Instant Message / Presence 295 Protocol Requirements." Work in progress, 296 draft-ietf-impp-reqts-03.txt. 298 [Type-feature] 299 G. Klyne. "MIME content types in media feature expressions." Work in 300 progress, draft-ietf-conneg-feature-type-01.txt. 302 [RFC 1738] 303 T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators 304 (URL)." RFC 1738, December 1994. 306 [RFC 2045-2049] 307 N. Freed, N. Borenstein. "Multipurpose Internet Mail Extensions 308 (MIME)." RFC 2045-2049, November 1996. 310 [RFC 2119] 311 S. Bradner. "Key Words for Use in RFCs to Indicate Requirement 312 Levels." RFC 2119, March 1997. 314 [RFC 2234] 315 D. Crocker, Ed., P. Overell. "Augmented BNF for Syntax 316 Specifications: ABNF." RFC 2234, November 1997. 318 [RFC 2533] 319 G. Klyne. "A Syntax for Describing Media Feature Sets." RFC 2533, 320 March 1999. 322 [Unicode] 323 ISO (International Organization for Standardization). "ISO/IEC 324 10646-1993 (E). Information technology -- Universal Multiple-Octet 325 Coded Character Set (UCS) -- Part 1: Architecture and Basic 326 Multilingual Plane." [Geneva]: International Organization for 327 Standardization, 1993 (plus amendments AM 1 through AM 7). 329 [XML] 330 T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup 331 Language (XML) 1.0." W3C Recommendation REC-xml-19980210, February 332 1998.