Subject: [art] RFC2817, IPP, and XCAP

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Jan 2022 17:24:42 +1100

Happy New Year, ART folks.

I'm looking into whether we can move RFC2817 to Historic, because for HTTP's purposes, the bits we actually use have moved into the Semantics document.

However, I notice that RFC8010 still specifies the Upgrade mechanism for 'ipp' URLs. Can anyone from the IPP community speak as to whether that's actually in use?

There's a similar question regarding RFC4825 and XCAP.

If the damage caused by moving it to Historic would be too great, I might try to spin up a short applicability note that explained which bits moved into semantics, and that what's left is only usable if a protocol using HTTP explicitly opts into it (like IPP).

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eliot Lear <[email-masked]>
Date: Mon, 3 Jan 2022 07:40:06 +0100

I can't speak for the IPP community, but it's still in many printers 
across the major players (HP, Canon, Xerox, Ricoh).

Eliot

On 03.01.22 07:24, Mark Nottingham wrote:
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Jan 2022 19:15:00 +1100

Yes, thanks know that. I’m asking specifically about this feature. 

Sent from my iPhone

> On 3 Jan 2022, at 5:40 pm, Eliot Lear <[email-masked]> wrote:
> 
> I can't speak for the IPP community, but it's still in many printers across the major players (HP, Canon, Xerox, Ricoh).
> 
> Eliot
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Jan 2022 11:27:32 +0000

Hi Mark,

[email-masked] might be the right place to ask about the continued use of
Upgrade in IPP.

regards,

Ted

On Mon, Jan 3, 2022 at 6:25 AM Mark Nottingham <[email-masked]> wrote:

> I'm looking into whether we can move RFC2817 to Historic, because for
> HTTP's purposes, the bits we actually use have moved into the Semantics
> document.
>
> However, I notice that RFC8010 still specifies the Upgrade mechanism for
> 'ipp' URLs. Can anyone from the IPP community speak as to whether that's
> actually in use?
>
> If the damage caused by moving it to Historic would be too great, I might
> try to spin up a short applicability note that explained which bits moved
> into semantics, and that what's left is only usable if a protocol using
> HTTP explicitly opts into it (like IPP).
>
> Cheers,
>
>
> --

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Jan 2022 13:12:39 +0000

Hi,

3GPP does reference 2817, so I have a couple of questions:

Q1: Are there any TECHNICAL differences between the upgrade mechanism in 2817 and 7230/draft-ietf-httpbis-semantics? I.e., could one simply do a reference update and still be backward compatible with 2817?

Q2: RFC 2817 adds the "TLS" value to the IANA upgrade token registry. How would that be impacted? Would the value also become "Historic"? Or, will draft-ietf-httpbis-semantics re-define the value, and update the IANA registry reference?

Regards,

Christer

-----Original Message-----
From: art <[email-masked]> On Behalf Of Mark Nottingham
Sent: maanantai 3. tammikuuta 2022 8.25
To: [email-masked]
Subject: [art] RFC2817, IPP, and XCAP

Cheers,

--
Mark Nottingham   https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=200ef84e-c213-48da-a489-d8c459acaeb9&u=https%3A%2F%2Fwww.mnot.net%2F

_______________________________________________
art mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6d2584570e589803&q=1&e=200ef84e-c213-48da-a489-d8c459acaeb9&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart

---

From: Ira McDonald <[email-masked]>
Date: Mon, 3 Jan 2022 14:35:20 -0500

Hi Mark,

Speaking for the IPP community. Yes RFC 2817 upgrade for "ipp" URLs is
still mandatory
to support in all conforming IPP implementations and is commonly used
(after doing an
unauthenticated Get-Printer-Attributes operation for printer discovery and
before doing a
secure print operation such as Create-Job/Send-Document or Print-Job).

IPP is now supported in over 98% of all network printers shipped in the
last decade and
has essentially completely replaced proprietary printing protocols.

For information about the PWG program for self-certification of IPP
Everywhere driver-less
printers, see:

https://pwg.org/ipp/everywhere.html

Cheers,
- Ira McDonald (co-chair of IEEE-ISTO PWG IPP WG, successor to IETF IPP WG)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Jan 2022 11:55:23 +1100

Thanks, Ira, that's helpful.

It'd be good to somehow clarify that the upgrade mechanisms in sections 3 and 4 aren't widely implemented by generic implementations of HTTP, but only used when explicitly called for by a HTTP-based protocol (like IPP).  BCP56bis would have been a good vehicle for that, but it's pretty far into the RFC Editor queue, and I suspect that we'd need to do a bit of security analysis before folks would be comfortable recommending the upgrade mechanism for use by new HTTP-based protocols even in a limited way. 

So I'm not sure what to do (a new document seems a bit excessive). Perhaps we should hold onto this until the *next* time we revise HTTP or BCP56.

Cheers,

> On 4 Jan 2022, at 6:35 am, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mark,
> 
> Speaking for the IPP community. Yes RFC 2817 upgrade for "ipp" URLs is still mandatory
> to support in all conforming IPP implementations and is commonly used (after doing an
> unauthenticated Get-Printer-Attributes operation for printer discovery and before doing a 
> IPP is now supported in over 98% of all network printers shipped in the last decade and
> For information about the PWG program for self-certification of IPP Everywhere driver-less 
> printers, see:
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Jan 2022 12:31:32 +1100

> On 4 Jan 2022, at 12:12 am, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> Hi,
> 

I believe that's the case. The difference is that 7230 (and the upcoming revision) specify the mechanisms (the Upgrade header, 426, etc.), but not how to compose them to achieve a desired effect; that's left to the reader. 2817 walks the reader through each one. From a technical / normative standpoint, 7230 is sufficient.

> Q2: RFC 2817 adds the "TLS" value to the IANA upgrade token registry. How would that be impacted? Would the value also become "Historic"? Or, will draft-ietf-httpbis-semantics re-define the value,…

Good question. I think whatever happens would need to leave that value alone -- unless we went to the trouble of doing a security review and it determined that the technique isn't safe to use any more. 

At this point, it's become pretty clear that we can't just move 2817 to historic.

Cheers,

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jan 2022 12:53:15 +0000

Hi,

Assuming 2817 is not moved to Historic, another question came up.

Assume I have the following text somewhere: "MUST support RFC 2817 and the updates in RFC 7230".

2817 is updated by 7230 and 7231. However, both of those RFCs are made obsolete by draft-ietf-httpbis-semantics.

But, as the updates have not been formally "moved" to draft-ietf-httpbis-semantics, I cannot replace the reference to 7230 with draft-ietf-httpbis-semantics in the text above. draft-ietf-httpbis-semantics does not even mention 2817.

So, should draft-ietf-httpbis-semantics formally update RFC 2817?

(I realize this specific question might belong to the HTTPbis list, but there might be some generic guidelines in cases like this. Also, my apologies if this has already been discussed and resolved.)

Regards,

Christer

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: keskiviikko 5. tammikuuta 2022 3.32
To: Christer Holmberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [art] RFC2817, IPP, and XCAP

Cheers,

> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6d2584570e589803&q=1&e=613b70ae-1115-4ed6-9de7-da0c861b48d0&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart

--
Mark Nottingham   https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=613b70ae-1115-4ed6-9de7-da0c861b48d0&u=https%3A%2F%2Fwww.mnot.net%2F

---

From: Ira McDonald <[email-masked]>
Date: Wed, 5 Jan 2022 14:10:05 -0500

Hi Mark,

I'm a bit confused about IETF process, I think.

IPP/1.1 (RFC 8010/8011 / IETF STD92) normatively references RFC 2817.  If
RFC 2817 is
moved to Historic, is that somehow *not* a problem because of RFC 7230 and
further
successors (even if the details of Upgrade are no longer specified)?

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Wed, Jan 5, 2022 at 7:53 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> 2817 is updated by 7230 and 7231. However, both of those RFCs are made
> obsolete by draft-ietf-httpbis-semantics.
>
> But, as the updates have not been formally "moved" to
> draft-ietf-httpbis-semantics, I cannot replace the reference to 7230 with
> draft-ietf-httpbis-semantics in the text above.
> draft-ietf-httpbis-semantics does not even mention 2817.
>
> (I realize this specific question might belong to the HTTPbis list, but
> there might be some generic guidelines in cases like this. Also, my
> apologies if this has already been discussed and resolved.)
>
> Regards,
>
> Christer
>
>
>
>
> > Q1: Are there any TECHNICAL differences between the upgrade mechanism in
> 2817 and 7230/draft-ietf-httpbis-semantics? I.e., could one simply do a
> reference update and still be backward compatible with 2817?
>
> I believe that's the case. The difference is that 7230 (and the upcoming
> revision) specify the mechanisms (the Upgrade header, 426, etc.), but not
> how to compose them to achieve a desired effect; that's left to the reader.
> 2817 walks the reader through each one. From a technical / normative
> standpoint, 7230 is sufficient.
>
> > Q2: RFC 2817 adds the "TLS" value to the IANA upgrade token registry.
> How would that be impacted? Would the value also become "Historic"? Or,
> will draft-ietf-httpbis-semantics re-define the value, and update the IANA
> registry reference?
>
> Good question. I think whatever happens would need to leave that value
> alone -- unless we went to the trouble of doing a security review and it
> determined that the technique isn't safe to use any more.
>
> > If the damage caused by moving it to Historic would be too great, I
> might try to spin up a short applicability note that explained which bits
> moved into semantics, and that what's left is only usable if a protocol
> using HTTP explicitly opts into it (like IPP).
> >
> > Cheers,
> >
> >
> > --
> > Mark Nottingham
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=200ef84e-c213-48da-a489-d8c459acaeb9&u=https%3A%2F%2Fwww.mnot.net%2F
> >
> Mark Nottingham
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=613b70ae-1115-4ed6-9de7-da0c861b48d0&u=https%3A%2F%2Fwww.mnot.net%2F
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Jan 2022 15:18:58 -0500

