[Nmc-wg] [ogf nmc-base svn commit] r14 - /

[svn at ogf.org]

Author: imonga
Date: 2010-02-23 16:31:15 -0600 (Tue, 23 Feb 2010)
New Revision: 14

Modified:
   chaining.tex
   messages.tex
Log:

Chaining.tex: Made changes to bold SHOULD, MUST text in section 5.1

Messages.tex: various nits changed including added text after "message is rejected outright"



Modified: chaining.tex
===================================================================
--- chaining.tex	2010-02-23 22:02:19 UTC (rev 13)
+++ chaining.tex	2010-02-23 22:31:15 UTC (rev 14)
@@ -10,18 +10,18 @@
 \subsection{Merge Chaining}
 \label{s:information_chaining_merge}
 
-As the name implies, we intend to \textit{merge} or combine metadata elements through this structure. There are many things we \textbf{MAY} consider when describing this operation:
+As the name implies, we intend to \textit{merge} or combine metadata elements through this structure. There are many things we may consider when describing this operation:
 
 \begin{itemize}
 \item Which elements are \textit{mergeable}?
 \item How much \textit{recursion} is needed for merge-able elements?
-\item When \textbf{SHOULD} we \textit{duplicate} elements?
-\item When \textbf{SHOULD} we \textit{replace} elements in the course of merging?
+\item When should we \textit{duplicate} elements?
+\item When should we \textit{replace} elements in the course of merging?
 \end{itemize}
 
-As stated previously, the schemata itself does not offer any suggestions as to what is a \textit{good merge} vs. a \textit{bad merge}. There are no rules regarding which \textit{types} of data \textbf{SHOULD} and \textbf{SHOULD NOT} be merged. There is no guidance on when we \textbf{SHOULD} duplicate or replace elements.
+As stated previously, the schemata itself does not offer any suggestions as to what is a \textit{good merge} vs. a \textit{bad merge}. There are no rules regarding which \textit{types} of data should and should not be merged. There is no guidance on when we should duplicate or replace elements.
 
-We \textbf{RECOMMEND} some very simple and succinct guidelines that services may implement for this particular style of merging. There \textbf{SHALL} always be exceptions to rules, therefore the reader is encouraged to think carefully about what a specific service \textbf{MAY} need when implementing this recommendation.
+We recommend some very simple and succinct guidelines that services may implement for this particular style of merging. There shall always be exceptions to rules, therefore the reader is encouraged to think carefully about what a specific service may need when implementing this recommendation.
 
 \subsubsection{Mergeable Elements and Recursion}
 \label{s:information_chaining_merge_elements}

Modified: messages.tex
===================================================================
--- messages.tex	2010-02-23 22:02:19 UTC (rev 13)
+++ messages.tex	2010-02-23 22:31:15 UTC (rev 14)
@@ -11,13 +11,13 @@
 %
 % The original thinking was the NM-WG document, "An Extensible Schema for
 % Network Measurement and Performance Data", would contain the entire
-% explanation of namespaces (the idea itself coming from another OGF WG). 
+% explanation of namespaces (the idea itself coming from another OGF WG). 
 %
 % Any future documents from related projects (NMC, NML, others?) would reference
-% this and only note caveats to the original rule.  The NM-WG doc is here:
-%
-% https://forge.gridforum.org/sf/go/doc15649?nav=1
-%
+% this and only note caveats to the original rule.  The NM-WG doc is here:
+%
+% https://forge.gridforum.org/sf/go/doc15649?nav=1
+%
 % Namespaces are in section 4.  Regardless, we need to discuss this and provide
 % the reference somewhere before we discuss the message structure.  
 
@@ -67,8 +67,8 @@
 
 \begin{itemize}
 \item \textbf{Syntax} - Does the request parse correctly?  Incorrect syntax will trigger \textit{error routines}.
-\item \textbf{Message Type} - Can this service accept and act on this kind of message?  An unexpected message \textbf{MUST} be rejected outright.
-\item \textbf{Structure} - Is there at least a single metadata and data pair that is capable of being acted on?  A service that cannot determine if there is actionable content in the request will \textit{reject} the message with an \textit{error routine}.
+\item \textbf{Message Type} - Can this service accept and act on this kind of message?  An unexpected message \textbf{MUST} be rejected outright by discarding it and responding with a corresponding error message. 
+\item \textbf{Structure} - Is there at least a single metadata and data pair that is capable of being acted on?  A service that cannot determine if there is actionable content in the request will \textit{discard} the message with an \textit{error routine}.
 \item \textbf{Semantics} - Does the request make sense according to the schematic rules; can the metadata be acted upon; are the chains resolved properly?  Handling of semantic rules are the discretion of the service: \textit{error routines} are possible or perhaps some form of \textit{panic parsing} may result in partial completion of a request.  
 \end{itemize}
 
@@ -269,8 +269,17 @@
 \item \textbf{Parameter} - Described in Section~\ref{s:request_message_analysis_parameter}
 \end{itemize}
 
-Note that the use of this element (in this particular location) is \textbf{OPTIONAL}.  Services are not required to understand this element and in some cases \textbf{MAY} view inclusion as an error.  Please consult service documentation before proceeding.
 
+% XXX imonga - 02/23/2010
+% 
+% Comment: I am making the change the line below to the following
+% "Services are not required to understand this element and SHOULD ignore this 
+%  element if not expected by the service"
+% 
+%  
+
+Note that the use of this element (in this particular location) is \textbf{OPTIONAL}.  Services are not required to understand this element and \textbf{SHOULD} ignore this element if not expected by the service.  Please consult service documentation before proceeding.
+
 \paragraph{Parameter}
 \label{s:request_message_analysis_parameter}
 
@@ -400,7 +409,7 @@
 \paragraph{Key}
 \label{s:request_message_analysis_key}
 
-example of status response in 4.1 does not explain too much (looks the 
+example of status response in 4.1 does not explain too much (looks the 
 > same as earlier response example)
 
 % XXX jz - 1/13/2010
@@ -444,7 +453,7 @@
 
 The key element is rooted in the concept of a \textit{hash function} --- a function or process designed to convert a variable amount of information into a single value or \textit{index}.  Once converted this single value can then be used a shorthanded notation to reference the original entity, imparting a performance increase for computational tasks.  
 
-The key structure \textbf{SHALL} used to convey sensitive or private information to and from the service. For this reason the contents of the key \textbf{SHOULD} be viewed as ``opaque'', and \textbf{MUST NOT} be dissected. The key \textbf{SHOULD} contain a \textit{Parameters} (see Section~\ref{s:request_message_analysis_parameters}) element. There is only one attributes possible: \textit{id}. This \textbf{MAY} used to track state. A detailed description follows:
+The key structure \textbf{SHALL} used to convey sensitive or private information to and from the service. For this reason the contents of the key \textbf{SHOULD} be viewed as ``opaque'', and \textbf{MUST NOT} be dissected. The key \textbf{SHOULD} contain a \textit{Parameters} (see Section~\ref{s:request_message_analysis_parameters}) element. There is only one attribute possible: \textit{id}. This \textbf{MAY} used to track state. A detailed description follows:
 
 \begin{itemize}
 \item \textbf{id} - Identifying attribute that \textbf{MAY} be used to track state.