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

[Henning Schulzrinne <[e-mail]>]

Spencer:

thanks for your, as usual, helpful review. I will make the recommended 
changes, as they seem to be editorial clarifications. All: I'm assuming 
I should create a new version and just submit it to the I-D editor?

Henning

> 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