Ira,

For whatever it is worth, you are not the only one who is
confused.  At one time, the general understanding was that, if a
document was either "obsoleted" or moved to Historic (if want to
get more confused, try figuring out the difference), then any
normative references to it had been dealt with.  Dealing with
them might involve updating all of the documents that referred
to the Obsolete and/or Historic one or it might involve creating
a "tombstone" document that explained what had happened with the
older document's index and metadata showing that it had been
"Obsoleted by" the newer one. 

The existence of RFC 7230 would have solved the problem if it
contained a section that explicitly indicated what parts of 2817
it was changing, what was being changed, and how that might
affect documents referencing 2817.   But, had it done that, the
references from RFC 8010/8011 should have been to both 2817 and
7230, not 2817 alone.

There has been some, IMO unfortunate, sloppiness with that sort
of record-keeping within the RFC Series in recent years but I
assume some version of cleanups and documentation were part of
what Mark had in mind when he indicated that simply moving 2817
was not going to work (I don't remember his exact words).

best,
   john

--On Wednesday, January 5, 2022 14:10 -0500 Ira McDonald
<[email-masked]> wrote:

> IPP/1.1 (RFC 8010/8011 / IETF STD92) normatively references
> RFC 2817.  If RFC 2817 is
> moved to Historic, is that somehow *not* a problem because of
> RFC 7230 and further
> *Chair - Linux Foundation Open Printing WGSecretary -
> IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG
> Internet Printing Protocol WGIETF Designated Expert - IPP &
> Printer MIBBlue Roof Music / High North
> <http://sites.google.com/site/highnorthinc>mailto:
> [email-masked] <[email-masked]>(permanent)
> PO Box 221  Grand Marais, MI 49839 906-494-2434*
> 
> 
> On Wed, Jan 5, 2022 at 7:53 AM Christer Holmberg
> <christer.holmberg= [email-masked]> wrote:
> 
>> Hi,
>> 
>> 2817 is updated by 7230 and 7231. However, both of those RFCs
>> are made obsolete by draft-ietf-httpbis-semantics.
>> 
>> draft-ietf-httpbis-semantics, I cannot replace the reference
>> to 7230 with draft-ietf-httpbis-semantics in the text above.
>> (I realize this specific question might belong to the HTTPbis
>> list, but there might be some generic guidelines in cases
>> like this. Also, my apologies if this has already been
>> discussed and resolved.)
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> > On 4 Jan 2022, at 12:12 am, Christer Holmberg
>> > <christer.holmberg=
>> 2817 and 7230/draft-ietf-httpbis-semantics? I.e., could one
>> simply do a reference update and still be backward compatible
>> with 2817?
>> 
>> I believe that's the case. The difference is that 7230 (and
>> the upcoming revision) specify the mechanisms (the Upgrade
>> header, 426, etc.), but not how to compose them to achieve a
>> desired effect; that's left to the reader. 2817 walks the
>> reader through each one. From a technical / normative
>> How would that be impacted? Would the value also become
>> "Historic"? Or, will draft-ietf-httpbis-semantics re-define
>> the value, and update the IANA registry reference?
>> 
>> Good question. I think whatever happens would need to leave
>> that value alone -- unless we went to the trouble of doing a
>> security review and it determined that the technique isn't
>> safe to use any more.
>> 
>> > From: art <[email-masked]> On Behalf Of Mark
>> > Nottingham Sent: maanantai 3. tammikuuta 2022 8.25
>> > To: [email-masked]
>> HTTP's purposes, the bits we actually use have moved into the
>> Semantics document.
>> > 
>> 'ipp' URLs. Can anyone from the IPP community speak as to
>> whether that's actually in use?
>> > 
>> might try to spin up a short applicability note that
>> explained which bits moved into semantics, and that what's
>> left is only usable if a protocol using HTTP explicitly opts
>> into it (like IPP).
>> > 
>> > Cheers,
>> > 
>> > 
>> > --
>> > Mark Nottingham
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-31327
>> 3af-454445555731-2328097a3e27f5ac&q=1&e=200ef84e-c213-48da-a4
>> 89-d8c459acaeb9&u=https%3A%2F%2Fwww.mnot.net%2F
>> > 
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-31327
>> 3af-454445555731-6d2584570e589803&q=1&e=200ef84e-c213-48da-a4
>> 89-d8c459acaeb9&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flist
>> info%2Fart
>> > 
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-31327
>> 3af-454445555731-6d2584570e589803&q=1&e=613b70ae-1115-4ed6-9d
>> e7-da0c861b48d0&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flist
>> info%2Fart
>> 
>> --
>> Mark Nottingham
>> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-31327
>> 3af-454445555731-2328097a3e27f5ac&q=1&e=613b70ae-1115-4ed6-9d
>> e7-da0c861b48d0&u=https%3A%2F%2Fwww.mnot.net%2F
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Jan 2022 21:43:15 +0000

