Re: [Sip] Hop limit diagnostics

[Robert Sparks <[e-mail]>]

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