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

From: "Elwell, John" <[email-masked]>
Date: Wed, 12 Oct 2005 07:49:09 +0100

Paul,

> I don't know how valid an argument this is, but I am finding an 
> "impedence mismatch" between the approaches in the two 
> drafts, that is 
> disconcerting.
> 
> - In H-I, the reason is associated with the uri that
>    was retargetted-from
> 
> - In draft...retargeting... the reason is associated
>    with the uri that was retargetted-to
> 
> When you combine them, you get one entry with a 
> retargetted-from uri and 
> the reason why retargetting from it happened, and then you 
> get another 
> entry for the retargetted-to uri with the reason why 
> retargetting to it 
> happened. If they agree then they are redundant. If they are 
> different, 
> then one has to deal with why they are different.
> 
> I'd be more comfortable if all the reasons for a particular 
> retargetting 
> were gathered up in *one* place.

[JRE] Your observation is correct. The way we (the authors) looked at is was
that the first entry shows why the attempt to send the request to the first
target failed and the second entry shows why the new target was selected
(e.g., forwarding to it because of busy). I agree it is equally valid to
look at the other way round.

John

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Oct 2005 10:51:12 -0400

> look at the other way round.

Hmm. It hadn't been apparent to me that there was a requirement for both 
kinds of reasons - why one failed vs why another was chosen. I just 
looked at the requirements in your draft and in H-I. They are pretty 
similar. The H-I draft says:

    5) CONTENT-req:  The "Request History" information for each
    occurrence of retargeting, shall include the following:
    ...
    5.3) The reason for the Request-URI or address modification,

While H-I puts the reason with the URI that was replaced rather than 
with the replacement, it seems that it is neutral about whether that is 
a positive reason or a negative one. So there would seem to be no reason 
why there couldn't even be one of each kind of reason for a given entry 
in H-I. (Though it might not be valid to have two from the same 
namespace - that isn't entirely clear to me.) So I think the H-I 
mechanism is sufficient, without adding yet another.

As I said in another message, it does seem easier to say why a given 
address failed than it is to say in a positive sense why another was 
chosen. The reasons for failure are more easily enumerated than the 
reasons for choice.

Nevertheless, if a suitable vocabulary is available, then I guess it can 
be left up to the agent making the retargetting decision to decide how 
to characterize its decision. But I do think it is important that the 
semantics of the alternatives be sufficiently well defined so as to 
enable those assigning a reason and those consuming a reason to decide 
their actions independently.

I think H-I probably meets your requirements if only you add a new 
reason namespace. However, in 13.1 you hint at another requirement for 
backward compatibility with some components. Is that a requirement?

	Paul