Hi Mark,

> I believe that's the case. The difference is that 7230 (and the upcoming revision) specify the mechanisms (the Upgrade header, 426, etc.), but not how to compose them to achieve a desired effect; that's left to the reader. 
> 2817 walks the reader through each one. From a technical / normative standpoint, 7230 is sufficient.

Just to clarify, what exactly is 7230 updating in 2817?

Based on my reading, the only thing updated is the procedure for the Upgrade token registry. Is that all?

Regards,

Christer

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Jan 2022 10:14:34 +1100

7230 and 7231 take over:

* The definition of CONNECT
* The Upgrade Token Registry
* The HTTP Status Code Registry
* The 426 Upgrade Required status code

The Upgrade header is also in 7231, but it was previously defined by 2616, not 2817.

Once those are taken into account, I think the only thing that 2817 really does is explain how to compose Upgrade and 426 to achieve certain results (in sections 3 and 4). I.e., that text isn't the source of definition of any protocol elements or normative requirements on them (at least now). 

AFAICT, all of the requirements in 2817 that apply to servers or clients are either restating requirements from elsewhere (mostly, HTTP), MAYs, or discretionary (e.g., "If an unsecured response would be unacceptable, a client MUST send an OPTIONS request first to complete the switch to TLS/1.0 (if possible).")

Regardless of what happens to 2817, I'm not sure what requiring support for 2817 really means -- which of the various mechanisms, for what roles in the protocol? Does this take discretion away from the roles (e.g., can a server just refuse client-requested mandatory upgrade)?

draft-ietf-httpbis-semantics doesn't touch anything in 2817 that wasn't already updated by 7230 or 7231, so as things currently sit, I don't think it needs to update it. 

Cheers,

> On 5 Jan 2022, at 11:53 pm, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> Hi,
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Jan 2022 10:15:37 +1100

Hi Ira,

As I said before, based upon the discussion so far I don't think we can just move 2817 to Historic, because XCAP and IPP reference it normatively.

Cheers,

> On 6 Jan 2022, at 6:10 am, Ira McDonald <[email-masked]> wrote:
> 
> Hi Mark,
> 
> IPP/1.1 (RFC 8010/8011 / IETF STD92) normatively references RFC 2817.  If RFC 2817 is 
> moved to Historic, is that somehow *not* a problem because of RFC 7230 and further 
> Ira McDonald (Musician / Software Architect)
> Chair - SAE Trust Anchors and Authentication TF
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: [email-masked]
> (permanent) PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> On Wed, Jan 5, 2022 at 7:53 AM Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Jan 2022 00:19:55 +0000

Hi,

>* The definition of CONNECT

For this part, I think it would have been good to explicitly say that the definition in 7230 is identical to the one in 2817. It would have made it easier for people to determine what (if any) the impacts of updating from 2817 to 7230/7231 would have been.

>The Upgrade header is also in 7231, but it was previously defined by 2616, not 2817.

Correct. My mistake.

(2817 also references 2616, which has been obsoleted by 723x, but I don't know if anything can be done about that.)

>draft-ietf-httpbis-semantics doesn't touch anything in 2817 that wasn't already updated by 7230 or 7231, so as things currently sit, I don't think it needs to update it. 

The updates to 2817 that were previously in 7230/7231 are now in draft-ietf-httpbis-semantics. Wouldn't it be good to indicate what those updates are? Otherwise people will have to read the obsoleted 7230/7231 to figure it out...

Regards,

Christer

> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-6d2584570e589803&q=1&e=1226fece-6338-43c7-9804-682d25df397d&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fart

--
Mark Nottingham   https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-2328097a3e27f5ac&q=1&e=1226fece-6338-43c7-9804-682d25df397d&u=https%3A%2F%2Fwww.mnot.net%2F

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Jan 2022 11:27:07 +1100

> On 6 Jan 2022, at 11:19 am, Christer Holmberg <[email-masked]> wrote:
> 

semantics is approved and in AUTH48, so the changes that we can make at this stage are *extremely* limited, unfortunately. 

It's also not clear that this is the right way to do that -- semantics doesn't actually change anything regarding the relationship to 2817, so it's hard to justify an 'updates' entry.  I suspect that the right thing to do is to create a new document that obsoletes 2817, in the process removing the parts that have been overtaken by other specs, and giving the remaining portions the appropriate reviews (including for security). 

BTW, I'm not volunteering to do that by writing this message :)

Cheers,

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2022 14:59:09 -0500

--On Thursday, January 6, 2022 11:27 +1100 Mark Nottingham
<[email-masked]> wrote:

>> The updates to 2817 that were previously in 7230/7231 are now
>> in draft-ietf-httpbis-semantics. Wouldn't it be good to
>> indicate what those updates are? Otherwise people will have
>> to read the obsoleted 7230/7231 to figure it out...
> 
> semantics is approved and in AUTH48, so the changes that we
> can make at this stage are *extremely* limited, unfortunately. 

See below.

> It's also not clear that this is the right way to do that --
> semantics doesn't actually change anything regarding the
> relationship to 2817, so it's hard to justify an 'updates'
> entry.  I suspect that the right thing to do is to create a
> new document that obsoletes 2817, in the process removing the
> parts that have been overtaken by other specs, and giving the
> remaining portions the appropriate reviews (including for
> security). 
> 

Mark,

Coming back to those "*extremely* limited" options.

I am not recommending this and won't initiate it but, since
questions have been raised about procedures, anyone who felt
strongly about it could presumably create an appeal an appeal to
the RFC Editor and IESG against the decision to move the
document into AUTH48.  Such an appeal would  point out the
controversy, uncertainty, and this conversation.  It would then
request that publication be frozen until these issues could be
resolved, possibly by creating the document to which you refer
and inserting a normative reference to it in semantics.

If I were writing it, I would also point out the inherent
difficulties in comprehensively reviewing a 252 page document
during a normal two week Last Call, that the procedures were
never designed with such documents in mind, and that such a
review is inherently unfair to anyone with significant interest
in the consequences of publication who was not sufficiently
involved in other specific issues to justify involvement in the
HTTPBIS WG.

For the benefit of those not familiar with the IETF process, the
procedure for doing that would be to write an email note
addressed to the responsible AD at [email-masked] and copying
[email-masked], using a subject line like "Appeal
against further processing and publication of
draft-ietf-httpbis-semantics" and including an explanation,
presumably making some of the points above.  Given the timing,
if that did not produce a fairly immediate response from
Francesca or Murray asking the RFC Editor to put the document on
hold, a follow up note with the same content addressed to
[email-masked], copying [email-masked] and probably this list
should be sent.

Again, I am not going to do that and am not recommending the
action to anyone else.  But, procedurally, that action would be
a way to freeze publication until these issues are sorted out
(as, of course, would Francesca, Murray, or the WG co-chairs
requesting a pause on their own initiative).  The appeals
procedures are designed for just such situations.

best,
  john

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Jan 2022 20:12:18 +0000

Hi,
 
> It's also not clear that this is the right way to do that -- semantics doesn't actually change anything regarding the relationship to 2817, so it's hard to justify an 'updates' entry.  

Ok. I don't want to delay the publication - especially since I haven't even been involved in the work.

I just think that, even if semantics does not formally updates 2817, it would have been useful with some informative text about the differences between 2817 and semantics (regarding the things that were defined in 2817). There was such text in 7230/7231. Because, I think the wish is to get people to move from 2817 to semantics, and having text which describes the differences is extremely useful. For example, if you want to update a reference in 3GPP, you need to explain what the changes (if any) are, because people need to know whether there will be backward compatibility issues or not.

> I suspect that the right thing to do is to create a new document that obsoletes 2817, in the process removing the parts that have been overtaken by other specs, and giving the remaining portions the appropriate reviews (including for security). 
>

Neither do I :)

Also, I don't think it would make very much sense. I assume any NEW implementation of 2817 will be those who implement IPP and XCAP. And, at least XCAP does not reference 7230/7231, so from an XCAP perspective it should not matter  if they become obsolete.

Also, I noted that 2817 also references 2616, which has already previously been obsoleted, so anyone implementing/referencing 2817 will anyway have to deal with references that have been obsoleted.

Regards,

Christer