[uf-discuss] hCard Comments
paul at msn.com
Thu Dec 22 00:17:38 PST 2005
"Tantek Ç elik" wrote...
> On 12/21/05 3:24 PM, "Paul Bryson" wrote:
>> Key is mentioned specifically in the spec, but there doesn't seem to be
>> definition indicating how exactly it should be implemented. What kind of
>> key to use? Is there a link to a file or base64 encoded inline?
> Any such questions about "what kind of key to use" are left to the RFC.
> hCard doesn't change the semantic of the key property.
>From the RFC:
Type purpose: To specify a public key or authentication certificate
associated with the object that the vCard represents.
Type encoding: The encoding MUST be reset to "b" using the ENCODING
parameter in order to specify inline, encoded binary data. If the
value is a text value, then the default encoding of 8bit is used and
no explicit ENCODING parameter is needed.
Type value: A single value. The default is binary. It can also be
reset to text value. The text value can be used to specify a text
Type special notes: The type can also include the type parameter TYPE
to specify the public key or authentication certificate format. The
parameter type should specify an IANA registered public key or
authentication certificate format. The parameter type can also
specify a non-standard format.
First, you specify the encoding using "encoding", which hasn't been used
anywhere else up to this point. It's other uses involve photos, sounds, and
other binary files that are realistically never placed inline. And
specifying them explicitly isn't needed because we use src="" and href="".
But we could theoretically place the key inline.
Here is an actual signing that is done in an email.
-----BEGIN PGP SIGNED MESSAGE-----
Some Message text
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 22.214.171.124 by EQUIPMENTE.DE
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
You will notice the entire message is encompassed about by the key. It also
includes version information so that you know how to authenticate the key.
Some other clients will place the email text in one attachment and the key
(BEGIN to END SIGNATURE) in another.
The vCard RFC, however, does not seem to include any of this information.
Honestly, I have no idea what kind of key they are suggesting they are
using, nor what data they are trying to authenticate. This part of the RFC
seems incredibly ambiguous. Am I missing something or reading this wrong?
I'm not complaining because I really don't know how you would validate some
XHTML data, especially using an element that is the child of the element you
are trying to authenticate.
>> Is class="hcard" ever used?
> No. Though it has been suggested that should hCard ever expand beyond
> vCard, we could use class="hcard" to indicate such an expansion.
> we would be smart enough to keep it backward compatible with hCard "1.0"
> it were, and thus use something like class="vcard hcard", permitting hCard
> 1.0 parsers to consume such future content. Again, these are just
> looking statements" and are not commitments to an expansion. We may just
> consider hCard "done" with the current 1.0 version.
> We should consider adding one more step and that is:
> If no "fn" is present either, then look for a "nickname" element to uses
> imply both the "fn", and the "given-name", leaving the "family-name" as
> This would allow you to write in your example:
> <span class="nickname">Atamido</span>
> For the "public" display and have it work and have it imply an "fn" and
> "n/given-name". Then in the admin case you would have:
> <span class="fn">Paul Bryson</span>
> <span class="nickname">Atamido</span>
> And it would use the "fn" to imply the "n", and everything would work as
> before for that case. The net result is that the admin sees more info
> the public.
> Proposal captured here:
> What do folks think?
Your proposal seems very clean. If n can fall back to fn, then also falling
back to nickname would not seem like a stretch, and it simplifies things
within the HTML itself.
More information about the microformats-discuss