Re: [Asap] I-D Action: draft-ietf-asap-sip-auto-peer-09.txt

Hi Nicola,
Thank you for your suggestions, I agree that references to RFC 7231 is incorrect. Our intention was to specify and enforce the usage of HTTPS or HTTP over TLS. We will make the required modifications in an upcoming version of the draft that will be published shortly.

Thanks,
Kaustubh
> On 27-Nov-2023, at 11:55 AM, Nicola Serafini <n.serafini=40tutanota.com@dmarc.ietf.org> wrote:
> 
> Hi everybody, first of all,  many thanks for your work.
> 
> While reading the draft, I may noticed some typos regarding the HTTP protocol, all of those typos I identified use HTTPS instead of HTTP; a week ago I emailed Authors and I have not received any response so far.
> 
> An example of typo that I also referenced in my previous email is Section "2.1. Reference Architecture":
> 2.1.  Reference Architecture
> 
>    Figure 1 illustrates a reference architecture that may be deployed to
>    support the mechanism described in this document.  The enterprise
>    network consists of a SIP-PBX, media endpoints (M.E.) and a Session
>    Border Controller [RFC7092].  It may also include additional
>    components such as application servers for voicemail, recording, fax
>    etc.  At a high level, the service provider consists of a SIP
>    signaling entity (SP-SSE), a media entity for handling media streams
>    of calls setup by the SP-SSE and a HTTPS [RFC7231] server.
> 
> As you can see here, I think "HTTPS [RFC7231]" is typo for three main reasons:
> 
>     1 - RFC7231 defines HTTP protocol.
>     2 - RFC7231 was obsoleted by RFC9110 (https://www.rfc-editor.org/rfc/rfc9110 <https://www.rfc-editor.org/rfc/rfc9110>).
>     3 - RFC9110 also obsoletes RFC2818 (https://www.rfc-editor.org/rfc/rfc2818 <https://www.rfc-editor.org/rfc/rfc2818>).
> 
> Another example is:
>    Taking the above considerations into account, this document proposes
>    a Hypertext Transfer Protocol (HTTP)-based workflow using which the
>    enterprise network can solicit and ultimately obtain the service
>    provider capability set.  The enterprise network creates a well
>    formed HTTPS GET request to solicit the service provider capability
>    set.  Subsequently, the HTTPS response from the SIP service provider
>    includes the capability set.  The capability set is encoded in JSON,
>    thus ensuring that the response can be easily parsed by automation.
> 
> Where I believe you mean: "[...] The enterprise network creates a well formed HTTP GET request [...]".
> 
> Finally, I agree with you that you may want to suggest the use of HTTP over TLS for this architecture.
> 
> Am I wrong with this concerns/suggestions?
> 
> 
> Regards,
> 
> --
> Nicola
> -- 
> Asap mailing list
> Asap@ietf.org
> https://www.ietf.org/mailman/listinfo/asap