Subject: [Sip] bug in date header specification

From: Juha Heinanen <[email-masked]>
Date: Wed, 06 Feb 2002 21:06:47 +0200 (EET)

when defining the date header, sip i-d refers to rfc1123 date.  i think
it should refer to rfc1123 date-time, since date doesn't include time at
all, but date-time does.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Feb 2002 10:03:21 -0500

> it should refer to rfc1123 date-time, since date doesn't include time at

We do explicitly define rfc1123-date, so there is no bug here per se.
The definition is actually copied verbatim from HTTP 1.1, rfc2616, which
specified the format for rfc-1123 date:

HTTP-date    = rfc1123-date | rfc850-date | asctime-date
       rfc1123-date = wkday "," SP date1 SP time SP "GMT"

So, we are consistent with that.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 7 Feb 2002 19:59:15 +0200

> So, we are consistent with that.

ok, i just looked rfc 1123 and there a syntax item called "date" doesn't
include time, but "date-time" does.  in order to avoid confusion, the
first sentence 

The Date header field contains an RFC 1123 date (see [H14.18]).

could be changed to

The Date header field contains an rfc1123-date (see [H14.18]).

because "RFC 1123 date" doesn't include time.

-- juha

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Feb 2002 17:31:59 -0500

> The Date header field contains an rfc1123-date (see [H14.18]).

I just changed to "The Date header field contains the date and time."

-Jonathan R.

---

From: "VIDHI RASTOGI" <[email-masked]>
Date: Fri, 8 Feb 2002 10:56:02 +0530

Hi,
I have a question regarding the To tags in the 1xx response..

Sec 8.2.6.2 of bis-07 states that

   "the UAS MUST add a tag to the To field in the response
   (with the exception of the 100 (Trying) response, in which a tag MAY
   be present)...."

This would mean that a provisional response (say 180) for INVITE request
would always establish an early dialog.
But according to "Sec10.2.2.1" of the same draft,

   "   The early dialog will only be needed if the UAC needs to send a
   request to its peer within the dialog before the initial INVITE
   transaction completes.  This will be the case for all reliable
   provisional responses, which require transmission of PRACK."

This section implies that an early dialog is not mandatory. But the To Tag
present in the 180 response would always result in an early dialog.

Could you please explain the intent behind adding a To-Tag in all the
provisional
responses (except 100 trying). Is there any way to avoid early dialogs, if
the UAC
does not want to establish one.

When the transaction layer receives a provisional response with a To Tag,
does it
need to clone the transaction?

Please let me know if I am missing something here..

thanks & regards
Vidhi

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Feb 2002 02:46:41 -0500

> present in the 180 response would always result in an early dialog.

The text in 10.2.2.1 is saying that even though the tag is there, the
UAC need not construct the actual early dialog. Doing that would only be
needed if it had to send a request or some other such thing.

However, on pondering this further, it occurs to me that we could be in
trouble down the road if the UAC doesn't always build the early dialog.
The reason is that the UAS might send a COMET/UPDATE eventually. If it
sends a 18x first, with a tag, but the UAC ignores the tag and doesn't
build a dialog, and then the UAS sends a COMET/UPDATE, that will not
properly match any existing dialog at the caller. 

The solution is to either (1) mdante the UAC to build an early dialog
for any tags, in which case we probably should relax the constraint on
tags in provisionals, or (2) allow for a COMET/UPDATE to create a
dialog, much like a NOTIFY can for SUBSCRIBE. In the case of (2), this
would be handled entirely within the specification of COMET/UPDATE.

I'll need to ponder that one some more.

> does not want to establish one.

We made tags in all 1xx mandatory to make things simpler, and also,
figured that more information is always better than less. After all, the
UAC is going to want to know which provisional responses are from the
which UASs, and it can't do that unless they are tagged.

> need to clone the transaction?

No, of course not. Transactions and dialogs are independent things. Each
provisional response, with or without tags, is passed from the server
transaction to the TU. The TU deals with dialogs.

Note, however, that how you build your implementation is your choice. If
you have implemented a transaction layer in code that does some dialog
work too, you may need to clone it. 

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 17 Feb 2002 00:29:10 -0500

inline.

> I'll need to ponder that one some more.

After pondering, I decided (2) was the best approach. The UPDATE and
PRACK specs have text mandated creation of early dialogs on 1xx when
those extensions are used.

Thanks,
Jonathan R.