Please use something like [MiddlewareControl](https://github.com/microsoftgraph/msgraph-sdk-javascript/blob/dev/src/middleware/MiddlewareControl.ts instead of using _middlewareOptions. Please move addMiddlewareOptions and getMiddlewareOptions options to the MiddlewareControl.

• A separate class for managing the properties as an object allows extensibility. A user can extend the MiddlewareControl class and flexibly customize their get and add middleware options or any property of the requestinfo class.
• We can observe Single Responsibility Principle if we neatly segregate some functionalities into specific classes.
• Avoids bulking up the RequestInfo class with too many methods.

Yeah I was looking at the dotnet sdk which uses options but have uses control too. I'm not sure why we have a difference between languages today. @darrelmiller any guidance on options or control?
https://www.github.com/microsoftgraph/msgraph-sdk-dotnet-core/tree/dev/src%2FMicrosoft.Graph.Core%2FRequests%2FMiddleware%2FOptions%2FIMiddlewareOption.cs

We're attaching the options to request info to avoid passing multiple parameters between the layers. Request info is already being passed between layers. And the options or controls are related to the request info, which is why it felt natural to add them there. I'm not sure how you'd do it differently without having to pass additional parameters to the http core service?

Both JS and .NET use the term Options. It looks like JS has a container for for middlewareOptions. .NET just uses a dictionary. I'm not sure why JS has the extra layer of indirection. Part of the confusion might be because the original requirement document talked about middleware controls. That notion got renamed to middleware options during implementation.

Thanks for the context here. So I'm guessing we're sticking with options then.

What is the likelihood of this namespace being used in the same context as System.Net.Http.HttpClient? If they show up in the same context, the naming collision can be confusing for the customers. Could we rename the last part or drop it altogether to bump the namespace one level up to Microsoft.Kiota.Http?

@baywet, I think @nikithauc is referring to this.

aaah we had a long naming debate with @darrelmiller a long time ago.
I wanted to name this Microsoft.Kiota.Transport.Http leaving room for other transport implementations potentially in the future. Thoughts on that name? And for typescript we'd have something like @microsoft/kiota-transport-http.

What are transport implementations?

well one of them is HTTP of course, another one could be gRPC, etc...

I think another common thing between HTTP and gRPC is that they are both protocols. So we can also have Microsoft.Kiota.Protocol.Http or Microsoft.Kiota.Protocols.Http as the namespace alternatives. I am OK with Microsoft.Kiota.Transport.Http too.

I don't think transport is correct here. Protocol is more accurate. For example, if we introduced WebSockets, we'd have:
Microsoft.Kiota.Protocol.Http
Microsoft.Kiota.Protocol.WebSocket

They use the same transport.

Microsoft.Kiota.Protocol.Http
Microsoft.Kiota.Protocol.WebSocket

The namespace looks meaningful.

Hypertext Transfer Protocol (HTTP) is an application-layer protocol for transmitting hypermedia documents, such as HTML. It was designed for communication between web browsers and web servers, but it can also be used for other purposes.

https://developer.mozilla.org/en-US/docs/Web/HTTP

yep, protocol works for me as well. As this is a discussion on existing naming pattern, and as I'd like Darrel's "blessing" before changing the naming, I'm going to create a separate issue for that. Thanks for all the great suggestions!

#444