Subject: Re: [Uri-review] Requesting approval for URI schemes net.msmq, net.tcp, net.pipe

From: Piyush Joshi <[email-masked]>
Date: Tue, 22 Mar 2011 22:27:45 +0000

Thank you for your questions/suggestions - 
Please find the refreshed version below: 

Context and justification of the schemes - 
Windows Communication Foundation (WCF) [1] is part of .Net Framework and it provides a unified communications framework to create service-oriented applications which can communicate over various transport protocols. WCF also provides a set of pre-defined configurations (packaged in 'bindings') which are used for communication over specific transport protocols namely HTTP, TCP, Windows Named Pipe, MSMQ. 
WCF defines a transport agnostic framing protocol (.Net Message Framing Protocol [2]) supported over TCP (.Net Message Framing TCP Binding Protocol [3]), Named Pipe and MSMQ ( .Net Message Framing MSMQ Binding Protocol [4]). The schemes applied for registration are used for communication using .Net Message Framing Protocol over TCP (net.tcp scheme), Named Pipe (net.pipe) and MSMQ (net.msmq)
These URI schemes have been used by WCF from the very first version of the product and we intend to continue to use them therefore we do believe that there is a clear utility in registering these schemes to serve as global namespaces . 
 
Syntax - 
Section 3 of RFC 3986[5] defines the general URI syntax. 
The specific constraints on this generic syntax for the requested URI schemes are specified below - 
	1. net.tcp_URI  = "net.tcp:" "//" host  [":" port] [abs-path] 
		o If the port is not specified then the default port MUST be considered to be 808. 
	2. net.pipe_URI  = "net.pipe:" "//" host  [abs-path] 
	3. net.msmq_URI  = "net.msmq:" "//" host  [abs-path] 
 
host, port, abs-path are as defined in Uniform Resource Identifier (URI): Generic Syntax [6]
 
Semantics
	1. net.tcp
	· The net.tcp scheme is used by .Net Message Framing Protocol [2] for framing messages over TCP protocol while communicating with a listener identified by a URI qualified with net.tcp scheme.
	· The semantics are that the listener is located at the server listening for TCP connections on that port of that host, and is identified by abs_path. 
	· Details on .Net Message Framing TCP Binding protocol which specifies how .Net Message Framing Protocol is used over TCP protocol can be found here - .Net Message Framing TCP Binding Protocol Specification [3]. 
	 
	2. net.pipe
	· The net.pipe scheme is used by .Net Message Framing Protocol [2] for framing messages over Windows Named Pipes while communicating with a listener identified by a URI qualified with net.pipe scheme.
	· The semantics are that the listener is located at the server listening for Windows Named Pipe connection of that host, and is identified by abs_path. 
	 
	3. net.msmq
	· The net.msmq scheme is used by .Net Message Framing Protocol [2] for framing messages over MSMQ protocol while communicating with an MSMQ queue identified by a URI qualified with net.msmq scheme.
	· The semantics are that the MSMQ queue is located at the server which is listening for MSMQ connections on that host, and the address of the queue is abs_path. 
	· Details on .Net Message Framing MSMQ Binding protocol which specifies how .Net Message Framing Protocol is used over MSMQ protocol can be found here - .Net Message Framing MSMQ Binding Protocol Specification [4]. 
 
Characters 
The definition of the schemes does not define any special rules for characters including "reserved characters" outside of what is already defined in Section 2 of RFC 3986 [7]
 
Encoding
The definition of the schemes does not mandate any particular character encoding for mapping between URI characters and the octets used to store or transmit those characters. When a URI defined by these schemes appear in a protocol element, the character encoding is defined by that protocol. 
An Internationalized Domain Name MAY be used in the URI for host in which case it MUST be transformed to the Internationalized Domain Name in Applications (IDNA) encoding [RFC 5891]. 
 
Security consideration 
The definition of the schemes does not specify any special security considerations outside of what are already defined in Section 7 of RFC 3986 describing the general security  considerations for URI schemes.

[1] - http://msdn.microsoft.com/en-us/netframework/aa663324.aspx
[2] - http://msdn.microsoft.com/en-us/library/cc219293(PROT.10).aspx
[3] - http://msdn.microsoft.com/en-us/library/ff470920(PROT.10).aspx
[4] - http://msdn.microsoft.com/en-us/library/ff469340(PROT.10).aspx
[5] - http://tools.ietf.org/html/rfc3986#section-3
[6] - http://tools.ietf.org/html/rfc3986
[7] - http://tools.ietf.org/html/rfc3986#section-2
[8] - http://tools.ietf.org/html/rfc3986#section-7

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 3:09 PM
To: Piyush Joshi
Cc: Mykyta Yevstifeyev; [email-masked]; Kirill Gavrylyuk
Subject: Re: [Uri-review] Requesting approval for URI schemes net.msmq, net.tcp, net.pipe

On 17.01.2011 23:58, Piyush Joshi wrote:
> Thanks Mykyta, Julian for your comments!
> Do you have any example you could point me to which will help me in providing the syntax/definition which will be useful for this review?

Have a look at a recently published scheme, such as <http://www.rfc-editor.org/rfc/rfc6068.txt>.

> Julian - I didn't quite understand what is meant by this question. Could you please elaborate?
>>> Is that URI stable?
>
> Thank you.

Will the the spec still be served from the URI in five years from now? 
URIs assigned by some CMS (or something similar to that) always make be a bit skeptical...

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 23 Mar 2011 07:45:06 +0200

> 		o If the port is not specified then the default port MUST be considered to be 808.
One notice - this port is not officially registered by IANA.  This 
should be considered in the Internet-Draft registering the schemes - it 
should also register this port.
> 	3. net.msmq_URI  = "net.msmq:" "//" host  [abs-path]
Another notice: it's better to use the <path-abempty> RFC 3986 rule 
here, that assumes that path may be empty.

Mykyta
> Have a look at a recently published scheme, such as<http://www.rfc-editor.org/rfc/rfc6068.txt>.
>