Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis)

Please do not put it in 100 responses, i.e. MUST NOT.

Note that if it is put in 1xx responses that are not sent reliably, then in my understanding you have no means of telling you have lost it along with the response. So in this case it would have to be repeated in the final response. However there is probably a use case for being able to inform the user of call diversion at alerting time, so I would certainly allow it, i.e. MAY to generate it or add to it, MUST to pass one on if you receive it.

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Tuesday, November 02, 2010 10:20 PM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: 
> WGLC: draft-ietf-sipcore-rfc4244bis)
> 
> 
> 
> On 11/2/2010 4:31 PM, Elwell, John wrote:
> > So the remaining issue from this thread concerns whether to 
> mandate History-Info in a all provisional responses or just 
> non-100 provisional responses (subject to presence of the 
> option tag in the request). Given that 100 tends to be 
> generated differently from other provisional responses, and 
> given the marginal use of H-I in 100 responses, I would 
> prefer either to omit H-I from 100 responses or use MAY. I 
> don't have a strong opinion, but perhaps others have a view.
> 
> Requiring (even permitting) H-I in 100 responses is a *terrible* idea.
> 
> I don't see why you would need H-I in *any* provisional 
> responses (with the possible exception of 199.)
> 
> (Disclaimer - I have not read all the discussion on this subject.)
> 
> 	Thanks,
> 	Paul
> 
> > John
> >
> >
> >> -----Original Message-----
> >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> >> Sent: 02 November 2010 19:51
> >> To: Elwell, John
> >> Cc: sipcore@ietf.org
> >> Subject: Re: [sipcore] REMINDER: Re: WGLC:
> >> draft-ietf-sipcore-rfc4244bis
> >>
> >> John,
> >>
> >> I've done the same. A couple responses inline below [MB2].
> >>
> >> Thanks,
> >> Mary.
> >>
> >> On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John 
> >> <john.elwell@siemens-enterprise.com>  wrote:
> >>> Mary,
> >>>
> >>> I have responded below, stripping out the stuff where I
> >> have nothing further to add.
> >>>
> >> <snip>
> >>>>> 2. It nearly always uses the term "header" rather than
> >>>> "header field", although never, as far as I know, meaning the 
> >>>> entire SIP header.
> >>>> [MB] I'm not sure that I fully understand the concern. Can
> >> you point
> >>>> out a specific sentence or section of concern?  The term
> >> "header" is
> >>>> used when it is referring to the History-Info header
> >> field, but that
> >>>> is done in other documents as well.  In general, I think it's 
> >>>> understood that it's referring to the header field when it's 
> >>>> qualified. Perhaps you're referring to places where it is not
> >>>> qualified?   The term hi-entry is used, as well.
> >>>> [/MB]
> >>> [JRE] I have explained in more detail in my comments on -02.
> >> [MB2] I've responded to that in my subsequent response to your 
> >> comments. [/MB2]
> >>>
> >>> <snip/>
> >>
> >>>>>
> >>>>> 18. Section 4.2.2:
> >>>>> "the UAS MUST
> >>>>>    include any History-Info received in the request  in the
> >>>> subsequent
> >>>>>    response"
> >>>>> Does this include 100 responses?
> >>>> [MB] I would think so. Can you think of a reason why it
> >> shouldn't?  I>>  would think it could be useful for debug. [/MB]
> >>> [JRE] The 100 response typically only travels back a single
> >> hop, so the benefit of H-I in a 100 is marginal. Also some 
> >> implementations might send back a 100 response quite early during 
> >> processing, perhaps even before they decide whether to act as a 
> >> proxy, a UAS or a redirect, so knowing how to populate H-I 
> in a 100 
> >> might be difficult.
> >> [MB2] If it has no additional hi-entries, then there is nothing 
> >> additional to send back, so I don't think it hurts 
> anything - I would 
> >> agree that in most cases it's of marginal value. We can 
> include it as 
> >> an exception in that sentence if you would prefer, 
> although per the 
> >> next comment, it seems that you are okay with leaving it as is.
> >> [/MB2]
> >>>
> >>> <snip/>
> >>>>>
> >>
> >>>>>
> >>>>> 26. Section 5.2:
> >>>>> "A proxy that receives a request with the "histinfo" option
> >>>> tag in the
> >>>>>    Supported header, SHOULD forward captured History-Info in
> >>>> subsequent,
> >>>>>    provisional , and final responses "
> >>>>> Does this include 100 responses?
> >>>> [MB] That's the implication of "provisional" per RFC 3261. [/MB]
> >>> [JRE] I am doubtful about the usefulness of 100. However,
> >> it is probably fairly academic, since 100 will probably have been 
> >> sent earlier. A proxy is unlikely to send a 100 after receiving a 
> >> provisional response from a downstream entity.
> >>>
> >>>>>
> >>>>> 27. Section 5.2:
> >>>>> "A proxy MAY anonymize any hi-entry whose domain 
> corresponds to a
> >>>>>    domain for which it is responsible (as per [RFC3323 ])."
> >>>>> I don't think RFC 3323 tells me how to anonymize an hi-entry.
> >>>> [MB]  RFC 3323 discusses anonymization and the role of an
> >> anonymizer,
> >>>> etc. So, I'm not clear on your concern. [/MB]
> >>> [JRE] I guess if we talked about anonymizing the URI in the
> >> hi-target-to-uri it would be clearer.
> >> [MB2] That's fine...I'll make it explicit that it's the 
> >> hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2]
> >>>
> >>> <snip/>
> >>>
> >>>
> >>> John
> >>
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> >
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 