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

[Ted Hardie <[e-mail]>]

At 3:11 PM -0500 11/21/05, Henning Schulzrinne wrote:
>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

Hi Henning,
	This review is part of the IESG review of this document (Brian delegates
review to the Gen-ART team).  Please wait for the rest of the IESG reviews before
re-spinning the document.
			thanks,
				Ted Hardie





>>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