Subject: [Simple] Expires in MESSAGE

From: [email-masked]
Date: Mon, 12 Nov 2001 17:54:32 +0200

Hi All,

draft-ietf-simple-im-01 doesn't currently say anything about the usage of
Expires in MESSAGE. However, it is marked as optional. 

Do we consider the meaning of Expires in a MESSAGE to follow the default
meaning as in bis-05:
	
   The Expires header field gives the date and time after which the
   message (or content) expires. The precise meaning of this is method
   dependent.

...or might we consider adding something special, e.g., Expires: 0 to
indicate,  that the IM is only valid right now, and cannot be forwarded to
email, SMS, whatever?  

Regards,
Aki 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 12 Nov 2001 11:40:33 -0600

>   message (or content) expires. The precise meaning of this is method

This seems like the most logical interpretation for MESSAGE.
This would also seem to encompass the application you have in
mind below. 

>indicate,  that the IM is only valid right now, and cannot be 

Regards,
Sean

---

From: [email-masked]
Date: Mon, 12 Nov 2001 20:56:32 +0200

Hi Sean,

> This would also seem to encompass the application you have in 

I assumed the zero expiry is only defined for REGISTER and SUBSCRIBE, and
maybe similar definitions for its semantics for MESSAGE would be needed?

Cheers,
Aki

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Mon, 12 Nov 2001 13:24:54 -0600

Hi,

I see what you are saying. Should the "Expires: 0" be
interpreted as in a REGISTER or as in an INVITE? I was
thinking it would be treated the same as in an INVITE.
If you receive a MESSAGE with an Expires: that has passed
(or is literally zero), you return a 400 response and 
"drop" the MESSAGE. 

/sean

---

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Nov 2001 15:57:07 -0500

Interpreting Expires to put bounds on the validity of the content
of the message is the correct thing to do. 
 
This is, however, information for the applications (or people) using
the message, not for the routing fabric. In particular, I don't think
it will make sense to reject "expired" messages at, say, a proxy. 
Even at an endpoint, it should be up the the application running
above SIP to decide if it wants to process the "expired" message.
Taking that decision away (by requiring the SIP implementation
itself to reject the expired message) will do harm.
 
RjS
 
-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Monday, November 12, 2001 1:25 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [Simple] Expires in MESSAGE

Hi, 

/sean

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 12 Nov 2001 16:07:52 -0500

Hi, Roberts:
 
Is not that "MESSAGE" another method in SIP like INVITEs, etc.? If so, why
do we not use the same rules (e.g., the interpretations can be made in the
SIP layer)?
 
Radhika

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Monday, November 12, 2001 3:57 PM
To: Sean Olson; [email-masked]'
Cc: [email-masked]
Subject: RE: [Simple] Expires in MESSAGE

 
RjS
 
-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Monday, November 12, 2001 1:25 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [Simple] Expires in MESSAGE

Hi, 

/sean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Nov 2001 16:54:57 -0500

I agree with Robert here. Proxies should ignore Expires in MESSAGE. If a UA
wants to use it in some way, for example to limit the display of an IM on
the screen, that is reasonable.

-Jonathan R.

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

> Sent: Monday, November 12, 2001 4:50 PM
> To: 'Roy, Radhika R, ALCTA'; Robert Sparks; Sean Olson;
> [email-masked]'
> I'm not sure I understand your point.
> 
> Yes, MESSAGE is a SIP method.
> 
> There are no "same rules" to be considered. The core
> spec provides meaning to Expires for REGISTER, and
> (somewhat loosely) for INVITE, and those are different!
> It has no meaning for the other core methods (Expires
> is meaningless for BYE). New methods must specify meaning
> (if any) on their own.
> 
> For MESSAGE, I hold that the Expire header contains the
> period for which the content of the message should be
> considered valid, and it should be up to the applications
> involved to decide what to do with expired messages, not
> the transport mechanism. Different applications are likely
> to need to make different choices. I may have a service where
> it is useful for me to know you invited me to lunch, even
> though I didn't see your invitation until it was too late to
> accept.
> 
> 
> RjS
> 
> 
> > From: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> > Sent: Monday, November 12, 2001 3:08 PM
> > To: Robert Sparks; Sean Olson; [email-masked]'

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 13 Nov 2001 10:07:44 -0500

