[uf-discuss] hCard Comments

[Paul Bryson]

"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 
>> any
>> 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
   key.

   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.

   Type example:

        KEY;ENCODING=b:MIICajCCA....

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-----
Hash: SHA1

Some Message text
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5/UHXXdo3FmeeeYRAhDEAJ0eNCBD4ncYAJt0i+qGxDq47ie8dwCgmfFU
3PBLjF1xtXjZBHpOVtEthMc=
=UCHu
-----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. 
> Hopefully
> we would be smart enough to keep it backward compatible with hCard "1.0" 
> as
> it were, and thus use something like class="vcard hcard", permitting hCard
> 1.0 parsers to consume such future content.  Again, these are just 
> "forward
> looking statements" and are not commitments to an expansion.  We may just
> consider hCard "done" with the current 1.0 version.

Good thoughts.

> PROPOSAL:
>
> We should consider adding one more step and that is:
>
> If no "fn" is present either, then look for a "nickname" element to uses 
> to
> imply both the "fn", and the "given-name", leaving the "family-name" as
> empty.
>
> 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 
> than
> the public.
>
> Proposal captured here:
>
> http://microformats.org/wiki/hcard-brainstorming#Implied_.22FN_and_N.22_Opti
> mization_.28proposal.29
>
> 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.


Atamido