Re: [stir] RFC 8224

[Roman Shpount <[e-mail]>]

I have a border question: What if the destination is phone number +
extension as in sip:[e-mail]? The portion after the
# has no meaning for transit providers but can be interpreted by the
destination PBX.

Best regards.
_____________
Roman Shpount


On Tue, Apr 20, 2021 at 10:50 AM Peterson, Jon <jon.peterson=
[e-mail]> wrote:

>
>
> I certainly think it was the intention of the canonicalization procedures
> to resolve dial strings into globally routable numbers. While there are
> always going to be some exceptions to this (service codes is an example, or
> certain non-geographic freephone numbers, say), I think Chris is hitting on
> the right point here. We sign calls so that a relying party on the
> terminating side can validate them. If what the relying party receives is a
> dial string that has no meaning in their network, what are we accomplishing?
>
>
>
> Jon Peterson
>
> Neustar, Inc.
>
>
>
> *From: *Chris Wendt <[e-mail]>
> *Date: *Tuesday, April 20, 2021 at 7:22 AM
> *To: *"Zerr, Brad" <[e-mail]>
> *Cc: *Christer Holmberg <[e-mail]>, Marc
> Petit-Huguenin <[e-mail]>, Cullen Jennings <[e-mail]>,
> IETF STIR Mail List <[e-mail]>, Eric Rescorla <[e-mail]>,
> "Peterson, Jon" <[e-mail]>, "Toy, Arthur" <[e-mail]>
> *Subject: *Re: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> I think maybe you are addressing the local mechanics since you are likely
> focused on getting implementation correct, but i’m asking more high level
> about why we are signing dialing codes as a dest, when this is application
> specific and there is no chance this will mean anything to a terminating
> provider or customer across NNI interface.  In fact, seems like a real
> potential security threat, which is why i’d like to get some feedback on
> whether i’m not seeing why this would be potentially useful in the case of
> STIR generically let alone STIR/SHAKEN specifically.
>
>
>
> -Chris
>
>
>
> On Apr 19, 2021, at 4:33 PM, Zerr, Brad <[e-mail]> wrote:
>
>
>
> Good afternoon, Chris.
>
>
>
> I am a visual person, so thought it would be nice to lead off with the
> call flow scenario to put this into context.  This is a pretty typical call
> flow scenario for ADC (abbreviated dialing codes / short codes).  I fit
> into the green box below.  As you can see, there is a lot of escaping and
> putting # back into the correct fields.
>
>
>
> <image001.png>
>
>
>
> *From:* Chris Wendt <[e-mail]>
> *Sent:* Monday, April 19, 2021 2:48 PM
> *To:* Christer Holmberg <[e-mail]>
> *Cc:* Zerr, Brad <[e-mail]>; Marc Petit-Huguenin <
> [e-mail]>; Cullen Jennings <[e-mail]>; IETF STIR Mail
> List <[e-mail]>; Eric Rescorla <[e-mail]>; Jon Peterson <
> [e-mail]>; Toy, Arthur <[e-mail]>
> *Subject:* Re: [stir] RFC 8224
>
>
>
> Hi Brad, All,
>
>
>
> 1000082 is a technical report and not a normative document, however
> doesn’t mean that fixes can’t or shouldn’t happen, but you or the folks
> that participate should bring this back to IPNNI group.
>
>
>
> But maybe to take it up a level, I’m still struggling why you are sending
> this dial string, signed back to a peering point.  I’m just wondering do we
> have something broken here and is this an IETF stir issue or IPNNI issue.
>
>
>
> Since this is IETF list, can anyone justify why we want to sign sip:*99 as
> dest for any general SIP scenario?
>
>
>
> I really think part of STIR/SHAKEN initiative should be thinking about
> what telephone identity is being used in To/From/PAID, and it think this is
> something that needs cleaning up, especially across NNI, but i would argue
> even intra network too, but I realize that is harder argument.
>
>
>
> So, not sure i’m missing something, but i’m a little puzzled why others
> are not questioning this as well, thus i’m asking the question.
>
>
>
> -Chris
>
>
>
>
> On Apr 8, 2021, at 4:25 PM, Christer Holmberg <
> [e-mail]> wrote:
>
>
>
> Hi,
>
>
>
> I am not making ATIS contributions, but I am sure there is someone else
> who can help you with that :)
>
>
>
> I still think the processing of the phone-context parameter is a question
> mark, though. Maybe we need to add some text somewhere (unless I’ve missed
> it).
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Zerr, Brad <[e-mail]>
> *Sent:* torstai 8. huhtikuuta 2021 22.56
> *To:* Christer Holmberg <[e-mail]>; Marc
> Petit-Huguenin <[e-mail]>; Chris Wendt <
> [e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Fyi.  Something like this in the document (ATIS-1000074 or 1000082) may go
> a long way:
>
>
>
> <image001.png>
>
>
>
> *From:* Christer Holmberg <[e-mail]>
> *Sent:* Thursday, April 8, 2021 2:34 PM
> *To:* Zerr, Brad <[e-mail]>; Marc Petit-Huguenin <
> [e-mail]>; Chris Wendt <[e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> You take the telephone number from the To header, and place it into the
> “dest”/”tn” claim of the PASSport.
>
>
>
> But, unfortunately # has to be escaped in the To header, and un-escaped in
> the “dest”/”tn” claim, so you need to do a escaped-to-un-escaped conversion
> when placing the phone number in the PASSport.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Zerr, Brad <[e-mail]>
> *Sent:* torstai 8. huhtikuuta 2021 22.27
> *To:* Christer Holmberg <[e-mail]>; Marc
> Petit-Huguenin <[e-mail]>; Chris Wendt <
> [e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi Christer,
>
>
>
> Can you describe how you determine that.  According to ATIS-1000074-E, the
> destination claim “tn” states to use the To header.
>
>
>
> <image002.png>
>
>
>
> *From:* Christer Holmberg <[e-mail]>
> *Sent:* Thursday, April 8, 2021 2:21 PM
> *To:* Zerr, Brad <[e-mail]>; Marc Petit-Huguenin <
> [e-mail]>; Chris Wendt <[e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* Re: [stir] RFC 8224
>
>
>
> Hi Brad,
>
>
>
> The ATIS text you reference is not for the To header.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Get Outlook for iOS
> <https://urldefense.com/v3/__https://aka.ms/o0ukef__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm4_Mp3zA$>
> ------------------------------
>
> *From:* Zerr, Brad <[e-mail]>
> *Sent:* Thursday, April 8, 2021 10:16:44 PM
> *To:* Christer Holmberg <[e-mail]>; Marc
> Petit-Huguenin <[e-mail]>; Chris Wendt <
> [e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi all,
>
>
>
> From previous conversations, it was recommended that the # character in
> the TO header needed to be escaped with %23
>
>
>
> To: sip:%2355;phone-context=[e-mail]420.
> mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
>
>
>
> This seems to be at odds with ATIS 1000082 stating what the allowed
> characters are.  As you can see below from 1000082, the % is not as part of
> this list.
>
>
>
> Recommendations?
>
>
>
> <image003.png>
>
>
>
> *From:* Christer Holmberg <[e-mail]>
> *Sent:* Wednesday, April 7, 2021 4:00 PM
> *To:* Marc Petit-Huguenin <[e-mail]>; Zerr, Brad <
> [e-mail]>; Chris Wendt <[e-mail]>
> *Cc:* Cullen Jennings <[e-mail]>; IETF STIR Mail List <[e-mail]>;
> Eric Rescorla <[e-mail]>; Jon Peterson <[e-mail]>;
> Toy, Arthur <[e-mail]>
> *Subject:* RE: [stir] RFC 8224
>
>
>
> Hi,
>
> >>>>> 1. Section 8.1:
> >>>>>
> >>>>> The origin is either in the From header or in the
> P-Asserted-Identity header, in the example below we have both, but which
> one to use is a matter of local policy, so we are going to process all 3
> (one in the From, two in the PAI):
> >>>>>
> >>>>> orig1:
> >>>>> sip:[e-mail];tag=p65539t1617
> >>>>> 20
> >>>>> 6731m169121c110882s1_1220390100-1617434405
> >>>>> orig2: sip:[e-mail]
> >>>>> orig3: tel:xxxxxxxxx <xxxxxxxxx>
> >>>>>
> >>>>> The destination is always in the To header:
> >>>>>
> >>>>> dest:
> >>>>> sip:*99;phone-context=[e-mail].
> >>>>> mc
> >>>>> cxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
> ;user=phone
> >>>>>
> >>>>> 2. Section 8.1
> >>>>>
> >>>>> Per this section, SIP URIs containing a user=phone parameter or tel
> URI contain a phone numbers. Everything else does not contain a phone
> number.
> >>>>>
> >>>>> Here only orig3 and dest contains a phone number, and need to be
> canonicalized using section 8.3. The part subject to canonicalization is
> the user part of the URI:
> >>>>>
> >>>>> orig3: xxxxxxxxx
> >>>>> dest: *99;phone-context=ims.mncxxx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=7c40792e-23db4012-7c4039b5-86b1886cfa64-568f8cb842251179&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mncxxx.mccxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm9qz1or8$>
> >>>>>
> >>>>> orig1 and orig2 are canonicalized using section 8.5. The input is
> the whole URI:
> >>>>>
> >>>>> orig1: sip:[e-mail]
> >>>>> orig2: ip:[e-mail]
> >>>>
> >>>> Where in Section 8 is it defined that phone-context is removed?
> >>>
> >>> It is removed by not being part of the username (or user part) portion
> of a SIP URI:
> >>
> >> It is part of the user part.
> >>
> >> When user=phone is present, the user part is encoded as a
> telephone-subscriber (RFC 2806), which may contain a phone-context.
> >
> > Right, I was thinking of user=phone.
> >
> > phone-context and the other parameters are removed when applying the
> first bullet point in 8.3.
>
> well, the bullet only talks about specific characters, which means numeric
> characters of the phone-context would remain...
>
> I think there should be explicit text about tel-URL parameters (in
> addition to phone-context there are also others).
>
> Regards,
>
> Christer
>
>
>
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> >
> >
> >
> >
> >
> > 8.1:
> >
> > "First, implementations will ascertain if the user portion of the URI
> > constitutes a telephone number. Telephone numbers most commonly
> > appear in SIP header field values in the username portion of a SIP
> > URI"
> >
> > 8.3:
> >
> > "Once an implementation has identified a telephone number, it must
> > construct a number string."
> >
> > "o Implementations MUST drop any "+"s, internal dashes, parentheses,
> > or other non-numeric characters, except for the "#" or "*" keys
> > used in some special service numbers"
> >
> >
> >>
> >>
> >>
> >> On 4/7/21 9:54 AM, Christer Holmberg wrote:
> >>> Hi,
> >>>
> >>>>> Maybe the problem with the To header is the phone-context parameter.
> >>>>> The RFC 8224 procedures do not cover the presence of the parameter:
> the parameter is not removed, nor is it added to the tn. And, the generic
> SIP canonicalization procedures does not remove the parameter either.
> >>>>
> >>>> That is not my understanding of RFC 8224 section 8.1 and 8.3.
> >>>
> >>> What is your understanding?
> >>>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>>
> >>>> From: Zerr, Brad <[e-mail]>
> >>>> Sent: keskiviikko 7. huhtikuuta 2021 18.26
> >>>> To: Chris Wendt <[e-mail]>; Christer Holmberg
> >>>> <[e-mail]>
> >>>> Cc: Marc Petit-Huguenin <[e-mail]>; Cullen Jennings
> >>>> <[e-mail]>; IETF STIR Mail List <[e-mail]>; Eric Rescorla
> >>>> <[e-mail]>; Jon Peterson <[e-mail]>; Toy,
> >>>> Arthur <[e-mail]>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Hi Chris,
> >>>>
> >>>> Here is a little background that got this conversation going.
> >>>>
> >>>> One of our customers sent us a SIP INVITE so we could perform the
> Stir-Shaken Signing for them. The customer performed the translations on
> their MMTEL TAS to translate *55 to a 10 digit number. When we receive the
> SIP INVITE for signing, it had the REQ-URI with the 10 digit number and the
> TO header with *55, see below. Our applications rejected this because of
> the TO header (whether it is right or wrong is to be determined). So we
> start questioning how * and # short codes should be handled.
> >>>>
> >>>> FYI, I “x” out information to keep anonymous
> >>>>
> >>>> INVITE
> >>>> sip:+xxxxxxxxxx;phone-context=[e-mail]
> >>>> x x x.mcc3xxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://x.mcc3xxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm2TTnri4$>;user=phone
> SIP/2.0
> >>>> To:
> >>>> sip:*99;phone-context=[e-mail].
> >>>> m
> >>>> c
> >>>> cxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://cxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmPaMNhOA$>
> ;user=phone
> >>>> From:
> >>>> sip:[e-mail];tag=p65539t1617
> >>>> 2
> >>>> 0
> >>>> 6731m169121c110882s1_1220390100-1617434405
> >>>> Call-ID: p65539t1617206731m169121c110882s2
> >>>> CSeq: 1 INVITE
> >>>> Max-Forwards: 66
> >>>> Content-Length: 896
> >>>> Via: SIP/2.0/TCP
> >>>> xxxxxxxxxx:5060;branch=z9hG4bK1a5ca0b3c42536a59ddec4c723f8774fk5555
> >>>> 5
> >>>> 5 yaaaaacaaaaaaaaaaaaa3Zqkv7yujk3t0qbaaiaiaaaaabqaaaaaaaqaaaaaa
> >>>> Via: SIP/2.0/TCP xxxxxxx:5082;branch=z9hG4bK1220390081-337970536
> >>>> Route:
> >>>> sip:xxxx.cgah.ims.mncxxx.mccxxx.3gppnetwork.org;callhalf=orig;lr
> >>>> Route:
> >>>> sip:3Zqkv7%2FcaGmGRV9neaaaacgloTpN3kFNU6jv2EObabaecaSdeaaaadsip%3A%
> >>>> 2
> >>>> B
> >>>> xxxxxxxx%40ims.mncxxx.mccxxx.3gppnetwork.orgOLxz6Geaeaqxxxxxxxxxxx%
> >>>> 4
> >>>> 0 ims.mncxxx.mcc3xxx.3gppnetwork.org@xxxxxxxxxxxx:5060;lr
> >>>> Record-Route:
> >>>> sip:3Zqkv7%20caqmGRV9ngaaaaaQjv2EObabaeaaaaamsip%3A%2Bxxxxxxx%40ims.
> >>>> m
> >>>> [e-mail].3gppnetwork.
> >>>> o
> >>>> rg:5060;maddr=xxxxxxxxx;lr
> >>>> Contact:
> sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype="cellular";+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel<sip:p65539t1617206731m169121c110882s1@xxxxxxxx:5082;+g.3gpp.accesstype=%22cellular%22;+g.3gpp.icsi-ref=%22urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel
> >"
> >>>> Content-Type: application/sdp
> >>>> Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE, PRACK,
> >>>> UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
> >>>> Accept-Contact:
> *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
> >>>> Supported: timer, 100rel, path, precondition, replaces
> >>>> P-Asserted-Identity:
> >>>> sip:[e-mail]
> >>>> P-Asserted-Identity: tel:xxxxxxxxx <xxxxxxxxx>
> >>>> Proxy-Authorization: Digest
> >>>> uri=sip:*99;phone-context=[e-mail]
> >>>> c
> >>>> x
> >>>> xx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://xx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmrKVq_1I$>
> ;user=phone,response="",nonce="",realm="",
> >>>> u
> >>>> s
> >>>> ername=[e-mail]<mailto:xxx
> >>>> x x [e-mail]>
> >>>> P-Visited-Network-ID: ims.mnc420.mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=34ec8226-6b77bb1a-34ecc2bd-86b1886cfa64-e171fd55781981c8&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mcc312.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm_E69mA8$>
> >>>> P-Access-Network-Info:
> >>>> 3GPP-E-UTRAN-FDD;local-time-zone="2021-03-31T11:05:31-05:00";utran-
> >>>> c
> >>>> e
> >>>> ll-id-3gpp=xxxxxxxxxxxxxxxxxxxxxxxx
> >>>> Min-SE: 900
> >>>> Session-Expires: 1800
> >>>> P-Charging-Vector:
> >>>> icid-value=pcscf2.ims.mncxxx.mcc3xxx.3gppnetw-1617-206731-149675;ic
> >>>> i
> >>>> d
> >>>> -generated-at=pcscf2.ims.mncxxx.mccxxx.3gppnetwork.org
> <https://urldefense.com/v3/__http://ims.mncxxx.mccxxx.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmzkbVY5k$>
> ;orig-ioi=ims.
> >>>> m
> >>>> ncxxx.mccxxxx.3gppnetwork.org
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=eeef46a8-b1747f94-eeef0633-86b1886cfa64-e50d414254cbb27d&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fncxxx.mccxxxx.3gppnetwork.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmmgQ1NYU$>
> >>>> User-Agent: Ericsson MTAS - CXP2010134/1 R20F14
> >>>> P-Charging-Function-Addresses: ccf="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
> >>>> P-Served-User:
> >>>> sip:[e-mail];sescase=orig;regs
> >>>> t
> >>>> a
> >>>> te=reg
> >>>> Feature-Caps: *;+g.3gpp.registration-token="<63b9cf28>"
> >>>> P-Early-Media: supported
> >>>> Session-ID: 7c386176b888d13d404845e189d6885b
> >>>>
> >>>> From: Chris Wendt
> >>>> <[e-mail]<mailto:[e-mail]>>
> >>>> Sent: Wednesday, April 7, 2021 10:10 AM
> >>>> To: Christer Holmberg
> >>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
> <[e-mail]%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>> Cc: Zerr, Brad <[e-mail]<mailto:[e-mail]>>; Marc
> >>>> Petit-Huguenin
> >>>> <[e-mail]<mailto:[e-mail]>>; Cullen
> >>>> Jennings <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List
> >>>> <[e-mail]<mailto:[e-mail]>>; Eric Rescorla
> >>>> <[e-mail]<mailto:[e-mail]>>; Jon Peterson
> >>>> <[e-mail]<mailto:[e-mail]>>; Toy,
> >>>> Arthur <[e-mail]<mailto:[e-mail]>>
> >>>> Subject: Re: [stir] RFC 8224
> >>>>
> >>>> This is a legit question for RFC8224 and agree with the answers, but
> just in case it’s relevant you would not send these types of SIP URIs as
> dest in context of STIR/SHAKEN (over NNI/peering relationship) which only
> supports tel URIs currently. That may not be your use-case but just wanted
> to clarify in case it was relevant. I would be curious to know the context
> if you are willing to share though, i am guessing intra network use case
> between device and app server? Definitely interested in those cases, for me
> in context of delegate certs.
> >>>>
> >>>> -Chris
> >>>>
> >>>>
> >>>>
> >>>> On Apr 7, 2021, at 9:52 AM, Christer Holmberg <
> [e-mail]<mailto:[e-mail]>>
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> ´*´ can be used as such in a SIP-URI, but ‘#’ would have to be
> escaped.
> >>>>
> >>>> So:
> >>>>
> >>>> To:
> >>>> sip:*55;phone-context=[e-mail]420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> …is ok, but;
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=[e-mail]420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=de790f19-81e23625-de794f82-86b1886cfa64-8040fe565ed6c82c&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmXz7Bjus$>
> >>>> c
> >>>> 3 [e-mail];user=phone>
> >>>>
> >>>> …is NOT ok. Instead:
> >>>>
> >>>> To:
> >>>> sip:%2355;phone-context=[e-mail]420.
> >>>> mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>
> >>>> …will have to be used.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>> From: Zerr, Brad <[e-mail]<mailto:[e-mail]>>
> >>>> Sent: keskiviikko 7. huhtikuuta 2021 14.27
> >>>> To: Christer Holmberg
> >>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
> <[e-mail]%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>> ; Marc Petit-Huguenin
> >>>> <[e-mail]<mailto:[e-mail]>>; Cullen
> >>>> Jennings <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List
> >>>> <[e-mail]<mailto:[e-mail]>>
> >>>> Cc: [e-mail]<mailto:[e-mail]>;
> >>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson
> >>>> <[e-mail]<mailto:[e-mail]>>; Toy,
> >>>> Arthur <[e-mail]<mailto:[e-mail]>>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Good Morning.
> >>>>
> >>>> Would you mind providing an example of what the TO header should look
> like for both a * and # dial to help clear up? Assume they are leading
> characters in the TO header.
> >>>>
> >>>> Example of what is being sent today:
> >>>>
> >>>> To:
> >>>> sip:*55;phone-context=[e-mail]420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>>
> >>>> To:
> >>>> sip:#55;phone-context=[e-mail]420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone<sip:*55;phone-context=ims.mnc420.mc
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=8b69ba29-d4f28315-8b69fab2-86b1886cfa64-770258b0ccf0eabc&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fims.mnc420.mc*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmuZBnGaY$>
> >>>> c
> >>>> 3 [e-mail];user=phone>
> >>>>
> >>>> From: Christer Holmberg
> >>>> <[e-mail]<mailto:christer.holmberg@ericsson.c
> <[e-mail]%3cmailto:christer.holmberg@ericsson.c%0b>>>>>
> o
> >>>> m
> >>>>>>
> >>>> Sent: Wednesday, April 7, 2021 3:14 AM
> >>>> To: Marc Petit-Huguenin
> >>>> <[e-mail]<mailto:[e-mail]>>; Cullen
> >>>> Jennings <[e-mail]<mailto:[e-mail]>>; Zerr, Brad
> >>>> <[e-mail]<mailto:[e-mail]>>; IETF STIR Mail List
> >>>> <[e-mail]<mailto:[e-mail]>>
> >>>> Cc: [e-mail]<mailto:[e-mail]>;
> >>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson
> >>>> <[e-mail]<mailto:[e-mail]>>; Toy,
> >>>> Arthur <[e-mail]<mailto:[e-mail]>>
> >>>> Subject: RE: [stir] RFC 8224
> >>>>
> >>>> Hi,
> >>>>
> >>>>> I think the question was about the format to use before
> canonicalization.
> >>>>>
> >>>>> My understanding of RFC 3986 is that `#` should be escaped because
> it is the delimiter for an URI fragment. Fragments are not defined in SIP
> URIs, but a generic URI parser may still remove everything after and
> including '#'.
> >>>>
> >>>> "#" will have to be escaped in a SIP-URI, e.g., in a To header field.
> >>>>
> >>>> But, Section 8.3 of RFC 8224 has nothing to do with a SIP-URI or the
> To header field.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> OTOH there is no need to escape '*' as it is part of the `sub-delims`
> rule.
> >>>>
> >>>> so
> >>>>
> >>>> ....
> >>>> To:
> >>>> sip:*55;phone-context=[e-mail]420.
> >>>> m
> >>>> c
> >>>> c312.3gppnetwork.org
> <https://urldefense.com/v3/__http://c312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmVfPlssk$>
> ;user=phone
> >>>> ....
> >>>>
> >>>> is fine, but dialing directly an extension would be:
> >>>>
> >>>> ....
> >>>> To: sip:[e-mail];user=phone
> >>>> ....
> >>>>
> >>>> On 4/6/21 5:43 AM, Christer Holmberg wrote:
> >>>>> Hi,
> >>>>>
> >>>>> %2A is not the ASCII format of *, it is the escaped (see RFC 3261).
> >>>>>
> >>>>> And, the syntax allows both * and #, so no need to escape (in fact,
> it is not even possible to escape in this case):
> >>>>>
> >>>>> tn-spec = 1*tn-char
> >>>>> tn-char = "#" / "*" / DIGIT
> >>>>>
> >>>>> Also, note that RFC 8224 does not define the syntax of the To header
> field - that is done in RFC 3261. The telephone number described in Section
> 8.3 of RFC 8224 will be included in the PASSPort (RFC 8225).
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Christer
> >>>>>
> >>>>> From: stir <[e-mail]<mailto:[e-mail]>>
> >>>>> On Behalf Of Cullen Jennings
> >>>>> Sent: tiistai 6. huhtikuuta 2021 15.30
> >>>>> To: Zerr, Brad <[e-mail]<mailto:[e-mail]>>; IETF STIR
> >>>>> Mail List <[e-mail]<mailto:[e-mail]>>
> >>>>> Cc: [e-mail]<mailto:[e-mail]>;
> >>>>> Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Jon Peterson
> >>>>> <[e-mail]<mailto:[e-mail]>>; Toy,
> >>>>> Arthur <[e-mail]<mailto:[e-mail]>>
> >>>>> Subject: Re: [stir] RFC 8224
> >>>>>
> >>>>>
> >>>>> Adding to STIR mailing list …
> >>>>>
> >>>>>
> >>>>> On Apr 5, 2021, at 9:19 AM, Zerr, Brad <
> [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]
> <[e-mail]%3cmailto:[e-mail]%3cmailto:[e-mail]%3cmailto:[e-mail]>>>>
> wrote:
> >>>>>
> >>>>> Good Morning.
> >>>>>
> >>>>> This may not be the correct process, so let me know if I should ask
> this in a different forum.
> >>>>>
> >>>>> I had a question regarding section 8.3 when it comes to * and #
> >>>>> handling. Is this stating that when a * or # proceeds a digit
> >>>>> string (i.e. *55), it should be in ASCI Format for the * (i.e.
> >>>>> %2A)
> >>>>>
> >>>>> <image001.png>
> >>>>>
> >>>>> So Instead of this:
> >>>>>
> >>>>> To:
> >>>>> sip:*55;phone-context=[e-mail]420.
> >>>>> m
> >>>>> cc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://cc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmfRONVeE$>
> ;user=phone
> >>>>>
> >>>>> It should be this
> >>>>>
> >>>>> To:
> >>>>> sip:%2A55;phone-context=[e-mail]4
> >>>>> 2
> >>>>> 0
> >>>>> .mcc312.3gppnetwork.org
> <https://urldefense.com/v3/__http://mcc312.3gppnetwork.org/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmFbxZBbE$>
> ;user=phone
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
>
>
>
>
> --
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog:
> https://protect2.fireeye.com/v1/url?k=28d0d527-774bedc5-28d095bc-86073b36ea28-f2c358423b8421cd&q=1&e=78d08abe-b951-45e0-a93d-4a2bc670a4be&u=https%3A%2F%2Fmarc.petit-huguenin.org%2F
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=28d0d527-774bedc5-28d095bc-86073b36ea28-f2c358423b8421cd&q=1&e=78d08abe-b951-45e0-a93d-4a2bc670a4be&u=https*3A*2F*2Fmarc.petit-huguenin.org*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm6Ydzy3k$>
> Profile: https://www.linkedin.com/in/petithug
> <https://urldefense.com/v3/__https://www.linkedin.com/in/petithug__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmoI6LC4M$>
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=42ec3a2d-1d770311-42ec7ab6-86b1886cfa64-3d8237f494010d10&q=1&e=0857f501-f35f-4a5a-b9cc-18fdb5033d11&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmQbUy4sM$>
> ------------------------------
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=020077dc-5d9b4ef1-02003747-8692dc8284cb-ec95acff01abac94&q=1&e=1f14ae7d-a5b2-43c1-b945-f0c630ffb408&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmjtmQmno$>
> ------------------------------
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=d374985c-8cefa160-d374d8c7-86b1886cfa64-26115e6a3e22c2ad&q=1&e=776a0e59-f4eb-4d9d-9834-6391c543254b&u=http*3A*2F*2Fwww.mimecast.com*2F__;JSUlJQ!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODm-WDhmgg$>
> ------------------------------
>
>
>
>
> ------------------------------
>
>
> This e-mail message is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information of Transaction Network
> Services.
> Any unauthorized reviews, use, disclosure or distribution is prohibited.
> If you are not
> the intended recipient, please contact the sender by reply e-mail and
> destroy all copies
> of the original message.
>
>
>
> ------------------------------
>
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> <https://urldefense.com/v3/__http://www.mimecast.com/__;!!N14HnBHF!q9wWho1cNUwvzcZ8DPi8PsgND6ZUxdV4-VKsWX8A7KKpPQawDODmLPaDIuo$>
>
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>