[Nmc-wg] Result Code Redux - One last issue

[Roman Łapacz]

W dniu 2011-09-23 11:32, Jason Zurawski pisze:
> Gang;

Hi,

>
> In typing up the final version of the status codes into the document, 
> I hit upon a snag.  Here is an example of what was proposed in the 
> prior mail:
>
>   http://schemas.ogf.org/nmc/2011/09/status/informational/protocol 
> version/
>
> This goes against our typical method of constructing namespaces.  I 
> would suggest we do this instead:
>
>   http://schemas.ogf.org/nmc/status/informational/protocol 
> version/2011/09/
>
> Or even better using:
>
>   201109
>
> or
>
>   20110923

Right. Good you spotted this. I prefer to have just one field for 
version number (201109 or 20110923)  with an exception for early testing 
versions (201109/beta or 20110923/beta).

>
> As the 'version' string.  I am attaching an updated document going 
> with the first suggestion, I prefer the last best of all.  Other 
> opinions?

What do you think to replace the code hierarchy with the pattern in the 
beginning of section 2. Example:

--example---------------------

   
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>

<STATUS_CATEGORY> may have the following text values:
   - informational
   - successful
   - redirection
   - clienterror
   - servererror

<STATUS_NAME> depends on the status category and may have the following 
text values:
   - informational category
     -- protocol version
     -- data limitation
     -- service_contact
   - client error category
     -- bad_message
     -- bad request
     -- authentication_failed
     -- unauthorized
     -- message not allowed
     -- event_type_not_allowed
     -- event_type_not_allowed
     -- request_too_large
     -- request_timeout
     -- protocol_not_allowed
     -- chaining_not_understood
   - servererror category
     -- data_fetch_error
     -- too_busy
     -- administrative_down
   Two categories, successful and redirection,  do not need to have 
certain status names.

VERSION is a string presenting information about the version of 
protocol, e.g. 201109 or 20110925. In case of early testing version an 
optional part after "/" may be added (e.g. 201109/beta or 20110925/beta) .

-- end---------------------

I'm thinking about such update because version numbers don't look good 
in the structure. They are not generic. The use of pattern solves this 
issue. What do you think? (of  course a short description below the 
pattern in my example may be done much better; I just wanted to present 
my idea).

Cheers,
Roman

>
> Thanks;
>
> -jason
>
>
> _______________________________________________
> Nmc-wg mailing list
> Nmc-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nmc-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nmc-wg/attachments/20110923/e187e0f8/attachment.html