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

["Mary Barnes" <[e-mail]>]

Dean,

My comments are embedded below [MB], hopefully clarifying rather than
adding additional confusion to this thread. 

Mary.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dean Willis
Sent: Wednesday, October 19, 2005 12:16 AM
To: Barnes, Mary [NGC:B601:EXCH]
Cc: Elwell, John; Audet, Francois [SC100:9T51:EXCH]; sipping; Paul
Kyzivat; Michael Hammer (mhammer)
Subject: RE: [Sipping] Re:
draft-elwell-sipping-service-retargeting-00.txt


On Tue, 2005-10-18 at 21:25 -0500, Mary Barnes wrote:

> 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."


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.

[MB] Yes. H-I can be in any response.  However, for a redirect server it
explicitly mentions that the H-I would be the same H-I that it had
received in the request for which it was sending a response.  A redirect
server would not add an H-I entry because it does not do the
retargeting. It provides the new target in the contact.  
[/MB]

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).  

[MB] I don't think anyone is debating that - we're debating how H-I
works and why this is not entirely equivalent to the approach of using
service specific URIs (mainly because H-I doesn't care or know about
services - it just captures what's happening from a pure SIP
perspective. )
[/MB]

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.

[MB] Based upon the definition of retargeting in the History-Info draft,
Node B is not doing the "retargeting".  Node B is generating a potential
new target(s) (i.e. "redirecting")  and placing that in the contact
header, which is sent in the 302 response.  It's the recipient of that
response that does the actual retargeting by building a new request,
which is targeted to the request URI that was in the contact header in
the 302 response.  This may be slightly confusing, but it keeps the
definition of retargeting consistent with the normal routing a proxy
might do with no redirect server involved (i.e. if we allowed the
redirect server to create the H-I entry, then we have exception
processing for 3xxs). And, I think it's clearly stated in History-Info
draft in section :
"  A redirect server SHOULD NOT add any new History-Info, as that would 
   be done by the entity receiving the 3xx response. However, a redirect

   server MAY include History-Info in responses by adding any History-
   Info headers received in a request to a subsequent response. " 
I think it's that last sentence that might be confusing, that's just
saying if the redirect server gets a list of H-I entries in the request
it receives, it can certainly include that whole list in the response.
Perhaps it would have been more clear to state that the reason the H-I
entries would be included in the request would be to provide the
redirect server information such that it doesn't re-try routes that have
already been tried. 

I also think there is confusion since this draft
(elwell-service-retargeting) introduces a new term "service retargeting"
which is a function attributed also to redirect servers.  It should
likely be clarified that this service retargeting is slightly different
than the normal retargeting associated with routing of SIP requests. Or
perhaps, the term "service redirection" should be used. 

That all said, it is a "SHOULD NOT" in terms of redirect servers adding
H-I entries. If we accept that this is an exception case, then the
redirect server could add an H-I entry with the 486 Busy as the reason
associated with the new targeted-to-uri, which is returned also in the
contact header in the 302.  The recipient of the 302 would then add
another H-I entry for the new targeted-to-uri with a reason of 302.
Thus, there is a unique pattern in the H-I entries for the end
application to decipher. This would be roughly equivalent to the current
proposal (for systems supporting H-I) to include a service specific uri
in the new targeted-to-uri, along with the 302.  

This really brings us back to the debate we've had in this area from day
one as to where the service logic is - in the network or relegated to
some end application server or user.  Basically, we're debating whether
the redirect server should provide the appropriate service specific URIs
or whether we put the burden on the end application to decipher the H-I
entries.  It's  been suggested that the latter is quite difficult,
however, I think that can be debated. I agree it does but an additional
burden on the recipient applications and that overall IF the service
specific URIs are agreed and appropriately configured, it is a much
simpler solution in terms of processing for the end application. 
[/MB]  

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).

[MB] Hopefully, the above clarifies things. If you could take a look at
the History-Info draft and see if there isn't anything additional that
should be added to make sure this is clear (again, I can't see anything
that is really missing), we could perhaps work with the SIP chairs and
get an RFC Editor's note added or make this change during AUTH48.
[/MB]

--
dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP