[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yet another <auth> type


>>>>> "Pat" == Pat Farrell <pfarrell@netcom.com> 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   [
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ | red q blue q[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface