<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi, gang.&nbsp; At the October meetings we left one spec issue unresolved,
because it seemed subtle and complex enough to deserve some off-line
thought and discussion by email.&nbsp; That issue was the notation we use
for delivery point names.<br>
<br>
The spec currently says that a delivery point name is the concatenation
of a transport service name, an equals ('=') sign, and an endpoint name
in transport-service-specific format.&nbsp; Currently the syntax of the
transport service name for TCP is the intuitively obvious "tcp", and
endpoint names are in the similarly obvious format <i>hostname</i>:<i>portnumber</i>;
likewise for UDP.&nbsp; But for VxWorks message queues the spec says the
transport service name is "vxmq<i>hostnumber</i>", with <i>msgqID </i>as
the endpoint name.&nbsp; The idea under discussion, as I recall, was to
simplify the protocol by using the general structure <i>protocolname</i>:<i>qualifier</i>:<i>qualifier</i>:...:<i>qualifier
</i>for all delivery point names, e.g. "tcp:amroc.jpl.nasa.gov:5453"
and "vxmq:2113451256:11311876".<br>
<br>
I've given this some thought and have concluded that, while I agree
that the proposed notation's generality is appealing, this is one of
those rare cases where the more intuitively elegant approach is
disadvantageous in implementation.<br>
<br>
The intent of the current design is to simplify the processing of
delivery vectors in MAMS messages: a receiving MAMS entity can always
know whether or not a given delivery point is one that it can use for
message transmission to the sending entity, simply by looking for the
'=' character and then comparing the preceding character string to the
names of the transport services to which it has access.<br>
<br>
The proposed design is, paradoxically, more complex.&nbsp; In the case of
"tcp:amroc.jpl.nasa.gov:5453" the receiving entity would know that the
delivery point is usable if "tcp" -- the token preceding the first
colon -- is one of its transport services.&nbsp; But in the case of
"vxmq:2113451256:11311876" the delivery point would be usable only if
"vxmq:2113451256" -- the string preceding the *second* colon -- was one
of its transport services, because message-queue transport is possible
only between tasks residing on the same machine.&nbsp; Tasks residing on
different computers running VxWorks cannot exchange messages among
themselves via message queue; "vxmq" alone would not be enough to
assure connectivity.<br>
<br>
In order to make the proposed syntax work, we would have to build
transport-service-specific rules into the code that processes delivery
vectors in inbound MAMS messages, indicating how much of the delivery
point name constitutes the transport service name.&nbsp; To avoid adding any
more complexity to an already complex specification, I think we should
stick with the current notation.&nbsp; Does anyone have strong feelings
otherwise?<br>
<br>
Scott<br>
</body>
</html>