Either solution would work, I have no preference either way. :)

Cheers

Andrew




-----Original Message-----
From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] 
Sent: Thursday, 1 December 2005 7:38 a.m.
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting


I think for TCP mapping a transport header with message size would be more
appropriate framing than termination character. 

Thanks,
Anton.  

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross
> Sent: Wednesday, November 30, 2005 7:19 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> 
> 
> Rainer,
> 
> That sounds good to me at this stage, and it keeps the door 
> open. I would prefer to see all binary data encoded in some 
> "safe" format like base64. It just makes logging the data to 
> file much easier. For instance, if the binary data contained 
> a LF character, when it was logged to disk, it would end up 
> as two separate messages when opened in notepad etc.
> 
> Also, if we are to transport syslog over TCP at some stage, 
> we need to keep a delimiter character free from use in the 
> message. Again, a LF would be a good choice for this delimiter.
> 
> Cheers
> 
> Andrew
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Rainer Gerhards
> Sent: Wednesday, 30 November 2005 9:26 p.m.
> To: [EMAIL PROTECTED]
> Subject: [Syslog] #3 NUL octets, #4 binary data, #8 octet-counting
> 
> 
> Hi WG,
> 
> I have received notes via private mail telling me there seem 
> to be some existing (and eventually soon upcoming) valid use 
> cases for binary data in syslog. I think there is no point in 
> arguing whether that's fortunate or not. It simply looks like 
> that's the way it is. I do not like the idea of breaking 
> existing use cases for syslog (because that will only lead to 
> implementors ignoring the spec and the story of syslog 
> inconsistencies continues...). As such, I think we need to 
> provide at least some minimal support for it (aka "not outlaw it").
> 
> At first, this implies that NUL octets may be present in the message.
> 
> I propose that we write text that discourages the use of NUL, 
> but allows it if needed. That text should also allow, but 
> discourage, a receiver to modify messages containing NUL. 
> With that, we allow the use case, but do not make it a "show 
> stopper" for implementing compliant software. This would also 
> be pretty much in sync with what we currently find in 
> practice, so it is already expected behaviour. Finally, such 
> text would caution implementors that when NUL octets are 
> present, chancs are high that eventually present digitial 
> signatures will be broken. In my point of view, that's fair 
> and efficient.
> 
> Chris proposal for #5 (character encoding) also provides an 
> elegant solution for binary data. We can use something like:
> 
> [enc="binary"]
> 
> or
> 
> [enc="base-64"]
> 
> I do NOT intend to specify this - I think it should be in the 
> scope of a separate document specifying the use of binary 
> data. Then would also be the right time to discuss all issues 
> that arise out of it. For now, I just would like to keep the 
> door open.
> 
> Finally, I propose to extend Chris format so that the message 
> size can be conveyed. This has been brought up several times 
> and I think a clean solution is now obvious:
> 
> [enc="utf-8" lang="en" size="MSG-size-in-octets"]
> 
> MSG-size-in-octets would be the size of the MSG part (just 
> that!) in octets. Counting just the MSG part is sufficient, 
> as the rest of the message consists of fields properly 
> delimited. The size is probably most useful for binary data.
> 
> Please comment.
> 
> Rainer
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 
> 
> _______________________________________________
> Syslog mailing list
> Syslog@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/syslog
> 


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

Reply via email to