Rainer: I hope I have annoyed you too much with my non-stop comments, but I think we are making good progress!
> > 23. Section 5 & beyond. Why is there a need to specified > > structured data > > *anywhere* within the message. I thought we will designate > a special > > field like TAG for the structured data. This way we won't need a > > special sequence to identify it. Also, I think allowing it > everywhere > > gives too much unnecessary freedom. Harder to evolve > protocol later. > > I did this to allow app software layers/libraries an easy way > to add its information. But we could also specify that it > MUST be immediatley after the tag, with no SPs between the > structured data elements. > > On the special sequence, I think that is actually still > mandatory. Otherwise it may be mistaken by a non structured > data element which co-incidently begins at that location. An > alternative, of course, would be to supply a special sequence > (eg "[]") to indicate that no structured data elements are present. I don't think it is even necessary if we designate it as a field with its own separator that follows it. Suppose we want to say that structured context goes after the TAG field (if we want to leave the latter as is). Then, all we have to say is that if structured content is not there, the field is blank, but it still has to be followed with a separator (presumably a space). So, if TAG is followed by 2 spaces, you know structured content is missing and message starts at the next character. So it could be... Oct 11 22:14:15 myhost2 su: [msgno=1] Message line Or... Oct 11 22:14:15 myhost2 su: Message line But I think an even better solution is to combine structured data and the TAG into one field. The migration strategy for old client could use a special structured content parameter to represent the old tag value. This will also address my concern about TAG being nothing else than another structured content field. So, we could have: Oct 11 22:14:15 myhost2 [tag=su][msgno=1] Message line Or Oct 11 22:14:15 myhost2 Message line Two spaces after HOST mean there is structured content. I think this approach is much cleaner. And is actually closer to the old format. Here the old TAG field is still separated with a space, except spaces are also allowed inside the square brackets as well. Thanks! Anton.
