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

[Jason Zurawski]

Hi Roman;

Thanks for doing this, I will try to send an updated version by the end 
of the week, and include this in the formal document.  Thanks;

-jason

On 9/27/11 12:32 PM, thus spake Roman Łapacz:
> W dniu 2011-09-23 14:22, Jason Zurawski pisze:
>> Hi Roman;
>>
>> I think this is a good idea, would you be able to make the changes to
>> the document and sent it back to the list?
>
> Attached (needs polishing).
>
> Cheers,
> Roman
>
>>
>> Thanks;
>>
>> -jason
>>
>> On 9/23/11 12:29 PM, thus spake 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