[uf-discuss] "uid" microformats?

[Etan Wexler]

Tantek Çelik wrote to the Microformats Discuss mailing list on 
2006-04-19 in a message with a title like “[uf-discuss] UID, URL, live 
microformats (was: Microformat auto-discovery WAS: Plazes & 
Microformats)” (<mid:C06BB5C0.6CCEE%25tantek at cs.stanford.edu>, 
<http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html>):

> a UID is *supposed to* uniquely identify the contact or event,
> globally.

Section 3.6.7 of “vCard MIME Directory Profile” (RFC 2426, 
<http://www.rfc-editor.org/rfc/rfc2426.txt>) defines the “UID” type:

> 3.6.7 UID Type Definition
> 
>    To: ietf-mime-directory at imc.org
> 
>    Subject: Registration of text/directory MIME type UID
> 
>    Type name: UID
> 
>    Type purpose: To specify a value that represents a globally unique
>    identifier corresponding to the individual or resource associated
>    with the vCard.
> 
>    Type encoding: 8bit
> 
>    Type value: A single text value.
> 
>    Type special notes: The type is used to uniquely identify the object
>    that the vCard represents.
> 
>    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. The value can also be a non-standard
>    format.
> 
>    Type example:
> 
>         UID:19950401-080045-40000F192713-0052

Tantek asks:

> In addition to marking up the authoritative/canonical URL for a
> contact/event with class name of URL, why not also use that URL for the UID?

Unless the hCard is about itself, such use of a “UID” property is 
incorrect. To do it right, a vCard publisher would make the “UID” value 
a URI that identifies a person or an organization. The publisher would 
also specify a “type=uri” parameter for the “UID” property.

> As far as I can tell, this should work perfectly to answer the question of
> "What do do about UID?".

The semantics of the “UID” type are to identify the subject of a vCard, 
not to identify the authoritative version of a vCard. The “SOURCE” type 
provides a semantics that comes close to identifying authoritative 
version or versions. I suggest the use of the “SOURCE” type if we need 
to find a ready solution within RFC 2426 or RFC 2425. (Also consider an 
XMDP defining an “authority” or “authoritative-version” value for the 
“rel” attribute.)

Section 6.1 of “A MIME Content-Type for Directory Information” (RFC 
2425, <http://www.rfc-editor.org/rfc/rfc2425.txt>):

> 6.1.  SOURCE Type Definition
> 
>    To: ietf-mime-direct at imc.org
>    Subject: Registration of text/directory MIME type SOURCE
> 
>    Type name: SOURCE
> 
>    Type purpose: To identify the source of directory information
>    contained in the content type.
> 
>    Type encoding: 8bit
> 
>    Type valuetype: uri
> 
>    Type special notes: The SOURCE type is used to provide the means by
>    which applications knowledgable in the given directory service
>    protocol can obtain additional or more up-to-date information from
>    the directory service. It contains a URI as defined in [RFC-1738]
>    and/or other information referencing the directory entity or entities
>    to which the information pertains. When directory information is
>    available from more than one source, the sending entity can pick what
>    it considers to be the best source, or multiple SOURCE types can be
>    included. The interpretation of the value for a SOURCE type can
>    depend on the setting of the CONTEXT type parameter. The value of the
>    CONTEXT type parameter MUST be compatible with the value of the uri
>    prefix.
> 
>    Type example:
>            SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
>             %20o=Babsco,%20c=US
> 

The “SOURCE” type pretty well hits the nail on the head.

-- 
Etan Wexler.