Subject: [sipcore] RFC5628 - notifier setting up "cseq" attribute

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 11 Oct 2011 11:58:53 +0200

Hello,

RFC5628 states in section 5:
-------
   If the notifier includes the <temp-gruu> element, it MUST populate
   the element with the most recently assigned temporary GRUU that is
   associated with the instance ID and AOR of the registered contact.
   >>>It MUST also populate ___the element___ with a "cseq" attribute
   corresponding to the first (oldest) currently active temporary GRUU
   that is associated with the instance ID and AOR of the registered
   contact. The value of the "cseq" attribute is set to the value of
   the CSeq header field of the REGISTER request that caused that first
   temporary GRUU to be assigned. <<<
-------

My question relates to the marked sentences above (between >>> and <<<).

Does ___the element___ in the 1st marked sentence refer to:
A) the <temp-gruu> element (defined in RFC5628); or
B) the <contact> element (defined in RFC3680)?

If A) is the answer, then the marked sentences seem to be incorrect as "cseq" attribute is not defined in the <temp-gruu> element in the XML schema in RFC5628 section 9. Most likely "cseq" attribute should be replaced with "first-cseq" attribute.

If B) is the answer, then RFC5628 seems to contradict RFC3680 since:
- RFC3680 states:
        ----
        The optional
           "callid" attribute contains the current Call-ID carried in the
           REGISTER that was last used to update this contact, and the optional
           "cseq" attribute contains the last CSeq value present in a REGISTER
           request that updated this contact value.
        ---
- the 2nd marked sentence states:
        ----
        The value of the "cseq" attribute is set to the value of
           the CSeq header field of the REGISTER request that caused that first
           temporary GRUU to be assigned.
        ----

Thanks for clarification.

Kind regards

Ivo Sedlacek

Ericsson
Technology and Portfolio Management, Terminal Standardization
Sweden
Office: +46 10 711 9382
Fax: +46 10 713 5929
[email-masked]
www.ericsson.com

[http://www.ericsson.com/shared/images/Email.gif]

This communication is confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 15:28:53 -0400

Ivo,

This does seem to be a bug in 5628. Thanks for identifying it.

On 10/11/11 5:58 AM, Ivo Sedlacek wrote:
> *>>>It MUST also populate ___the element___ with a "cseq" attribute
> contact.* *The value of the "cseq" attribute is set to the value of
> temporary GRUU to be assigned. *<<<
> -------

It means (A).

> If A) is the answer, then the marked sentences seem to be incorrect as
> "cseq" attribute is not defined in the <temp-gruu> element in the XML
> schema in RFC5628 section 9. Most likely "cseq" attribute should be
> replaced with "first-cseq" attribute.

Yes, I agree.

> "cseq" attribute contains the _last CSeq value present in a REGISTER
> __request that updated this contact value_.
> ---
> the _CSeq header field of the REGISTER request that caused that first
> temporary GRUU to be assigned_.
> ----

Again, this ought to be "first-cseq".

	Thanks,
	Paul

> *Ivo Sedlacek **
> *
> Ericsson logo
> This communication is confidential. We only send and receive email on
> the basis of the term set out at www.ericsson.com/email_disclaimer
> <http://www.ericsson.com/email_disclaimer>
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Oct 2011 15:45:54 -0400

Ivo - I filed an errata on this.

	Thanks again,
	Paul