Subject: Re: [sip-clf] Request for Consensus: Adopt ASCII

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 02 Dec 2010 14:22:31 -0600

On 12/01/2010 12:47 AM, Gonzalo Salgueiro wrote:
> Peter -
>
> There might be value in converging as a group on many of these
> lingering issues that have recently been raised before submitting
> the -00 version of the WG doc.

Gonzalo: Here is some feedback from me on some of the items below,
partly in my role as a co-author and partly as a WG participant.

> These issues include:
>
> - Should we use indexing at all versus tab delimited? or should we
> stick with just pointers? or go with do away with the indexing but
> still log the field lengths?

I can go either way.  I see the benefit of indexing (fast searches.)
If we decide to go with tab delimiters (or space delimiters, as
Hadriel had suggested [1]), then we should ensure that a record
length appears in a fixed field to allow readers to skip records
that are not of interest.

> - Update the presentation of optional fields from something
> like:<mandatory fields>	01,07,foo.bar	02,0b,hello world      to
> something like:<mandatory fields>  1="foo.bar" 2="hello world"

I like the first one better.  The length allows quick reading and
skipping.

> - Should we add vendor specified fields in the optionally logged
> portion (using enterprise numbers or related mechanism)

Sounds reasonable.

> - What format do we use to log a field that cannot be parsed?

I had suggested a "?" in an earlier email; see [2].

> - How do we log a missing field? Stick with - and come up with some
> escape sequence for it? or do we log all fields which are
> interpreted/derived not use "", but all fields which are the literal
> string use " ?

Just stick a "?" in it as well.

> - While we have to consensus that logging bodies (SDP and otherwise)
> is capped at 4k and optional, how much of of this should be
> specified in the Problem Statement and how much in the ASCII draft?

Specifying the maximum length should be in the problem-statement draft.

> For something that is considered option, do we need to decide on how
> to represent a multi-line body in a format which tries to use a
> single text line?

Can we not just put the literal "\r\n" --- at least for SDP bodies,
since that is what most folks appear to want to log.  I doubt that
folks will log bodies consisting of GIF images or other binary
bodies.  The literal "\r\n" will also handle XML (won't be pretty,
but at least it'll be there.)

Thanks,

[1] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00394.html
[2] http://www.ietf.org/mail-archive/web/sip-clf/current/msg00399.html

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 2 Dec 2010 16:25:48 -0500

> Just stick a "?" in it as well.

Hi, 

I see a need for a distinction between a tag which is not present (because e.g. it's a new INVITE with no from tag, or a request and hence has no response code) - versus a message in which the tag or response code failed to parse. 

? for both does not allow this distinction. 

Peter

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 02 Dec 2010 15:59:38 -0600

On 12/02/2010 03:25 PM, Peter Musgrave wrote:
> I see a need for a distinction between a tag which is not present
> (because e.g. it's a new INVITE with no from tag, or a request and hence
> has no response code) - versus a message in which the tag or response
> code failed to parse.
>

Indeed, I was afraid that we may want to make that distinction.

If we want to make that distinction, then a variation of what
you suggested earlier ("Stick with - and come up with some escape
sequence for it") seems appropriate.  Or maybe some sort of a
digraph (--) or trigraph (---).

Thanks,

- vijay

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 3 Dec 2010 08:07:52 -0500

Hi Vijay, 

Maybe we can do something simple (but not perfect)
- for empty field
? for unparsable field

In practice a tag or other field which contains the literal text - or ? would not be distinguishable from empty/unparsable, but I view that as a very remote case. We could go down the rat-hole of escaping them, but then e.g. a tag could legitimately contain the exact escaped sequence etc. etc. 

Peter

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 03 Dec 2010 08:48:03 -0600

On 12/03/2010 07:07 AM, Peter Musgrave wrote:
> In practice a tag or other field which contains the literal text - or
> ? would not be distinguishable from empty/unparsable, but I view that
> as a very remote case. We could go down the rat-hole of escaping
> them, but then e.g. a tag could legitimately contain the exact
> escaped sequence etc. etc.

Peter: I agree that a tag field consisting of only one character --- an
unadorned "-" --- and the Call-ID field consisting of only one character
--- an unadorned "?" --- will be extremely rare in practice (although
ABNF allows them.)

If these characters are part of a sequence of other characters, then
of course, there is no ambiguity.  Ambiguity arises if they are the
only character for that field, and in such a case, we could say
something like the following:

   If the To- or From- tag fields contain only one character, and that
   character is the literal "-", the implementation SHOULD insert an
   escaped %2D in the SIPCLF record.  Similarly, if the Call-ID field
   contains only one character, and that character is the literal "?",
   the implementation SHOULD insert an escaped %3F in the SIPCLF record.

This way, the SIPCLF log record can still contain "-" and "?" and if
this is the only character in the field, then the reader can assert
that the fields were empty and unparseable, respectively.

Thanks,

- vijay

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 4 Dec 2010 11:11:54 -0500

Hi Vijay, 

That works for me.

Peter