RE: Structured Data Elements anywhere in the message?
Anton, I would like to turn to issue 8, that is structured data element placement. I have put together the (few) most important thoughts here: http://www.syslog.cc/ietf/protocol/issue8.html Anton proposed that we a) allow elements only in their own, well-defined field b) merge that with TAG I personally think a) is a good idea while I am very sceptical about b). I would appreciate any more feedback on this issue. I was actually going to raise the issue of TAG field as another issue if we don't address it as part of this one. As you yourself indicated, we are not sure about the whole business of static and dynamic parts of TAG and what it is supposed to be used for. I don't think we can allow such ambiguity in the -protocol. Whatever this field is used for, it must be specified clearly IMO. When I think about what TAG field might be used for, I definitely see an overlap with structured content field in concept. I just wanted to let everyone know that I am now tracking this as issue 16: http://www.syslog.cc/ietf/protocol/issue16.html The link above also contains pointers to two important past discussion threads. I suggest to review them while thinking over this issue. Rainer
Structured Data Elements anywhere in the message?
Hi WG, I am trying to close up the current open issues for protocol before I create new ones ;) I would like to turn to issue 8, that is structured data element placement. I have put together the (few) most important thoughts here: http://www.syslog.cc/ietf/protocol/issue8.html Anton proposed that we a) allow elements only in their own, well-defined field b) merge that with TAG I personally think a) is a good idea while I am very sceptical about b). I would appreciate any more feedback on this issue. Many thanks, Rainer
RE: Structured Data Elements anywhere in the message?
Rainer: I would like to turn to issue 8, that is structured data element placement. I have put together the (few) most important thoughts here: http://www.syslog.cc/ietf/protocol/issue8.html Anton proposed that we a) allow elements only in their own, well-defined field b) merge that with TAG I personally think a) is a good idea while I am very sceptical about b). I would appreciate any more feedback on this issue. I was actually going to raise the issue of TAG field as another issue if we don't address it as part of this one. As you yourself indicated, we are not sure about the whole business of static and dynamic parts of TAG and what it is supposed to be used for. I don't think we can allow such ambiguity in the -protocol. Whatever this field is used for, it must be specified clearly IMO. When I think about what TAG field might be used for, I definitely see an overlap with structured content field in concept. Anton.
