15 Matching Annotations
  1. Dec 2015
    1. site

      not part of AS2. What does that mean anyway, from a semantic point of view?

    2. links

      no such thing in AS2

    3. links

      no such thing in AS2

    4. tags
    5. articleId

      again, there is no articleId in the AS2 spec. Is this a test of how to deal with non-conforming documents?

    6. site

      There is no actor type or object type "site" in AS2. Test documents should only test things in the spec. Nothing else.

    1. Some people want things to be RESTish..

      Why is this an issue? For me that makes perfect sense and the referenced specifications are also "RESTish" from my perspective. The question is, what is the "appropriate endpoint". In a RESTful world the endpoint would be different depending on the type of content, e.g. an activity would be POSTed to the activity endpoint and a microblog post to the messages endpoint. This makes sense from my perspective.

    2. Webmention

      If there is a standard exactly for that problem: +1 for using it

    3. ActivityPump

      +1 on the ActivityPump solution

    4. SHOULD

      why is that only a SHOULD? I would say: MUST for content types available in the Activity Streams vocabulary and if they are not sufficient, people can use the extension mechanism defined in the AS2 vocabulary document.

    5. attributes of the subject

      Should be specify a minimum set of required attributes (e.g. like ActivityPump) or leave it completely to the implementations to think of some meaningful attributes?

      I'm a fan of specifying attribute names and meanings in order to foster interoperability, but make most optional, so that implementations do not have to deal with them, but if dealing with them, then doing it in a well defined way instead something implementation specific

    1. stored directly on the file system instead of using a database

      I consider that an implementation detail that is irrelevant for a specification, since the client is only talking to the server using http, it makes no difference, whether the server stores the data on the file system or in a database.

    2. implemented using only application logic, with no need to change code on the server

      I find that part misleading, since application logic can be both on the client and on the server

    1. OAuth 2.0 bearer tokens

      Does it make sense to require OpenID connect? From my understanding they eliminate some potential interoperability issues by forcing JSON Web tokens as a token format.

    2. Actor objects MUST have, in addition to the properties mandated by 3.1 Object Identifiers, the following properties:

      I'd really like to see that separated. I don't see why all these properties should be present in every activity. I think there should be a separation between the activity, which includes the URL, which can be then used to GET the properties specified here.