Result Code Redux - One last issue
Gang; 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 As the 'version' string. I am attaching an updated document going with the first suggestion, I prefer the last best of all. Other opinions? Thanks; -jason
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@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
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? 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
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?
OK. I'll do that at the beginning of next week. 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
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
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
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain
Hello all, I wanted to post this earlier but didn't got around to it, Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part: "http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>" and 201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.) preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it. "http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ? Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all. Best regards, Michael On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski <zurawski@internet2.edu> wrote:
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
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain
Hi Michael; If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue. Thanks; -jason ----- Original Message ----- From: Michael Bischoff <Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz <romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue Hello all, I wanted to post this earlier but didn't got around to it, Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part: "http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>" and 201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.) preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it. "http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ? Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all. Best regards, Michael On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski <zurawski@internet2.edu> wrote:
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
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Alright jason, for review: Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg) * kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped. Michael On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff <Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz <romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski <zurawski@internet2.edu> wrote:
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
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
I can not open the doc you attached (opening process can not be completed). Roman W dniu 2011-09-28 13:08, Michael Bischoff pisze:
Alright jason, for review:
Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg)
* kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text
to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped.
Michael
On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski<zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff<Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz<romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Hello Roman, doc seems ok from here (downloaded from webclient, opens in both word 2010 and google docs) perhaps someone else can someone verify? "- I don't think it's a big problem to have a parser which reads a complete status code and then check each part of it (do we expect the use of streaming parser here? )" given how the internet works buffering happens to some extend anyway the impact of requiring the parser to buffer this would be insignificant. "- NMC and NM already use the version number as the last part so the change of it only for status code would be inconsistent. Moving the location of the version number in NMC and NM now would be a huge change and I don't think we need that in the moment." I have mixed feelings about this, on the one part I want progress but the rational and the fact that we are apparently rolling a snowball downhill doesn't jive with me either. Anyway at the very least we need to avoid the use of "/" in the version and reword the section about terminating parsing. Michael On Wed, Sep 28, 2011 at 2:13 PM, Roman Łapacz <romradz@man.poznan.pl> wrote:
I can not open the doc you attached (opening process can not be completed).
Roman
W dniu 2011-09-28 13:08, Michael Bischoff pisze:
Alright jason, for review:
Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg)
* kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text
to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped.
Michael
On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski<zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff<Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz<romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole:
"http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Hi Jason and all, I just want to comment about our implementation in PHP of perfSONAR framework. It is almost done the implementation and I think after our metting that Jason will talk about perfSONAR in 2 weeks we may synchronize and deploy this implementation. I think would be interesting to make public to download this framework in the perfSONAR website so others that would like to have access to it can deploy as well. I think after Jason's presentation, at least one person at RNP is going to follow the OGF meetings so we can follow the protocol definitions. What do you think about it Jason? Do you think it is going to be possible? We already have 3 services implemented with this perfSONAR flavor (MA, CLMP, CACTISonar) and it is going to be possible to make it public too. Hope we could deploy this implementations with perfSONAR community. Thanks all. Murilo Vetter MonIPÊ / RNP
Hi Murilo; Thank you for your email. I do want to note that the NMC group is concerned only with the protocol aspects of a measurement framework - we have to remain implementation independent as much as possible. The work that is being done here is not *only* for 'perfSONAR' services. NMC would be happy to have your (and RNPs) help in working on protocol documentation, as long as it is understood that the final product of this work will be general enough to be used by any potential framework or service, and does not reflect the needs of a specific implementation. It is very good news to hear that you are progressing on your development of a perfSONAR compliant framework, but this group does not make decisions regarding what does or does not get to be downloaded on the perfSONAR web site. You are probably better directing those requests to the perfSONAR development or users mailing lists instead - someone managing those lists will be able to address the issue of releasing a product that is 'perfSONAR' related, instead of NMC related. Hope this helps; -jason On 9/28/11 9:09 AM, thus spake murilo:
Hi Jason and all,
I just want to comment about our implementation in PHP of perfSONAR framework. It is almost done the implementation and I think after our metting that Jason will talk about perfSONAR in 2 weeks we may synchronize and deploy this implementation.
I think would be interesting to make public to download this framework in the perfSONAR website so others that would like to have access to it can deploy as well. I think after Jason's presentation, at least one person at RNP is going to follow the OGF meetings so we can follow the protocol definitions.
What do you think about it Jason? Do you think it is going to be possible?
We already have 3 services implemented with this perfSONAR flavor (MA, CLMP, CACTISonar) and it is going to be possible to make it public too.
Hope we could deploy this implementations with perfSONAR community.
Thanks all.
Murilo Vetter MonIPÊ / RNP
Hi Michael; Thank you for providing the document. I don't agree at all with your proposal, and feel that the original is much better for our needs. I prefer to keep the status codes the same as the namespaces (using the date as a version string at the end) for all the same reasons we have constructed the namespaces in this pattern. You can read this justification in the NM document. Its not for me to judge which is best though, I will send out a doodle vote poll later today so we can pick one, and move on with the document. Regarding your observation that we went with '2.0' for NMWG - this was chosen in 2004 before we had a lot of experience in using namespaces and the complications we had in establishing new versions. In 2007 we realized that appending a date was much easier, particularly when the schema was changing frequently. I would prefer to use dates, and I would prefer they stay at the end of the string to foster extensibility and short/circuit identification of a general concept. -jason On 9/28/11 7:08 AM, thus spake Michael Bischoff:
Alright jason, for review:
Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg)
* kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text
to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped.
Michael
On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski<zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff<Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz<romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
W dniu 2011-09-29 13:44, Jason Zurawski pisze:
Hi Michael;
Thank you for providing the document. I don't agree at all with your proposal, and feel that the original is much better for our needs. I prefer to keep the status codes the same as the namespaces (using the date as a version string at the end) for all the same reasons we have constructed the namespaces in this pattern. You can read this justification in the NM document.
Its not for me to judge which is best though, I will send out a doodle vote poll later today so we can pick one, and move on with the document.
Regarding your observation that we went with '2.0' for NMWG - this was chosen in 2004 before we had a lot of experience in using namespaces and the complications we had in establishing new versions. In 2007 we realized that appending a date was much easier, particularly when the schema was changing frequently. I would prefer to use dates, and I would prefer they stay at the end of the string to foster extensibility and short/circuit identification of a general concept.
I'm fine to use dates but Michael's comments convinced me that a strict rule how such date version is constructed should be documented in the doc (now it says about a string and there are two examples). Again, I would drop optional testing version part (e.g. "/beta"; instead we could have 20110920-beta or 20110920.beta or 20110920beta - to be selected). Cheers, Roman
-jason
On 9/28/11 7:08 AM, thus spake Michael Bischoff:
Alright jason, for review:
Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg)
* kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text
to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped.
Michael
On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski<zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff<Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz<romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/
(or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/
?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
Hi Roman; I removed the sentence from the document proposing '/beta'. Thanks; -jason On 9/29/11 8:19 AM, thus spake Roman Łapacz:
W dniu 2011-09-29 13:44, Jason Zurawski pisze:
Hi Michael;
Thank you for providing the document. I don't agree at all with your proposal, and feel that the original is much better for our needs. I prefer to keep the status codes the same as the namespaces (using the date as a version string at the end) for all the same reasons we have constructed the namespaces in this pattern. You can read this justification in the NM document.
Its not for me to judge which is best though, I will send out a doodle vote poll later today so we can pick one, and move on with the document.
Regarding your observation that we went with '2.0' for NMWG - this was chosen in 2004 before we had a lot of experience in using namespaces and the complications we had in establishing new versions. In 2007 we realized that appending a date was much easier, particularly when the schema was changing frequently. I would prefer to use dates, and I would prefer they stay at the end of the string to foster extensibility and short/circuit identification of a general concept.
I'm fine to use dates but Michael's comments convinced me that a strict rule how such date version is constructed should be documented in the doc (now it says about a string and there are two examples). Again, I would drop optional testing version part (e.g. "/beta"; instead we could have 20110920-beta or 20110920.beta or 20110920beta - to be selected).
Cheers, Roman
-jason
On 9/28/11 7:08 AM, thus spake Michael Bischoff:
Alright jason, for review:
Also updated the examples. (ps it's interesting that we went with 2.0 for nmwg)
* kept the date as version. (didn't feel strongly about changing this also since it is now easy to detect the version we can opt to not redefine unchanged parts in future versions which probably removes any burden that changing it aims to solve) * moved the version to the left. * updated text
to elaborate on the last email: "Client applications should be advised that parsing an error code may result in seeing this ‘unexpected’ last part, and could terminate parsing up to this point to avoid a complete failure." If the version is at the end it also get's dropped.
Michael
On Wed, Sep 28, 2011 at 12:01 PM, Jason Zurawski<zurawski@internet2.edu> wrote:
Hi Michael;
If you feel strongly about this proposal, I will ask you to prepare a formal document so we can review as a group. Please do so by Friday of next week however, as we cannot continue to debate this issue.
Thanks;
-jason
----- Original Message ----- From: Michael Bischoff<Michael.bischoff@controplex.nl> To: zurawski@internet2.edu Cc: Roman Łapacz<romradz@man.poznan.pl>, nmc-wg@ogf.org Sent: Wed, 28 Sep 2011 05:18:08 -0400 (EDT) Subject: Re: [Nmc-wg] Result Code Redux - One last issue
Hello all,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/
(or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/
?
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
W dniu 2011-09-28 11:18, Michael Bischoff pisze:
Hello all,
Hi,
I wanted to post this earlier but didn't got around to it,
Perhaps something to consider: having the version at the end makes it more difficult to change the structure and to support multiply versions in one client/service, especially if you don't force it to be strictly a last single part:
"http://schemas.ogf.org/nmc/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/"<VERSION>"
and
201109/beta -> 201109.beta or 201109-beta (mandate that the version bit will not consist out of '/' I would also recommend standardizing the separation sign for this) (ps don't think we need a day in there unless you want to make multiply updates in a single month - which seems unlikely.)
From a easy-to-parse point of view: We need the version first to establish if we can interpret the status regardless if the status we encounter is known. As such the version is a more significant bit then what is currently left to it, as such I would not put it at the end. Also client programmers might be tempted to ignore the version bit given the version is at the end or least significant spot, esp since we allow them to already ignore certain preceding parts. Ignoring the version will lead to poorly functioning clients. Moving the version to the left doesn't prevent this but does require them to actively ignore it while at the same time doesn't force them to do more work to ignore it.
"http://schemas.ogf.org/nmc/status/"<VERSION>"/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ (or do we tie things to a version of nmc as a whole: "http://schemas.ogf.org/nmc/"<VERSION>"/status/"<STATUS_CATEGORY>"/"<STATUS_NAME>"/ ?
I see your point but - I don't think it's a big problem to have a parser which reads a complete status code and then check each part of it (do we expect the use of streaming parser here? ) - NMC and NM already use the version number as the last part so the change of it only for status code would be inconsistent. Moving the location of the version number in NMC and NM now would be a huge change and I don't think we need that in the moment.
Also dates are good and bad - for example with dates you can't declare forwards compatibility - 1.0 1.1, 1.2 - structure stayed the same all messages in 1.0 are available in 1.1 1.2. So if you encounter a known status and only the last part has changed it's safe to interpret. 1.0 -> 2.0 semantics and or structure has changed. Then again - forcing clients to update might not be a bad thing at all.
This is reasonable. Dates are inconsistent with that what we already have in NM and NMC (2.0). So maybe 2.1 would be fine (as an update of 2.0)? I would also agree to drop the idea of additional part for a testing version. Cheers, Roman
Best regards,
Michael
On Wed, Sep 28, 2011 at 10:20 AM, Jason Zurawski<zurawski@internet2.edu> wrote:
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
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
participants (5)
-
Freek Dijkstra -
Jason Zurawski -
Michael Bischoff -
murilo -
Roman Łapacz