Subject: RE: [Simple] -05 MESSAGE and Expires header

From: [email-masked]
Date: Mon, 22 Jul 2002 17:08:20 +0300

Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so.

Should we do something like that or are these issues part of the ieprep work?

Regards,
Hisham

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Monday, July 22, 2002 4:51 PM
> To: Khartabil Hisham (NMP/Helsinki); Jonathan Rosenberg; Adam Roach
> Cc: Ben Campbell; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [Simple] -05 MESSAGE and Expires header
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > - When is a message urgent but does not require immediate delivery?
> 
> Are you proposing an "Urgency" header, or confusing priority with
> urgency? I'll see if I can accurately demonstrate their 
> orthangonality.
> 
> High Priority, Low Urgency:
>   Note to new residents: failure to file income taxes by April
>   15th can lead to substantial penalties.
> 
> Low Priority, High Urgency:
>   You have 5 minutes to come by and pick up the rest of your lunch
>   or I'm going to throw it away.
>                              
> High Priority, High Urgency:
>   There's a tornado coming your way!
> 
> Low Priority, Low Urgency:
>   Llamas can make four distinct noises: humming, clucking, 
> orgling, and
>   a high pitched, rhythmic alarm sound.
> 
> /a
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Jul 2002 09:28:56 -0500

[email-masked] wrote:
> Well, you read my mind. I wanted to get consensus that Priority header 
> is for user interface purposes only before I do so.

RFC 2076 says this about Priority:

3.9 Quality information

    Can be "normal", "urgent" or "non-   Priority:      RFC 1327, not for
    urgent" and can influence                           general usage.
    transmission speed and delivery.

Which leads me to believe that it may *not* be for UI purposes only.

> Should we do something like that or are these issues part of the ieprep 

Good question; especially in view of the IEPREP discussion at the
SIPPING WG meeting in Yokohama...

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Ben Campbell <[email-masked]>
Date: Mon, 22 Jul 2002 11:15:56 -0500

> Well, you read my mind. I wanted to get consensus that Priority header is for user interface purposes only before I do so.

As I mentioned in a separate mail, priority _can_ be used for routing 
purposes. But it means something different than urgency.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Jul 2002 17:54:14 -0400

I still believe that we should follow Robert's advice as offered in the 
SIMPLE session. We are now down to arguing the interpretation of the 
terms priority, urgency, and expiration. This is an argument for which 
there is no right answer. Since 3261 allows each method to define a 
method-specific meaning for Expires, we are well within the scope of the 
specifications. No one has found a technical flaw in this approach. At 
least several people (myself included) feel its reasonable if not 
perfect. Robert's advice was to leave it be unless people found it to be 
broken. I would rather finish this specification finally, rather than 
debating the relative interpretations of the terms in play here.

-Jonathan R.

Ben Campbell wrote:
>>Should we do something like that or are these issues part of the
> 
> ieprep work?
> 
>>Regards,
>>Hisham
>>
>>
>>

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2002 17:07:31 -0500

I concur. I have had many responses suggesting we leave it alone, and 
only a couple of people arguing for a change.

The draft currently leaves most of the handling of Expires as a matter 
of local policy. I think that is the appropriate level of detail for the 
MESSAGE specification. Since the majority of the controversy concerns 
store and forward relays, I will echo Sean's statement that if we choose 
to standardize such relays, that specification if free to further 
constrain relay behavior.

Also, as mentioned in the wg meeting, this discussion belongs on the SIP 
list, as it concerns a SIP work item. I have tried moving it there, but 
it doesn't seem to stick. Please direct any future discussion to the SIP 
list.

Jonathan Rosenberg wrote:
>>>> urgency? I'll see if I can accurately demonstrate their orthangonality.
>>>>
>>>> Llamas can make four distinct noises: humming, clucking, orgling, and

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Jul 2002 17:08:25 -0500

orthangonality.

---

From: Bobby Sardana <[email-masked]>
Date: Tue, 23 Jul 2002 15:11:51 -0700

Comments inline.

> debating the relative interpretations of the terms in play here.

I agree that it is important to finish the specification than to debate
about the merits of "Expire" and "Priority". The comment I want to make is
that allowing "Expire" to be method specific allows it to be mis-used,
maybe not in case of MESSAGE, but in still-to-be-articulated methods. We
have the opportunity to fix it now by picking a header, like Priority,
which is more verbose. Also, as an implementor, I would not have to pick
the spec to figure out what specific meaning does "Expire" have and in what
method context. If there are self-descriptive headers, then their use would
be of help -- both from an implementation & understanding purposes.

with regards,

Bobby Sardana.
[email-masked]

--
___________________________

Bobby Sardana |  SEVEN
Software Engineer, Engineering
___________________________

901 Marshall St.
Redwood City, CA 94063
650.381.2535 (v)
650.216.6455 (f)
[email-masked]
www.seven.com