Hi, Robert:

I just wanted to get the things clarified separating the layers: SIP's
Session Layer and Application Layer.

The second objective has been that the interpretation of all expire headers
of all methods in the SIP layer should not create any conflicts when they
are used in creating the SIP session (Let us now examine whether there are
any conflicts or confusions in the SIP layer).

Further comments inline [RRR]

Many thanks for clarifications!

Radhika

-----Original Message-----

[RRR] Right. Each SIP methods clearly understands what the "expire header"
means in the SIP layer. What the application will do with this information
for each METHOD is outside the scope of SIP.

considered valid, 

[RRR] Excellent! This is what the SIP layer will do in interpreting the
"expire header" of the MESSAGE method. Let us stick to this in defining the
"expire" header in the SIP session layer (as long as it does not have any
conflicts with other expire headers in the SIP layer).

and it should be up to the applications

[RRR] Agreed. The use of the expire header by the application is outside the
scope of SIP. However, if people want to go further for standardization in
building value-added applications, separate proposals can be made. (For
example, MESSAGE sessions can be inter-related to the audio/video sessions

[RRR] I just wanted to get the things clarified separating the layers: SIP's
session Layer and Application Layer (Many Thanks for clarification!!)

RjS

---

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Nov 2001 09:02:11 -0500

And nothing prevents your IM delivery application
from interpreting the request this way. Of course,
you might run into _really_ bad interactions with
the receiver's IM display application when you are
capable of delivering the message immediately. "Oh -
this one's expired - I won't show it".

RjS

> From: Pekka Pessi [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 1:46 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] Expires in MESSAGE
> 
> 
> In message 
> <[email-masked]
> son.se> <[email-masked]> writes:
> ...
> >If want to unregister, I can send a REGISTER with an "Expires" of
> >"1" and wait a second. I can send a REGISTER with an "Expires" of
> >"2" and wait two seconds. Or, I can send a REGISTER with an "Expires"
> >of "0" and wait zero seconds. It all works. Zero isn't a special
> >case at all.
> 
> 	Zero is not magic when handling SIP URLs. However, if you want
> 	to (un)register an IM or PRES or TEL URL, not to speak about *,
> 	the Expires: 0 suddenly has a special magic meaning.
> 
> 	We would like to specify the lifetime of a SIP instant message
> 	within a IM gateway. The GSM system allows users to specify how
> 	long their SMS messages are valid. If, for instance, an SMS
> 	could not have been delivered within 3 hours, it will be
> 	dropped.
> 
> 	We would like to have similar functionality for SIP IM gateways;
> 	sender can select how long her message is kept stored in the IM
> 	gateway if it cannot be delivered instantly. If user wants to
> 	have truly instant delivery, no store-and-forward in any case,
> 	she could use Expires: 0.
> 	
> 
> 						Pekka

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 01:33:54 -0500

I think the MESSAGE draft requires additional wording. Most of the semantics
for zero expirations is now in the section on registrations, where it
belongs. We need a similar kind of thing for IM.

-Jonathan R.

---

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Tuesday, November 13, 2001 10:57 PM
> To: Robert Sparks
> Cc: 'Roy, Radhika R, ALCTA'; Sean Olson; [email-masked]';
> Do you think the (rather imprecise) definition in bis-05 22.19 is 
> sufficient? Or do we need to add more to the message draft?
> 
> Robert Sparks wrote:
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 01:36:23 -0500

> Sent: Wednesday, November 14, 2001 9:02 AM
> To: 'Pekka Pessi'; [email-masked]

To be more preceise, the interpretation at a gateway which would allow it to
be dropped after the expiration is a valid interpretation. But, that is not
to say that the meaning is "this is how long a gateway will retry it for".
Should a client believe that this is the interpretation, and therefore set
Expires:0, it may very well be ignored at the terminating host. Expires is
as it says, it is the lifetime over which this message is useful. After that
time has expired, the message is no longer useful. That applies to all
systems, not just gateways.

-Jonathan R.

---