Subject: [SIP] Expires header in MESSAGE

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Thu, 6 Jun 2002 13:49:36 +0200

In SIP RFC 3261, only INVITE and REGISTER may include the Expires header.
Section 20.19 states that "The precise meaing of this (Expires header) is
method dependent". The meanings of Expires in INVITE and REGISTER are
explained in detail in RFC 3261 (and in draft-ietf-sip-event for SUBSCRIBE).
For example, in the section specifying UAS processing of the INVITE, there
is a paragraph explaining how the UAS should handle the Expires header if
one is present in the INVITE.

draft-ietf-sip-message-04 allows MESSAGE to contain the Expires header, but
does not explain the precise meaning of it. 

I propose to add the following statements to the draft:

Section 4. UAC Processing

   The UAC MAY add an Expires header field to limit the
   validity of the message content. An Expires header
   field with a value of "0" is an indication to the gateway
   or store-and-forward server that the message MUST
   be delivered immediately.

Section 7. UAS Processing

   If the MESSAGE request contains an Expires header
   field, the UAS sets a timer for the number of seconds
   indicated in the header field value.  When the timer 
   fires, the message is considered to be expired. If the
   message expires before the UAS displays the message 
   to the user, the UAS should discard the message. A 
   UAS which is a store-and-forward relay MUST NOT 
   forward the message after the timer fired. When a
   message relay forwards a message, any Expires 
   header field present in the MESSAGE request MUST 
   be copied into the forwarded message. If there is a 
   delay in forwarding the message, the UAS MUST 
   substract the difference between time of forwarding 
   and receipt of the request from the Expires value.

   A UAS receiving a MESSAGE request containing an
   Expires header field with a value of "0" MUST display the
   message to the user immediately. If the UAS is a
   store-and-forward relay, it MUST forward the message
   immediately.

- Ya-Ching

_______________________________________________
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: Ben Campbell <[email-masked]>
Date: Thu, 06 Jun 2002 14:31:06 -0500

I agree with weekening the language to SHOULD NOT. I can invision 
applications where it would make perfectly good sense to display an old 
message with a warning that it has expired. So the expires header would 
really be a fairly strong hint on behavior, but the sender cannot assume 
that the recipient will never see expired messages.

Jonathan Rosenberg wrote:
> I think the general usage of Expires that is discussed here is good, and 
> consistent with the usage envisioned for the header. However, I would 
> weaken many of the strengths below from MUST NOT or MUST to SHOULD NOT 
> or SHOULD.
> 
> -Jonathan R.
> 
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
>>    indicated in the header field value.  When the timer    fires, the 
>> message is considered to be expired. If the
>>    message expires before the UAS displays the message    to the user, 
>> the UAS should discard the message. A    UAS which is a 
>> store-and-forward relay MUST NOT    forward the message after the 
>> timer fired. When a
>>    message relay forwards a message, any Expires    header field 
>> present in the MESSAGE request MUST    be copied into the forwarded 
>> message. If there is a    delay in forwarding the message, the UAS 
>> MUST    substract the difference between time of forwarding    and 
>> receipt of the request from the Expires value.
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jun 2002 15:18:14 -0400

-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: "Ken Jordan" <[email-masked]>
Date: Fri, 7 Jun 2002 07:03:33 -0400

The concern I raised in SIP-Implementors regarding the detrimental effect of
transmission delays on the intended value for the expires header (delays
which includes UAS delays in forwarding) would be handled by Tan Ya-Ching's
proposed text below:

    In Section 7. UAS Processing

	If there is a delay in forwarding the message, the UAS MUST subtract the
difference between time of forwarding and receipt of the request from the
Expires value.

I would like to see this text added with Jonathans recommended changes.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: Thursday, June 06, 2002 3:18 PM
> To: Tan Ya-Ching ICM N PG U ID A 1
> Cc: 'Ben Campbell'; [email-masked]'
> Subject: Re: [SIP] Expires header in MESSAGE
>
>
> > Section 20.19 states that "The precise meaing of this
> (Expires header)
> > is
> > is a paragraph explaining how the UAS should handle the
> Expires header
> > if
> > draft-ietf-sip-message-04 allows MESSAGE to contain the
> Expires header,
> > but

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jun 2002 11:41:23 -0400

I do not support the inclusion of this text. We have not done this for 
INVITE, and I think the notion of setting expirations that are near in 
value to the transmission or processing delays is fundamentally a bad 
idea. They will generally result in race conditions, whereby whether the 
recipient even gets the data depends on the specific latency for that 
message, or the number of proxy hops, and so on. Such race conditions 
are to be avoided. Sending messages into the network just so they can be 
discarded is a waste of bandwidth and overall resources. I do not think 
we should do anything to encourage such usages, as the text below would.

Thanks,
Jonathan R.

Ken Jordan wrote:
>>>method dependent". The meanings of Expires in INVITE and
>>
>>REGISTER are
>>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Jun 2002 11:14:54 -0500

> we should do anything to encourage such usages, as the text below would.

That makes sense for small transmission and processing delays. But what 
about store and forward situations, where the delay time could be very 
long? This situation pretty much breaks the whole idea of delta time 
Exires headers.

---

From: "Ken Jordan" <[email-masked]>
Date: Fri, 7 Jun 2002 14:08:58 -0400

Jonathan,
Thank you for your patience and response.

It is difficult for clients to know what value to set for the expires value
since, as you point out, there's no way to know what path will be taken
(i.e. what UAS or proxy with their associated delay will be used, number of
hops, etc).  I agree with the implicit fact that handling the expires field
in a meaningful way in all uses across SIP and accounting for end-end delays
(which will include UAS delays in processing the messages) is a complicated
and slippery slope.

Given that timeouts are in place to handle long end-end delays, is it
possible for a UA or proxy to receive an INVITE or REGISTER that is near
expiration or has already expired?  If so, how would the UA or proxy know?

What recommendation would you give on how a UA determines the minimum
expires value that should be used?  (You indicated in an earlier response
that the expires value should be several orders of magnitude larger than the
transmission delays.)  Should it be substantially larger than the timeout
value (timeout=32 seconds)?

Does bis-09 already have a recommended value or method for determining it?

Thanks again for your help,
Ken

> Sent: Friday, June 07, 2002 11:41 AM
> To: [email-masked]
> Cc: 'Tan Ya-Ching ICM N PG U ID A 1'; 'Ben Campbell'; [email-masked]
> > difference between time of forwarding and receipt of the
> request from
> > the
> > Expires value.
> >
> >>>For example, in the section specifying UAS processing of
> the INVITE,
> >>>there