Having looked at ATOM, there are many required elements that do not apply to me
I don't thin it's as many as you might think (1 or 2?), but even if it is, I will say to you what I say to everyone trying to invent something new: reuse is good! People have a tendency to say "well, this existing tech has something required that I don't need/want, so I'll invent a whole new thing." Wrong! Reusing the existing vocabulary (and, in the case of XML, namespace) means that existing parsers can make some sense of your content without needing to know you exist. It also means that devs familiar with that vocabulary understand more of your content more easily. In fact, if everyone uses almost the same vocabulary for the same kind of data everywhere, this works out even better.
You may prefer <guid> to <id> or "creator" to author or activity-actor, or url to link, but honestly where does inventing a new vocabulary get you?
The biggest thing here, also, is re-syndication. If you hand me a bunch of ATOM-based blobs, I can send them on to someone else as a feed or over PuSH trivially, and then they can process as much of the data as they understand, which thanks to the common vocabulary may be quite a lot of it.
My biggest current problem with OAuth is in how I want to handle user accounts. An authentication scheme that revolves around attaining user permission is something I want to avoid as an attempt at being mostly white-label.
Marketing tends to fail a lot. It confuses too many people. This may be what OAuth is often used for but it is not what OAuth is. OAuth is a generic protocol for signing arbitrary HTTP requests using any signing method that uses two pieces of data for signing (or, realistically, one, and leave the other as a blank string). So, you issue your clients two tokens (I prefer two for durability. If you need, for security reasons, to upgrade your signing method in the future, more of them need 2 than can work with 1) and they use them as the access token/secret. If you look at the spec, though, you'll see that what you call the two tokens is mostly a library thing. Really, in all cases, you just order the parameters a certain way, include other important information (like the verb) and the sign with the chosen signing mechanism. I would suggest HMAC-SHA1 for now, as it's still basically secure (SHA1 attacks aren't practical yet) and it is very well supported (both by languages, and by the libraries that exist for basically all your favourite languages, including C liboauth). Nonces are actually optional, though recommended.
OAuth is both not hard to implement (I've done it twice) and you don't need to implement it because there are libraries already.
I'm leaning toward restricting to English-centric ASCII in the old school manner, largely because every bit of documentation I've ever found on anything unicode leaves me more confused than ever.
What are you reading that makes it complicated. I implemented UTF-8 in a CS course. If the idiots in CS courses can be expected to do it, it can't be that hard. Perhaps you are reading something evil?
Do not count out all of everyone who is not English. Seriously. Half the time you won't even need to parse the stuff, just store it and pass it through blindly. If you make limits in bytes instead of chars, this solves your counting problem.
UTF-8 is the only charset anyone should be using for anything (except internal representation, which is handled for you in scripting languages usually). Benefit is you can pretend it's ASCII in the english case, and if you treat it like ASCII you'll be fine unless you're truncating or length-measuring.
I meant to imply that the KVPs were created with the meta site. It's part of award creation, and all award creation is (currently) done on the site.
Oh… that's a bit odd. Why not just let me POST the award I want when awarding it and then store that? Works magically better for everything except threshold.
attaining user permission is something I want to avoid as an attempt at being mostly white-label. From your comments, I need to either explain my goals regarding user accounts better or re-think it completely.
Hmm, I see. We do have two slightly different goals here, but I don't think said goals have to be incompatible. You want a white-label "I will store your awards for you" API, and I want an awards syndication/sharing/republication system. I basically assume that my app can handle awards existing by itself (especially in the offline case), but I want a way to share/publish the awards.
This is part of why I want awards to be POSTable instead of pre-created. That way an app can hook up to anything supporting this API and just go.
Basically, though, the API ends up looking the same. If an app wants white-label, they sign up for a white-label keypair and use that to auth. If they want to publish for their user, they get tokens for that user's account and publish with that auth. You don't have to support both in your implementation, but I'd like both to be supported in the spec (at least conceptually).
Speaking of spec and interop, at some point we should talk discovery. Unless you don't care about the non-white-label case at all, in which case i can fork your spec later and add discovery for my use case
