Subject: [VCARDDAV] UID property

From: "Javier Godoy" <[email-masked]>
Date: Fri, 8 Feb 2008 02:45:11 -0200

Simon and Peter,

I have just read the new version of your draft. It's much more readable that 
the original 2425+2426, congratulations!

Additionally, as the structure and the overall wording are evolving, it 
makes easier to spot other issues.

IIRC, we have discussed about IANA "registered formats" for PHOTO, LOGO, 
SOUND and KEY types, but not about UID.

In Section 5.7.7, UID is required to be "an IANA registered identifier
format" (legacy text from RFC 2426)

1. What is exactly an "identifier format"?  I can think about URI schemes
and URN namespaces but only URI schemes are valid in this context (URN
namespaces are not because the  ":" character is not allowed within TYPE,
which is an iana-token). Thus we have,

UID;TYPE=urn:"uuid:78bc65f7-5eef-45d1-92c9-2555277560db"

instead of

UID;TYPE="urn:uuid":78bc65f7-5eef-45d1-92c9-2555277560db

Of course, UID TYPE could be extended for accepting quoted-strings... do we
want that?

2. Wouldn't a URI substitute the need for a TYPE parameter?

UID:urn:uuid:78bc65f7-5eef-45d1-92c9-2555277560db

This is already possible because the UID value is a text-value...
Then, unless it were useful for something else, it looks like the CONTEXT 
parameter of SOURCE.

(any example in contrary will be welcomed ;-)

3. Should experimental identifiers be allowed? (this could be tricky,
since the prefix "x-" has no particular meaning in either RFC 3986 or RFC
4395).

On the other hand, note that the current ABNF production allows "x-name"
(i.e. tokens "reserved for non-standard use"), but the natural language
requirement from Section 5.7.7 requires it to be registered.

---

Btw, some minor editorial observations:

* The example in Section 5.6.4. (AGENT) uses email addresses @host3.com and
@host.com, instead of example.com, etc (as recommended by BCP 32).

* According to Section 5.7.9, the comment to the ABNF production for
name="VERSION" should be updated (actually it says "3.0").

* For name="SOUND", in comments to snd-inline-param and snd-refer-param, the
string "IANA registered" should be replaced by "image media type as defined
in [RFC 4288]", echoing the modification in section 5.7.6, as well as the
new wording for img-inline-param, img-refer-param and keytype.

Best Regards,

Javier

_______________________________________________
VCARDDAV mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Fri, 8 Feb 2008 08:28:28 -0500

On Thursday 07 February 2008 23:45:11 Javier Godoy wrote:
> I have just read the new version of your draft. It's much more readable
> that the original 2425+2426, congratulations!

Thank you!

> format" (legacy text from RFC 2426)

The wording doesn't specify this exactly:

   The type can include the type parameter "TYPE" to specify the format
   of the identifier. The TYPE parameter value should be an IANA
   registered identifier format.

So if the TYPE parameter is included, then it must be an IANA token. 
Otherwise, everything goes. I'm just being pedantic.

I'd prefer that we choose *one* type (be it restricted to UUIDs or general 
like URNs) and not rely on IANA for maintaining a registry of UID types. Much 
simpler to implement, and we don't really need the flexibility. Moreover, it 
would mean faster look-up if the type is of a fixed length, and UIDs are one 
property where fast look-up is desireable.

> * For name="SOUND", in comments to snd-inline-param and snd-refer-param,
> the string "IANA registered" should be replaced by "image media type as
> defined in [RFC 4288]", echoing the modification in section 5.7.6, as well
> as the new wording for img-inline-param, img-refer-param and keytype.

Thanks, fixed.