RE: Mohamed Boucadair's Discuss on draft-ietf-httpbis-safe-method-w-body-13: (with DISCUSS and COMMENT)

Hi Mark, 

Thanks for the clarification.

Updated my ballot accordingly.

Cheers,
Med

> -----Message d'origine-----
> De : Mark Nottingham <mnot=40mnot.net@dmarc.ietf.org>
> Envoyé : lundi 17 novembre 2025 09:53
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : The IESG <iesg@ietf.org>; draft-ietf-httpbis-safe-method-w-
> body@ietf.org; httpbis-chairs@ietf.org; ietf-http-wg@w3.org
> Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-httpbis-
> safe-method-w-body-13: (with DISCUSS and COMMENT)
> 
> 
> Hi Mohamed,
> 
> Thanks for the review. Just one note below...
> 
> > On 17 Nov 2025, at 6:57 pm, Mohamed Boucadair via Datatracker
> <noreply@ietf.org> wrote:
> [...]
> > # Unlike 9110 which uses a clear language about the expected
> error
> > codes, the specification is ambiguous (for some aspects) for a
> PS
> > document. The document uses “can” in many places while I think a
> > better clarity is needed. For example,
> >
> > CURRENT:
> >   *  If a media type is specified, but is inconsistent with the
> actual
> >      request content, a 400 (Bad Request) can be returned.  That
> is, a
> >                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      server is not allowed to infer a media type from the
> request
> >      content and then override a missing or "erroneous" value
> ("content
> >      sniffing").
> >
> >   *  If the media type is specified, is understood, and the
> content is
> >      indeed consistent with the type, but the query cannot be
> processed
> >      due to the actual contents of the query, the status 422
> >      (Unprocessable Content) can be used.  An example would be a
> >      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >      syntactically correct SQL query that identifies a non-
> existent
> >      table.
> >
> > Or
> >
> >   A server can assign a URI to the equivalent resource (Section
> 2.2) of
> >            ^^^^^^^^^^^^
> >   a QUERY request.  If the server does so, the URI of that
> resource can
> >
> ^^^
> >   be included in the Location header field of the 2xx response
> (see
> >   ^^
> >   Section 10.2.2 of [HTTP]).
> >
> > Any reason why a less ambiguous language (e.g., normative
> language) is
> > not used here (and other similar parts of the spec)?
> 
> This is considered good practice in HTTP specifications, because
> there are a variety of conditions that can cause a non-200 status
> code. We don't want to normatively require a particular behaviour
> in isolation because doing so doesn't take into account the
> complete state of the request (or the server, or the network...),
> and it would create the impression that clients can depend on a
> certain status code appearing in a particular circumstance, which
> is not the case in deployment.
> 
> Cheers,
> 
> 
> --
> Mark Nottingham

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Monday, 17 November 2025 09:27:22 UTC