[apps-discuss] APPSDIR review of draft-salgueiro-vcarddav-kind-device-03

[Larry Masinter <[e-mail]>]

(resend)
I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other comments you  may receive.  Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-salgueiro-vcarddav-kind-device-03
Title: vCard KIND:device
Reviewer: Larry Masinter 
Review Date: 24 Nov 2012 
Summary: The document is almost ready for publication as a Proposed Standard. Some clarification and design rationale would be quite helpful.

Major Issues: none
Minor Issues/Nits:  

I had trouble between "Minor issues" or "Nits" for many of these, so I put them together. I don't feel strongly about any of them, if the authors are confident that anyone steeped in vCard and LDAP wouldn't have the same issues.

=================================
1. use cases (definitely NIT)
> use cases for device   vCards have emerged
Are these documented somewhere else?  A few more examples would be helpful. 
================================

2. LDAP / X.521 alignment, nature of devices  (NIT)

> In this context, the concept of a device is constrained to computing
>   devices and thus is distinct from purely mechanical devices such as
>   elevators, electric generators, etc. that cannot communicate in any
>   way over a network.

Why not allow mechanical devices such as elevators, electric generators, or gas and electric meters?
Wouldn't compatibility with LDAP be useful?

Is there a need to distinguish between network elements (routers) and appliances and light switches? 
Between physical objects and virtual objects that do not have a distinct physical location?

>   Although it might be desirable to define a more fine-grained taxonomy
>   of devices (e.g., a KIND of "device" with a subtype of "router" or 
>   "computer"), such a taxonomy is out of scope for this document

"out of scope" is a convenient but frustrating label for "we decided not to do it".  As a spec author/editor it's great; for a reader it isn't so great. Some more elaboration "There were no compelling use cases for such a distinction, and advantages to not making distinctions where some use cases straddled the categories." (if that's a reason) might be more satisfactory.

========================================
3. Devices "containing" vCards, normative language around it (MINOR)

" A device MAY contain..."
The "contain" relationship is unspecified. How are these vCards discovered and accessed in a "device"?  I can see saying that a device "has" one or more vCards and being explicit that discovery and access are unspecified? If a 2D barcode is affixed to the device and used to retrieve the vCards associated with it, is that in scope?  
My concern is over the normative language "MAY" for a relationship that is unspecified.


   > When a device contains vCards other than its KIND:device vCard, those
   >  vCards MUST be linked together with RELATED (see the definition of
 >   the RELATED organizational property in Section 6.6.6 of [RFC6350]).

Since 'contain' is unspecified, the scope of this advice (and thus the MUST requirement) is unclear. Even if you define "contain", isn't this a SHOULD?

===================================================
4. Use of RELATED for devices (NIT)

The values for RELATED in RFC 6350 
 
                     "contact" / "acquaintance" / "friend" / "met"
                        / "co-worker" / "colleague" / "co-resident"
                        / "neighbor" / "child" / "parent"
                        / "sibling" / "spouse" / "kin" / "muse"
                        / "crush" / "date" / "sweetheart" / "me"
                        / "agent" / "emergency"

don't seem to match device relationships (robot love?). Perhaps some more examples of RELATED use or advice here would help?

=========================
5. Example unexplained (MINOR)

Section 4, the Example is not explained! Lots of the example is mysterious to me. Please annotate the example with a description of what it means and why.