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

[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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20110923-NMCResultCodes-RL.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 36003 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nmc-wg/attachments/20110927/41db0511/attachment-0001.bin