Re: [dispatch] Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored

Hi,

>Sure -- my suggestion was one for clarification. If 3GPP does, in fact,
>intend to allow the header field in mid-dialog  messages, then my
>comment doesn't apply.
>
>But if they *do* intend to allow the field mid-dialog, I'm curious about
>why it's forbidden in the current list of methods: save for some obscure
>corner cases, all of the methods called out by name are sent mid-dialog,
>and none of the un-named methods are.

OPTIONS, BYE, REFER (with RFC7615) and re-INVITE can be sent in-dialog.

I can’t give an answer here and now why the list looks like it does, but
this is how it’s specified in 3GPP :)

>Either way, it's just a suggestion. The hard block here is in the ACK
>handling that I pointed out.

Based on your comments, the new text would now say:

   "The P-Associated-URI header field can appear in SIP REGISTER
   2xx responses. The P-Called-Party-ID header field can appear in
   SIP INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.
   The P-Visited-Network-ID header field can appear in all SIP methods
   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO and UPDATE. The
   P-Access-Network-Info header field can appear in all SIP methods
   and non-100 responses, except in CANCEL methods, CANCEL responses
   and ACK methods triggered by non-2xx responses. The P-Charging-Vector
   header field can appear in all SIP methods and non-100 responses,
   except in CANCEL methods, CANCEL responses and ACK methods triggered
   by non-2xx responses. The P-Charging-Function-Addresses header field
   can appear in all SIP methods and non-100 responses, except in ACK
   and CANCEL methods and CANCEL responses.”

Regards,

Christer

>
>/a
>
>On 4/27/16 08:01, Christer Holmberg wrote:
>> Hi,
>>
>> One more thing:
>>
>> I guess we could also change ³all responses² to ³all non-100 responses²,
>> as 100 responses are also hop-to-hop (similar to ACKs triggered by
>>non-2xx
>> responses).
>>
>> Regards,
>>
>> Christer
>>
>>
>> On 25/04/16 14:30, "Christer Holmberg" <christer.holmberg@ericsson.com>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> Are you ok with my suggested way forward?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> On 21/04/16 22:43, "Christer Holmberg" <christer.holmberg@ericsson.com>
>>> wrote:
>>>
>>>> Hi Adam,
>>>>
>>>> ....
>>>>
>>>>>> One additional review note that does not affect my expert review
>>>>>> (treat it as a last-call comment):
>>>>>>
>>>>>>
>>>>>>       Add statement that the P-Visited-Network-ID header field
>>>>>>cannot
>>>>>>       appear in the SIP NOTIFY, PRACK, INFO and UPDATE methods.
>>>>>>
>>>>>> It seems to me that it would be significantly more future proof to
>>>>>> phase this as "...cannot appear in mid-dialog requests," as that
>>>>>> appears to be the intention. The revised text then becomes something
>>>>>> like: "The P-Visited-Network-ID header
>>>>>> field can appear in all SIP methods except ACK and CANCEL; however,
>>>>>>it
>>>>>> cannot be sent in >any mid-dialog requests."
>>>>> Seems reasonable, but I'll verify with my 3GPP delegates.
>>>> I had a closer look at this, and I don't think we can forbid usage in
>>>>all
>>>> mid-dialog requests.
>>>>
>>>> For example, the header field is allowed in OPTIONS, that can be sent
>>>> in-dialog.
>>>>
>>>> Also, the header field is allowed in REFER, and RFC 7614 defines a
>>>> mechanism that allows in-dialog REFERs.
>>>>
>>>> re-INVITE is also tricky. The header field is generally allowed in
>>>>INVITE
>>>> requests, but there is no text explicitly disallowing it in
>>>>re-INVITEs.
>>>>
>>>> Whether it makes sense to include the header field in the methods
>>>>above I
>>>> don't know (3GPP does allow them), but as the purpose is only to align
>>>> 7315 with 3455 I'd suggest we keep the text as it is.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 3/7/16 14:08, A. Jean Mahoney wrote:
>>>> Since this draft updates RFC 7315, which required expert review of its
>>>> header fields, Adam Roach will be conducting an expert review of this
>>>> draft according to the guidance given in RFC 5727.
>>>>
>>>> Thanks,
>>>>
>>>> Jean
>>>>
>>>>
>>>> On 3/7/16 9:33 AM, Mary Barnes wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> This document has been proposed to be progressed as AD sponsored:
>>>> 
>>>>https://datatracker.ietf.org/doc/draft-holmberg-dispatch-rfc7315-update
>>>>s/
>>>> The document has been carefully reviewed and it is now ready to move
>>>> forward - Jean Mahoney is the shepherd.
>>>>
>>>> I don't anticipate anyone would have concerns about this decision,
>>>>given
>>>> that's how RFC 7315 was progressed and this update has actually been
>>>>much
>>>> more carefully reviewed.  However, f anyone has any final comments,
>>>> please post no later than Friday, March 11th, 2016.  Note, that you
>>>>will
>>>> also still have IETF LC to provide any comments.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>