I meant to "Reply to all" on this...per my reference in response to Dean's email...
-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH]
Sent: Thursday, June 27, 2002 2:47 PM
To: 'frank.derks@philips.com'
Subject: RE: [Sipping] draft-watson-sipping-req-history-01
Hi Frank,
A new draft was submitted on Monday and is waiting to make it's way through the queue. There is a copy available if you'd like to look at this before it does:
http://home.attbi.com/~mbarnes42/IETF/draft-watson-sipping-req-history-02.txt
The major changes are:
- More detailed specification of the security requirements associated with Request history, documented in section 5 Security Considerations, per the issue raised in the SIP Interim meeting.
- Further clarification of the optionality aspects (section 4.3) of Request History wrt requirements that it puts on applications which might make use of such a mechanism.
Although this draft might be useful for QSIG interworking, the intent is indeed to provide a basic building block for the use of SIP based applications.
Feedback on the draft in general would be appreciated, most specifically on the updated sections. And yes, the authors would also certainly like this to be accepted as a WG document, but it is likely that this needs to be preceded by some discussion on the new content.
Regards,
Mary H. Barnes
mbarnes@nortelnetworks.com
972-684-5432
Wireless 817-703-4806
-----Original Message-----
From: frank.derks@philips.com [mailto:frank.derks@philips.com]
Sent: Thursday, June 27, 2002 6:52 AM
To: sipping@ietf.org
Subject: [Sipping] draft-watson-sipping-req-history-01
Having read this read this draft, I was wondering why the authors have not
produced a new version. Because, as indicated in the draft, SIP currently
does not have certain potentially useful"notification mechanisms" (and I
am not referring to SIP NOTIFY).
Notifications that help the participants involved in session establishment
to take action based on "why" a request arrived and "from where" it arrived,
could greatly enhance the services offered.
Take the following example. When Alice calls Bob and is diverted to Carol,
it might be useful (depending on what you want to do) to have:
- a way to inform Alice and Carol about what't going on. I.e. that the call
is being diverted and why it is being diverted.
- a way to inform Carol about the party that was originally called and the
party that is diverting the call
- preventing this information from being presented
- etc.
There are many more possibilities. These issues surfaced when we were
trying to look at some interworking scenarios between QSIG supplementary
services and SIP. The lack of this sort of functionality would reduce
the QSIG functionality in an interworking scenarion
Not surprising, this type of notifications, is also useful in a "pure"
SIP environment. Which sort of brings me back to my original question.
I support that the SIPPING and SIP groups should probably make this into
an item to be addressed.
Any other views?
Regards,
Frank