Date   

[OSLC forum] [oslc4j-client] Can't specify Configuration Context in parameters and/or headers

Andrii Berezovskyi
 

Jim, Nick, I might need your advice before making changes to the client.

--
/Andrew
(from phone)

Vidarebefordrat brev:

Från: Luis via OSLC forum <discourse@...>
Datum: 30 juli 2019 21:01:57 CEST
Till: andriib@...
Ämne: [OSLC forum] [oslc4j-client] Can't specify Configuration Context in parameters and/or headers
Svara till: Luis via OSLC forum <discourse@...>

cenobyte321
July 30

In the OSLC implementation of IBM Jazz CLM, there are two ways to specify the configuration context, that is, the URI of the configuration the request uses: Using the header “Configuration-Context” or appending the query parameter “oslc_config.context” to the URL.

This last way is not recommended in IBM Jazz CLM since it is not homogeneous between the core CLM apps. For example, in DNG, adding this causes an error when requesting a resource, but in RQM it works as expected.

In the OSLC4J Client library https://github.com/eclipse/lyo.client/tree/master/oslc4j-client, I found the next issues related to this:

  • It doesn’t seem possible to add this header inside the OslcClient class (/src/main/java/org/eclipse/lyo/oslc4j/client/OslcClient.java), other than in the getResource method.
  • Inside the OSLC Query related classes there doesn’t seem to be a way to add headers or append the “oslc_config.context” parameter.
  • In the RmUtil class (/src/main/java/org/eclipse/lyo/oslc4j/client/resources/RmUtil.java) the “typeURI” request fails if the type is in another Configuration

Are OSLC Configurations supported in the OSLC4J Client?

A little bit related to this, there are times where I need to unset the “OSLC-Core” header to access a particular API to manage modules in DNG https://jazz.net/wiki/bin/view/Main/DNGModuleApiOverview. Specifically, instead of that header, I need to set one as “DoorsRP-Request-Type” with value “public 2.0”. Is there a way to do this?

Regards.


Visit Topic to respond.

To unsubscribe from these emails, click here.


Re: SC errors

Andrii Berezovskyi
 

Thanks a lot, Nick! The PRs now build successfully.

 

--

–Andrew.

 

Från: Nicholas Crossley <nick_crossley@...>
Datum: måndag, 29 juli 2019, W31 20:19
Till: Andrii Berezovskyi <andriib@...>
Kopia: "oslc-op@..." <oslc-op@...>, "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne: RE: [oslc-op] SC errors

 

Fixed this by updating ShapeChecker to the latest Jena and latest Apache HttpClient.

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        "oslc-op@..." <oslc-op@...>, Nicholas Crossley <nick_crossley@...>
Cc:        "fabio.ribeiro@..." <fabio.ribeiro@...>
Date:        07/29/2019 08:41 AM
Subject:        [EXTERNAL] Re: [oslc-op] SC errors


 

I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:

 

curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core-v

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 80 (#0)

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

>

< HTTP/1.1 301 Moved Permanently

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/html

< Content-Length: 194

< Connection: keep-alive

< Location: https://open-services.net/ns/core

<

* Ignoring the response-body

* Connection #0 to host open-services.net left intact

* Issue another request to this URL: 'https://open-services.net/ns/core'

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 443 (#1)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

* ALPN, server accepted to use http/1.1

* Server certificate:

*  subject: CN=open-services.net

*  start date: Jun 25 16:46:12 2019 GMT

*  expire date: Sep 23 16:46:12 2019 GMT

*  subjectAltName: host "open-services.net" matched cert's "open-services.net"

*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3

*  SSL certificate verify ok.

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

>

< HTTP/1.1 200 OK

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/turtle; charset=UTF-8

< Content-Length: 25162

< Connection: keep-alive

< X-Powered-By: Express

< Accept-Ranges: bytes

< Cache-Control: public, max-age=0

< Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT

< ETag: W/"624a-160c4b70260"

<

@prefix dcterms: <http://purl.org/dc/terms/>.

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix dcterms: <http://purl.org/dc/terms/> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix vann: <http://purl.org/vocab/vann/> .

@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>.

@prefix oslc: <http://open-services.net/ns/core#> .

 

oslc:

  a owl:Ontology ;

  dcterms:title "The OSLC Core Vocabulary" ;

  dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ;

  dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ;

  vann:preferredNamespacePrefix "oslc" ;

  rdfs:label "Core" .

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum:
måndag, 29 juli 2019, W31 17:36
Till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>, Nicholas Crossley <nick_crossley@...>
Kopia:
"fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne:
Re: [oslc-op] SC errors

 

Nick,

 

As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:

 

openssl s_client -connect archive.open-services.net:443

CONNECTED(00000005)

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

verify return:1

depth=0 CN = archive.open-services.net

verify return:1

---

Certificate chain

0 s:/CN=archive.open-services.net

   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum:
fredag, 26 juli 2019, W30 21:23
Till:
Nicholas Crossley <nick_crossley@...>
Kopia:
"oslc-op@..." <oslc-op@...>, "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne:
Re: [oslc-op] SC errors

 

Thanks Nick, great work! We will fix the TLS certs.

--

/Andrew

(from phone)


26 juli 2019 kl. 21:20 skrev Nicholas Crossley <nick_crossley@...>:

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.


However, we still get some hard errors - one is due to the pain-in-the-neck redirect from
open-services.netwiki to archive.open-services.netand the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
  While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
     Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire '
archive.open-services.net' thing!

Nick.




From:        
Andrii Berezovskyi <andriib@...>
To:        
Nick Crossley <
nick_crossley@...>
Cc:        
"
oslc-op@..." <oslc-op@...>
Date:        
07/25/2019 09:28 AM
Subject:        
[EXTERNAL] SC errors


 

Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.

 




Re: SC errors

Nick Crossley <nick_crossley@...>
 

Fixed this by updating ShapeChecker to the latest Jena and latest Apache HttpClient.

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        "oslc-op@..." <oslc-op@...>, Nicholas Crossley <nick_crossley@...>
Cc:        "fabio.ribeiro@..." <fabio.ribeiro@...>
Date:        07/29/2019 08:41 AM
Subject:        [EXTERNAL] Re: [oslc-op] SC errors



I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:

 

curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core-v

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 80 (#0)

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

>

< HTTP/1.1 301 Moved Permanently

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/html

< Content-Length: 194

< Connection: keep-alive

< Location: https://open-services.net/ns/core

<

* Ignoring the response-body

* Connection #0 to host open-services.net left intact

* Issue another request to this URL: 'https://open-services.net/ns/core'

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 443 (#1)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

* ALPN, server accepted to use http/1.1

* Server certificate:

*  subject: CN=open-services.net

*  start date: Jun 25 16:46:12 2019 GMT

*  expire date: Sep 23 16:46:12 2019 GMT

*  subjectAltName: host "open-services.net" matched cert's "open-services.net"

*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3

*  SSL certificate verify ok.

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

>

< HTTP/1.1 200 OK

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/turtle; charset=UTF-8

< Content-Length: 25162

< Connection: keep-alive

< X-Powered-By: Express

< Accept-Ranges: bytes

< Cache-Control: public, max-age=0

< Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT

< ETag: W/"624a-160c4b70260"

<

@prefix dcterms: <http://purl.org/dc/terms/>.

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix dcterms: <http://purl.org/dc/terms/> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix vann: <http://purl.org/vocab/vann/> .

@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>.

@prefix oslc: <http://open-services.net/ns/core#> .

 

oslc:

  a owl:Ontology ;

  dcterms:title "The OSLC Core Vocabulary" ;

  dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ;

  dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ;

  vann:preferredNamespacePrefix "oslc" ;

  rdfs:label "Core" .

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum:
måndag, 29 juli 2019, W31 17:36
Till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>, Nicholas Crossley <nick_crossley@...>
Kopia:
"fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne:
Re: [oslc-op] SC errors

 

Nick,

 

As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:

 

openssl s_client -connect archive.open-services.net:443

CONNECTED(00000005)

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

verify return:1

depth=0 CN = archive.open-services.net

verify return:1

---

Certificate chain

0 s:/CN=archive.open-services.net

   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till:
"oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum:
fredag, 26 juli 2019, W30 21:23
Till:
Nicholas Crossley <nick_crossley@...>
Kopia:
"oslc-op@..." <oslc-op@...>, "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne:
Re: [oslc-op] SC errors

 

Thanks Nick, great work! We will fix the TLS certs.

--

/Andrew

(from phone)


26 juli 2019 kl. 21:20 skrev Nicholas Crossley <
nick_crossley@...>:

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.


However, we still get some hard errors - one is due to the pain-in-the-neck redirect from
open-services.netwiki to archive.open-services.netand the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
  While examining resource shape
http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
     Error on
http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire '
archive.open-services.net' thing!

Nick.




From:        
Andrii Berezovskyi <andriib@...>
To:        
Nick Crossley <nick_crossley@...>
Cc:        
"oslc-op@..." <oslc-op@...>
Date:        
07/25/2019 09:28 AM
Subject:        
[EXTERNAL] SC errors


 

Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.

 



Re: SC errors

Andrii Berezovskyi
 

I also tried to fetch the the core ontology with the debug output, there seems to be no error in the TLS config at all:

 

curl -H "Accept: text/turtle,application/rdf+xml" -L http://open-services.net/ns/core -v

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 80 (#0)

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

< HTTP/1.1 301 Moved Permanently

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/html

< Content-Length: 194

< Connection: keep-alive

< Location: https://open-services.net/ns/core

* Ignoring the response-body

* Connection #0 to host open-services.net left intact

* Issue another request to this URL: 'https://open-services.net/ns/core'

*   Trying 165.227.5.255...

* TCP_NODELAY set

* Connected to open-services.net (165.227.5.255) port 443 (#1)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

* ALPN, server accepted to use http/1.1

* Server certificate:

*  subject: CN=open-services.net

*  start date: Jun 25 16:46:12 2019 GMT

expire date: Sep 23 16:46:12 2019 GMT

subjectAltName: host "open-services.net" matched cert's "open-services.net"

*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3

SSL certificate verify ok.

> GET /ns/core HTTP/1.1

> Host: open-services.net

> User-Agent: curl/7.54.0

> Accept: text/turtle,application/rdf+xml

< HTTP/1.1 200 OK

< Server: nginx/1.10.3 (Ubuntu)

< Date: Mon, 29 Jul 2019 15:38:41 GMT

< Content-Type: text/turtle; charset=UTF-8

< Content-Length: 25162

< Connection: keep-alive

< X-Powered-By: Express

< Accept-Ranges: bytes

< Cache-Control: public, max-age=0

< Last-Modified: Fri, 05 Jan 2018 05:06:56 GMT

< ETag: W/"624a-160c4b70260"

@prefix dcterms: <http://purl.org/dc/terms/>.

@prefix owl: <http://www.w3.org/2002/07/owl#> .

@prefix dcterms: <http://purl.org/dc/terms/> .

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix vann: <http://purl.org/vocab/vann/> .

@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#>.

@prefix oslc: <http://open-services.net/ns/core#> .

 

oslc:

  a owl:Ontology ;

  dcterms:title "The OSLC Core Vocabulary" ;

  dcterms:description "All vocabulary URIs defined in the OSLC Core namespace."^^rdf:XMLLiteral ;

  dcterms:source <https://tools.oasis-open.org/version-control/svn/oslc-core/trunk/vocab/core-vocab.ttl> ;

  vann:preferredNamespacePrefix "oslc" ;

  rdfs:label "Core" .

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till: "oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum: måndag, 29 juli 2019, W31 17:36
Till: "oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>, Nicholas Crossley <nick_crossley@...>
Kopia: "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne: Re: [oslc-op] SC errors

 

Nick,

 

As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:

 

openssl s_client -connect archive.open-services.net:443

CONNECTED(00000005)

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

verify return:1

depth=0 CN = archive.open-services.net

verify return:1

---

Certificate chain

0 s:/CN=archive.open-services.net

   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till: "oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum: fredag, 26 juli 2019, W30 21:23
Till: Nicholas Crossley <nick_crossley@...>
Kopia: "oslc-op@..." <oslc-op@...>, "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne: Re: [oslc-op] SC errors

 

Thanks Nick, great work! We will fix the TLS certs.

--

/Andrew

(from phone)


26 juli 2019 kl. 21:20 skrev Nicholas Crossley <nick_crossley@...>:

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.

However, we still get some hard errors - one is due to the pain-in-the-neck redirect from open-services.net wiki to archive.open-services.net and the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
   While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
      Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire 'archive.open-services.net' thing!

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        Nick Crossley <nick_crossley@...>
Cc:        "oslc-op@..." <oslc-op@...>
Date:        07/25/2019 09:28 AM
Subject:        [EXTERNAL] SC errors


 

Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.

 


Re: SC errors

Andrii Berezovskyi
 

Nick,

 

As Fabio noted, the problem is not with the TLS certs. I re-checked and the CN is correct:

 

openssl s_client -connect archive.open-services.net:443

CONNECTED(00000005)

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

verify return:1

depth=0 CN = archive.open-services.net

verify return:1

---

Certificate chain

0 s:/CN=archive.open-services.net

   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

   i:/O=Digital Signature Trust Co./CN=DST Root CA X3

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Andrii Berezovskyi <andriib@...>
Svara till: "oslc-op@..." <oslc-op@...>, Andrii Berezovskyi <andriib@...>
Datum: fredag, 26 juli 2019, W30 21:23
Till: Nicholas Crossley <nick_crossley@...>
Kopia: "oslc-op@..." <oslc-op@...>, "fabio.ribeiro@..." <fabio.ribeiro@...>
Ämne: Re: [oslc-op] SC errors

 

Thanks Nick, great work! We will fix the TLS certs.

--

/Andrew

(from phone)


26 juli 2019 kl. 21:20 skrev Nicholas Crossley <nick_crossley@...>:

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.

However, we still get some hard errors - one is due to the pain-in-the-neck redirect from open-services.net wiki to archive.open-services.net and the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
   While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
      Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire 'archive.open-services.net' thing!

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        Nick Crossley <nick_crossley@...>
Cc:        "oslc-op@..." <oslc-op@...>
Date:        07/25/2019 09:28 AM
Subject:        [EXTERNAL] SC errors


 

Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.

 


Re: [tosca] 2019 Open Standards Cup winners

Paul Lipton <paul.lipton@...>
 

Hello Chet,

 

On behalf of the TOSCA TC, our thanks for being considered. We are very pleased to find ourselves in great company as a category finalist. That said; please be aware that TOSCA will be coming on strong in 2020, and that as a past Open Standards Cup winner, we aspire to be in the winner’s circle again next year!

 

Best regards,

Paul

 

From: tosca@... <tosca@...> On Behalf Of Chet Ensign
Sent: Wednesday, July 24, 2019 11:49 AM
To: tc-announce@...; members@...
Cc: OASIS TAB <tab@...>; Staff Bizdev <staff-bizdev@...>; mqtt@...; legaldocml@...; coel@...; tosca@...; Universal Business Language <ubl@...>; vel@...; odf-advocacy@...; oslc-op@...
Subject: [tosca] 2019 Open Standards Cup winners

 

All, 

 

I am pleased to announce the winners of the 2019 Open Standards Cup. We had a number of deserving projects and standards this year and all are truly deserving of recognition and applause. 

 

2019 Outstanding Approved Winner

MQTT Version 5.0 (https://www.oasis-open.org/committees/mqtt/


One of the fundamental standards powering thousand of IoT networks, MQTT v5.0 added significant new features including enhancements for scalability, improved error reporting, extensibility mechanisms, and performance improvements to support small clients. MQTT is designed to support messaging for devices requiring small code footprints, low power/bandwidth, variable availability, and negotiated delivery guarantees.

Category Finalists:

1) Akoma Ntoso Version 1.0 (https://www.oasis-open.org/committees/legaldocml/)

2) Classification of Everyday Living Version 1.0 (https://www.oasis-open.org/committees/coel/)

3) TOSCA Simple Profile in YAML Version 1.2 (https://www.oasis-open.org/committees/tosca/)

4) Universal Business Language Version 2.2 (https://www.oasis-open.org/committees/ubl/)

2019 Outstanding New Initiative

OSLC Open Project (https://github.com/oslc-op and public web presence at https://open-services.net/)

The OSLC-OP is developing standards, frameworks and test suites for capabilities that enable the development of integrated toolchains supporting software development and life-cycle management. In 2019, they migrated to an Open Project to grow their community and open the work to contributors beyond the boundaries of OASIS. 

Category Finalists:

- OASIS Variability Exchange Language (VEL) TC (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vel)

- ODF Advocacy (https://github.com/odf-advocacy)

My thanks to the members of the TAB for their consideration and time to select the finalists. 

 

Our congratulations on all the candidates. 


/chet 
----------------

Chet Ensign

Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org


Mobile: +1 201-341-1393 


Re: SC errors

Andrii Berezovskyi
 

Thanks Nick, great work! We will fix the TLS certs.

--
/Andrew
(from phone)

26 juli 2019 kl. 21:20 skrev Nicholas Crossley <nick_crossley@...>:

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.

However, we still get some hard errors - one is due to the pain-in-the-neck redirect from open-services.net wiki to archive.open-services.net and the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
   While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
      Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire 'archive.open-services.net' thing!

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        Nick Crossley <nick_crossley@...>
Cc:        "oslc-op@..." <oslc-op@...>
Date:        07/25/2019 09:28 AM
Subject:        [EXTERNAL] SC errors



Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.



Re: SC errors

Nick Crossley <nick_crossley@...>
 

Andrew,

I have worked around the foaf issue (and fixed a bunch of other issues found internally in IBM) in the latest version of ShapeChecker.

However, we still get some hard errors - one is due to the pain-in-the-neck redirect from open-services.net wiki to archive.open-services.net and the name mismatch for the SSL certificate:

Checked shapes from file:/Users/ndjc/git/oslc-specs/specs/core/shapes/Error-shape.ttl, with 1 issue (0 info, 0 warnings, 1 errors)
   While examining resource shape http://open-services.net/ns/core/shapes/3.0/Error-shape.ttl#Error:
      Error on http://open-services.net/ns/core#Error:The target resource cannot be fetched or parsed as RDF. (bad value org.apache.jena.atlas.web.HttpException: javax.net.ssl.SSLException: hostname in certificate didn't match: <open-services.net> != <archive.open-services.net> OR <archive.open-services.net>)

Can you fix that in the http/https setup somewhere?  I still do not believe there is any benefit in that entire 'archive.open-services.net' thing!

Nick.



From:        Andrii Berezovskyi <andriib@...>
To:        Nick Crossley <nick_crossley@...>
Cc:        "oslc-op@..." <oslc-op@...>
Date:        07/25/2019 09:28 AM
Subject:        [EXTERNAL] SC errors



Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.



Problems with OASIS Latest version URLs

Jim Amsden
 

Chet,
There are two problems with the OASIS Latest version URL for Open Project documents. Here's an example from the OSLC Change Management 3.0 specification:

Latest version:
        http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.html(Authoritative)
        http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.pdf

First, its not the latest version of a specification, its the latest revision of a version. Once a document becomes an OASIS standard, then it can no longer have revisions. Any changes have to be done in a new version. Since the OASIS Latest version URL contains the version identifier in the URL, it cannot link to the latest version, only the latest revision.

The second problem is that the docs.oasis-open.net host is changing to docs.oasis-open-project.net. We assume the reason for this is that OASIS doesn’t want to have different naming conventions in the same document library, and they are not keen to change the naming conventions to address the issues we’ve raised over relative links and file names.

But as a result, the OASIS Latest version URI is not stable - as the OSLC specs move from a TC to an OP, the latest version URL changes. This raises the question of what the old TC latest version should point to. Or a question on the relationship between closed TC documents that have migrated to OP.

The goal is to ensure that the latest version URL in any version of an OSLC OASIS published document (TC or OP) always links to what it says - the latest version, that URL and any required redirects are properly maintained, and the URL is stable, or if it changes, the old URLs are still properly updated.

Our recommendation is to remove the version identifier from the latest version URL going forward, and manage the transition with redirects at docs.oasis-open.net.

Alternatively we may introduce multiple latest version URLs, one managed by OASIS and another managed by the oslc-op using open-services.net to host the URL and manage the redirects.

We need to resolve this issue in order to know what URL to use for the Latest version in PSD documents we are trying to get published.



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575


SC errors

Andrii Berezovskyi
 

Nick,

 

Is this the lowest level of SC strictness? I don’t like that every build is failing: https://circleci.com/gh/oslc-op/oslc-specs/100?utm_campaign=workflow-failed&utm_medium=email&utm_source=notification#

 

--

–Andrew.


Re: oslc-op meeting minutes 2019-07-25

Andrii Berezovskyi
 

Could you please publish them on oslc-admin as previous minutes? HackMD is just a temp editing place.

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Jim Amsden <jamsden@...>
Svara till: "oslc-op@..." <oslc-op@...>, Jim Amsden <jamsden@...>
Datum: torsdag, 25 juli 2019, W30 19:11
Till: "oslc-op@..." <oslc-op@...>
Ämne: [oslc-op] oslc-op meeting minutes 2019-07-25

 

See https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575


oslc-op meeting minutes 2019-07-25

Jim Amsden
 

See https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575


Re: Please review the agenda for tomorrow's oslc-op meeting

Andrii Berezovskyi
 

I can join a short call next week.

 

--

–Andrew.

 

Från: <oslc-op@...> på uppdrag av Chet Ensign <chet.ensign@...>
Svara till: "oslc-op@..." <oslc-op@...>, "chet.ensign@..." <chet.ensign@...>
Datum: onsdag, 24 juli 2019, W30 19:03
Till: "oslc-op@..." <oslc-op@...>, Jim Amsden <jamsden@...>, Paul Knight <paul.knight@...>
Ämne: Re: [oslc-op] Please review the agenda for tomorrow's oslc-op meeting

 

Hey Jim, Paul and I are in staff and board meetings this week but on the issue of finalizing the template/style sheets, how about we get on a call together next week and walk through all the remaining questions/issues and close on them together? Will you all have time free? 

 

/chet

 

On Wed, Jul 24, 2019 at 11:01 AM Jim Amsden <jamsden@...> wrote:

Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575


 

--


/chet 
----------------

Chet Ensign

Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org


Mobile: +1 201-341-1393 


Re: Please review the agenda for tomorrow's oslc-op meeting

Jim Amsden
 

Nick,
All good points. Comments embedded below, and I've removed the ones that have no comments for clarity...

--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575




From:        "Nick Crossley" <nick_crossley@...>
To:        oslc-op@...
Date:        07/24/2019 12:41 PM
Subject:        [EXTERNAL] Re: [oslc-op] Please review the agenda for tomorrow's oslc-op meeting
Sent by:        oslc-op@...




Some comments on the numbered issues in the agenda, for discussion tomorrow:

3. Format for published document URLs


See above for URLs. Good that we can use relative links. For ReSpec, once we have agreement I can change ReSpec to be compliant. I could also keep the label field but have it generated by default from the other four fields (shortName, oslcVersion, specStatus and revision); this might be useful for non-standards track documents or notes.


<jra>I would recommend removing the label field, ReSpec properties are confusing enough. I think non-standards track document (e.g, Project Note) follow similar naming conventions.</jra>



4. URL to the immutable, authoritative revision of PSD, PS, COS and OS specifications


I find the suggested URL (
https://github.com/oslc-op/oslc-specs/blob/cm-v3.0-psd01/specs/cm/change-mgt-spec.html) unacceptable. That *is* a rendered version, contrary to the statement that the the authoritative version be the actual source and not a rendered version: it is rendered to show all sorts of extra github info which is not part of the spec.

Far better is
https://raw.githubusercontent.com/oslc-op/oslc-specs/cm-v3.0-psd01/specs/cm/change-mgt-spec.html. In this particular case, the fact that this is delivered without content negotiation is a plus - you get the raw source rather than an HTML rendering.

<jra>Agreed the far better URI is indeed far better. Lets use that</jra>



5. Where permanent links will be established to specifications.


"Once an open-services.net redirect opens an actual specification, the reader will see the appropriate this, previous and latest OASIS links."


The 'latest version' link is the one that concerns me the most - what if the latest is no longer at OASIS, or at least not where OASIS thought it was at that time? Can OASIS guarantee to have a stable URL for 'latest' that always follows the spec wherever it goes in the future? There's already the potential issue about versions of the spec, as opposed to revisions - what will the OASIS 'latest' link for Core 3.0 PSD 01 point to after Core 4.0 is published?

<jra>re: "what if the latest is no longer at OASIS" - then all bets are off because the specs are no longer under OASIS governance and perhaps the OASIS document library is no longer accessible.

But I don't think this is an issue. OASIS guarantees the preservation of these published documents and their URLs, that's what membership dues are for and why OASIS has naming conventions.

So I have no problem having an open-services.net redirect to a docs.oasis-open-project resource.<jra>



6. Additional components URLs also need to be generated


Given the agreement in (3) that relative links are OK, I think we should use those.


<jra>OASIS may insist on the full URL. Or we can try again to make these proper HTML anchors, and not display the URL at all. That would be my much preferred solution. Note however if anyone copied any of these links, they might not work if only the relative link is copied.</jra>


Nick.





From:        
"Jim Amsden" <jamsden@...>
To:        
oslc-op@...
Date:        
07/24/2019 08:02 AM
Subject:        
[EXTERNAL] [oslc-op] Please review the agenda for tomorrow's oslc-op meeting
Sent by:        
oslc-op@...




Meeting agenda:
https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--

Jim Amsden, Senior Technical Staff Member

ELM Quality Manager

919-525-6575









Re: Please review the agenda for tomorrow's oslc-op meeting

Nick Crossley <nick_crossley@...>
 

Some comments on the numbered issues in the agenda, for discussion tomorrow:

1. OP Project Specification format and OASIS boilerplate

OK.

2. Where OP specifications are published

Where OASIS publishes specs is indeed up to OASIS. However, I would still prefer we separate that from the URLs that we recommend and display to users, provided the URLs we do recommend and display resolve to the same place. In other words, no one has yet convinced me we are not better off using open-services.net and redirects - see my response to point 5.

3. Format for published document URLs

See above for URLs. Good that we can use relative links. For ReSpec, once we have agreement I can change ReSpec to be compliant. I could also keep the label field but have it generated by default from the other four fields (shortName, oslcVersion, specStatus and revision); this might be useful for non-standards track documents or notes.

4. URL to the immutable, authoritative revision of PSD, PS, COS and OS specifications

I find the suggested URL (https://github.com/oslc-op/oslc-specs/blob/cm-v3.0-psd01/specs/cm/change-mgt-spec.html) unacceptable. That *is* a rendered version, contrary to the statement that the the authoritative version be the actual source and not a rendered version: it is rendered to show all sorts of extra github info which is not part of the spec.

Far better is https://raw.githubusercontent.com/oslc-op/oslc-specs/cm-v3.0-psd01/specs/cm/change-mgt-spec.html. In this particular case, the fact that this is delivered without content negotiation is a plus - you get the raw source rather than an HTML rendering.

5. Where permanent links will be established to specifications.

"Once an open-services.net redirect opens an actual specification, the reader will see the appropriate this, previous and latest OASIS links." The 'latest version' link is the one that concerns me the most - what if the latest is no longer at OASIS, or at least not where OASIS thought it was at that time? Can OASIS guarantee to have a stable URL for 'latest' that always follows the spec wherever it goes in the future? There's already the potential issue about versions of the spec, as opposed to revisions - what will the OASIS 'latest' link for Core 3.0 PSD 01 point to after Core 4.0 is published?

6. Additional components URLs also need to be generated

Given the agreement in (3) that relative links are OK, I think we should use those.

Nick.




From:        "Jim Amsden" <jamsden@...>
To:        oslc-op@...
Date:        07/24/2019 08:02 AM
Subject:        [EXTERNAL] [oslc-op] Please review the agenda for tomorrow's oslc-op meeting
Sent by:        oslc-op@...




Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--

Jim Amsden, Senior Technical Staff Member

ELM Quality Manager

919-525-6575






Re: Please review the agenda for tomorrow's oslc-op meeting

Chet Ensign
 

Hey Jim, Paul and I are in staff and board meetings this week but on the issue of finalizing the template/style sheets, how about we get on a call together next week and walk through all the remaining questions/issues and close on them together? Will you all have time free? 

/chet

On Wed, Jul 24, 2019 at 11:01 AM Jim Amsden <jamsden@...> wrote:
Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575



--

/chet 
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Mobile: +1 201-341-1393 


2019 Open Standards Cup winners

Chet Ensign
 

All, 

I am pleased to announce the winners of the 2019 Open Standards Cup. We had a number of deserving projects and standards this year and all are truly deserving of recognition and applause. 

2019 Outstanding Approved Winner

MQTT Version 5.0 (https://www.oasis-open.org/committees/mqtt/

One of the fundamental standards powering thousand of IoT networks, MQTT v5.0 added significant new features including enhancements for scalability, improved error reporting, extensibility mechanisms, and performance improvements to support small clients. MQTT is designed to support messaging for devices requiring small code footprints, low power/bandwidth, variable availability, and negotiated delivery guarantees.

Category Finalists:

1) Akoma Ntoso Version 1.0 (https://www.oasis-open.org/committees/legaldocml/)

2) Classification of Everyday Living Version 1.0 (https://www.oasis-open.org/committees/coel/)

3) TOSCA Simple Profile in YAML Version 1.2 (https://www.oasis-open.org/committees/tosca/)

4) Universal Business Language Version 2.2 (https://www.oasis-open.org/committees/ubl/)

2019 Outstanding New Initiative

OSLC Open Project (https://github.com/oslc-op and public web presence at https://open-services.net/)

The OSLC-OP is developing standards, frameworks and test suites for capabilities that enable the development of integrated toolchains supporting software development and life-cycle management. In 2019, they migrated to an Open Project to grow their community and open the work to contributors beyond the boundaries of OASIS. 

Category Finalists:

- OASIS Variability Exchange Language (VEL) TC (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=vel)

- ODF Advocacy (https://github.com/odf-advocacy)

My thanks to the members of the TAB for their consideration and time to select the finalists. 

Our congratulations on all the candidates. 

/chet 
----------------
Chet Ensign
Chief Technical Community Steward
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Mobile: +1 201-341-1393 


Please review the agenda for tomorrow's oslc-op meeting

Jim Amsden
 

Meeting agenda: https://hackmd.io/GBxx8iRLS3Sf-VvZM2z1Dw?view



--
Jim Amsden, Senior Technical Staff Member
ELM Quality Manager
919-525-6575


Re: Minutes for 2019-07-18

Nick Crossley <nick_crossley@...>
 

I have reviewed Andrew's pull request for ReSpec changes to URI generation, and merged it with my own changes into master (ReSpec 2.1.4). In doing so, I have restored the handling of previousMaturity and previousPublishDate - if you set those conf variables, they will show up in the 'Previous' URIs section of the header.

Nick.



From:        "Andrii Berezovskyi" <andriib@...>
To:        "oslc-op@..." <oslc-op@...>
Date:        07/18/2019 08:53 AM
Subject:        [EXTERNAL] [oslc-op] Minutes for 2019-07-18
Sent by:        oslc-op@...



Hi,

 

Please find the minutes from today here: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2019/2019-07-18.md

 

Please add agenda items for the next meeting here: https://hackmd.io/@driib/oslc-op-minutes/edit?both

 

Cheers,

Andrew






Minutes for 2019-07-18

Andrii Berezovskyi
 

Hi,

 

Please find the minutes from today here: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2019/2019-07-18.md

 

Please add agenda items for the next meeting here: https://hackmd.io/@driib/oslc-op-minutes/edit?both

 

Cheers,

Andrew

1061 - 1080 of 1118