Subject: Re: [drinks] security considerations...

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 1 Sep 2011 09:41:48 -0400

We don't want to put data elements into the protocol just to allow someone to use some tool to generate code.  That would be the tail wagging the dog.  Furthermore, there are already other tools that can generate DB schemas and/or ORM code that can be used for that, irrespective of whether or not a data element is in the protocol.  But with respect to this specific data element, this discussion is OBE, since the folks asking to have that data element removed have agreed to add it back in.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, September 01, 2011 1:54 AM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

On 8/31/11 12:00 PM, Cartwright, Ken wrote:

>
> KJC:  Not correct.  The protocol does not specify everything that is
> "stored".  SPPP does not define the DB schema.  You are free to
> store anything additional that you want.  In my implementation,
> regardless of what is in the protocol, I would store/track the rar
> that created each individual object.  And I would do this for
> multiple reasons, my authorization policies being one of the main
> ones.

The protocol does define the XSD which in turn defines OpenSPP's
programatically-generated inter-layer messaging, and in some cases the
actual database schema or parts thereof. Jeremy can add details on this;
perhaps I'm off-base.

My gSOAP code definitely uses the data types defined programatically by
gSOAP from the XSD.

I can certainly add parallel tables and messages, but it'sa a lot easier
to piggyback on the tool's automatic plumbing when the auth_ID is in the
payload.

--
Dean

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

---

From: "Jeremy Barkan \(Digitalshtick\)" <[email-masked]>
Date: Thu, 1 Sep 2011 20:20:09 +0300

I want to stress that IMHO - two of the goals of the XSD is to provide
interoperability and validation. So it's just about support for
implementation tools.
Otherwise - too much would be left to different implementation preferences.
By having all the "nouns" clearly defined with   their constraints - we can
make sure that regardless of the  implementation, that these will be defined
uniformly across all implementations.

Jeremy Barkan

CTO
Digitalshtick
Tel: +972 2 6728069
Mobile: +972 54 6321603
Skype: jeremy_barkan
www.digitalshtick.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cartwright, Ken
Sent: 01 September 2011 16:42
To: Dean Willis
Cc: [email-masked]
Subject: Re: [drinks] security considerations...

We don't want to put data elements into the protocol just to allow someone
to use some tool to generate code.  That would be the tail wagging the dog.
Furthermore, there are already other tools that can generate DB schemas
and/or ORM code that can be used for that, irrespective of whether or not a
data element is in the protocol.  But with respect to this specific data
element, this discussion is OBE, since the folks asking to have that data
element removed have agreed to add it back in.

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, September 01, 2011 1:54 AM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

On 8/31/11 12:00 PM, Cartwright, Ken wrote:

> "stored".  SPPP does not define the DB schema.  You are free to store 
> anything additional that you want.  In my implementation, regardless 
> of what is in the protocol, I would store/track the rar that created 
> each individual object.  And I would do this for multiple reasons, my 
> authorization policies being one of the main ones.

I can certainly add parallel tables and messages, but it'sa a lot easier to
piggyback on the tool's automatic plumbing when the auth_ID is in the
payload.

--
Dean

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network
Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply
e-mail and destroy all copies of the original message.

_______________________________________________
drinks mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/drinks

---

From: "Cartwright, Ken" <[email-masked]>
Date: Thu, 1 Sep 2011 13:27:53 -0400

Ok.  But just to be clear, we're not discussing nouns or verbs.  We're discussing whether an additional data element needed to be in the protocol or not.

Ken

-----Original Message-----
From: Jeremy Barkan (Digitalshtick) [mailto:[email-masked]]
Sent: Thursday, September 01, 2011 1:20 PM
To: Cartwright, Ken; 'Dean Willis'
Cc: [email-masked]
Subject: RE: [drinks] security considerations...

Jeremy Barkan

CTO
Digitalshtick
Tel: +972 2 6728069
Mobile: +972 54 6321603
Skype: jeremy_barkan
www.digitalshtick.com

-----Original Message-----

Ken

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Thursday, September 01, 2011 1:54 AM
To: Cartwright, Ken
Cc: Ali, Syed Wasim; [email-masked]
Subject: Re: [drinks] security considerations...

--
Dean