Subject: RE: [Sipping] Followup on history comment

From: "Mary Barnes" <[email-masked]>
Date: Mon, 15 Jul 2002 23:05:59 -0500

Ben,

You are absolutely correct that we don't have an explicit requirement on the
"Optionality" concept.  The text around this issue had been built overtime
based upon some mailing list feedback and I agree that what's there now gets
into implementation rather than protocol requirements.  Actually, the entire
section 4 was intended to capture more solution oriented concerns that arise
from the requirements. Are you asking for a concise requirement around this
or suggesting this is best left entirely for the protocol solutions stage?
My proposal would be to entirely remove section 4 as the requirements should
be sufficient to standalone and to provide the specific guidelines to which
you refer in the solution draft.

Thanks,
Mary. 

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Monday, July 15, 2002 9:23 PM
To: Sipping
Subject: [Sipping] Followup on history comment

In the wg meeting, I made the comment that perhaps the history 
requirements draft should contain language encouraging applications to 
be able to function in the absense of history information. Rohan 
suggested that this was already in the draft.

On a quick re-read, I do not believe this is the case. Section 4.3 
suggests that an application have its behavior in the absense of history 
information be documented. It offers a couple of examples, one of which 
is a voice mail system that is documented to simply not work in the 
absense of history information. This does not seem to me to encourage 
applications to be able to function without history.

Also, to follow up on Robert's comments: Section 3, requirement 8, says 
an entity _shall_ include history info when it handles a redirect or 
refer. Also, 4.1 contains language that an entity should not internally 
retarget without adding history info. Both of these seem to imply that a 
retargeting device either should or must implement history. Both also 
seem to be more implementation concerns that protocol requirements. I 
suspect that was not the intent, considering the other "optionallity" 
language in the 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: Ben Campbell <[email-masked]>
Date: Tue, 16 Jul 2002 01:11:19 -0500

I think it is best left to protocol solution stage.

However, I am still concerned that REDIRECT-RESP-req seems to require 
certain actions supporting request history from devices that may not 
know about it, or may choose not to provice it. That requirement may 
also be more solution than requirement.

Perhaps something to the effect of "It must be possible to preserver 
request history information across redirect or refer operations."

Mary Barnes wrote:
> Ben,
> 
> You are absolutely correct that we don't have an explicit requirement on 
> the "Optionality" concept.  The text around this issue had been built 
> overtime based upon some mailing list feedback and I agree that what's 
> there now gets into implementation rather than protocol requirements.  
> Actually, the entire section 4 was intended to capture more solution 
> oriented concerns that arise from the requirements. Are you asking for a 
> concise requirement around this or suggesting this is best left entirely 
> for the protocol solutions stage?  My proposal would be to entirely 
> remove section 4 as the requirements should be sufficient to standalone 
> and to provide the specific guidelines to which you refer in the 
> solution draft.
> 
> Thanks,
> Mary.
>