Subject: RE: [Sip] Protocol Action: Session Initiation Protocol Extension for Instant Messaging to Proposed Standard

From: Tan Ya-Ching ICM N PG U ID A 1 <[email-masked]>
Date: Tue, 24 Sep 2002 10:45:26 +0200

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]]
| Sent: 23 September 2002 18:40
| 
| Thank you for bringing this to our attention.  If this is correct, the
| authors will have the opportunity to correct this during the "authors
| 48 hours" period.

Hi,

While you are at it, you may want to add the Max-Forwards header to the
example messages in section 10. Max-Forwards headers are mandatory in RFC
3261.

Perhaps this is too late, but here is my last attempt to bring up the issue
of provisional response again. The last paragraph of section 8 is
self-contradictory.

   It has been suggested that provisional responses should not be
   allowed for pager-model MESSAGE requests.  However, it is not
   possible to require special treatment for MESSAGE, since many proxy
   servers will not be aware of the MESSAGE method.  Therefore MESSAGE
   requests will receive the same provisional response treatment as any
   other non-INVITE method, as described in the SIP specification.

The "same provisional response treatment as any other non-INVITE method, as
described in the SIP specification", is exactly as the first sentence said :
"provisional responses should not be allowed". I have raised the issue of
allowing provisional response for MESSAGE some months ago on the SIMPLE
mailing list but there has been no response from the authors. Here is the
link to the previous mails :

http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001664.html

Regards,
Ya-Ching Tan
_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 25 Sep 2002 09:04:36 -0500

inline

> link to the previous mails :

You are misreading the first sentence. This points out that the language
should be tuned. What the first sentence tried, (and failed) to convey
to you was that some people were saying the Message spec should forbid
provisional responses, that is make them a MUST NOT (an earlier draft
contained exactly this). 3261 makes non-INVITE provisionals SHOULD NOT. 

> http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001664.html

I don't understand your motivation here at all. A provisional
response to a non-INVITE doesn't squelch retransmission over UDP - it
only slows it down. Lay out the timing of messages with and without
an immediate provisional and you'll see that you reduce the total number
of messages by exactly two - and you truly damage recovery time from
loss of the final response.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Sep 2002 09:45:33 -0500

> example messages in section 10. Max-Forwards headers are mandatory in RFC

Thanks for catching that one--we will fix in the author's 48

> link to the previous mails :

No, 3261 says SHOULD NOT, which is not the same as MUST NOT.

> http://mailman.dynamicsoft.com/pipermail/simple/2002-July/001664.html

I thought we had responded to that one--sorry if it fell through the 
cracks. MESSAGE is based on the non-invite transaction model, where 
provisionals essentially do more harm than good. If we wanted to use 
provisionals for the purpose you suggest, we would need a completely new 
transaction model, which does not seem worthwhile.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 25 Sep 2002 10:42:20 -0700

>>    other non-INVITE method, as described in the SIP specification.

we are discussing two issues here.  one is how the UAS TU acts, and the 
other is how the non-INVITE transaction layer acts.  we can more 
stringently enforce UAS behavior for MESSAGE requests if we'd like.  two 
suggestions below (I prefer #1).

thanks,
-rohan

Suggested replacement text #1:
A UAS compliant to this specification MUST NOT respond to MESSAGE 
requests with a provisional response. Provisional responses to 
non-INVITE requests cause more harm than good (they prevent timely 
retransmission of the final response). Note that for 
backward-compatibility reasons, the SIP transaction layer still MUST be 
prepared to receive a provisional response to any request as described 
in RFC3261.

Suggested replacement text #2:
Provisional responses to MESSAGE requests are handled the same way as 
for any non-INVITE request. As discussed in RFC3261 section x.y, a UAS 
SHOULD NOT respond to MESSAGE requests (or other non-INVITE methods) 
with a provisional response. In general, provisional responses to 
non-INVITE requests cause more harm than good (they prevent timely 
retransmission of the final response).

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Sep 2002 15:46:08 -0500

The current version pretty much is the same as your option 2, except 
that avoided repeating the 3261 language. I guess that is a trade off 
between manageablility vs. convenience of the reader. Since 3261 is 
stable now, it is no big deal to add it in the author's 48.

As for option 1, I'm not sure why MESSAGE needs to have any more or less 
restriction here than any other non-invite method. If your desire is to 
strengthen the restriction for all non-invites, then it seems that the 
place to do that is in the base spec, not the extension.

It is worth noting that the original paragraph was there in response to 
an AD suggestion that was later withdrawn as we added more 
congestion-control language. It may be the best thing to do is strike 
the whole paragraph. Provisionals are treated the same as for any other 
non-invite, therefore this draft doesn't need to discuss them.

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 25 Sep 2002 13:54:27 -0700

> stable now, it is no big deal to add it in the author's 48.

option 2 is also more clear than the current language.

> As for option 1, I'm not sure why MESSAGE needs to have any more or 
> less restriction here than any other non-invite method. If your desire 
> is to strengthen the restriction for all non-invites, then it seems 
> that the place to do that is in the base spec, not the extension.

well, since the base spec didn't say this, and won't be updated for a 
while, we certainly have a legitimate reason to say this now for all NEW 
non-INVITE extension methods.

> non-invite, therefore this draft doesn't need to discuss them.

i really want us to prevent folks from sending provisionals and CANCELs 
for non-INVITE.  I don't think that's a lot to ask.

thanks,
-rohan

>> we are discussing two issues here.  one is how the UAS TU acts, and 
>> the other is how the non-INVITE transaction layer acts.  we can more 
>> stringently enforce UAS behavior for MESSAGE requests if we'd like.  
>> two suggestions below (I prefer #1).
>> thanks,
>> -rohan
>> backward-compatibility reasons, the SIP transaction layer still MUST 
>> be prepared to receive a provisional response to any request as 
>> described in RFC3261.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 25 Sep 2002 16:07:44 -0500

> for non-INVITE.  I don't think that's a lot to ask.

Regardless of whether I agree that we should forbid provisionals for 
non-invite, I really hate to encumber MESSAGE with that discussion at 
this point in time--The IESG has approved the current version with a few 
unrelated edits. This seems a bit much for an author's 48 change.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Sep 2002 01:43:02 -0400

I strongly concur with Ben; the MESSAGE spec is not the place to change 
the wording on the strength of sending provisionals for non-INVITE requests.

-Jonathan R.

Ben Campbell wrote:
> Rohan Mahy wrote:
> 
>> i really want us to prevent folks from sending provisionals and 
>> CANCELs for non-INVITE.  I don't think that's a lot to ask.
> 
> 

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