Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Dec 2015 10:22:20 +0000

Hi,

3GPP has been studying possible misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229.

Rather than posting all the issues in a single e-mail, I will send e-mails per header field. This e-mail is about P-Access-Network-Info, where two issues were identified.

Issue 1)             3GPP TS 24.229 allows PANI in ACK requests

Back in 2012, CT1 agreed on a case, related to network provided location information, where PANI is needed in ACK.

Now, this should have been introduced in RFC7315 (which wasn't published until 2014), but unfortunately the authors (myself included) missed that part.

I assume this cannot be fixed with an errata - it would require an update to RFC7315 (probably not a bis, but a draft that updates the affected part(s) of RFC7315).

Issue 2)             RFC 7315 is inconsistent on whether PANI is allowed  in SIP responses

RFC 3455, and 3GPP TS 24.229, allow usage of the PANI header field in SIP responses. However, RFC 7315 is inconsistent.
Chapter 4.4 says:

                "When a UA generates a SIP request or response that it knows is going
               to be securely sent to its SIP proxy that is providing services, the
               UA inserts a P-Access-Network-Info header field into field the SIP
               message."

... which DOES imply that PANI is allowed in SIP responses.

Chapter 4.4.2.1 implies the same thing:

                "A UA that supports this extension and is willing to disclose the
               related parameters MAY insert the P-Access-Network-Info header field
               in any SIP request or response."

However, chapter 5.7. says:

5.7.  New Headers

               "The P-Associated-URI header field can appear in SIP REGISTER method
               and 2xx resonses.  The P-Called-Party-ID header field can appear in
               SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all
               responses.  The P-Visited-Network-ID header field can appear in all
               SIP methods except ACK, BYE, and CANCEL and all responses.  The
               P-Access-Network-Info header field can appear in all SIP methods
               except ACK and CANCEL.  The P-Charging-Vector header field can appear
               in all SIP methods except CANCEL.  The P-Charging-Function-Addresses
               header field can appear in all SIP methods except ACK and CANCEL."

...where responses, unlike in the case of other header fields, are not explicitly mentioned for PANI.

I assume this is just a bug in section 5.7, which could be fixed with an errata:

OLD TEXT:

                "The P-Access-Network-Info header field can appear in all SIP methods
               except ACK and CANCEL."

NEW TEXT:

                "The P-Access-Network-Info header field can appear in all SIP methods
               except ACK and CANCEL <new>and all responses</new>."

Regards,

Christer

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 3 Dec 2015 16:03:54 -0600

Hi Christer,

On 12/3/15 4:22 AM, Christer Holmberg wrote:
> Hi,
>
> 3GPP has been studying possible misalignments between the P- header
> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229.
>
> Rather than posting all the issues in a single e-mail, I will send
> e-mails per header field. This e-mail is about P-Access-Network-Info,
> where two issues were identified.
>
> *Issue 1)             3GPP TS 24.229 allows PANI in ACK requests*
>
> Back in 2012, CT1 agreed on a case, related to network provided location
> information, where PANI is needed in ACK.
>
> Now, this should have been introduced in RFC7315 (which wasn’t published
> until 2014), but unfortunately the authors (myself included) missed that
> part.
>
> I assume this cannot be fixed with an errata – it would require an
> update to RFC7315 (probably not a bis, but a draft that updates the
> affected part(s) of RFC7315).

This change would be more than can be handled by an erratum, and I think 
that an update to RFC 7315 makes sense, with some text on what the use 
case is. I tried to find the scenario in 24.229, but the TS didn't yield 
that info easily. However, I did find inconsistencies in 24.229 on using 
PANI in ACK requests. For instance:

5.1.6.8.2: "...the UE shall include in the P-Access-Network-Info header 
field in any request for a dialog, any subsequent request (except ACK 
requests and CANCEL requests) or response (except CANCEL responses) 
within a dialog or any request."

5.1.6.10 Note 3: "The UE will populate the P-Access-Network-Info header 
field in any request (except ACK requests and CANCEL requests) or 
response (except CANCEL responses) within a dialog with the current 
point of attachment to the IP-CAN....

5.7.1.3: "The AS may also receive information about the served user 
access network in other requests (excluding ACK requests and CANCEL 
requests and responses). This information can be obtained from the 
P-Access-Network-Info header field."

But in other places, using PANI in ACK is implied/allowed:

5.1.2A.2: "If available to the UE ..., the UE shall insert a P-Access 
Network-Info header field into any response to a request for a dialog, 
any subsequent request (except CANCEL requests) or response (except 
CANCEL responses) within a dialog or any response to a standalone method..."

TS 24.229 5.2.1: "When the P-CSCF receives any request or response from 
the UE, the P-CSCF: ... 4) may insert a P-Access-Network-Info header 
field where: ..."

TS 24.229 8.1.1 "If in normal operation the UE generates requests or 
responses containing a P-Access-Network-Info header field which included 
a value of ..."

Table A.165/A.7: Supported header fields within the ACK request

>
> *Issue 2)             RFC 7315 is inconsistent on whether PANI is
> allowed  in SIP responses*
>
> RFC 3455, and 3GPP TS 24.229, allow usage of the PANI header field in
> SIP responses. However, RFC 7315 is inconsistent.
>
> *Chapter 4.4 says:*
>
>                  “When a UA generates a SIP request or response that it
> knows is going
>
>                 message.”
> … which DOES imply that PANI is allowed in SIP responses.

Both RFC 3455 and RFC 7315 have the same text here. So far so good.

>
> *Chapter 4.4.2.1*implies the same thing:
>
>                  “A UA that supports this extension and is willing to
> disclose the
>
>                 in any SIP request or response.”
>

Both RFC 3455 and RFC 7315 have the same text here. So far so good.

> However, *chapter 5.7*. says:
>
> 5.7.  New Headers
>
>                 “The P-Associated-URI header field can appear in SIP
> REGISTER method
>
>                 header field can appear in all SIP methods except ACK
> and CANCEL.”
>
> …where responses, unlike in the case of other header fields, are not
> explicitly mentioned for PANI.

And here is where it goes wrong - RFC 7315 attempted to capture in prose 
the content of Table 1 in RFC 3455, but did not cover that PANI was 
allowed in responses, which is clear in the RFC 3455 table.

Nothing in RFC 7315 Appendix A indicates that this change was intentional.

> I assume this is just a bug in section 5.7, which could be fixed with an

This does appear to be a bug.

>
> OLD TEXT:
>
>                  “The P-Access-Network-Info header field can appear in
> all SIP methods
>
>                 except ACK and CANCEL.”
>
> NEW TEXT:
>
>                  “The P-Access-Network-Info header field can appear in
> all SIP methods
>
>                 except ACK and CANCEL <new>and all responses</new>.”

How about this NEW TEXT?

"The P-Access-Network-Info header field can appear in any request except 
for the CANCEL request and the ACK request. The P-Access-Network-Info 
header field can appear in any response, except in responses to CANCEL."

But since we're trying to clarify - what about 100 Trying (specifically 
100, not 1xx) responses? Does PANI make sense there?

Thanks,

Jean

>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Dec 2015 11:20:47 +0000

Hi Jean,

>> Back in 2012, CT1 agreed on a case, related to network provided 
>> location information, where PANI is needed in ACK.
>>
>> Now, this should have been introduced in RFC7315 (which wasn't 
>> published until 2014), but unfortunately the authors (myself included) 
>> missed that part.
>>
>> I assume this cannot be fixed with an errata - it would require an 
> This change would be more than can be handled by an erratum, and I think that an update to RFC 7315 makes sense, with some text on what the use 
> case is. I tried to find the scenario in 24.229, but the TS didn't yield that info easily. 

Correct, and the CR which added support of PANI for ACK didn't give much information either. It said:

                 "RFC3455 currently does not allow the usage of the P-Access-Network-Info header field in the SIP ACK request.
                 
                 However, in order to implement all scenarios defined for network provided location information, in order to avoid having to 
                 implement B2BUA functionality in the P-CSCF, the P-CSCF needs to be able to insert the P-Access-Network-Info header field in 
                 that requests."

Now, I actually wrote that CR myself, but as it was back in 2012 I can't remember the details from my head. So, I'd have to look into that :)

