Re: [EXT] Embedded Relationships

["Mr. Stefan Hagen" <stefan@hagen.link>]

I personally think the document is well written and clear here, to allow the ole "anonymous ftp incoming folder" pattern and also does  enforce neither long term storage nor transactions (CRUD) to conform to it. 
Jason and John (IMO) kind of nicely explained that, but when not being engaged in discussions, things often appear clear, so I might be biased due to having no stakes in the matter ...

... and I am not sure what that rant on email communication is about? 
I think the email exchange over all these time zones and life-work balances of the participants makes it an accessible, sustainable, and non-intrusive communication medium - hard to top

Stefan/200

On 12/05/17 21:28, Reller, Nathan S. wrote:
> I agree that we are talking past each other. It’s a bit difficult to
> communicate over email.
> 
>  
> 
> It’s not just the status code, but it’s also the returned status JSON
> object for a 202 status code. John, you said that a write-only feed
> should return 202. I think that sounds right, but then the question is
> what is in the response status JSON object? Each SDO that is added must
> go into a bin of success, failure, or pending to indicate its status for
> the POST request. If it’s a success then it must return a URL to
> download the object, or at least that’s how I’m reading the spec. It
> seems to be conflicting with a write-only collection. I’m trying to
> figure out if that is conflicting, or if I’m missing something.
> 
>  
> 
> I do agree with Jason’s point that there might be different types of
> TAXII servers. I think he has provided some useful examples, but I think
> the spec needs to provide more details on how to implement them. This
> may be an example of a conflict that I am trying to discover to make the
> document better.
> 
>  
> 
> -Nate
> 
>  
> 
> *From: *"Wunder, John A." <jwunder@mitre.org>
> *Date: *Friday, May 12, 2017 at 3:18 PM
> *To: *"Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, Bret Jordan
> <Bret_Jordan@symantec.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
> *Cc: *Allan Thomson <athomson@lookingglasscyber.com>,
> "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, John-Mark Gurney
> <jmg@newcontext.com>, "Struse, Richard" <Richard.Struse@hq.dhs.gov>,
> Terry MacDonald <terry.macdonald@cosive.com>
> *Subject: *Re: [cti] Re: [EXT] [cti] Embedded Relationships
> 
>  
> 
> Hm, I wonder if people are talking past each other. We’re talking about
> the error code for when you try to get something that you don’t have
> access to:
> 
>  
> 
> 1.      POST an indicator to a write-only feed (think an inbox) ->
> Status code is 202
> 
> 2.      GET the URL for that indicator -> Status code is 405
> 
>  
> 
> The initial POST is fine…the object was successfully added to the
> collection. That doesn’t, however, mean that it’s always and forever
> accessible to in that collection…maybe it’s an inbox so the collection
> is write-only. Maybe it ages out after a day so if you try again in a
> day it’s gone and you get a 404. Maybe a user only has access to some
> data so it’s a 403.
> 
>  
> 
> The key thing IMO is what Jason said…a TAXII server isn’t always just
> going to be a database of content. If it was literally just a database
> where you can put stuff and get it out then there are plenty of existing
> technologies for that. TAXII is a spec to describe the interactions
> between products exchanging CTI….some products may be data feeds (TAXII
> server that just provides read-only data), others might be TIPs
> (read/write), and others might be content submission inboxes
> (write-only). That’s all still TAXII and all might be backed by
> validated TAXII Servers, but that doesn’t mean that each of them behaves
> identically as a TAXII repository.
> 
>  
> 
> John
> [...]