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

["Elwell, John" <[e-mail]>]

Paul,

Comment at end.

John


> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]] 
> Sent: 12 October 2005 15:51
> To: Elwell, John
> Cc: Dolly, Martin C, ALABS; GARCIN Sebastien RD-CORE-ISS; sipping
> Subject: Re: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 
> 
> 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
>
[JRE] Yes, I believe it is important to have a solution that works without
needing to change the UACs, so perhaps this should have been written as a
requirement. In general it is easier to upgrade network equipment than lots
of customer premises equipment. I see this as the major advantage of this
approach and it is probably important enough to cancel out the various
disadvantages or limitations that have emerged during this thread.
 

_______________________________________________
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