[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: yet another <auth> type
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Pat" == Pat Farrell <firstname.lastname@example.org> writes:
Pat> I'm making a tiny working assumption that adding more <auth>
Pat> fields once we've fielded SDSI/SPKI is simple. If not, then
Pat> perhaps work is needed to make it simple.
I think the draft is a little bit unclear as to how new auth's can
be published. Perhaps the draft should include a section that could
be used as a template for future drafts about new Auth fields. (Maybe
this is in the latest draft, I'm just rereading it, first time since
the June timeframe)
Pat> I recommend tabling this suggestion. Consider it sometime
Pat> down the line.
I would second this.
However, this conversation is several times more than what has been
discussed to date on the list.
Does it seem an unreasonable thing to have *some* sample code by Memphis?
It would be nice for the proponents of binary/S-expr/rfc822 formats
to just *compare* the complexity of their parsing code.
I favour a format that I can compose in my editor, but with well
defined lengths. If all my input is printable (for whatever definition
of printable), then the output is printable. But that doesn't equal
rfc822 which may require specific quoting rules for non-Latin-1 alphabets.
] Temporarily located in balmy Helsinki, Finland | one quark [
] Michael Richardson, Sandelman Software Works, Ottawa, ON | two quark [
] email@example.com http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----