[auth48] [IANA] Re: AUTH48: RFC-to-be 9484 <draft-ietf-masque-connect-ip-13> for your review

[Alanna Paloma <[e-mail]>]

IANA,

Please make the following update to the “Related Information” field of the “masque” URI Suffix in the "Well-Known URIs” registry <https://www.iana.org/assignments/well-known-uris>.

Old: 
For sub-suffix allocations, see registry at [https://www.iana.org/assignments/masque].

New (add “the” before “registry”):
For sub-suffix allocations, see the registry at <https://www.iana.org/assignments/masque>.

The diff file can be seen here: https://www.rfc-editor.org/authors/rfc9484-diff.html

Thank you,
RFC Editor/ap


> On Oct 16, 2023, at 7:22 AM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> Hi Aloma, hi all,
> 
> thanks for the work and catching these last changes. Sorry for my late reply. I reviewed the diff and approve for publication!
> 
> Mirja
> 
> 
> On 06.10.23, 21:26, "Alanna Paloma" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Hi Martin,
> 
> 
> Thank you for your reply. Your approval has been noted on the AUTH48 status page:
> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
> 
> 
> Best regards,
> RFC Editor/ap
> 
> 
>> On Oct 6, 2023, at 11:51 AM, Martin Duke <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Changes LGTM
>> 
>> On Thu, Oct 5, 2023 at 8:35 AM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Magnus,
>> 
>> Thank you for your reply. We have noted your approval on the AUTH48 status page:
>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>> 
>> Once we receive approvals from Mirja and Martin (AD), we will move this document forward in the publication process. 
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>>> On Oct 5, 2023, at 4:43 AM, Magnus Westerlund <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi,
>>> 
>>> I approve the publication of this document.
>>> 
>>> Magnus Westerlund
>>> 
>>> From: Alanna Paloma <[e-mail] <mailto:[e-mail]>>
>>> Date: Friday, 29 September 2023 at 00:39
>>> To: David Schinazi <[e-mail] <mailto:[e-mail]>>
>>> Cc: Alex Chernyakhovsky <[e-mail] <mailto:[e-mail]>>, Martin Duke <[e-mail] <mailto:[e-mail]>>, Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>>, Magnus Westerlund <[e-mail] <mailto:[e-mail]>>, Jean Mahoney <[e-mail] <mailto:[e-mail]>>, Tommy Pauly <[e-mail] <mailto:[e-mail]>>, RFC Errata System <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, Christopher Wood <[e-mail] <mailto:[e-mail]>>, auth48archive <[e-mail] <mailto:[e-mail]>>
>>> Subject: Re: [AD] AUTH48: RFC-to-be 9484 <draft-ietf-masque-connect-ip-13> for your review
>>> 
>>> Hi David,
>>> 
>>> Thank you for your reply. Your approval has been noted on the AUTH48 status page:
>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>> 
>>>> One small point I did notice when comparing our XML with yours is that yours appears to have UTF-8 character tabulation (&#x9;) in a bunch of odd places.
>>>> As an example, I saw that in the text that you just added today, "reject the HTTP Upgrade and attempt to parse the IP packets as a subsequent HTTP request".
>>>> In that sentence, it looks like you added whitespace between the word "and" and the word "attempt".
>>>> In our copy of the XML, the only character between those two words is a space (ASCII 0x20).
>>>> In your copy, there is the following hex sequence between them: 0a 09 20 20 20. The 0x0a is a newline, and it's fine - it makes sense that your copy has line endings in different places - but it's odd to me that there's a tabulation character 0x09 followed by three spaces 0x20. I suspect that was unintentional and done automatically by whichever editor you've been using to make changes.
>>> 
>>> 
>>> Those tabulation characters were likely inserted from copying and pasting the new text into in the XML. Apologies for overlooking this. We have cleaned up this extra spacing in the XML. 
>>> 
>>> We will await approvals from Mirja, Magnus, and Martin (AD).
>>> 
>>> Thank you,
>>> RFC Editor/ap
>>> 
>>>> On Sep 28, 2023, at 2:06 PM, David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Thank you for making the changes Alanna.
>>>> 
>>>> I approve the document for publication.
>>>> 
>>>> One small point I did notice when comparing our XML with yours is that yours appears to have UTF-8 character tabulation (&#x9;) in a bunch of odd places.
>>>> As an example, I saw that in the text that you just added today, "reject the HTTP Upgrade and attempt to parse the IP packets as a subsequent HTTP request".
>>>> In that sentence, it looks like you added whitespace between the word "and" and the word "attempt".
>>>> In our copy of the XML, the only character between those two words is a space (ASCII 0x20).
>>>> In your copy, there is the following hex sequence between them: 0a 09 20 20 20. The 0x0a is a newline, and it's fine - it makes sense that your copy has line endings in different places - but it's odd to me that there's a tabulation character 0x09 followed by three spaces 0x20. I suspect that was unintentional and done automatically by whichever editor you've been using to make changes.
>>>> 
>>>> All that said, I really don't feel strongly about it, so if you think that those tabulations don't matter then that totally works for me.
>>>> 
>>>> David
>>>> 
>>>> 
>>>> 
>>>> On Thu, Sep 28, 2023 at 1:40 PM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>> Hi David, Alex, and Martin (AD)*,
>>>> 
>>>> *Martin - As the AD, please review and approve of the added text at the end of Section 11. This change can be seen in this diff file:
>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html> 
>>>> 
>>>> David and Alex - Thank you for your replies. We have updated the files accordingly and noted Alex’s approval on the AUTH48 status page:
>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>> 
>>>> The files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-editor.org/authors/rfc9448.pdf>
>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>> 
>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html> (comprehensive diff)
>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all AUTH48 changes)
>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html> (htmlwdiff diff between last version and this)
>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html> (rfcdiff between last version and this)
>>>> 
>>>> We will await approvals from David, Mirja, Magnus, and *Martin prior to moving this document forward in the publication process.
>>>> 
>>>> Thank you,
>>>> RFC Editor/ap
>>>> 
>>>>> On Sep 28, 2023, at 11:49 AM, Alex Chernyakhovsky <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Hi Alanna,
>>>>> 
>>>>> Assuming the updates David linked above are incorporated, I've completed my review and approve the document in this form.
>>>>> 
>>>>> Sincerely,
>>>>> -Alex
>>>>> 
>>>>> On Thu, Sep 28, 2023 at 2:45 PM David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> Thanks Alanna.
>>>>> 
>>>>> We did resolve the bug, and accumulated a few minor editorial tweaks along the way as well. Could you update your copy to match ours please? Ours is on the left side of this diff:
>>>>> https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&url2=https://www.rfc-editor.org/authors/rfc9484.txt <https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&amp;url2=https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>> 
>>>>> David
>>>>> 
>>>>> On Wed, Sep 27, 2023 at 4:15 PM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> Hi David, Alex, Mirja, and Magnus,
>>>>> 
>>>>> This is a friendly reminder that we await any further changes you may have as well as your reviews and approvals prior to moving this document forward in the publication process.
>>>>> 
>>>>> David - Please let us know if the bug has been fixed so we can incorporate that change into the files.
>>>>> 
>>>>> The files have been posted here (please refresh):
>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-editor.org/authors/rfc9448.pdf>
>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>> 
>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html> (comprehensive diff)
>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all AUTH48 changes)
>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html> (htmlwdiff diff between last version and this)
>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html> (rfcdiff between last version and this)
>>>>> 
>>>>> Please see the AUTH48 status page for this document here:
>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>> 
>>>>> Thank you,
>>>>> RFC Editor/ap
>>>>> 
>>>>>> On Sep 20, 2023, at 12:37 AM, Magnus Westerlund <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> For your information Mirja is on vacation and not back until the 4th of October. It may take until the second week of October until she can respond to the AUTH48. I will perform my review now. 
>>>>>> 
>>>>>> Cheers
>>>>>> 
>>>>>> Magnus
>>>>>> 
>>>>>> From: David Schinazi <[e-mail] <mailto:[e-mail]>>
>>>>>> Date: Tuesday, 19 September 2023 at 22:21
>>>>>> To: Alanna Paloma <[e-mail] <mailto:[e-mail]>>
>>>>>> Cc: Jean Mahoney <[e-mail] <mailto:[e-mail]>>, Tommy Pauly <[e-mail] <mailto:[e-mail]>>, RFC Errata System <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, Mirja Kuehlewind <[e-mail] <mailto:[e-mail]>>, Magnus Westerlund <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, Christopher Wood <[e-mail] <mailto:[e-mail]>>, Martin Duke <[e-mail] <mailto:[e-mail]>>, auth48archive <[e-mail] <mailto:[e-mail]>>
>>>>>> Subject: Re: AUTH48: RFC-to-be 9484 <draft-ietf-masque-connect-ip-13> for your review
>>>>>> 
>>>>>> Thank you Alanna, this is looking great.
>>>>>> 
>>>>>> To keep you in the loop, we found a last minute bug in the spec that we're also going to fix, but we're discussing it on the masque mailing list to ensure everyone agrees.
>>>>>> https://mailarchive.ietf.org/arch/msg/masque/CT7iXultXzjk4IJNkuT7NxtehVY/ <https://mailarchive.ietf.org/arch/msg/masque/CT7iXultXzjk4IJNkuT7NxtehVY/>
>>>>>> I think we'll be able to merge that change in before the end of the week, but I want to make sure folks on the mailing list have a chance to object before we do.
>>>>>> 
>>>>>> Once that's done, we'll request a small change to your version of the document to incorporate that fix.
>>>>>> I've completed my full readthrough so I'll be ready to approve the document for publication once this is resolved.
>>>>>> 
>>>>>> David
>>>>>> 
>>>>>> On Tue, Sep 19, 2023 at 9:32 AM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Hi David,
>>>>>> 
>>>>>> The files have been updated accordingly.
>>>>>> 
>>>>>> The files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-editor.org/authors/rfc9448.pdf>
>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>> 
>>>>>> The relevant diff files are posted here:
>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html> (comprehensive diff)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all AUTH48 changes)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html> (htmlwdiff diff between last version and this)
>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html> (rfcdiff between last version and this)
>>>>>> 
>>>>>> We will await any further changes and approvals from David, Alex, Mirja, and Magnus.
>>>>>> 
>>>>>> Please see the AUTH48 status page for this document here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>> 
>>>>>> Thank you,
>>>>>> RFC Editor/ap
>>>>>> 
>>>>>>> On Sep 18, 2023, at 5:27 PM, David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> I've also made a couple more very minor changes, visible at the same diff link.
>>>>>>> 
>>>>>>> + Jean to comment on the nbsp-vs-space in BCP 14 question
>>>>>>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a165b79afa467e1c&q=1&e=1d2ccd24-f948-40bc-9bad-d30817dc1a83&u=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-rfc%2Fpull%2F204%23issuecomment-1724227942 <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a165b79afa467e1c&amp;q=1&amp;e=1d2ccd24-f948-40bc-9bad-d30817dc1a83&amp;u=https%3A%2F%2Fgithub.com%2Fcabo%2Fkramdown-rfc%2Fpull%2F204%23issuecomment-1724227942>
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> 
>>>>>>> On Mon, Sep 18, 2023 at 11:18 AM David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> Hi Alanna,
>>>>>>> 
>>>>>>> Thank you for the edits. From looking at the diff [1], I think we have two instances of an extra slash at the end of the IANA link.
>>>>>>> 
>>>>>>> OLD: https://www.iana.org/assignments/masque/ <https://www.iana.org/assignments/masque/>
>>>>>>> NEW: https://www.iana.org/assignments/masque <https://www.iana.org/assignments/masque>
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> 
>>>>>>> 
>>>>>>> [1] https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&url2=https://www.rfc-editor.org/authors/rfc9484.txt <https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&amp;url2=https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>> 
>>>>>>> On Mon, Sep 18, 2023 at 10:03 AM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> Hi David,
>>>>>>> 
>>>>>>> Thank you for your reply. We have updated the files per the diff you provided.
>>>>>>> 
>>>>>>> The files have been posted here (please refresh):
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>> https://www.rfc-editor.org/authors/rfc9448.pdf <https://www.rfc-editor.org/authors/rfc9448.pdf>
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>> 
>>>>>>> The relevant diff files are posted here:
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html> (comprehensive diff)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (all AUTH48 changes)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastdiff.html> (htmlwdiff diff between last version and this)
>>>>>>> https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html <https://www.rfc-editor.org/authors/rfc9484-lastrfcdiff.html> (rfcdiff between last version and this)
>>>>>>> 
>>>>>>> Please see the AUTH48 status page for this document here:
>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> RFC Editor/ap
>>>>>>> 
>>>>>>>> On Sep 15, 2023, at 6:52 PM, David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> 
>>>>>>>> Thanks Alanna,
>>>>>>>> 
>>>>>>>> I've gone through the edits and would like to make a few minor changes. Please see them in the following diff:
>>>>>>>> https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&url2=https://www.rfc-editor.org/authors/rfc9484.txt <https://author-tools.ietf.org/iddiff?url1=https://ietf-wg-masque.github.io/draft-ietf-masque-connect-ip/auth48/draft-ietf-masque-connect-ip.txt&amp;url2=https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>> (The author version is on the left and the RFC editor's version is on the right, please switch to the author's version)
>>>>>>>> 
>>>>>>>> You can ignore the diffs in the BCP 14 boilerplate and in the references (/info/ vs /rfc/) - those are tooling issues
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>> 
>>>>>>>> On Fri, Sep 15, 2023 at 1:12 PM Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> Hi Tommy,
>>>>>>>> 
>>>>>>>> Thank you for your quick response. We have noted your approval on the AUTH48 status page:
>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/ap
>>>>>>>> 
>>>>>>>>> On Sep 15, 2023, at 12:53 PM, Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Alanna,
>>>>>>>>> 
>>>>>>>>> Thanks for making those updates! I’ve review the doc and I approve it in this form.
>>>>>>>>> 
>>>>>>>>> Best,
>>>>>>>>> Tommy
>>>>>>>>> 
>>>>>>>>>> On Sep 15, 2023, at 12:34 PM, Alanna Paloma <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Tommy and David,
>>>>>>>>>> 
>>>>>>>>>> Thank you for your replies. We have updated the files accordingly. 
>>>>>>>>>> 
>>>>>>>>>> The files have been posted here (please refresh):
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.pdf <https://www.rfc-editor.org/authors/rfc9484.pdf>
>>>>>>>>>> 
>>>>>>>>>> The relevant diff files have been posted here:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html> (comprehensive diff)
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-auth48diff.html <https://www.rfc-editor.org/authors/rfc9484-auth48diff.html> (AUTH48 changes)
>>>>>>>>>> 
>>>>>>>>>> Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC.
>>>>>>>>>> 
>>>>>>>>>> We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
>>>>>>>>>> 
>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>>>>>> 
>>>>>>>>>> Thank you,
>>>>>>>>>> RFC Editor/ap
>>>>>>>>>> 
>>>>>>>>>>> On Sep 15, 2023, at 9:10 AM, David Schinazi <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Thanks everyone! Really excited to see this in AUTH48.
>>>>>>>>>>> 
>>>>>>>>>>> For some reason I never received the original AUTH48 email (it's not even in my spam folder) but I did receive Tommy's reply. Maybe the [e-mail] <mailto:[e-mail]> alias is broken?
>>>>>>>>>>> 
>>>>>>>>>>> More responses to individual questions inline.
>>>>>>>>>>> 
>>>>>>>>>>> I'll do a full readthrough of the RFC editor edits once these responses have been incorporated.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Sep 14, 2023 at 8:27 PM Tommy Pauly <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>> Hello RFC Editor,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for your work on this! My comments are inline.
>>>>>>>>>>> 
>>>>>>>>>>> Best,
>>>>>>>>>>> Tommy
>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 14, 2023, at 6:19 PM, [e-mail] <mailto:[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Authors,
>>>>>>>>>>>> 
>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) <!-- [rfced] Please review the "type" attribute of each sourcecode element
>>>>>>>>>>>> in the XML file to ensure correctness. If the current list of preferred
>>>>>>>>>>>> values for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt <https://www.rfc-editor.org/materials/sourcecode-types.txt>) 
>>>>>>>>>>>> does not contain an applicable type, then feel free to let us
>>>>>>>>>>>> know. Also, it is acceptable to leave the "type" attribute not
>>>>>>>>>>>> set. 
>>>>>>>>>>>> 
>>>>>>>>>>>> In addition, review each artwork element. Specifically,
>>>>>>>>>>>> should any artwork element be tagged as sourcecode or another
>>>>>>>>>>>> element? 
>>>>>>>>>>>> -->
>>>>>>>>>>> 
>>>>>>>>>>> These types seem correct to me, and I have no issues with these. I’ll let the others chime in as well.
>>>>>>>>>>> 
>>>>>>>>>>> +1, looks good to me
>>>>>>>>>>>> 2) <!--[rfced] Is "Internet Protocol Number" the same as "IP protocol number"? May 
>>>>>>>>>>>> we update as follows to reflect usage throughout the rest of the document?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> IP Protocol: The Internet Protocol Number for traffic that can be
>>>>>>>>>>>> sent to this range, encoded as an unsigned 8-bit integer.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> IP Protocol: The IP protocol number for traffic that can be
>>>>>>>>>>>> sent to this range, encoded as an unsigned 8-bit integer.
>>>>>>>>>>>> --> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Yes, an Internet Protocol Number is the same as an IP protocol number in this usage. I’m happy to see this standardized on “IP protocol number”.
>>>>>>>>>>> 
>>>>>>>>>>> I disagree. "IP Protocol Number" expands to "Internet Protocol Protocol Number" which is silly (cf PIN number and ATM machine). The IANA registry is called "Assigned Internet Protocol Numbers" so I would prefer to standardize on "Internet Protocol Numbers".
>>>>>>>>>>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>
>>>>>>>>>>> 
>>>>>>>>>>>> 3) <!--[rfced] The SVG figures in Sections 8.1, 8.2, 8.3, and 8.4 have
>>>>>>>>>>>> width or height specified, which will make the artwork not scale.
>>>>>>>>>>>> Please consider whether scaling should be enabled. Scaling will allow
>>>>>>>>>>>> the figure to be resized when it is viewed on a mobile device; however,
>>>>>>>>>>>> there may be aesthetic trade-offs (e.g., image may appear too large 
>>>>>>>>>>>> on a desktop screen or different figures may scale differently based
>>>>>>>>>>>> on their relative sizes). Please review the HTML and PDF outputs and
>>>>>>>>>>>> let us know how to proceed.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>> I don’t have any particular opinion on this. I’ll defer to the others.
>>>>>>>>>>> 
>>>>>>>>>>> Similarly, I have no opinion on the details here as long as the output looks reasonable. The width/height are only specified because the tool we used made them this way, it wasn't intentional.
>>>>>>>>>>>> 4) <!-- [rfced] We have included specific questions about the IANA
>>>>>>>>>>>> text below. In addition to responding to these questions, please
>>>>>>>>>>>> review all of the IANA-related updates carefully and let us know
>>>>>>>>>>>> if any further updates are needed.
>>>>>>>>>>>> 
>>>>>>>>>>>> a) We have updated the section titles for consistency. Please review
>>>>>>>>>>>> and let us know if these are agreeable or if you prefer otherwise.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 12.1. HTTP Upgrade Token
>>>>>>>>>>>> 12.2. Creation of the MASQUE URI Suffixes Registry
>>>>>>>>>>>> 12.3 Updates to masque Well-Known URI
>>>>>>>>>>>> 12.4 Capsule Type Registrations
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> 12.1. HTTP Upgrade Token Registration
>>>>>>>>>>>> 12.2. MASQUE URI Suffixes Registry Creation
>>>>>>>>>>>> 12.3 Well-Known URIs Updates
>>>>>>>>>>>> 12.4 HTTP Capsule Types Registrations
>>>>>>>>>>> 
>>>>>>>>>>> I think 12.3 should still describe in the title that it is updating the particular well-known URI registration for “masque”. I would prefer to see that one stay as it was.
>>>>>>>>>>> 
>>>>>>>>>>> The changes for 12.1, 12.2, and 12.4 seem fine.
>>>>>>>>>>> 
>>>>>>>>>>> +1, maybe switch 12.3 to "Updates to masque Well-Known URI Registration" ?
>>>>>>>>>>> 
>>>>>>>>>>>> b) In Section 12.4, Table 2 contains a "Description" column, but the
>>>>>>>>>>>> "HTTP Capsule Types" registry does not (see
>>>>>>>>>>>> <https://www.iana.org/assignments/masque/> <https://www.iana.org/assignments/masque/&gt;>). Should IANA add
>>>>>>>>>>>> this column to their registry?
>>>>>>>>>>> 
>>>>>>>>>>> I don’t think we should add a “description” column. These descriptions are particularly useful. There is a “notes” column that we could fill out, but I think we should just drop the description column.
>>>>>>>>>>> 
>>>>>>>>>>> +1, we should just remove the description column from the document
>>>>>>>>>>> 
>>>>>>>>>>>> c) In Section 12.4, we updated the URL from
>>>>>>>>>>>> "https://www.iana.org/assignments/http-capsule-protocol" <https://www.iana.org/assignments/http-capsule-protocol&quot;> to
>>>>>>>>>>>> "https://www.iana.org/assignments/masque" <https://www.iana.org/assignments/masque&quot;> since the "HTTP Capsule
>>>>>>>>>>>> Types" registry has moved. Please let us know if this is agreeable
>>>>>>>>>>>> or if you prefer otherwise.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original: 
>>>>>>>>>>>> This document requests IANA to add the following values to
>>>>>>>>>>>> the "HTTP Capsule Types" registry maintained at
>>>>>>>>>>>> <https://www.iana.org/assignments/http-capsule-protocol> <https://www.iana.org/assignments/http-capsule-protocol&gt;>.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> IANA has added the following values to the "HTTP Capsule Types"
>>>>>>>>>>>> registry maintained at <https://www.iana.org/assignments/masque> <https://www.iana.org/assignments/masque&gt;>.
>>>>>>>>>>>> -->
>>>>>>>>>>> 
>>>>>>>>>>> That looks fine to me, thanks!
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>>> 5) <!--[rfced] Should RFC 6874 be tagged like the other RFC references for consistency?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
>>>>>>>>>>>> IPv6 Zone Identifiers in Address Literals and Uniform
>>>>>>>>>>>> Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
>>>>>>>>>>>> February 2013, <https://www.rfc-editor.org/rfc/rfc6874> <https://www.rfc-editor.org/rfc/rfc6874&gt;>.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> [ZONE-ID] Carpenter, B., Cheshire, S., and R. Hinden, "Representing
>>>>>>>>>>>> IPv6 Zone Identifiers in Address Literals and Uniform
>>>>>>>>>>>> Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874,
>>>>>>>>>>>> February 2013, <https://www.rfc-editor.org/rfc/rfc6874> <https://www.rfc-editor.org/rfc/rfc6874&gt;>.
>>>>>>>>>>>> --> 
>>>>>>>>>>> 
>>>>>>>>>>> Sure, that’s a good call-out. Perhaps the tag could be [IPV6-ZONES]?
>>>>>>>>>>> 
>>>>>>>>>>> Sounds good. Slight preference for [IPv6-ZONE-ID] for consistency with [IPv6-ADDR]
>>>>>>>>>>>> 6) <!--[rfced] Throughout the text, the following terms appear to be used
>>>>>>>>>>>> inconsistently. Please review.
>>>>>>>>>>>> 
>>>>>>>>>>>> a) May we capitalize these terms throughout for consistency?
>>>>>>>>>>>> 
>>>>>>>>>>>> HTTP Datagram vs. HTTP datagram
>>>>>>>>>>> 
>>>>>>>>>>> Yes, please make “HTTP Datagram” capitalized throughout, to match RFC 9298.
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> IP Address vs. IP address
>>>>>>>>>>>> IP Address Range vs. IP address range
>>>>>>>>>>>> IP Prefix Length vs. IP prefix length
>>>>>>>>>>> 
>>>>>>>>>>> All three of these instances should remain as they are, I believe. When we capitalize “Address”, “Address Range”, and “Prefix Length”, we refer to specific fields in a structure. Otherwise, the phrases are colloquial.
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> Quarter Stream ID vs. quarter stream ID
>>>>>>>>>>> 
>>>>>>>>>>> Please do capitalize the one lowercase instance here.
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> Requested Address vs. requested address
>>>>>>>>>>>> Start IP Address, End IP Address vs. start and end IP address
>>>>>>>>>>> 
>>>>>>>>>>> These should be left as-is, as they either refer to a structure field (capitalized) or a concept (not capitalized).
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> b) We notice 60 instances of "IP proxying" vs. 2 instances of "IP
>>>>>>>>>>>> Proxying" in the running text. May we make these instances 
>>>>>>>>>>>> lowercase for consistency?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> The IP Proxying HTTP Datagram Payload contains the following fields:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> This instance should remain capitalized.
>>>>>>>>>>> 
>>>>>>>>>>> +1, this is the definition of a field whereas the others are colloquial
>>>>>>>>>>> 
>>>>>>>>>>>> If an IP proxying endpoint with a connection containing an
>>>>>>>>>>>> IP Proxying request stream disables congestion control, it 
>>>>>>>>>>>> cannot signal Explicit Congestion Notification (ECN) [ECN] 
>>>>>>>>>>>> support on that outer connection.
>>>>>>>>>>> 
>>>>>>>>>>> This instance can be lowercased.
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 7) <!-- [rfced] FYI: We have added expansions for the following abbreviations
>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>>>>>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>>>>>>> 
>>>>>>>>>>>> Authenticated Encryption with Associated Data (AEAD)
>>>>>>>>>>>> ECN-Echo (ECE)
>>>>>>>>>>>> Encapsulating Security Payload (ESP)
>>>>>>>>>>>> Not ECN-Capable Transport (Not-ECT)
>>>>>>>>>>>> Stream Control Transmission Protocol (SCTP)
>>>>>>>>>>>> -->
>>>>>>>>>>> 
>>>>>>>>>>> These look fine.
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of the online 
>>>>>>>>>>>> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;> 
>>>>>>>>>>>> and let us know if any changes are needed. 
>>>>>>>>>>>> 
>>>>>>>>>>>> Note that our script did not flag any words in particular, but this should still 
>>>>>>>>>>>> be reviewed as a best practice.
>>>>>>>>>>>> --> 
>>>>>>>>>>> 
>>>>>>>>>>> We have checked this, thank you!
>>>>>>>>>>> 
>>>>>>>>>>> +1
>>>>>>>>>>> 
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor/ap/kc
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 14, 2023, at 6:16 PM, [e-mail] <mailto:[e-mail]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>> 
>>>>>>>>>>>> Updated 2023/09/14
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>> --------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>>> 
>>>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and 
>>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC. 
>>>>>>>>>>>> If an author is no longer available, there are several remedies 
>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/ <https://www.rfc-editor.org/faq/>).
>>>>>>>>>>>> 
>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties 
>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing 
>>>>>>>>>>>> your approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> Planning your review 
>>>>>>>>>>>> ---------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>>> 
>>>>>>>>>>>> * RFC Editor questions
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor 
>>>>>>>>>>>> that have been included in the XML file as comments marked as 
>>>>>>>>>>>> follows:
>>>>>>>>>>>> 
>>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>>> 
>>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>>> 
>>>>>>>>>>>> * Changes submitted by coauthors 
>>>>>>>>>>>> 
>>>>>>>>>>>> Please ensure that you review any changes submitted by your 
>>>>>>>>>>>> coauthors. We assume that if you do not speak up that you 
>>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>>> 
>>>>>>>>>>>> * Content 
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the full content of the document, as this cannot 
>>>>>>>>>>>> change once the RFC is published. Please pay particular attention to:
>>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>>> - contact information
>>>>>>>>>>>> - references
>>>>>>>>>>>> 
>>>>>>>>>>>> * Copyright notices and legends
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions 
>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/ <https://trustee.ietf.org/license-info/>).
>>>>>>>>>>>> 
>>>>>>>>>>>> * Semantic markup
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of 
>>>>>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> 
>>>>>>>>>>>> and <artwork> are set correctly. See details at 
>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
>>>>>>>>>>>> 
>>>>>>>>>>>> * Formatted output
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the 
>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is 
>>>>>>>>>>>> reasonable. Please note that the TXT will have formatting 
>>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Submitting changes
>>>>>>>>>>>> ------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
>>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties 
>>>>>>>>>>>> include:
>>>>>>>>>>>> 
>>>>>>>>>>>> * your coauthors
>>>>>>>>>>>> 
>>>>>>>>>>>> * [e-mail] <mailto:[e-mail]> (the RPC team)
>>>>>>>>>>>> 
>>>>>>>>>>>> * other document participants, depending on the stream (e.g., 
>>>>>>>>>>>> IETF Stream participants are your working group chairs, the 
>>>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>>>> 
>>>>>>>>>>>> * [e-mail] <mailto:[e-mail]>, which is a new archival mailing list 
>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion 
>>>>>>>>>>>> list:
>>>>>>>>>>>> 
>>>>>>>>>>>> * More info:
>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
>>>>>>>>>>>> 
>>>>>>>>>>>> * The archive itself:
>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ <https://mailarchive.ietf.org/arch/browse/auth48archive/>
>>>>>>>>>>>> 
>>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out 
>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>>>> If needed, please add a note at the top of the message that you 
>>>>>>>>>>>> have dropped the address. When the discussion is concluded, 
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> will be re-added to the CC list and 
>>>>>>>>>>>> its addition will be noted at the top of the message. 
>>>>>>>>>>>> 
>>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>>> 
>>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>>> — OR —
>>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>>> 
>>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>>> 
>>>>>>>>>>>> OLD:
>>>>>>>>>>>> old text
>>>>>>>>>>>> 
>>>>>>>>>>>> NEW:
>>>>>>>>>>>> new text
>>>>>>>>>>>> 
>>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit 
>>>>>>>>>>>> list of changes, as either form is sufficient.
>>>>>>>>>>>> 
>>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem
>>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, 
>>>>>>>>>>>> and technical changes. Information about stream managers can be found in 
>>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream manager.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Approving for publication
>>>>>>>>>>>> --------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating
>>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’,
>>>>>>>>>>>> as all the parties CCed on this message need to see your approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Files 
>>>>>>>>>>>> -----
>>>>>>>>>>>> 
>>>>>>>>>>>> The files are available here:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.xml <https://www.rfc-editor.org/authors/rfc9484.xml>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.html <https://www.rfc-editor.org/authors/rfc9484.html>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.pdf <https://www.rfc-editor.org/authors/rfc9484.pdf>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484.txt <https://www.rfc-editor.org/authors/rfc9484.txt>
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-diff.html <https://www.rfc-editor.org/authors/rfc9484-diff.html>
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9484-rfcdiff.html> (side by side)
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff of the XML: 
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9484-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9484-xmldiff1.html>
>>>>>>>>>>>> 
>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>> -----------------
>>>>>>>>>>>> 
>>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9484 <https://www.rfc-editor.org/auth48/rfc9484>
>>>>>>>>>>>> 
>>>>>>>>>>>> Please let us know if you have any questions. 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>> 
>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>> RFC9484 (draft-ietf-masque-connect-ip-13)
>>>>>>>>>>>> 
>>>>>>>>>>>> Title : Proxying IP in HTTP
>>>>>>>>>>>> Author(s) : T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky, M. Kühlewind, M. Westerlund
>>>>>>>>>>>> WG Chair(s) : Christopher A. Wood, Eric Kinnear
>>>>>>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 
> 
> 
> 
> 
>