I believe content-indirection was looked at and also sending a new request in the reverse direction.
I believe the issue with content indirection was the issue of if the sender of the original request cannot construct a routeable SIP query, will they be able to construct a routeable HTTP query to get to the content indirection server. Would welcome a fuller explanation or correction here. The problem with issuing a new request falls into two parts: - it does not solve the problem of standalone transactions like MESSAGE. - will a new request in the reverse direction reach the original sender given that the routeing path can be totally independent of the original request. Again would welcome a fuller explanation or correction here. Regards Keith > -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 11, 2007 4:07 PM > To: DRAGE, Keith (Keith) > Cc: [email protected] > Subject: Re: [Sip] Hop limit diagnostics > > For completeness - haven't we also talked about requests in > the opposite direction and diagnostics by indirection? I know > each of those have their own thorny problems, but the > tradeoff against really large responses may make them the > least unpalatable. > > And I remember conversations, but not much list traffic about > a series of best-effort provisionals to carry the information. > > I still think its worth figuring out, but won't throw fits if > the WG decides to put it off to the indefinite future. > > RjS > > > On Jul 11, 2007, at 9:07 AM, DRAGE, Keith ((Keith)) wrote: > > > (As WG chair) > > > > We have a couple of related milestones on our charter that we are > > stuck > > on: > > > > Jul 2007 Diagnostic Responses for SIP Errors to WGLC (PS) > > Nov 2007 Diagnostic Responses for SIP Errors to IESG (PS) > > > > The draft associated with this expired some way back, but > you can find > > it at: > > > > http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03 > > > > The charter item is for a more general document that covers other > > error situations as well as hop limit issues. > > > > However the editor's hit the intractable problem in that > any transport > > decision is made on the request on any particular hop, and > if UDP is > > used on the request, it will also be used on the response on any > > particular hop. This was specified based on the assumption that any > > response would not be significantly larger than the request, but as > > soon as we start putting lots of useful diagnostic > information in the > > response, this no longer applies. > > > > So we are now looking for the way forward. Options include: > > > > A) It is not worth the extra cycles - delete the milestone. > > > > B) Limit the diagnostic information (to say around 100 bytes in the > > worst case). If so will it contain enough useful > information to make > > it usable. > > > > C) Solve the transport problem. And no, we do not have a debate > > here on deprecating UDP. We've been there and done that. > > > > Unless people can come up with something that looks achievable, the > > working group chairs are currently favouring A) above. > > > > Comments please. > > > > > > Keith > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol Use > > [EMAIL PROTECTED] for questions on current sip Use > > [EMAIL PROTECTED] for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
