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

From: "Mary Barnes" <[email-masked]>
Date: Tue, 18 Oct 2005 21:25:24 -0500

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: [email-masked] [mailto:[email-masked]] 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 [email-masked] for questions on current sip
Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Wed, 19 Oct 2005 00:16:07 -0500

>    because the status code and the reason phrase already provide

yes, that's exactly my confusion point. History-Info can be included in
that 302 response, according to the way I read H-I. Right? After all,
the draft explicity says we can have H-I in any response, I think.

Including a Reason header field inside a History-Info header field that
is inside a response is NOT the same thing, imho, as including a Reason
header field in a response (which I think is probably a good idea
anyhow, but that's a separate issue).

Let's say Node B is retargeting a request by generating a 302 response
to that request. So it makes perfect sense to me for Node B, which is
issuing a 302 "for a reason" to include a History-Info describing the
retargeting operation it believes it is effecting, and including the
"reason" for that retargeting.

If this is just all wrong (and it may very well be), then I just wasn't
able to find in H-I where it SAYS this is wrong. Maybe I just missed it.
Please point . . . 

After all, if I'm confused, then it's reasonable to think that other
clueless readers are confused too (I'm a good test case for clueless).

--
dean