On Mon, 2009-02-02 at 13:06 -0600, Vijay K. Gurbani wrote: > The text version is available in the IETF archives at: > http://www.ietf.org/internet-drafts/draft-gurbani-sipping-clf-00.txt > > If you prefer the HTML version, you can get it from: > http://ect.bell-labs.com/who/vkg/IETF/I-D/draft-gurbani-sipping-clf-00.html > > Any feedback would be welcome. I like the concept, but there are a lot of details that aren't specified. On the first read, I see: - What separates fields? It appears that a single space is intended, but I don't see that specified. - date (%d) - should read something like: "Date/time of the request, specified as the decimal representation of the integral number of seconds since the Unix epoch." (This representation is time-zone independent.) - authuser (%u) - This specifies the user but not the realm used in authentication. Is it safe to assume the realm is always known from the context? - method (%m) - Presumably this is as appears in the request and is *not* necessarily upcased. But it would be wise to specify the casing rules. - from (%f) - Stated as "The From URI, including the tag." But the tag is not part of the From *URI* and cannot possibly be part of the From URI. Do you mean the From name-addr, the full value of the field? But in that case, spaces can appear in the field, messing up the separation of fields. Or pragmatically, should it be a synthesized name-addr: "<[From-URI]>;tag=[from-tag]"? - contactlist (%c) - This is stated to contain only the Contact URIs, but not their field-parameters, which could be of great interest e.g. in regard to REGISTER responses. But giving the entire name-addr leads to the same problems as with the %f field. - association codes (%x and %y) - What is the permitted syntax? Any non-empty string of non-space printable characters? - What exactly are the events that are logged? E.g., section 4.1.2 refers to a "method event", which is a phrase I've never heard before. Does it refer to SIP requests? In which case, does it mean the *reception* of a SIP request or the *sending* of a SIP request? Or is the intention to log the request/response pair as one line (as would make sense in an HTTP server, but less sense in a SIP proxy that implements forking)? - In regard to the remotehost (%h) field, does "upstream" mean (as it usually does) "the source if the request that initiated this processing"? In which case, there seems to be no place to identify the host/address to which an outgoing request is sent, or the host/address from which an incoming response is received (since that is a "downstream" host). - Some care needs to be taken to describe how CANCEL and ACK are logged. (E.g., ACK for success and ACK for failure *might* be logged differently -- what is intended?) This need is discussed in section 1, but I don't see clear prescriptions of what is to be done. - Are the "..." around %c really necessary? Or is that a legacy of the Apache format? (And if so, does the Apache format allow %c to contain spaces? How does that affect the identification of fields?) - What are the extension mechanisms (other than additional fields at the ends of the two line formats)? Is there any way to identify which software version generated a particular log file, so that the reader can unambiguously determine how to interpret the extension fields? - Why is the to-URI (%t) present in the response format? It's redundant with the same information in the corresponding request format. And if we want such redundant information, why not provide %f as well? - In the examples, a number of spaces between fields seem to have been omitted. (Remember, within <allOneLine>, line-break is removed and does not represent a space, only spaces at the beginning of a line represent spaces.) E.g., this: <allOneLine> 1230756550 192.168.1.2 - REGISTER sip:example.com sip:alice@xxxxxxxxxxx;tag=iu8u76 sip:alice@xxxxxxxxxxx;tag=8hy 8719u@xxxxxxxxxxx 401 - - - </allOneLine> is probably intended to be: <allOneLine> 1230756550 192.168.1.2 - REGISTER sip:example.com sip:alice@xxxxxxxxxxx;tag=iu8u76 sip:alice@xxxxxxxxxxx;tag=8hy 8719u@xxxxxxxxxxx 401 - - - </allOneLine> Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