> However, I did find inconsistencies in 24.229 on using PANI in ACK requests. For instance:
>
> 5.1.6.8.2: "...the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except ACK requests 
> and CANCEL requests) or response (except CANCEL responses) within a dialog or any request."
>
> 5.1.6.10 Note 3: "The UE will populate the P-Access-Network-Info header field in any request (except ACK requests and CANCEL requests) or response 
> (except CANCEL responses) within a dialog with the current point of attachment to the IP-CAN....
>
> 5.7.1.3: "The AS may also receive information about the served user access network in other requests (excluding ACK requests and CANCEL requests and 
> responses). This information can be obtained from the P-Access-Network-Info header field."
>
> 5.1.2A.2: "If available to the UE ..., the UE shall insert a P-Access Network-Info header field into any response to a request for a dialog, any subsequent request 
>(except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method..."
>
> TS 24.229 5.2.1: "When the P-CSCF receives any request or response from the UE, the P-CSCF: ... 4) may insert a P-Access-Network-Info header field where: ..."
>
> TS 24.229 8.1.1 "If in normal operation the UE generates requests or responses containing a P-Access-Network-Info header field which included a value of ..."
>

Correct. 24.229 is inconsistent, and needs to be fixed.

-------------------

>> SIP responses. However, RFC 7315 is inconsistent.

...

>>                 "The P-Associated-URI header field can appear in SIP 
>>                 REGISTER method and 2xx resonses.  The P-Called-Party-ID header field 
>>                 can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE 
>>                 methods and all responses.  The P-Visited-Network-ID header field can 
>>                 appear in all SIP methods except ACK, BYE, and CANCEL and all 
>>                 responses.  The P-Access-Network-Info header field can appear in all 
>>                 SIP methods except ACK and CANCEL.  The P-Charging-Vector header 
>>                 field can appear in all SIP methods except CANCEL.  The 
>>                 P-Charging-Function-Addresses header field can appear in all SIP methods except ACK 
>>                 and CANCEL."
>>
> And here is where it goes wrong - RFC 7315 attempted to capture in prose the content of Table 1 in RFC 3455, but did not cover that PANI was allowed in responses, which is clear in the RFC 3455 table.
>
>>                  "The P-Access-Network-Info header field can appear in 
>>                   all SIP methods except ACK and CANCEL."
>>
>> NEW TEXT:
>>
>>                  "The P-Access-Network-Info header field can appear in 
>>                   all SIP methods except ACK and CANCEL <new>and all responses</new>."
>
>
> How about this NEW TEXT?
>
> "The P-Access-Network-Info header field can appear in any request except for the CANCEL request and the ACK request. The P-Access-Network-Info header field can appear in any response, except in responses to CANCEL."
>
> But since we're trying to clarify - what about 100 Trying (specifically 100, not 1xx) responses? Does PANI make sense there?

I'd have to look at the details.

Now, in my e-mails regarding the other P- header fields, all of them require a fix in section 5.7.

So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual sentencens.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Dec 2015 09:09:00 -0500

> So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual se…

Yes, I think so.

I found the separate emails for each issue a little hard to follow since 
they were all affecting the same stuff. It is easier to follow the big 
picture when they are all put together.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Dec 2015 14:34:55 +0000

Hi,

So, based on my chapter 5.7 fix suggestions for each individual header field, below is a "compiled" fix suggestion for the whole chapter.

Note that I've done some minor editorial changes, based e.g. on Jean's comments.

OLD TEXT:

5.7.  New Headers

   The P-Associated-URI header field can appear in SIP REGISTER method
   and 2xx resonses.  The P-Called-Party-ID header field can appear in
   SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods.
   The P-Visited-Network-ID header field can appear in all
   SIP methods except ACK, BYE, and CANCEL and all responses.  The
   P-Access-Network-Info header field can appear in all SIP methods
   except ACK and CANCEL and all responses.  The P-Charging-Vector header field can appear
   in all SIP methods except CANCEL.  The P-Charging-Function-Addresses
   header field can appear in all SIP methods except ACK and CANCEL.

NEW TEXT:

5.7.  New Headers

   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, SUBSCRIBE, and MESSAGE methods and in all
   responses associated with those methods.  The P-Visited-Network-ID header field can appear in all
   SIP methods except ACK, BYE, and CANCEL.  The
   P-Access-Network-Info header field can appear in all SIP methods
   and responses, except in ACK and CANCEL methods and CANCEL responses.  The P-Charging-Vector header field can appear
   in all SIP methods and responses, except in CANCEL methods and CANCEL responses.  The P-Charging-Function-Addresses
   header field can appear in all SIP methods and responses except ACK and CANCEL.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 4. joulukuuta 2015 16:09
To: [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Yes, I think so.

I found the separate emails for each issue a little hard to follow since they were all affecting the same stuff. It is easier to follow the big picture when they are all put together.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Dec 2015 18:58:44 +0000

Hi,

I guess we could also consider changing "method" to "request". The "method" terminology doesn't seem to be used anywhere else in the document...

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 04 December 2015 16:35
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

OLD TEXT:

5.7.  New Headers

NEW TEXT:

5.7.  New Headers

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 4. joulukuuta 2015 16:09
To: [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Yes, I think so.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Dec 2015 20:15:36 +0000

Hi,

Also, assuming we will update RFC 7315 in order to allow the PANI header field in ACK requests, section 5.7 would be modified.

So, should we first finalize the errata, and then write an update draft based on the next text? I don't think the draft should be based on the old section 5.7 text.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg 
Sent: 04 December 2015 20:59
To: Christer Holmberg <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: RE: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 04 December 2015 16:35
To: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

OLD TEXT:

5.7.  New Headers

NEW TEXT:

5.7.  New Headers

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 4. joulukuuta 2015 16:09
To: [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Yes, I think so.

	Thanks,
	Paul

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 4 Dec 2015 16:12:30 -0600

Hi Christer,

I think finalizing the errata, and then writing an update draft are the 
correct steps.

Jean

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 4 Dec 2015 16:44:49 -0600

Hi Christer,

When analyzing the text of RFC 7315 section 5.7, I made the assumptions 
that the information in Table 1 of RFC 3455 section 5.7 was correct and 
complete, and that RFC 7315 did not intentionally modify the information 
given in RFC 3455 section 5.7. Based on that, I've added feedback below -

On 12/4/15 8:34 AM, Christer Holmberg wrote:
>     2xx responses.

I agree with the wording above.

>                      The P-Called-Party-ID header field can appear in
>     responses associated with those methods.

For P-Called-Party-ID, Table 1 in RFC 3455 didn't list PUBLISH but did 
list REFER, which is not included in the the text above.

>     SIP methods except ACK, BYE, and CANCEL.

P-Visited-Network-ID is also not applicable to NOTIFY, PRACK, INFO, 
UPDATE according to Table 1 in RFC 3455.

>                                               The
>     in all SIP methods and responses, except in CANCEL methods and CANCEL responses.

Table 1 in RFC 3455 says that P-Charging-Vector is also not applicable 
to ACK.

>     The P-Charging-Function-Addresses

The sentence above should read like the PANI sentence.

Thanks,

Jean

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Dec 2015 15:37:23 +0000

Hi Jean,

> When analyzing the text of RFC 7315 section 5.7, I made the assumptions that the information in Table 1 of RFC 3455 section 5.7 was 
> correct and complete, and that RFC 7315 did not intentionally modify the information given in RFC 3455 section 5.7. Based on that, I've added feedback below -
>
>> OLD TEXT:
>>
>> 5.7.  New Headers
>>

Ok.

---------------

> For P-Called-Party-ID, Table 1 in RFC 3455 didn't list PUBLISH but did list REFER, which is not included in the the text above.

That is true, I missed that part. Allowing it in REFER is also a requirement from 3GPP, so I guess that would have to be part of the 7315 update draft.

---------------

> UPDATE according to Table 1 in RFC 3455.

True.

I don't think that causes any issues in 3GPP, though, because afaik (needs to be verified) 3GPP only defines usage of PVNI in: INVITE-, MESSAGE-, OPTIONS-, PUBLISH-, REFER-, REGISTER- and SUBSCRIBE- requests, which seems to be aligned with *both* the current text and new text that would exclude NOTIFY, PRACK, INFO and UPDATE.

---------------

> Table 1 in RFC 3455 says that P-Charging-Vector is also not applicable 

True. 

However, RFC 7315, and 24.229, currently allows it in ACK requests.

Now, assuming that 7315 was not to do any changes to the 3455 Table 1, I guess the errata would need to remove ACK from 7315, and then the 7315 update draft would have to put it back :)

---------------

> The sentence above should read like the PANI sentence.

True.

	"The P-Charging-Function-Addresses header field can appear in all SIP methods
	and responses, except in ACK and CANCEL methods and CANCEL responses."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Dec 2015 08:46:05 +0000

Hi,

>I think finalizing the errata, and then writing an update draft are the correct steps.

I agree.

However, if doing so, we must still more or less agree on the content of the update draft.

Because, if we agree the errata, and then don't agree on the content of the draft, we will cause an even greater misalignment with 3GPP.

Regards,

Christer

On 12/4/15 2:15 PM, Christer Holmberg wrote:
> To: Christer Holmberg <[email-masked]>; Paul Kyzivat 
> <[email-masked]>; [email-masked]
> Subject: RE: [sipcore] Misalignments between the P- header definitions 
> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info
>
> Hi,
>
> Subject: Re: [sipcore] Misalignments between the P- header definitions 
> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info
>
> Hi,
>
> Subject: Re: [sipcore] Misalignments between the P- header definitions 
> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 6 Dec 2015 11:17:40 -0500

> Because, if we agree the errata, and then don't agree on the content of the draft, we will cause an even greater misalignment with 3GPP.

While there are (procedural) reasons to split the work this way, doing 
so obfuscates what is being done.

At the least I think it would be good settle on the overall set of 
changes required, and *then* partition them into errata and a draft. And 
IMO it would be a good thing to restate the errata in the draft. (In a 
non-normative way.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Dec 2015 18:30:31 +0000

Hi,

> While there are (procedural) reasons to split the work this way, doing so obfuscates what is being done.
>
> At the least I think it would be good settle on the overall set of changes required, and *then* partition them into errata 
> and a draft. And IMO it would be a good thing to restate the errata in the draft. (In a non-normative way.)

Ok. I started putting a draft together, so I'll put everything there.

As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-dispatch draft, but I guess that doesn't matter. Same people...

Regards,

Christer

>> Subject: RE: [sipcore] Misalignments between the P- header 
>> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: 
>> P-Access-Network-Info
>>
>> Hi,
>>
>> Subject: Re: [sipcore] Misalignments between the P- header 
>> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: 
>> P-Access-Network-Info
>>
>> Hi,
>>
>> Subject: Re: [sipcore] Misalignments between the P- header 
>> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: 
>> P-Access-Network-Info
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 6 Dec 2015 19:43:35 +0000

A few comments.

First of all, in response to an earlier comment by Jean, at some period in time we decided that the tables were not a good representation of the way to go, and that a series of normative statements would be better.

However part of the problem with the tables is that they also fell rapidly out of date as we added new methods, and therefore the new text suffers from the same problem in places. It would be better to refer to types of methods, and then give examples, e.g. "dialog creating requests", "requests that can appear within a dialog" and so on.

Obviously CANCEL requests and responses are an exception of any appearance, part of the reason being that these headers are used for information transfer and there is no guarantee with CANCEL as to what any information generated will be received from or sent to, as CANCEL is essentially directly at intermediate points in the interests at dialog cleanup, rather than a real endpoint, and responses to CANCEL are in any case sent on each hop as it is reached. I am happy that CANCEL is still excluded from all of these header fields.

In regard to the ACK request, I'd note that for those header fields where it is now added, it is only added where it is set as a result of 200 (OK) responses (to INVITE). ACK requests to 3xx - 6xx responses have the same problems as CANCEL. I think it would be worth capturing this distinction in the text.

Regards

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 06 December 2015 18:31
To: Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

> changes required, and *then* partition them into errata and a draft. 
> And IMO it would be a good thing to restate the errata in the draft. 
> (In a non-normative way.)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Dec 2015 05:46:53 +0000

Hi,

...

>In regard to the ACK request, I'd note that for those header fields where it is now added, it is only added where it is
>set as a result of 200 (OK) responses (to INVITE). ACK requests to 3xx - 6xx responses have the same problems as CANCEL. I think it would be worth capturing this distinction in the text.

I don't think such details should be in chapter 5.7. It should be clarified in the chapters describing the usage of individual header fields.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 06 December 2015 18:31
To: Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 7 Dec 2015 11:42:34 +0000

But now it is added to ACK, it does need to be clarified.

Keith

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 07 December 2015 05:47
To: DRAGE, Keith (Keith); Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: RE: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

...

>In regard to the ACK request, I'd note that for those header fields 
>where it is now added, it is only added where it is set as a result of 200 (OK) responses (to INVITE). ACK requests to 3xx - 6xx responses have the same problems as CANCEL. I think it would be worth capturing this distinction in the text.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 06 December 2015 18:31
To: Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Dec 2015 12:01:55 +0000

>But now it is added to ACK, it does need to be clarified.

Yes, but not in chapter 5.7 (in my opinion).

It is similar to the case where a header field is only allowed in responses associated with specific response code(s). I don't think we'd list all those response codes in section 5.7.

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: 07 December 2015 05:47
To: DRAGE, Keith (Keith); Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: RE: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

...

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 06 December 2015 18:31
To: Paul Kyzivat; A. Jean Mahoney; [email-masked]
Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info

Hi,

Regards,

Christer