Draft wording for resolution of subchannel MPC discussion, April 22 action item done.

ebXML MPC identifiers can be used to implement a wide variety of channel
filtering regimes. MPCs are URIs. Because certain URI schemes support
"hierarchy" by using the "/" character to separate path segments (such
as the "HTTP" scheme), paths may be used to group related channels into
channels and subchannels. Although each URI remains a distinct MPC,
local conventions may use channels and subchannels to simulate channel
filtering of either hierarchical topics (where subchannels are topic
specializations) or to simulate fixed, content-based filters. [Query
parameters, if supplied, have semantics defined by implementations, and
not by this specification. The semantics of paths in simulating topics
or content-based filters is not defined by this specification, but would
need to be defined by implementations or bilateral participant
agreements. -- optional]



[I think I mentioned on the call that either HTTP URLs or URNs could be
used to simulate MPC subchannels. But I glanced back at
http://www.ietf.org/rfc/rfc3986.txt  (Uniform Resource Identifier (URI):
Generic Syntax ) and realized that "/" is normally given the role of
indicating hierarchy in a path. And though URNs look like a structured
identifier with hierarchy, I cannot find anywhere that indicates that
the ":" in a URN actually indicate path segments. 

The following are two example URIs and their component parts:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose

And,

A path consists of a sequence of path segments separated by a slash
   ("/") character.  A path is always defined for a URI, though the
   defined path may be empty (zero length).  Use of the slash character
   to indicate hierarchy is only required when a URI will be used as the
   context for relative references. 

I am assuming that URNs can in principle,then, have paths that use a ":"
to indicate hierarchy because URNs will not be used as a context for
relative references. But the semantics of the path following the
urn:nid:xxxxx.yyyy.zzzz is up to the namespace registrar, it seems.
Anyway you can consult http://tools.ietf.org/rfc/rfc3406.txt on URN best
practices to follow the story. 

It therefore seems to me that we should just omit discussing URNs for
MPC identification because it just gets to have a lot of complexity and
administrative overhead (useful idea dies by overly intricate
specification...) So I omitted URNs from discussion in the draft above.]