Subject: [sip-clf] draft-ietf-sipclf-format-01, optional fields

From: Anders Nygren <[email-masked]>
Date: Wed, 16 Mar 2011 10:32:08 -0600

Hi
I hope this is the last from me for this version.

In the descriptions of the optional fields I think that there some things
that should be clarified.

- Can the optional fields be in any order, or do they have to be sorted
by increasing tag values?

- If an optional field represents a SIP header, e.g. Contact, can appear
several times in a SIP message how are they logged, as several optional
fields with the same tag, or does the all the Contact headers have to be
concatenated in the value of one optional field. (I think that draft-00
explicitly stated that the contact optional field could be repeated, but that
seems to have disappeared in draft-01.)

-If an optional field can be present several times, do they have to be adjacent
or can they be mixed with other optional fields?

- figure 1 shows that the optional fields are before the vendor extensions.
If we have the same format for standard optional fields and vendor extensions
is it still a requirement that they be separate, or can they be mixed.

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 16 Mar 2011 13:08:37 -0400

Inline...

> by increasing tag values?

They can be specified in any order, though I suppose most people would logically do it based on increasing tag number (assuming pre-defined optional field). Do you think this should be further restricted so that implementers MUST implement the pre-defined optional fields in ascending tag number order?
> seems to have disappeared in draft-01.)
This bit of text from -00 was removed as this is one of the areas requiring further discussion. For the Contact header (tag =0x0000) " the text in -00 states "(can be repeated)" but this is unclear as to whether this is logged as a single optional field entry with multiple instances of the Contact header in the Value field or as multiple entries (i.e. one for each Contact) with the same 0x0000 tag. I'm not sure which is better. This is something I hope to have more clarity on coming out of Prague, but maybe we can get a few folks to weigh in on this here on the alias.

> or can they be mixed with other optional fields?

This obviously depends upon what we decide for the above issue as far as whether we allow more more than one optional field entry with the same tag number, but there are no restrictions on this now. Do you have a preference.
> is it still a requirement that they be separate, or can they be mixed.

I don't want to speculate on where the conversations in Prague will lead us, but I would think we should stick with laying out the pre-defined optional elements first and the vendor-specified elements next.

Regards,

Gonzalo

> 
> /Anders
> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf

---

From: Anders Nygren <[email-masked]>
Date: Wed, 16 Mar 2011 11:34:49 -0600

On Wed, Mar 16, 2011 at 11:08 AM, Gonzalo Salgueiro <[email-masked]> wrote:
> They can be specified in any order, though I suppose most people would
> logically do it based on increasing tag number (assuming pre-defined
> optional field). Do you think this should be further restricted so that
> implementers MUST implement the pre-defined optional fields in ascending tag
> number order?

I think it is OK to allow any order.
But I do think that it is important to mention in the spec whatever is
decided.

> This bit of text from -00 was removed as this is one of the areas requiring
> further discussion. For the Contact header (tag =0x0000) " the text in -00
> states "(can be repeated)" but this is unclear as to whether this is logged
> as a single optional field entry with multiple instances of the Contact
> header in the Value field or as multiple entries (i.e. one for each Contact)
> with the same 0x0000 tag. I'm not sure which is better. This is something I
> hope to have more clarity on coming out of Prague, but maybe we can get a
> few folks to weigh in on this here on the alias.
>
>
> This obviously depends upon what we decide for the above issue as far as
> whether we allow more more than one optional field entry with the same tag
> number, but there are no restrictions on this now. Do you have a preference.

I would prefer to have several TLVs with the same tag.
With the addition that if it is a SIP header that is logged they should be in
the same order as in the original SIP message.

> I don't want to speculate on where the conversations in Prague will lead us,
> but I would think we should stick with laying out the pre-defined optional
> elements first and the vendor-specified elements next.

Fine with me.

The real point of this email was just to point out some things that were not
explicitly specified in the draft.

Another thing I noticed is that in the problem-statement it says that the length
limit for all fields are 4096 bytes per field. And currently there is
no mention of the
max field lengths for the mandatory fields and up to 65535 bytes for
each optional
field. I think this is something that should be clarified.

/Anders

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 16 Mar 2011 16:42:39 -0400

> explicitly specified in the draft.
Duly noted.

> field. I think this is something that should be clarified.

I'll probably add some text deferring to the Problem Statement.  I'm copying Vijay on this so he is aware and can update the text in the Problem Statement around the field limits for mandatory vs. optional.

Regards,

Gonzalo