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

[Dean Willis <[e-mail]>]

On Wed, 2005-10-19 at 07:56 -0500, Mary Barnes wrote:

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

Yes, that's exactly waht I was saying is allowed (although not
recommended, as you point out it's a SHOULD strength, and the
permissions table does allow it.

But I don't see it as roughly equivalent to the serice-URI proposal --
if the service-specific URI information is really 3087-compliant, (as
Francois seems to intend) History+hack is not at all equivalent. History
+hack is, however, a thorough replacement for Diversion. You could build
applications that would look much the same to the end user using History
+hack as you could with service-URI, but the composition logic is
entirely different.

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

Yes, that is the real heart of the question. As I said, I believe I'm
agreeing with what I think Francois is saying about service-URIs, but I
also think History-Info gives us more capabilities than we seem to be
realizing in this discussion.

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