Subject: Re: [sacm] [sacmwg/draft-ietf-sacm-information-model] datatype requests (#37)

From: Mike Cokus <[email-masked]>
Date: Tue, 10 Jan 2017 06:49:15 -0800

Concerning the URI part of the issue, we may need to discuss the scope.  URIs cover more than web addresses (see RFC3986 - https://datatracker.ietf.org/doc/rfc3986/).  Does the datatype need to address all URIs in general or just web addresses?  For example, the following are all URIs:
      ftp://ftp.is.co.za/rfc/rfc1808.txt
      http://www.ietf.org/rfc/rfc2396.txt
      ldap://[2001:db8::7]/c=GB?objectClass?one
      mailto:[email-masked]
      tel:+1-816-555-1212
      urn:oasis:names:specification:docbook:dtd:xml:4.1.2

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271594385

---

From: Mike Cokus <[email-masked]>
Date: Tue, 10 Jan 2017 10:06:06 -0800

Concerning the Array/Map part of the issue, it's not clear what "based on experience with CBOR" means in the context of an information model, since CBOR is a specific data format.  I'm thinking the intention is to describe the datatypes in a way that makes implementation in CBOR easier.  If that's the case, then we could pattern Map and Array on JSON, since CBOR can be use to define compact representations of JSON structures.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271650883

---

From: henkbirkholz <[email-masked]>
Date: Tue, 10 Jan 2017 10:59:47 -0800

"based on experience with CBOR": While CBOR is a encoding/dataformat, it can be described using the language CDDL - maybe that was implied here?. Because, CDDL can already represent both JSON and CBOR structures natively (and JSON uses a totally different serialization). This is for two primary reasons:

1) CBOR is comparable to JSON, because it has a superset of JSON's ability, it just.... serializes to a binary format.
2) More importantly, they both therefore share a huge portion of the underlying information model. That is why the language CDDL can represent them both, the language already abstracts (the CBOR-specific prelude excluded, of course) from the actual encoding, which is what an information model usually does.

In any case, the characteristics of arrays and map are the same in both encodings. If those are meant, I agree that the semantics can probably be derived from the corresponding definitions, as Mike already suggested:

https://tools.ietf.org/html/rfc4627#section-2.2
https://tools.ietf.org/html/rfc4627#section-2.3
(and Major Type 4 & Major Type 5 in https://tools.ietf.org/html/rfc7049)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271664954

---

From: Jim Schaad <[email-masked]>
Date: Tue, 10 Jan 2017 14:15:41 -0800

I think that this could probably have been written just as easily as "based on experience with JSON".  I just read it as we should have these types available because we have found them useful.  They are available (I think) as primitives (ordered vs unordered lists?) so I think that it has been satisfied.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271715412

---

From: henkbirkholz <[email-masked]>
Date: Tue, 10 Jan 2017 14:44:02 -0800

Well, as the definition says: Maps are an unordered set of AVP that only allows exactly one instance of each attribute, but provides unambigous semantics. An array is an ordered set of values that allows combination of sequences of values with the same type, but therefore also allows for ambigous semantics.

I am in doubt that the ordered and unordered lists defined by the IM draft are either of those. I am also not sure if we need them, though. In general, it does not hurt to enable the use of JSON, I'd say.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271722037

---

From: Jim Schaad <[email-masked]>
Date: Tue, 10 Jan 2017 15:10:11 -0800

An unordered list is defined as - here are a set of name and values pairs that can occur in any order in the list.  To me this is semantically the same as a MAP.

An ordered list is defined as - here are a set of name and value pairs that can occur in a fixed order in the list.  This is basically the same thing as what an array looks like assuming that you have the ability to deal with elements in the middle that are absent.  This could be done by the use of tagging or nil points in the array to say that the field is not there.  That seems to be to be the semantic equivalent of an array, but I can see some people might not agree with that.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271727933

---

From: Jim Schaad <[email-masked]>
Date: Tue, 10 Jan 2017 18:01:37 -0800

Can you generate a pull request so we can see how this would be different from what is current in the document?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-information-model/issues/37#issuecomment-271756844