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

Re: SD IDs (was: RE: [Syslog-sec] Syslogprotocoldraft(draft-ietf-syslog-protocol-11.txt))



The argument for x- as opposed to x is

a) already widely used in SMTP (and elsewhere?)

b) a bit more unusual - we may want to start something with x one day, or have -
in position two ie of the 1000 or so possible combinations of two characters, we
are keeping 999 to ourselves for future expansion and leaving one to enterprise,
which in this context, seems reasonable.  The general idea is a good one and we
may want to expand it in future in  directions we cannot currently anticipate so
let's keep our options open.

As to how to word it, how does SMTP?  (In RFC0822, I found
 "The prefatory string "X-" will never  be  used  in  the names  of
Extension-fields.  This provides user-defined fields with a protected set of
names.")


Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "syslog" <syslog-sec@employees.org>
Sent: Wednesday, May 11, 2005 4:53 PM
Subject: RE: SD IDs (was: RE: [Syslog-sec]
Syslogprotocoldraft(draft-ietf-syslog-protocol-11.txt))


Hi WG,

Alex suggestion (below) sounds good to me. I tend to reserve the first
character "x" for vendor extension and skip the part about the hyphen.
So everything is managed by IANA, except those SD-IDs starting with "x".

Are there any concerns?

Rainer

> ***ALEX: I think this is expressed a bit awkward.  Also, why
> require vendor extensions to use 2 extra characters ("x-") to
> designate them as such?  You could say that IANA SD-IDs will
> have no hyphen in the second position, whereas vendor
> extensions always need one (but then why restrict it to the
> letter "x"?)  Or, to make it even more compact, you could say
> that IANA SD-IDs will start with any letter other than "x",
> while vendor extensions always MUST start with the letter
> "x".  I don't think the extra hyphen is needed.  Given that
> we may see multiple SD-Elements in syslog messages and there
> are length restrictions, it seems prudent to be very
> economical with requiring additional positions.
>

_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec