Subject: [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt

From: [email-masked]
Date: Mon, 25 Feb 2002 06:22:20 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Generic Request History Capability - Requirements
	Author(s)	: M. Watson et al.
	Filename	: draft-watson-sipping-req-history-00.txt
	Pages		: 7
	Date		: 22-Feb-02
	
Many services that SIP is anticipated to support require the 
ability to determine why and how the call arrived at a specific 
application.  Examples of such services include (but are not limited 
to) sessions initiated to call centers via 'click to talk' SIP URLs 
on a web page, 'call history/logging' style services within 
intelligent 'call management' software for SIP UAs and calls to 
voicemail servers and call centers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-watson-sipping-req-history-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-watson-sipping-req-history-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-watson-sipping-req-history-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Mon, 25 Feb 2002 10:44:50 -0500

From:  Tom Gray@MITEL on 02/25/2002 10:44 AM

Looking at this document does not reveal a list of requirements but just a list
of proposed capabilities that may or may not require additions to the SIP
protocol. For this to be a useful requirement document, this list of
capabilities must be linked to a set of problems that need to be solved. Indeed
the list of problems would be the nub of the document. For example what problem
is the 'capability-req' capability intended to solve. Just what is 'Issuer-req'?
The description in the draft doesn't specify this beyond not identifying he
reason fro its proposal. What trade-offs if any will  be required for the
solution to these problems?

[email-masked] on 02/25/2002 06:22:20 AM

Please respond to [email-masked]

To:   ietf.org
cc:   [email-masked] (bcc: Tom Gray/Kan/Mitel)

Subject:  [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]
ftp://ftp.ietf.org/internet-drafts/draft-watson-sipping-req-history-00.txt

_______________________________________________
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: "Mark Watson"<[email-masked]>
Date: Mon, 25 Feb 2002 17:54:33 -0000

Tony,

I think it depends what stage in the process you think we are at, and what
you mean by requirements. 'Requirements' can be written at many levels, but
I thought the stage we got to at the last IETF was a need to identify
exactly a 'set of capabilities' that we wished to be able to provide with
SIP.

In terms of the overall problems that these capabilities solve: they enable
certain services, some of which are discussed in the draft and some of which
have been the motivation for the more specific mechanisms previously
proposed and listed in the references. We don't in IETF define a set of
services, and then design protocol to implement these, but rather identify
generic capabilities which might be useful to service designers.

This is where we were after IETF-52, with support for definition of a
generic capability for request history. Once we have agreement on the
details of what this capability does, *then* we can proceed to the next
stage of identifying what technical problems need to be solved from a
protocol perspective in order to provide achieve this.

We thought this was the required process under sipchange - define the
capability first in SIPPING and work on the solution later in SIP.

Are you questioning the rationalle for the whole capability, or do you
expect the requirements to go into more detail as to the effect on the
protocol ?

Regards,

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 25 February 2002 15:45
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] I-D
> ACTION:draft-watson-sipping-req-history-00.txt
> 
> 
> 
> 

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]

---

From: [email-masked]
Date: Mon, 25 Feb 2002 14:10:03 -0500

From:  Tom Gray@MITEL on 02/25/2002 02:10 PM

Reading this document, I do not see how anyone could assess its worth. What are
the capabilities identified in this document supposed to accomplish? This
understanding is what requirements documents are supposed to provide. I would
recommend that the requirements be specific  enough in their problem statement
so that:

a) it could be determined whether or not there is a problem that is of high
enough priority that it needs to be solved. The outcome would naturally be an
agreed upon problem statement. Intervenors could be invited to submit proposed
solutions.

b) the worth of proposed solutions could be assessed by comparing their ability
to solve the agreed upon problems

I see a very general description of a problem area in the document. However in
my opinion this could  be greatly improved by providing scenarios which
illustrate specific deficiencies that are not currently solvable with the
standard SIP protocol. Without this, I do not see how anyone can discuss the
document. What basis would anyone have for accepting or rejecting it?

"Mark Watson" <[email-masked]> on 02/25/2002 12:54:33 PM

To:   Tom Gray/Kan/Mitel@Mitel, [email-masked]
cc:

Subject:  RE: [Sipping] I-D ACTION:draft-watson-sipping-req-history-00.txt

Tony,

Regards,

Mark

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]

---

From: "Mary Barnes"<[email-masked]>
Date: Mon, 25 Feb 2002 14:06:16 -0600

Tom,

As Mark states, this document wasn't intended to prescribe the requirements
of a solution to solve specific problems or scenarios, but was intended to
focus on the requirements of the capabilities required in SIP (protocol) to
be able to use SIP as a solution for specific scenarios.  

As you say, we've been quite sketchy in describing the scenarios as we had
assumed the ones that we did use were fairly well known scenarios to the
audience.  In a sense this document is a guinea pig for the new SIPPING WG
process and will need refinement.  We can certainly back up yet another step
and add all the details for these scenarios and highlight how these
scenarios would use the capabilities that have been specified.  But, I would
think that would be a rather lengthy document at a fairly high level of
abstraction as to not be particularly useful either towards the end goal;
with the end goal of this draft being an acknowledgement that there is not a
"Request History" capability in SIP and that this is necessary in order to
be able to use SIP for certain services.  We do recognize that the level of
abstraction of the current document is fairly high and we see value in
taking it to the next step of evaluating different solution proposals
applied against the required capabilities including specific scenarios to
demonstrate the proposed solutions. Certainly, this step would be open to
all "intervenors". 

I think the basic question being asked here is whether we want to add more
to the requirements process by requiring a detailed description and
agreement of a problem domain prior to proposing requirements for the
capabilities required in the SIP protocol to solve a given problem? Do we
have any other opinions, particularly from the WG chairs?

Regards,
Mary H. Barnes
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 1:10 PM
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

Reading this document, I do not see how anyone could assess its worth. What
are
the capabilities identified in this document supposed to accomplish? This
understanding is what requirements documents are supposed to provide. I
would
recommend that the requirements be specific  enough in their problem
statement
so that:

a) it could be determined whether or not there is a problem that is of high
enough priority that it needs to be solved. The outcome would naturally be
an
agreed upon problem statement. Intervenors could be invited to submit
proposed
solutions.

b) the worth of proposed solutions could be assessed by comparing their
ability
to solve the agreed upon problems

I see a very general description of a problem area in the document. However
in

Tony,

Regards,

Mark

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]

---

From: [email-masked]
Date: Mon, 25 Feb 2002 15:31:04 -0500

From:  Tom Gray@MITEL on 02/25/2002 03:31 PM

It is my understanding that this document is about providing a traditional
telephony call redirection service within SIP. If that is so, I would just like
a requirements document for this to say that.  If not, it would be nice to know
what is the purpose of the capabilities described.

The capabilites are describing a proposed solution to an unnamed problem Calling
them requirements does not make them so.  Given a derscription of the problem
that is being addressed,  there could be a determination then of the information
that would be need to be carried by SIP for this service and whether or not this
was a problem of broad enough significance that it would be addressed in the
general protocol.

"Mary Barnes" <[email-masked]> on 02/25/2002 03:06:16 PM

To:   Tom Gray/Kan/Mitel@Mitel, "Mark Watson" <[email-masked]>
cc:   [email-masked]

Tom,

Regards,
Mary H. Barnes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 1:10 PM
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

Tony,

Regards,

Mark

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]

---

From: "Mary Barnes"<[email-masked]>
Date: Mon, 25 Feb 2002 14:44:14 -0600

Tom,

The intent of this document is not to provide a traditional telephony call
redirection service within SIP. That might be just one use.  Quite clearly
we saw at IETF-52 that it was indeed a mistake to provide that as an
example.  The goal is to ensure that what gets progressed is a general
purpose Request History mechanism which could be used for a variety of
services.

I do understand your concerns about this being too fuzzy and unspecific at
this time as I myself have struggled with that lack of concreteness and the
level of abstraction of the current draft.  If you have specific suggestions
on how to get more concrete on characterizing the nature of problems to
which these requirements apply without going either into the solution domain
or prescribing requirements for a narrow problem domain, that would be much
appreciated. 

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 2:31 PM
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

It is my understanding that this document is about providing a traditional
telephony call redirection service within SIP. If that is so, I would just
like
a requirements document for this to say that.  If not, it would be nice to
know
what is the purpose of the capabilities described.

The capabilites are describing a proposed solution to an unnamed problem
Calling
them requirements does not make them so.  Given a derscription of the
problem
that is being addressed,  there could be a determination then of the
information
that would be need to be carried by SIP for this service and whether or not
this
was a problem of broad enough significance that it would be addressed in the
general protocol.

Tom,

Regards,
Mary H. Barnes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 1:10 PM
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

Tony,

Regards,

Mark

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]

---

From: [email-masked]
Date: Tue, 26 Feb 2002 08:08:37 -0500

From:  Tom Gray@MITEL on 02/26/2002 08:08 AM

As a final comment on this, a disembodied set of 'requirements' that bear no
relation to any palpable function simply cannot function. Consider what would
happen is someone were to comment on this draft by advocating that the
'BACKWARDS-req'  be removed as being unneeded. Others would presumably disagree
and intervene to say that its removal would damage some valuable scenario. I

These scenarios, if they are valuable, should be identified in the requirements
document.  Failing to do this will result in sterile open-ended debate since
their can be no limitation on its scope. No set of problems has been defined to
limit the scope of the debate and so any topic must be germane to it.

Having made my opinion known on this, I'll leave it to the management of the
working group to decide if this draft holds a valid set of requirements that can
be used to define and limit discussion or not.

"Mary Barnes" <[email-masked]> on 02/25/2002 03:44:14 PM

To:   Tom Gray/Kan/Mitel@Mitel, "Mark Watson" <[email-masked]>,
      [email-masked]
cc:

Tom,

Thanks,
Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 2:31 PM
To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

Tom,

Regards,
Mary H. Barnes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 25, 2002 1:10 PM
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: [email-masked]; [email-masked]
Subject: RE: [Sipping] I-D

Tony,

Regards,

Mark

Send a message to:
     [email-masked].
In the body type:

mailto:[email-masked]