[Gen-art] Gen-ART Review of draft-ietf-simple-cipid-06

["Spencer Dawkins" <[e-mail]>]

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

Summary: this document is on the right track for publication as Proposed
Standard, but some changes may make the document more usable.

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 <person> or, less commonly, <tuple> element
   in the presence data model [9].  The <tuple> element is only extended
   with CIPID elements if the information describes a service referring
   to another person that is marked by an RPID <relationship> 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 <display-name> 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 <icon> 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 <map> 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. 


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art