Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt

[Alexey Melnikov <[e-mail]>]

Here is my detailed review:

1.  Introduction and Overview

 [...]

   3.  Principal namespace can be used to enumerate and find other users
       on the system.

A reference to the document defining "principal namespace" should be added
here.

 [...]

   5.  Well-defined internationalization support through standard HTTP.

This is a bit misleading, because this is or isn't true depending
on which HTTP feature you mean here.


3.  Requirements Overview

   o  MUST support secure transport as defined in [RFC2818] using TLS
      [RFC5246];

This recently came up in review of 
draft-ietf-geopriv-http-location-delivery-15.txt:

RFC 2818, Section 3.1 says:

  Matching is performed using the matching rules specified by
  [RFC2459].  If more than one identity of a given type is present in
  the certificate (e.g., more than one dNSName name, a match in any one
  of the set is considered acceptable.) Names may contain the wildcard
  character * which is considered to match any single domain name
  component or component fragment. E.g., *.a.com matches foo.a.com but
  not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Based on the discussion during an IESG telechat several ADs agreed that 
f* wildcards shouldn't be allowed anymore. So, the document should say
that it complies with RFC 2818, except for f* type wildcards are not 
allowed. (wildcards in the leftmost label are still allowed). This is 
consistent with the advice from RFC 5280.


I also think this document should reference RFC 5280.


6.2.1.  CARDDAV:addressbook-description Property

   Name:  addressbook-description

   Namespace:  urn:ietf:params:xml:ns:carddav

   Purpose:  Provides a human-readable description of the address book
      collection.

BCP 18 (RFC 2277), section 4.2 applies to elements carrying human 
readable text.
Any human readable text needs to be [optionally] accompanied by RFC 4646 
language tags.

You even use of xml:lang in your example later in this section. However 
the definition doesn't allow for this attribute:

   Definition:

       <!ELEMENT addressbook-description (#PCDATA)>
       <!-- PCDATA value: string -->


6.2.3.  CARDDAV:max-resource-size Property

   Name:  max-resource-size

   Namespace:  urn:ietf:params:xml:ns:carddav

   Purpose:  Provides a numeric value indicating the maximum size in
      octets of a resource that the server is willing to accept when an
      address object resource is stored in an address book collection.

   Value:  Any text representing a numeric value.

Ok, this is probably pedantic. But "Any text representing a numeric 
value" might mean that hexadecimal formats are allowed, but I am sure 
this is not what you meant here.


8.3.1.  CARDDAV:supported-collation-set Property


   Description:  The CARDDAV:supported-collation-set property contains
      zero or more CARDDAV:supported-collation elements which specify
      the collection identifiers of the collations supported by the
      server.

According to section 8.3 the "i;unicode-casemap" collation is "MUST 
implement"
(and the default), so I think this should say "one or more".
Also the definition needs to be updated accordingly:

   Definition:

         <!ELEMENT supported-collation-set (supported-collation*)>

         <!ELEMENT supported-collation (#PCDATA)>


9.  Guidelines

Suggest renaming the section to say that this section defines client 
guidelines.


9.4.  Finding Other Users' Address Books

   To find other users' address books, the DAV:principal-property-search

I think this needs a reference to RFC 3744.

   REPORT can be used to filter on some properties and return others.
   To search for an address book owned by a user named "Laurie", the
   REPORT request body would look like this:


10.5.1.  CARDDAV:prop-filter XML Element

   Name:  prop-filter

   Namespace:  urn:ietf:params:xml:ns:carddav

   Purpose:  Limits the search to specific vCard properties.

   Description:  The CARDDAV:prop-filter XML element specifies a search
      criteria on a specific vCard property (e.g., NICKNAME).  An
      address object is said to match a CARDDAV:prop-filter if:

      *  A vCard property of the type specified by the "name" attribute
         exists, and the CARDDAV:prop-filter is empty, or it matches any
         CARDDAV:text-match conditions if specified, and that CARDDAV:
         param-filter child elements also match.

Does this mean that "param-filter" matches in either case, or only
if CARDDAV:text-match is specified?



13.  Security Considerations

   HTTP protocol transactions are sent in the clear over the network
   unless protection from snooping is negotiated.  This can be
   accomplished by use of TLS as defined in [RFC2818].  In particular,
   if HTTP Basic authentication is available,

This needs a reference.

   the server MUST allow TLS
   to be used at the same time, and SHOULD prevent use of Basic
   authentication when TLS is not in use.

 [...]

   This specification currently relies on standard HTTP authentication
   mechanisms for identifying users.  These comprise Basic and Digest
   authentication as well as SSL using client-side certificates.

All three mechanisms need Informative References.


16.2.  Informative References

 [...]

   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

I know that Kurt strongly prefers when RFC 4510 is used for referencing 
LDAP.