Draft: draft-ietf-simple-cipid-06 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 11/21/2005 8:34 AM LC Date: 11/25/2005 Summary: this document is on the right track for publication as Proposed Standard, but some changes may make the document more usable. [Based on subsequent email discussion and a revised draft made available, this document is deemed Ready]. Thanks, Spencer Dawkins Details: 1. Introduction We describe elements for providing a "business card", references to the homepage, map, representative sound, display name and an icon. All elements extend the or, less commonly, element in the presence data model [9]. The element is only extended with CIPID elements if the information describes a service referring to another person that is marked by an RPID element with a value other than 'self'. All elements described in this document are optional. Spencer: Two points here - RPID is used without expansion, but more important - there are a fair number of references to RPID in this document, including an example in Section 4 that includes both RPID and CIPID, but there's no discussion of the relationship between CIPID and RPID in the document. The namespace URI for these elements defined by this specification is a URN [2], using the namespace identifier 'ietf' defined by [3] and extended by [4]: urn:ietf:params:xml:ns:pidf:cipid Spencer: is it reasonable to prefix this string with URN: for readability, as in Section 6.1? (It just looks like random characters, at first glance) 3. CIPID Elements Some of the elements below refer to content using URIs. If the watcher retrieves the content pointed to by the URI, it may reveal to the presentity that it is currently using the presence application. Thus, for increased watcher privacy, a presence application MAY want to cache these objects for later use. Spencer: this text just seems odd here - is this closer to Security Considerations text than an introduction to CIPID Elements? Similar text does appear in Security Considerations... 3.2 Display-Name Element The element includes the name identifying the tuple or person that the presentity suggests should be shown by the watcher user interface. It is up to watcher user interface to choose whether to heed this suggestion or use some other suitable string. Spencer: "up to the watcher user interface"? 3.4 Icon Element The element provides a URI pointing to an image (icon) representing the tuple or person. The watcher MAY use this information to represent the tuple or person in a graphical user interface. Presentities SHOULD provide images of sizes and aspect ratios that are appropriate for rendering as an icon. Support for JPEG, PNG and GIF formats is RECOMMENDED. Spencer: "The watcher MAY use this information" probably shouldn't be normative text for this specification. Suggest lower-case "may". Spencer: In 3.4 and 3.5, multiple formats are RECOMMENDED with no mandatory-to-implement format. Is there a format that could be mandatory-to-implement, so that conformant implementations won't discover that they don't interoperate? 3.5 Map Element The element provides a URI pointing to a map related to the tuple or person. The watcher MAY use this information to represent the tuple or person in a graphical user interface. The map may be either an image, an HTML client-side image map or a geographical information system (GIS) document, e.g., encoded as GML. Support for images formatted as PNG and GIF is RECOMMENDED. Spencer: same comments on "watcher MAY" and "RECOMMENDED" as in 3.4. 4. Example An example combining RPID and CIPID is shown below: Spencer: I saw in the PROTO questionnaire for this document that the working group has decided not to recombine the CIPID and RPID documents, which is fine, but I'd suggest that at least one example in this document be CIPID-only, so that an implementor who is working on CIPID doesn't have to reference both documents to understand the example. The example included is fine, I'm just asking for a CIPID-only example.