[Note I'm trying out some workflow ideas I had so I'm inflicting them on you
all... I'm keeping the Issues list up to date on the principle that no change
gets made without first being raised as an issue and listed as such. I hope this
will make tracking of changes easier. Rather than issue lots of drafts and have
people comment on different ones I think this might work better. I'll try and
close off each set of additions on an approximately fortnightly basis.]
[see http://www.w3.org/pub/WWW/Demographics/Logging-Issues ]
>Firstly, I think there should be another identifier for authentication name
>(like what is present in the CLFF). (I'm suprised there haven't been more
>request along this line, other than the geographic business being talked
>about earlier, no one has requested additional identifiers?)
The problem here being how to define the manner in which the name is obtained.
Some people are using cookies to abtain authentication names...
It is an oversight though..
 Representation of User name
Not bright to log BASIC auth strings for this purpose
Adding to the
complexity, it would seem different prefix-identifier combos would mean
slightly different things based on whether one was viewing a log file for a
origin server, or a proxy server.
The ide was to try to avoid this. A client and a server should be able to use
the same format and the same fields mean the same thing. This is why I chose cs
for client-to-server instead of in and out. (years of hacking code for big MIMD
>For instance, what does "sc-dns" mean on an origin server? Is that supposed
>to be what the server thinks it's DNS name is?
This should be s-dns or c-dns. I tried to fix this in the draft. some sort of
matrix showing which prefixes are valid is needed. Is it nonsensical given the
addition of the "s-" and "c-" prefixes? Yes these should be explicitly ruled out
>(You can see, we're going to be internally adding two identifiers to the mix
>called clf and clfdate that are only appropriate for CLF style logs. CLF
>style logs will not have #directives either. That's an internal
>configuration issue - I don't think the group or the draft needs to be aware
>of this kind of thing.)
I would suggest placing an x- in front to avoid the slight chance of a name
collision in a future version of the spec.
>So as you can see, it's not just an issue of I, as a origin server, only
>spitting out things I understand, I also have to validate the data fields my
>users attempt to configure, so I need a meaningful way of knowing when to
>draw the line and say "Hey, that field doesn't make any sense to me". And
>right now, there are alot of possible prefix-id's combos that don't make
>sense to me.
Yes, I adgree, I've been looking at the CL-HTTP server on this exact topic..
>If it will please anyone, I will volunteer to make a complete list of what I
>think is sensible/allowable for an origin server, and then you can all call
>me names for leaving foo-bar combo off, and then proceed to explain to me
>it's function. I think the exercise, while boring, may yield a little light
>about how to better define the identifiers.
OK.. even better!
 Matrix showing which prefixes are valid for which identifiers.
Action item DD
>I didn't see it addressed what's suppossed to occur with multiple headers,
>like cs(Accept). Is comma folding a requirement?
Yes, I would have thought implicitly in the HTTP spec??
>And I didn't see it addressed if there should be, or if there can be, any
>hard limits on headers sizes, and how it would be indicated if the log-file
>generator (the server) decided it wanted to cut off the logging of a
>Foo-Bar: header after one K. Is that acceptable practice?
Good plan! How to do it though? Perhaps we could have a - trailing the close
quote "http://fooooooooobaaaaaar.com/vvvvvvvvvvveerrylllllonggggg"- ?? Or is
that liable to be awkward for parsers? How about "!" or ~ ? Feelings anyone?
 "The following identifiers do no require a prefix" change to cannot take
Action item PHB
 Shouldn't the comment id be of type ?
Probably, Action item PHB
 The definition of name type says it's for DNS names, but identifier
method is of type
Probably, Action item PHB
 it's appropriate to say uri-query is of type ?
Probably Not, Action item PHB
 Is comma folding a requirement?
Yes, needs documenting, Action item PHB
 Cutting off egregiously long fields
needs to be done??
 What if a header field is empty
Log should contain - not "" and spec should be clear
 Reword to make it clear that placing the end data at the head of the log
is an option not an obligation.
Action item PHB