Subject: Use of NOTIFY in KPML (was [SIPPING] Comments on updated KPML draft)

From: "Eric Burger" <[email-masked]>
Date: Fri, 14 Mar 2003 10:08:49 -0500

Inline.

> -----Original Message From: Bert Culpepper [mailto:[email-masked]]
[snip]
> Section 4 - SIP Reporting
> 
> It's stated that the NOTIFY is sent to the Contact contained in an 
> INVITE.  How does this support SIP proxy-based applications? 
> draft-jennings-sip-app-info-00 allows proxies to add, delete, 
> and read 
> App-Info header values.  Or is the use of the NOTIFY method to be 
> limited to the endpoints of a SIP session, and any other 
> entity must use 
> HTTP?

Good point.  I was looking for a mechanism that makes third-party DDOS attacks harder.  Do you have an alternative mechanism for specifying who gets the notification?

> Another issue is that it's stated that a KPML session ends 
> when a NOTIFY 
> is sent, and further KPML sessions must be established with a 
> reINVITE. 
>   Why not allow a KPML document in the body of the 200 OK response to 
> the NOTIFY as specified similarly for HTTP reporting?  This 
> saves three 
> messages between the application and user device.

I don't have a problem with that.  However, I can hear a chorus of objection.  Principally, if you fetch a document, execute it, return a result, and that results in a new document, why aren't you using HTTP?

> According to RFC 3265, NOTIFY requests MUST contain an Event header. 
> What would the value of this header be for KPML bodies?
Whoops.  That would be kpml.  Something for the next draft.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Bert Culpepper <[email-masked]>
Date: Fri, 14 Mar 2003 18:53:47 -0500

Comments inline...

> Good point.  I was looking for a mechanism that makes third-party DDOS attacks harder.  Do you have an alternative mechanism for specifying who gets the notification?

I won't pretend to be knowledgeable in the area of DOS attacks (of any 
kind).  But was it considered that hosts appearing in Via and/or 
Record-Route headers can be trusted (can be authorized and/or 
authenticated if needed)?

> I don't have a problem with that.  However, I can hear a chorus of objection.  Principally, if you fetch a document, execute it, return a result, and that results in a new document, why aren't you…

My quick answer of not using HTTP is the fact that a SIP mechanism is 
now defined :)  Not knowing the motivation behind this addition I can't 
speak more to this point.  However, having to send a reINVITE if an 
entity (specifically a SIP proxy) wishes to "continue" the KPML session 
(or start a HTML/HTTP session) requires more SIP UA functionality in the 
entity than otherwise required.  I'll admit, I don't have any use cases 
in mind at the moment.  But I don't understand this limitation, perhaps 
some explanatory text motivating the defined behavior is enough.

> Whoops.  That would be kpml.  Something for the next draft.

I suspect this may be a sensitive subject, but a few words about an 
implicit subscription be established on receipt of the corresponding 
KPML document, what values to put in the Subsciption-State header 
(depending on the outcome of the above issue), etc. are also in order. 
In short, how to construct a "well-formed" NOTIFY request.

Regards,
Bert

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 Mar 2003 05:05:40 -0500

inline.

Bert Culpepper wrote:

>>> Another issue is that it's stated that a KPML session ends when a 
>>> NOTIFY is sent, and further KPML sessions must be established with a 
>>> reINVITE.  Why not allow a KPML document in the body of the 200 OK 
>>> response to the NOTIFY as specified similarly for HTTP reporting?  
>>> This saves three messages between the application and user device.
>>>
>>
>> I don't have a problem with that.  However, I can hear a chorus of 
>> objection.  Principally, if you fetch a document, execute it, return a 
>> result, and that results in a new document, why aren't you using HTTP?
> 
> 
> 
> speak more to this point. 

I would like to be clear that there is still not design team consensus 
on this point.

  However, having to send a reINVITE if an
> some explanatory text motivating the defined behavior is enough.

I think the bigger meta-issue is what a KPML "session" means. KPML 
provides no means for prompting. Thus, in most applications I can think 
of, you have a single KPML, collect a digit, and use that to kick off a 
real dialog, using VoiceXML or something like that. The KPML draft 
offers one other use case for KPML where there are multiple documents 
without prompting, by using VoiceXML in a server, and collecting digits 
via KPML. I think it is worth considering whether this should be in 
scope or not. The only benefit to this above rfc2833 is the possibility 
of "immediate barge", which is a fringe feature, to be certain. I am 
looking for places to cut back scope of this work so as to move it along 
faster, and this looked like one opportunity.

What kind of applications did people REALLY have in mind for this, and 
were those applications needing anything more than a single KPML 
document before a real dialog is carried out?

-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

---

From: "Steve Fisher" <[email-masked]>
Date: Mon, 17 Mar 2003 12:48:31 -0500

Jonathan,
 
For all of the applications that we have in mind, the digits interpreted
by the KPML document would either move the "far" end of the call to a
media server, thus removing the need for the KPML document (at least for
awhile), or would move the caller from one device to another, which
would result in a new INVITE for the new device anyway. Thus, for our
apps, having to issue a reINVITE to set a new KPML document would be
fine. 
 
We are also very eager to move this work along, as it's quite critical
for many of the services we hope to roll out.
 
Steve

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Rosenberg
Sent: Monday, March 17, 2003 5:06 AM
To: Bert Culpepper
Cc: Eric Burger; SIPPING List
Subject: Re: Use of NOTIFY in KPML (was [SIPPING] Comments on updated
KPML draft)

inline.

-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 <tel:+19739525050> 
http://www.jdrosen.net PHONE: (973) 952-5000 <tel:+19739525000> 
http://www.dynamicsoft.com

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