[Sip] RE: Hop limit diagnostics

So to explore further. 

If the final hop is TCP and a preceding hop is UDP, does it just get
thrown away at the transport protocol boundary in this solution.

Regards

Keith

> -----Original Message-----
> From: Sean Olson [mailto:Sean.Olson@microsoft.com] 
> Sent: Wednesday, July 11, 2007 7:33 PM
> To: DRAGE, Keith (Keith); sip@ietf.org
> Subject: RE: Hop limit diagnostics
> 
> Why not:
> 
> D) Define a diagnostic information mechanism that works with 
> TCP and accept that it will not work with UDP
> 
> 
> 
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]
> Sent: Wednesday, July 11, 2007 7:07 AM
> To: sip@ietf.org
> Subject: [Sip] Hop limit diagnostics
> 
> (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 
> sip-implementors@cs.columbia.edu for questions on current sip 
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip