Re: [dispatch] Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored]

[Christer Holmberg <[e-mail]>]

Thanks! :)

Regards,

Christer

-----Original Message-----
From: Adam Roach [mailto:[e-mail]] 
Sent: 13 May 2016 22:33
To: Christer Holmberg <[e-mail]>; A. Jean Mahoney <[e-mail]>; [e-mail]
Subject: Re: Draft new version: draft-holmberg-dispatch-rfc7315-updates-06 [was: Progressing draft-holmberg-dispatch-rfc7315-updates as AD sponsored]

The -06 version addresses the only blocking concerns that I had. From an expert review perspective, I approve its publication.

/a

On 4/27/16 10:57, Christer Holmberg wrote:
> Hi,
>
> Based on Adam's comments, I've submitted a new version (-06) of draft-holmberg-dispatch-rfc7315-updates.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: dispatch [mailto:[e-mail]] On Behalf Of 
> Christer Holmberg
> Sent: 27 April 2016 18:07
> To: Adam Roach <[e-mail]>; A. Jean Mahoney 
> <[e-mail]>; [e-mail]
> Subject: 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"
>>> <[e-mail]>
>>> wrote:
>>>
>>>> Hi Adam,
>>>>
>>>> Are you ok with my suggested way forward?
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> On 21/04/16 22:43, "Christer Holmberg"
>>>> <[e-mail]>
>>>> 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-u
>>>>> pd
>>>>> ate
>>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>>
>>>>> _______________________________________________
>>>>> dispatch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch