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:[EMAIL PROTECTED]>,
<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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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.
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
