As promised Slawek and I have prepared a doc describing new result codes. Comments and updates are welcome. Cheers, Roman
This looks good in general. Some comments: 1. Instead of having "clienterror" and "servererror" as top-level 'things': error/client error/server 2. badrequest seems almost a catch-all. (e.g. eventtypenotallowed is a form of badrequest, etc). If it's for a more specific error, it'd probably be good to define that error. In general, it'd probably be good to detail when some of these errors get used (e.g. use badrequest unless one of the more specific errors is applicable). 3. It might make sense to make it a bit more hierarchical (though this may be overkill), e.g.: http://perfsonar.net/status/error/client/badrequest/eventtypenotallowed/ This would make it easier for clients to understand new error types. e.g. http://perfsonar.net/status/error/client/unauthorized/invalidauthenticationt... The client wouldn't need to understand anything below "unauthorized", to display a "authorization denied" error, but it could provide more information if it understood. 4. I'm not a big fan of the result codes as having some text in the url makes it notedly more readable (not that users would read the event types, but for developers). Cheers, Aaron On Mar 3, 2010, at 9:06 AM, Roman Lapacz wrote:
As promised Slawek and I have prepared a doc describing new result codes. Comments and updates are welcome.
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Hi Aaron, Aaron Brown wrote:
This looks good in general.
Some comments:
1. Instead of having "clienterror" and "servererror" as top-level 'things':
error/client error/server
The question is how much we want to follow HTTP status codes standard. The initial proposal tries to be very close to it. On the other hand more hierarchical approach may be more handy for us.
2. badrequest seems almost a catch-all. (e.g. eventtypenotallowed is a form of badrequest, etc). If it's for a more specific error, it'd probably be good to define that error. In general, it'd probably be good to detail when some of these errors get used (e.g. use badrequest unless one of the more specific errors is applicable).
'badrequest' derives directly from existing HTTP status codes. I have included them but I'm not sure we need them. In the proposal pS result codes start from x30 (x31, x32, x33, ...).
3. It might make sense to make it a bit more hierarchical (though this may be overkill), e.g.:
http://perfsonar.net/status/error/client/badrequest/eventtypenotallowed/
hmm, we could say that all (or most of) client errors could be under 'badrequest' :)
This would make it easier for clients to understand new error types. e.g.
http://perfsonar.net/status/error/client/unauthorized/invalidauthenticationt...
The client wouldn't need to understand anything below "unauthorized", to display a "authorization denied" error, but it could provide more information if it understood.
agree
4. I'm not a big fan of the result codes as having some text in the url makes it notedly more readable (not that users would read the event types, but for developers).
Right and that is why I included result code numbers as possible alternative. Cheers, Roman
Cheers, Aaron
On Mar 3, 2010, at 9:06 AM, Roman Lapacz wrote:
As promised Slawek and I have prepared a doc describing new result codes. Comments and updates are welcome.
Cheers, Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org mailto:Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Hey All; I am attaching my comments in the document (may be easier to track this way). Some other thoughts inline: On 3/14/10 8:33 PM, Roman Lapacz wrote:
Hi Aaron,
Aaron Brown wrote:
This looks good in general.
Some comments:
1. Instead of having "clienterror" and "servererror" as top-level 'things':
error/client error/server
The question is how much we want to follow HTTP status codes standard. The initial proposal tries to be very close to it. On the other hand more hierarchical approach may be more handy for us.
We need to balance expressiveness vs complexity I think. I don't have a strong opinion, but if we make things too verbose there becomes a question on how developers will use (or expand) what is available. if there is an error/client subdivision we may fall into the trap we had before (error/client/ls, error/client/ma).
2. badrequest seems almost a catch-all. (e.g. eventtypenotallowed is a form of badrequest, etc). If it's for a more specific error, it'd probably be good to define that error. In general, it'd probably be good to detail when some of these errors get used (e.g. use badrequest unless one of the more specific errors is applicable).
'badrequest' derives directly from existing HTTP status codes. I have included them but I'm not sure we need them. In the proposal pS result codes start from x30 (x31, x32, x33, ...).
Yes, lets try to think of the specific errors - I want to avoid making a general available because laziness will always win (e.g. a new service may just encode everything as a 'bad request' instead of specific errors that may or may not exist).
3. It might make sense to make it a bit more hierarchical (though this may be overkill), e.g.:
http://perfsonar.net/status/error/client/badrequest/eventtypenotallowed/
hmm, we could say that all (or most of) client errors could be under 'badrequest' :)
This would make it easier for clients to understand new error types. e.g.
http://perfsonar.net/status/error/client/unauthorized/invalidauthenticationt...
The client wouldn't need to understand anything below "unauthorized", to display a "authorization denied" error, but it could provide more information if it understood.
agree
See previous two responses, but aaron makes a good point on 'on demand parsing'.
4. I'm not a big fan of the result codes as having some text in the url makes it notedly more readable (not that users would read the event types, but for developers).
Right and that is why I included result code numbers as possible alternative.
I would say its immaterial - but a public conversion system is a good idea too (or use of the 'datum'/'parameters' to convey more than just a number). Thanks; -jason
Cheers, Roman
Cheers, Aaron
On Mar 3, 2010, at 9:06 AM, Roman Lapacz wrote:
As promised Slawek and I have prepared a doc describing new result codes. Comments and updates are welcome.
Cheers, Roman
All; I have uploaded the updated proposal to the notes for this call: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/2010041...
Hi,
any thoughts on this? Does the update follow what has been discussed in Munich?
Roman
On Mon, 29 Mar 2010, romradz wrote:
Hi,
Updated proposal attached.
Roman
_______________________________________________ Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
-- Jason Zurawski, Network Software Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-6648] Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
On 4/14/10 3:14 PM, Jason Zurawski wrote:
All;
I have uploaded the updated proposal to the notes for this call:
https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/2010041...
Please read the proposal ASAP, and be ready to discuss any additional items that must be outlined in this document. The next step will be brining this to the larger perfSONAR audience, and including it in the nmc-base document. Thanks; -jason
Hi,
any thoughts on this? Does the update follow what has been discussed in Munich?
Roman
On Mon, 29 Mar 2010, romradz wrote:
Hi,
Updated proposal attached.
Roman
This looks good to me, and adequately represents what I saw as the general consensus in the Room in Munich. It would be especially important for those that were not in Munich to read/respond with their opinions. And, I'm going to call out client developers in particular. We need your feedback. thanks, jeff On Apr 14, 2010, at 1:15 PM, Jason Zurawski wrote:
On 4/14/10 3:14 PM, Jason Zurawski wrote:
All;
I have uploaded the updated proposal to the notes for this call:
https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/2010041...
Please read the proposal ASAP, and be ready to discuss any additional items that must be outlined in this document. The next step will be brining this to the larger perfSONAR audience, and including it in the nmc-base document.
Thanks;
-jason
Hi,
any thoughts on this? Does the update follow what has been discussed in Munich?
Roman
On Mon, 29 Mar 2010, romradz wrote:
Hi,
Updated proposal attached.
Roman
Nmc-wg mailing list Nmc-wg@ogf.org http://www.ogf.org/mailman/listinfo/nmc-wg
All; On the call today we discussed the issue of result codes. There were 2 decissions: - The 2nd proposal for message structure (using namespaced datum elements) as proposed by Jeff/Martin in Munich is the way to go. - We need to see a mapping of the proposed result codes to what is currently used in pS-MDM and pS-PS services. Roman and Slawek will start this for the MDM releases, Aaron will help with the PS. Once we determine what is in use, we may prune down the list to items we need and anticipate needing in the near future. Service/Client developers - your feedback is still needed but it may be prudent to wait until the next document version. Thanks; -jason On 4/14/10 3:20 PM, Jeff W. Boote wrote:
This looks good to me, and adequately represents what I saw as the general consensus in the Room in Munich.
It would be especially important for those that were not in Munich to read/respond with their opinions. And, I'm going to call out client developers in particular. We need your feedback.
thanks, jeff
On Apr 14, 2010, at 1:15 PM, Jason Zurawski wrote:
On 4/14/10 3:14 PM, Jason Zurawski wrote:
All;
I have uploaded the updated proposal to the notes for this call:
https://forge.gridforum.org/sf/wiki/do/viewPage/projects.nmc-wg/wiki/2010041...
Please read the proposal ASAP, and be ready to discuss any additional items that must be outlined in this document. The next step will be brining this to the larger perfSONAR audience, and including it in the nmc-base document.
Thanks;
-jason
Hi,
any thoughts on this? Does the update follow what has been discussed in Munich?
Roman
On Mon, 29 Mar 2010, romradz wrote:
Hi,
Updated proposal attached.
Roman
participants (6)
-
Aaron Brown -
Jason Zurawski -
Jeff W.Boote -
Roman Lapacz -
romradz
-
romradz＠man.poznan.pl