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

[Paul Kyzivat <[e-mail]>]

Elwell, John wrote:
> 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.

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

_______________________________________________
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