[sip-clf] AD review: draft-ietf-sipclf-format-06

[Robert Sparks <[e-mail]>]

Summary: there are still a few remaining clarifications to capture 
before IETFLC on this document.

This is an update to the AD review on -05. Thanks for addressing the 
majority of the concerns in that review. There are a few that remain, 
and the changes introduced some new ones.

1) Thanks for adding the additional description motivating replacing 
tabs with spaces when creating log entries. The new text says that this 
replacement SHOULD occur when logging bodies or entire messages. Why is 
this a SHOULD? When would you not do this replacement?

The new text says the decision to do this substitution was based on 
there being "no known use of tabs in SIP messages". What possible 
unknown uses are there? It would be better to say "No standardized use 
of tabs". I also think you mean to scope that claim to SIP header 
fields. We allow logging arbitrary bodies, and I don't think we have 
done the research to claim that tabs are meaningless (other than as 
whitespace) in all possible body types.

2) The description of escaping and encoding in Tag=01 is still 
ambiguous. You say you must base64 encode any binary body. You also say 
you must escape CRLFs. I suspect you intend for those to be mutually 
exclusive? What are you expecting the implementer to use to decide if 
the body is binary or not? We should be making much more precise use of 
the terms defined in the media type specifications to make this clear 
(to avoid things like encoding a body that's already encoded).

I don't remember a response to my question about whether log readers 
should unescape anything (apologies if I'm just not finding a response 
as I'm rereading the threads).
I think from the context of the conversations, the intent was that such 
a reader would never unescape (since you want to read these with grep 
and the like). Someone reading a logged body isn't going to be able to 
tell that the logging system re-encoded a body into base64 unless you're 
leaving evidence of having done something somewhere else. Are you?

3) This sentence needs adjusting: " It should be noted that as a result 
of the escaping mechanisms used in this document ('-' and '?') a field 
that would normally be able to parse if it appeared in a SIP header (as 
opposed to a log file) may not be syntactically parsable by a SIP 
parser." I suggest this replacement: "It should be noted that any field 
value that is modified by the escaping mechanisms defined in this 
document before logging ('-','?', and CRLF) is likely no longer 
well-formed SIP and will fail when given to such a parser".

4) Section 4.2's description of To and From tags still doesn't say what 
to do when the tags aren't present (or am I missing that discussion)?

5) (Nit: the change of text from 'Internet-Draft' to 'RFC' highlighted a 
problem for me that was already in -05:
I suggest this change:)
OLD:
    A Base64 encoded version of this log entry (without the changes
    required to format it for an RFC) is shown below.
NEW:
    A Base64 encoded version of this log entry (modified as
    required to format it for an RFC) is shown below.