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

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

Hi, Henning,

The revised draft addresses the questions I was raising - thanks for the 
speedy turnaround!

Spencer


>A revised draft is at
>
> http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-07.html
> http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-07.txt
>
> If this satisfies the review, I'm happy to submit it to the I-D editor and 
> resume the process.
>
> Henning
>
> Spencer Dawkins wrote:
>> 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