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

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Apr 2016 15:57:03 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 27 April 2016 18:07
To: Adam Roach <[email-masked]>; A. Jean Mahoney <[email-masked]>; [email-masked]
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" 
>> <[email-masked]>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> Are you ok with my suggested way forward?
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>> On 21/04/16 22:43, "Christer Holmberg" 
>>> <[email-masked]>
>>> 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-upd
>>>>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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch