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

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

Regards,

Gonzalo

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