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

On Wed, Mar 16, 2011 at 11:08 AM, Gonzalo Salgueiro <gsalguei@cisco.com> wrote:
> Inline...
> On Mar 16, 2011, at 12:32 PM, Anders Nygren wrote:
>
> 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?
>
> 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.

>
> - 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.)
>
> 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.
>
>
> -If an optional field can be present several times, do they have to be
> adjacent
> 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.

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.

>
> - 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.
>
> 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

> Regards,
> Gonzalo
>
> /Anders
> _______________________________________________
> sip-clf mailing list
> sip-clf@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-clf
>
>