comments inline...

And an important question for the WG close to the end of the message!

Rainer 

> -----Original Message-----
> From: Darren Reed [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 23, 2005 6:06 AM
> To: Rainer Gerhards
> Cc: Darren Reed; [EMAIL PROTECTED]
> Subject: Re: [Syslog] New direction and proposed charter
> 
> > > > WG,
> > > > <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG
> > > 
> > > I would put the SD-IDs after the message.
> > 
> > This raises the question of what terminates the MSG part ;)
> 
> Using the above syntax, how do you distinguish between [] at the start
> of the message from actualy SD-ID data?

I used the "short" syntax Chris used in his proposal. The full ABNF
would be:

 <PRI>VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP [SD-ID]s
SP MSG

This follows the IETF-tradition of SP-delemiting header fields. The
SD-IDs are clearly parsable based on that SP. -protcol-15 has the
details (everything from there would still apply).

> 
> I think what's missing from the above, is a ':' and the syntax should
> be:
> 
> <PRI>VERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]: MSG
> 
> The protocol document needs to outlaw ':' being in any field before
> the MSG.
> 
> If you mark "VERSION", "PROCID" and "SD-ID" data as all being optional
> then the format comes back to being very close to what's in use today.

PROCID and SD-ID are optional (but need to have "-" if non-present.
Version, IMHO, should NOT be optional because this will be a live-safer
when we do the next iteration of the protocol in the future. It also
shouldn't be a big deal to stick a "1" character in that position...

> 
> > That would
> > mean we would need to introduce byte-counting, at least I think so.
> 
> Well, without the ':' to say where the MSG starts, I'd have argued
> "How do you tell where SD-ID ends and MSG starts?" vs there just being
> a string of bad SD-ID data following some good SD-ID data.

If we have bad SD-ID data, than we have a bad message. I do not think
that it is appropriate to try to process bad data - there has been too
many security vulnerabilities because of this in recent days...

> 
> As for "but the SD has important information and the MSD does not",
> that's simply a matter of how you structure the message.

I agree on that. Trunction is always bad..

> 
> > > > - replace NUL with an escape sequence upon reception (e.g. <00>)
> > > 
> > > Why not \0 ?
> > 
> > That's another good choice.
> 
> It's also how data gets escaped, in general, in Internet stuff.
> 
> > That was my main message. Is it better to live
> > with that or introduce a CLR on not allowing NUL?
> 
> I'd like to see NUL outlawed from messages.

That would indeed solve a number of issues. The last time we discussed
this, it was consensus that this would be a CLR ("crappy little rule")
that we wanted to avoid. In the sense of the current discussion: do we
still think this is true? 

Question to WG: should we outlaw NUL from MSG?

Rainer

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to