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:[EMAIL PROTECTED] > Sent: Wednesday, July 11, 2007 7:33 PM > To: DRAGE, Keith (Keith); [email protected] > 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:[EMAIL PROTECTED] > Sent: Wednesday, July 11, 2007 7:07 AM > To: [email protected] > 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 > [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
