RE: [Sip] Hop limit diagnostics

["DRAGE, Keith \(Keith\)" <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, July 11, 2007 4:07 PM
> To: DRAGE, Keith (Keith)
> Cc: [e-mail]
> 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip