RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

"Mary Barnes" <mary.barnes@nortel.com> Wed, 19 October 2005 02:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3eI-0005xs-4y; Tue, 18 Oct 2005 22:25:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES3eG-0005xk-8w for sipping@megatron.ietf.org; Tue, 18 Oct 2005 22:25:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13854 for <sipping@ietf.org>; Tue, 18 Oct 2005 22:25:39 -0400 (EDT)
Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ES3ps-0003Fn-Rp for sipping@ietf.org; Tue, 18 Oct 2005 22:37:50 -0400
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9J2POD19451; Tue, 18 Oct 2005 22:25:25 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
Date: Tue, 18 Oct 2005 21:25:24 -0500
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0AB3D301@zrc2hxm1.corp.nortel.com>
Thread-Topic: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt
Thread-Index: AcXUIlUwX4quJuslT1iNE/pS4aWu4QAK9dhg
From: Mary Barnes <mary.barnes@nortel.com>
To: Dean Willis <dean.willis@softarmor.com>, Francois Audet <audet@nortel.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: quoted-printable
Cc: "Elwell, John" <john.elwell@siemens.com>, Paul Kyzivat <pkyzivat@cisco.com>, sipping <sipping@ietf.org>, "Michael Hammer (mhammer)" <mhammer@cisco.com>
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Dean,

It's not clear to me what more you would want said in the H-I draft on
the 3xx.  There is, in my view, quite a bit of discussion on redirect
server behavior and 3xx responses.  In general, H-I is fairly agnostic
as to what the response is - the response is generally captured without
consideration of its value by the entity doing the retargeting.  

There are some example use cases in the appendix of the History-Info
draft.  And, there are several showing 302 responses (including a VM
example).  Are you seeing the need for more than this?  

I still think there's fundamental confusion over how H-I works - that
302 isn't included in the H-I entry until a new request is built. Thus,
you could only correlate the 302 response (captured as a Reason in the
H-I entry) with a 486 IF you also had a separate Reason header in the
response.  This is because the entity that sends the 302 response isn't
the one that builds the H-I entry capturing that 302 response; the H-I
entry is added by the recipient of the 302 response (i.e. the entity
that's actually doing the retargeting). This point relates to why John's
earlier proprosal was suggesting to allow the Reason header in responses
and to extend the values in the Reason header to support this service
related information.  The History-Info draft was updated around that
time to take into account the possibility of getting a Reason header in
a response (and this was discussed on the mailing list and in the issue
discussions at the SIP WG meetings).   We did interpret the text in RFC
3326 (at that time) to mean that it was possible (i.e. it's certainly
not specifically dis-allowed) to have a Reason header in a response:
"  Note that the Reason header field is usually not needed in responses
   because the status code and the reason phrase already provide
   sufficient information."

Mary


-----Original Message-----
From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On
Behalf Of Dean Willis
Sent: Tuesday, October 18, 2005 3:01 PM
To: Audet, Francois [SC100:9T51:EXCH]
Cc: sipping; Paul Kyzivat; Elwell,John; Michael Hammer (mhammer)
Subject: Re: [Sipping] Re:
draft-elwell-sipping-service-retargeting-00.txt



On Oct 17, 2005, at 5:47 PM, Francois Audet wrote:

> You mean adding a Reason of 486 inside 302????
>
> That seems highly confusing to me.

That's more or less what I think I proposed, except I buried it in a  
History-Info header field.

One of the things that puzzles me about H-I is that while the RFC  
allows use of H-I in 302 responses, it doesn't talk about it in any  
great detail.

It would be very nice to have an H-I use-cases draft with some good  
examples.

--
Dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP