Date   

Form submission from: Publish a Candidate OASIS Standard

Chet Ensign
 

Submitted on Friday, March 5, 2021 - 23:27
Submitted by user: censign
Submitted values are:

Your name: Chet Ensign
TC name: OSLC Open Project
TC email address: oslc-op-pgb@lists.oasis-open-projects.org
Title: OSLC Requirements Management Version 2.1 PS01
Approval link:
https://lists.oasis-open-projects.org/g/oslc-op-pgb/topic/approve_submitting_oslc/80909739?p=,,,20,0,0,0::recentpostdate%2Fstick
Original or Amended: First COS
Previous Candidate OASIS Standard:
Notes: Entered on behalf of the OP after ballot passed. This will be our
first
Project Specification put forward as a candidate for OASIS Standard so adjust
public review metadata accordingly.


The results of this submission may be viewed at:
http://tools.oasis-open.org/issues/browse/TCADMIN


locked Re: Approve submitting OSLC Requirements Management V2.1 PS01 and OSLC Change Management v3.0 PS01 as candidates for OASIS Standard #poll-notice #poll-result

Andrii Berezovskyi
 

Thank you Chet,

Just cast my votes.

--
Cheers,
Andrew

On 2021-02-25 , at 20:00, Chet Ensign <chet.ensign@...> wrote:

A new poll has been created:

Please make two choices below to indicate whether you approve or disapprove the respective Project Specifications becoming candidates for OASIS Standards. 

OSLC Requirements Management Version 2.1 Project Specification 01 [1] was approved as a Project Specification on 03 September 2020. The Open Project received 3 Statements of Use from SodiusWillert, IBM, and KTH Royal Institute of Technology [2]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?
 
OSLC Change Management Version 3.0 Project Specification 01 [3] was approved as a Project Specification on 17 September 2020. The Open Project received 3 Statements of Use from KTH Royal Institute of Technology, SodiusWillert, and IBM [4]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?
 
Approving this ballot will result in a 60-day public review after which, if no comments are received, the PSs will be submitted to an OASIS-membership-wide call for consent. If comments are received, additional steps will need to be taken as explained in TC Process section 3.4.2, Public Review of a Candidate OASIS Standard [5], the rules applicable here.  
 
This ballot requires a Special Majority Vote [6]. The PGB has 3 voting members. In order to pass, at least 2 (2/3 x 3) have to vote Yes and none may vote No.
 
[1] URI to the PS:
 
 
[2] Links to Statements of Use for Requirements Management
 
- SodiusWillert :
 
- IBM: 
 
- KTH Royal Institute of Technology
 
[3] URI to the PS:
 
[4] Links to Statements of Use for Change Management
 
- KTH Royal Institute of Technology
 
- SodiusWillert
 
- IBM
 
 

1. OSLC Requirements Management Version 2.1 - yes
2. OSLC Requirements Management Version 2.1 - no
3. OSLC Requirements Management Version 2.1 - abstain
4. OSLC Change Management Version 3.0 - yes
5. OSLC Change Management Version 3.0 - no
6. OSLC Change Management Version 3.0 - abstain

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.



locked Approve submitting OSLC Requirements Management V2.1 PS01 and OSLC Change Management v3.0 PS01 as candidates for OASIS Standard #poll-notice #poll-result

Chet Ensign
 

Please make two choices below to indicate whether you approve or disapprove the respective Project Specifications becoming candidates for OASIS Standards. 

OSLC Requirements Management Version 2.1 Project Specification 01 [1] was approved as a Project Specification on 03 September 2020. The Open Project received 3 Statements of Use from SodiusWillert, IBM, and KTH Royal Institute of Technology [2]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?
 
OSLC Change Management Version 3.0 Project Specification 01 [3] was approved as a Project Specification on 17 September 2020. The Open Project received 3 Statements of Use from KTH Royal Institute of Technology, SodiusWillert, and IBM [4]. Do you now approve submitting this Project Specification to the OASIS membership for consideration as a candidate for OASIS Standard?
 
Approving this ballot will result in a 60-day public review after which, if no comments are received, the PSs will be submitted to an OASIS-membership-wide call for consent. If comments are received, additional steps will need to be taken as explained in TC Process section 3.4.2, Public Review of a Candidate OASIS Standard [5], the rules applicable here.  
 
This ballot requires a Special Majority Vote [6]. The PGB has 3 voting members. In order to pass, at least 2 (2/3 x 3) have to vote Yes and none may vote No.
 
[1] URI to the PS:
https://lists.oasis-open-projects.org/g/oslc-op-pgb/attachment/107/0/rm-2.1-cos01.zip
 
 
[2] Links to Statements of Use for Requirements Management
 
- SodiusWillert :
https://lists.oasis-open-projects.org/g/oslc-op/topic/sodiuswillert_statement_of/78363625?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78363625
 
- IBM: 
https://lists.oasis-open-projects.org/g/oslc-op/topic/ibm_statements_of_use_for/78712131?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78712131
 
- KTH Royal Institute of Technology
https://lists.oasis-open-projects.org/g/oslc-op/topic/kth_statement_of_use_of_oslc/78206691?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78206691
 
[3] URI to the PS:
https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/ps01/change-mgt-spec.html
 
[4] Links to Statements of Use for Change Management
 
- KTH Royal Institute of Technology
https://lists.oasis-open-projects.org/g/oslc-op/topic/kth_statement_of_use_of_oslc/78206683?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78206683
 
- SodiusWillert
https://lists.oasis-open-projects.org/g/oslc-op/topic/sodiuswillert_statement_of/78363625?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78363625
 
- IBM
https://lists.oasis-open-projects.org/g/oslc-op/topic/ibm_statements_of_use_for/78712131?p=,,,50,0,0,0::recentpostdate%2Fsticky,,,50,2,0,78712131
 
[5] http://www.oasis-open.org/policies-guidelines/tc-process#OASISstandard
 
[6] Special Majority Vote: http://www.oasis-open.org/committees/process-2010-07-28.php#dSpecialMajority

Results

See Who Responded


Re: [IANA #1189640] [Ietf-message-headers] OSLC-Core-Version header registration request (message-headers)

Andrii Berezovskyi
 

Dear Michelle,

Thank you for getting back to me so quickly! We accept the change of the application to the provisional status registration without any objections and will submit another application once our specification reaches OASIS OS stage.

Regarding the controller:

1) Yes, OSLC OP and its PGB will survive the publication of the OSLC Core standard. However, it may close in the future if all OSLC activity ceases (ie OSLC Core is one of many tracks we have).
2) We are OK with OASIS themselves serving as a more permanent controller (Chet did that before for other OASIS standards, your colleague Amanda Barber should be aware of this). Please choose one of the controller entries below.

OASIS OSLC Open Project PGB

OASIS, Chet Ensign

Thank you again kindly for your time.

Best regards,
Andrew

On 2021-02-23 , at 18:19, Michelle Cotton via RT <iana-prot-param@...> wrote:

Dear Andrew,

Your request has been approved by the designated expert for a provisional registration.

Review from the expert:
<start review>
It can then progress to permanent status when approved as an Oasis Standard.

This on the basis that:
1. OASIS is recognised as an open standards development organisation (per previous discussions about another submission).

2. The OASIS process includes formal public review in progressing from Candidate OASIS Standard to OASIS Standard, but not before. (If I’ve misunderstood this, I’d be happy to reconsider my recommendation.)

One comment about the registration template itself:

There is no email address given for the change controller. This is not strictly necessary if OASIS is specified, but it might be helpful if anyone wishes to enquire about our comment on the specification.

Something to consider when it becomes permanent:
You have indicated the change controller can be the OASIS PGB: does this group survive the work of the technical committee once the standard is published? If not, I’d suggest the change controller be OASIS, or a permanent role in that organisation. In any case, I think OASIS should be clearly identified here as the sponsoring standards organisation.
<end review>

Before we continue with the provisional registration, do you have an email that we can include in case anyone has questions?


Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services


On Mon Feb 22 12:15:16 2021, andriib@... wrote:
Dear IANA administrator,

I would like to submit the registration application as per the
procedure outlined in https://tools.ietf.org/html/bcp90#section-4.3.
Please find the registration request template forwarded below from our
original submission to ietf-message-headers@...<mailto:ietf-
message-headers@...> from 2 weeks ago. No objections have been
received on the mailing list as far as I can tell.

Thank you kindly for your time.

Kind regards,
Andrew Berezovskyi

OSLC OP PGB co-chair

Begin forwarded message:

From: Andrii Berezovskyi <andriib@...<mailto:andriib@...>>
Subject: [Ietf-message-headers] OSLC-Core-Version header registration
request
Date: 6 February 2021 at 13:38:41 CET
To: "ietf-message-headers@...<mailto:ietf-message-
headers@...>" <ietf-message-headers@...<mailto:ietf-message-
headers@...>>

Hello,

OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project
(OP) would like to submit the following registration request:


Header field name: OSLC-Core-Version

Applicable protocol: http (RFC 2616 and its successors)

Status:
  standard (Project Specification 01 as per OASIS classification, has
all the statements from the implementers to progress to the Candidate
OASIS Standards once PS02 is published with the changes related to
this registration request)

Author/Change controller:
  OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing
Board (PGB) itself)

Specification document(s):
  https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-
core.html (§4.2, Part 1, approved Project Specification 01)
  https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html
(latest draft that will have to be voted on again once this
registration request has been considered by IETF, contains ABNF as per
the registration requirements)
  https://archive.open-
services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning
(spec that introduced the header)

Related information:
  OSLC-Core-Version header has been in active use by OSLC
implementations since 2009.
  https://github.com/oslc-op/oslc-specs/issues/459
  This submission is made in preparation to progressing OSLC Core
specification to the OASIS Standard stage (currently Project
Specification stage has passed and Candidate OASIS Specification stage
is next).


Answers to the considerations in
https://tools.ietf.org/html/rfc7231#section-8.3:

1) Field is a single value.
2) The field can be used for both requests and responses; the spec
defines the expected behaviour.
3) The header is not to be stored by the origin servers on PUT
requests.
4) The semantics of the header only depend on whether a server or a
client is sending it.
5) The header field is not hop-by-hop.
6) Intermediaries between OSLC servers and OSLC clients shall not
insert or alter this header unless they are themselves OSLC servers or
OSLC clients.
7) Yes, the header may be listed in the Vary header because the server
may serve different content depending on the OSLC-Core-Version
capability of the client.
8) No, the header is not generated dynamically and is not useful as a
chunked trailer.
9) Yes, the header is to be preserved across redirects.
10) No private data is disclosed in the header. No security
implications arise from this header alone as it only guides clients
and servers on the version of the high-level protocol and is
independent of the protocols that constitute a larger attack surface
such as HTTP, TLS, oAuth. The attacker may infer from a value of a
header that a certain feature is not supported by an old client or
server (e.g. OSLC 2 uses oAuth 1.0 and OSLC 3 recommends OIDC 1.0).
The attacker may also indirectly try to guess that an old client or
server may run old software such as JDK 7 and use insecure settings
due to a lack of new TLS version support etc. We don't think, however,
that this header introduces any significant information for the
attacked they could not gather on their own.

Thank you kindly for your time and the consideration of our
application.

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair


_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@...<mailto:Ietf-message-headers@...>
https://www.ietf.org/mailman/listinfo/ietf-message-headers




[Ietf-message-headers] OSLC-Core-Version header registration request

Andrii Berezovskyi
 

Dear IANA administrator,

I would like to submit the registration application as per the procedure outlined in https://tools.ietf.org/html/bcp90#section-4.3. Please find the registration request template forwarded below from our original submission to ietf-message-headers@... from 2 weeks ago. No objections have been received on the mailing list as far as I can tell.

Thank you kindly for your time.

Kind regards,
Andrew Berezovskyi

OSLC OP PGB co-chair

Begin forwarded message:

From: Andrii Berezovskyi <andriib@...>
Subject: [Ietf-message-headers] OSLC-Core-Version header registration request
Date: 6 February 2021 at 13:38:41 CET

Hello,

OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project (OP) would like to submit the following registration request:


Header field name: OSLC-Core-Version

Applicable protocol: http (RFC 2616 and its successors)

Status:
   standard (Project Specification 01 as per OASIS classification, has all the statements from the implementers to progress to the Candidate OASIS Standards once PS02 is published with the changes related to this registration request)

Author/Change controller:
   OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing Board (PGB) itself)

Specification document(s):
   https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html (§4.2, Part 1, approved Project Specification 01)
   https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html (latest draft that will have to be voted on again once this registration request has been considered by IETF, contains ABNF as per the registration requirements)
   https://archive.open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning (spec that introduced the header)

Related information:
   OSLC-Core-Version header has been in active use by OSLC implementations since 2009.
   https://github.com/oslc-op/oslc-specs/issues/459
   This submission is made in preparation to progressing OSLC Core specification to the OASIS Standard stage (currently Project Specification stage has passed and Candidate OASIS Specification stage is next).


Answers to the considerations in https://tools.ietf.org/html/rfc7231#section-8.3:

1) Field is a single value.
2) The field can be used for both requests and responses; the spec defines the expected behaviour.
3) The header is not to be stored by the origin servers on PUT requests.
4) The semantics of the header only depend on whether a server or a client is sending it.
5) The header field is not hop-by-hop.
6) Intermediaries between OSLC servers and OSLC clients shall not insert or alter this header unless they are themselves OSLC servers or OSLC clients.
7) Yes, the header may be listed in the Vary header because the server may serve different content depending on the OSLC-Core-Version capability of the client.
8) No, the header is not generated dynamically and is not useful as a chunked trailer.
9) Yes, the header is to be preserved across redirects.
10) No private data is disclosed in the header. No security implications arise from this header alone as it only guides clients and servers on the version of the high-level protocol and is independent of the protocols that constitute a larger attack surface such as HTTP, TLS, oAuth. The attacker may infer from a value of a header that a certain feature is not supported by an old client or server (e.g. OSLC 2 uses oAuth 1.0 and OSLC 3 recommends OIDC 1.0). The attacker may also indirectly try to guess that an old client or server may run old software such as JDK 7 and use insecure settings due to a lack of new TLS version support etc. We don't think, however, that this header introduces any significant information for the attacked they could not gather on their own.

Thank you kindly for your time and the consideration of our application.

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair


_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@...
https://www.ietf.org/mailman/listinfo/ietf-message-headers


Reminder for Candidate OASIS Standard votes next week

Andrii Berezovskyi
 

Hello everyone,

I would like to remind you that we have formally notified OSLC OP PGB a week ago of the intent to submit two OSLC specs to become Candidate OASIS Standards. Everyone in the OSLC community is welcome to submit feedback on the project specs before they go for the COS vote next week:

https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/ps01/change-mgt-spec.html
https://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/requirements-management-spec.html

I wish everyone a pleasant weekend.

--
Cheers,
Andrew


Intent to publish OSLC CM 3.0 COS 01

Andrii Berezovskyi
 

Dear PGB,

I would like to notify you that we intend to publish OSLC Change Management 3.0 as a Candidate OASIS Standard 01. The details can be found under https://github.com/oasis-open-projects/administration/issues/20

Cheers,
Andrew on behalf of all OP contributors


Re: [oslc-op] CM COS

Andrii Berezovskyi
 

Hello,

Got a reply from Jim on the ticket in question. Just filed https://github.com/oasis-open-projects/administration/issues/20 for CM 3.0 COS 01.

--
Best regards,
Andrew

On 12 February 2021, at 13:00, Andrii Berezovskyi <andriib@...> wrote:

CCing the PGB

--
Best regards,
Andrew

On 12 February 2021, at 12:59, Andrew Berezovskyi via lists.oasis-open-projects.org <andrew=berezovskyi.me@...> wrote:

Hello OP,

Given what we heard from Chet yesterday that a new document is not needed for COS, shall we push CM to COS directly? If I understood him correctly, we can simply file a new ticket under https://github.com/oasis-open-projects/administration/issues for CM COS today and they will take it from there.

What do you think? PGB members, are you in favour of that (there will be an SMV ballot so this is not a binding reply)?

Here is the milestone for the CM COS: https://github.com/oslc-op/oslc-specs/milestone/23. Can someone confirm that the one issue in that milestone is not blocking us from going to COS?

–Andrew







Re: [oslc-op] CM COS

Andrii Berezovskyi
 

CCing the PGB

--
Best regards,
Andrew

On 12 February 2021, at 12:59, Andrew Berezovskyi via lists.oasis-open-projects.org <andrew=berezovskyi.me@...> wrote:

Hello OP,

Given what we heard from Chet yesterday that a new document is not needed for COS, shall we push CM to COS directly? If I understood him correctly, we can simply file a new ticket under https://github.com/oasis-open-projects/administration/issues for CM COS today and they will take it from there.

What do you think? PGB members, are you in favour of that (there will be an SMV ballot so this is not a binding reply)?

Here is the milestone for the CM COS: https://github.com/oslc-op/oslc-specs/milestone/23. Can someone confirm that the one issue in that milestone is not blocking us from going to COS?

–Andrew






Re: Notification of the intent to publish RM 2.1 COS 01

Andrii Berezovskyi
 

Request for SMV opened at https://github.com/oasis-open-projects/administration/issues/19

--
Best regards,
Andrew

On 11 February 2021, at 18:13, Andrii Berezovskyi <andriib@...> wrote:

Dear PGB members,

The rules require us to notify you at least 14 days before submitting the ballots for the spec drafts publication. We are hereby notifying you of the OP intention to publish OSLC Requirements Management 2.1 Candidate OASIS Standard 01 in 2 weeks’ time.

Pull request with the draft: https://github.com/oslc-op/oslc-specs/pull/487 (ZIP file attached for your convenience)

Best regards,
Andrew Berezovskyi on behalf of the OSLC OP maintainers






<rm-2.1-cos01.zip>


Notification of the intent to publish RM 2.1 COS 01

Andrii Berezovskyi
 

Dear PGB members,

The rules require us to notify you at least 14 days before submitting the ballots for the spec drafts publication. We are hereby notifying you of the OP intention to publish OSLC Requirements Management 2.1 Candidate OASIS Standard 01 in 2 weeks’ time.

Pull request with the draft: https://github.com/oslc-op/oslc-specs/pull/487 (ZIP file attached for your convenience)

Best regards,
Andrew Berezovskyi on behalf of the OSLC OP maintainers


Re: OSLC Speaker for OSD Digital Engineering Working Group

Jane Harnad
 

Terrific. 

I'll send an email introducing them now. Thanks, Jane



On Sat, Feb 6, 2021 at 9:06 AM Andrii Berezovskyi <andriib@...> wrote:
Hello,

I have no objections to Axel giving a presentation, thank you Axel! I would also be glad to attend the workshop online and participate in the discussion as the co-chair of the PGB and Lyo project lead. Axel, will you reach out to Michael and Nancy?

Thanks Jane for reaching out!

--
Cheers,
Andrew

On 2021-02-05 , at 17:45, Axel Reichwein <axel.reichwein@...> wrote:

Hello Jane, 

I would be very happy to give this presentation on OSLC. I have done this kind of presentation very often.

Do the PBG members agree if I give it?

Best regards,
Axel



On Fri, Feb 5, 2021 at 6:30 AM Jane Harnad <jharnad@...> wrote:
Hi Everyone,

We received this speaker request. Is there anyone from the PGB that might be interested? I'd be happy to help. 

Please let me know. Thanks so much, Jane


---------- Forwarded message ---------
From: 'Gully, Michael J CIV USARMY HQDA ASA ALT (USA)' via Communications Alias<Communications@...>
Date: Wed, Feb 3, 2021 at 4:52 PM
Subject: OSLC Speaker for OSD Digital Engineering Working Group
To: communications@... <communications@...>
Cc: Bucher, Nancy M CIV USARMY HQDA ASA ALT (USA) <nancy.m.bucher.civ@...>


Hello,

 

I’m reaching out looking for a speaker to present the OSLC to the upcoming United States Department of Defense Digital Engineering Working Group in March 2021 (specific date TBD).  The special topic for the meeting is engineering data exchange and the Army believes a presentation from the OSLC would be an excellent fit.  

 

Please respond to myself or Dr. Nancy Bucher (cc’ed) to coordinate next steps.

 

Michael J Gully

Army Digital Engineering Co-Lead

ASA(ALT) Office of the Chief Systems Engineer 

(256) 808 9184 (M / Telework)

(703) 545-4738 (O - NCR)

(256) 313 6197 (O - HSV)

Michael.J.Gully2.civ@...

 





Re: OSLC Speaker for OSD Digital Engineering Working Group

Andrii Berezovskyi
 

Hello,

I have no objections to Axel giving a presentation, thank you Axel! I would also be glad to attend the workshop online and participate in the discussion as the co-chair of the PGB and Lyo project lead. Axel, will you reach out to Michael and Nancy?

Thanks Jane for reaching out!

--
Cheers,
Andrew

On 2021-02-05 , at 17:45, Axel Reichwein <axel.reichwein@...> wrote:

Hello Jane, 

I would be very happy to give this presentation on OSLC. I have done this kind of presentation very often.

Do the PBG members agree if I give it?

Best regards,
Axel



On Fri, Feb 5, 2021 at 6:30 AM Jane Harnad <jharnad@...> wrote:
Hi Everyone,

We received this speaker request. Is there anyone from the PGB that might be interested? I'd be happy to help. 

Please let me know. Thanks so much, Jane


---------- Forwarded message ---------
From: 'Gully, Michael J CIV USARMY HQDA ASA ALT (USA)' via Communications Alias<Communications@...>
Date: Wed, Feb 3, 2021 at 4:52 PM
Subject: OSLC Speaker for OSD Digital Engineering Working Group
To: communications@... <communications@...>
Cc: Bucher, Nancy M CIV USARMY HQDA ASA ALT (USA) <nancy.m.bucher.civ@...>


Hello,

 

I’m reaching out looking for a speaker to present the OSLC to the upcoming United States Department of Defense Digital Engineering Working Group in March 2021 (specific date TBD).  The special topic for the meeting is engineering data exchange and the Army believes a presentation from the OSLC would be an excellent fit.  

 

Please respond to myself or Dr. Nancy Bucher (cc’ed) to coordinate next steps.

 

Michael J Gully

Army Digital Engineering Co-Lead

ASA(ALT) Office of the Chief Systems Engineer 

(256) 808 9184 (M / Telework)

(703) 545-4738 (O - NCR)

(256) 313 6197 (O - HSV)

Michael.J.Gully2.civ@...

 





[Ietf-message-headers] OSLC-Core-Version header registration request

Andrii Berezovskyi
 

Dear OP members,

The OSLC-Core-Version header registration was initiated with IETF.

--
Best regards,
Andrew

Begin forwarded message:

From: Andrii Berezovskyi <andriib@...>
Subject: [Ietf-message-headers] OSLC-Core-Version header registration request
Date: W5 6 February 2021 at 13:38:41 CET

Hello,

OASIS Open Services for Lifecycle Collaboration (OSLC) Open Project (OP) would like to submit the following registration request:


Header field name: OSLC-Core-Version

Applicable protocol: http (RFC 2616 and its successors)

Status:
   standard (Project Specification 01 as per OASIS classification, has all the statements from the implementers to progress to the Candidate OASIS Standards once PS02 is published with the changes related to this registration request)

Author/Change controller:
   OASIS (can be Chet Ensign or the OASIS OSLC OP Project Governing Board (PGB) itself)

Specification document(s):
   https://docs.oasis-open-projects.org/oslc-op/core/v3.0/oslc-core.html (§4.2, Part 1, approved Project Specification 01)
   https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html (latest draft that will have to be voted on again once this registration request has been considered by IETF, contains ABNF as per the registration requirements)
   https://archive.open-services.net/bin/view/Main/OslcCoreSpecification#Specification_Versioning (spec that introduced the header)

Related information:
   OSLC-Core-Version header has been in active use by OSLC implementations since 2009.
   https://github.com/oslc-op/oslc-specs/issues/459
   This submission is made in preparation to progressing OSLC Core specification to the OASIS Standard stage (currently Project Specification stage has passed and Candidate OASIS Specification stage is next).


Answers to the considerations in https://tools.ietf.org/html/rfc7231#section-8.3:

1) Field is a single value.
2) The field can be used for both requests and responses; the spec defines the expected behaviour.
3) The header is not to be stored by the origin servers on PUT requests.
4) The semantics of the header only depend on whether a server or a client is sending it.
5) The header field is not hop-by-hop.
6) Intermediaries between OSLC servers and OSLC clients shall not insert or alter this header unless they are themselves OSLC servers or OSLC clients.
7) Yes, the header may be listed in the Vary header because the server may serve different content depending on the OSLC-Core-Version capability of the client.
8) No, the header is not generated dynamically and is not useful as a chunked trailer.
9) Yes, the header is to be preserved across redirects.
10) No private data is disclosed in the header. No security implications arise from this header alone as it only guides clients and servers on the version of the high-level protocol and is independent of the protocols that constitute a larger attack surface such as HTTP, TLS, oAuth. The attacker may infer from a value of a header that a certain feature is not supported by an old client or server (e.g. OSLC 2 uses oAuth 1.0 and OSLC 3 recommends OIDC 1.0). The attacker may also indirectly try to guess that an old client or server may run old software such as JDK 7 and use insecure settings due to a lack of new TLS version support etc. We don't think, however, that this header introduces any significant information for the attacked they could not gather on their own.

Thank you kindly for your time and the consideration of our application.

Best regards,
Andrew Berezovskyi

OSLC OP PGB co-chair


_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@...
https://www.ietf.org/mailman/listinfo/ietf-message-headers


Re: OSLC Speaker for OSD Digital Engineering Working Group

Axel Reichwein
 

Hello Jane, 

I would be very happy to give this presentation on OSLC. I have done this kind of presentation very often.

Do the PBG members agree if I give it?

Best regards,
Axel



On Fri, Feb 5, 2021 at 6:30 AM Jane Harnad <jharnad@...> wrote:
Hi Everyone,

We received this speaker request. Is there anyone from the PGB that might be interested? I'd be happy to help. 

Please let me know. Thanks so much, Jane


---------- Forwarded message ---------
From: 'Gully, Michael J CIV USARMY HQDA ASA ALT (USA)' via Communications Alias <Communications@...>
Date: Wed, Feb 3, 2021 at 4:52 PM
Subject: OSLC Speaker for OSD Digital Engineering Working Group
To: communications@... <communications@...>
Cc: Bucher, Nancy M CIV USARMY HQDA ASA ALT (USA) <nancy.m.bucher.civ@...>


Hello,

 

I’m reaching out looking for a speaker to present the OSLC to the upcoming United States Department of Defense Digital Engineering Working Group in March 2021 (specific date TBD).  The special topic for the meeting is engineering data exchange and the Army believes a presentation from the OSLC would be an excellent fit. 

 

Please respond to myself or Dr. Nancy Bucher (cc’ed) to coordinate next steps.

 

Michael J Gully

Army Digital Engineering Co-Lead

ASA(ALT) Office of the Chief Systems Engineer

(256) 808 9184 (M / Telework)

(703) 545-4738 (O - NCR)

(256) 313 6197 (O - HSV)

Michael.J.Gully2.civ@...

 


OSLC Speaker for OSD Digital Engineering Working Group

Jane Harnad
 

Hi Everyone,

We received this speaker request. Is there anyone from the PGB that might be interested? I'd be happy to help. 

Please let me know. Thanks so much, Jane


---------- Forwarded message ---------
From: 'Gully, Michael J CIV USARMY HQDA ASA ALT (USA)' via Communications Alias <Communications@...>
Date: Wed, Feb 3, 2021 at 4:52 PM
Subject: OSLC Speaker for OSD Digital Engineering Working Group
To: communications@... <communications@...>
Cc: Bucher, Nancy M CIV USARMY HQDA ASA ALT (USA) <nancy.m.bucher.civ@...>


Hello,

 

I’m reaching out looking for a speaker to present the OSLC to the upcoming United States Department of Defense Digital Engineering Working Group in March 2021 (specific date TBD).  The special topic for the meeting is engineering data exchange and the Army believes a presentation from the OSLC would be an excellent fit. 

 

Please respond to myself or Dr. Nancy Bucher (cc’ed) to coordinate next steps.

 

Michael J Gully

Army Digital Engineering Co-Lead

ASA(ALT) Office of the Chief Systems Engineer

(256) 808 9184 (M / Telework)

(703) 545-4738 (O - NCR)

(256) 313 6197 (O - HSV)

Michael.J.Gully2.civ@...

 


Re: OSLC Automation 2.1 PSD 01 ballot #poll-notice

Andrii Berezovskyi
 

Hello,

I hereby close this poll and declare this ballot passed with 3 votes YES and 1 abstained.

–Andrew


Re: OSLC Automation 2.1 PSD 01 ballot #poll-notice

Andrii Berezovskyi
 

Hi everyone,

My apologies for forgetting to open the ballot before Christmas. Please cast your vote.

Did you keep the minutes from January 7 call?

--
Cheers,
Andrew

On 2021-01-12 , at 16:21, Andrii Berezovskyi <andriib@...> wrote:

A new poll has been created:


Do the PGB members approve publishing OSLC Automation 2.1 as the PSD 01?

Release materials are located under https://github.com/oslc-op/oslc-specs/releases Intent to publish: https://lists.oasis-open-projects.org/g/oslc-op/message/427?p=,,,50,0,0,0::Created,,am,50,2,0,78714754

The ballot opens immediately and will close on January 19.

Best regards, Andrew Berezovskyi


1. YES, approve the publication
2. NO, reject the publication

Vote Now

Do not reply to this message to vote in the poll. You can vote in polls only through the group's website.



OSLC Automation 2.1 PSD 01 ballot #poll-notice

Andrii Berezovskyi
 

Do the PGB members approve publishing OSLC Automation 2.1 as the PSD 01?

Release materials are located under https://github.com/oslc-op/oslc-specs/releases Intent to publish: https://lists.oasis-open-projects.org/g/oslc-op/message/427?p=,,,50,0,0,0::Created,,am,50,2,0,78714754

The ballot opens immediately and will close on January 19.

Best regards, Andrew Berezovskyi

Results

See Who Responded


Re: [oslc-op] IBM Statements of Use for OASIS OSLC Core, CM, RM and AM Specifications

Andrii Berezovskyi
 

Thank you Jim,

This is fantastic news, we now have enough SoUs to begin working on Candidate OASiS Standard submissions.

--
Cheers,
Andrew

On 2020-12-04 , at 17:08, Jim Amsden <jamsden@...> wrote:

IBM is pleased to provide statements of use to the following OASIS OSLC Open Project specifications. 

IBM Statements of use: for OSLC Core Version 3.0 Project Specification


IBM has successfully implemented the OASIS OSLC Core Version 3.0 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/ps01/oslc-core.html dated 17 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically the Engineering Lifecycle Management suite of products, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.
Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 


IBM Statements of use: for OSLC Requirements Management Version 2.1


IBM has successfully implemented the OASIS OSLC Requirements Management Version 2.1 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/rm/v2.1/ps01/requirements-management-spec.html dated 03 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically DOORS Next, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.
Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 


IBM Statements of use: for OSLC Change Management Version 3.0


IBM has successfully implemented the OASIS OSLC Change Management Version 3.0 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/ps01/change-mgt-spec.html dated 17 September 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically Engineering Workflow Management, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.
Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 


IBM Statements of use: for OSLC Quality Management Version 2.1


IBM has successfully implemented the OASIS OSLC Quality Management Version 2.1 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/qm/v2.1/ps01/quality-management-spec.html dated 27 August 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations in the jazz.net applications, specifically Engineering Test Management, as well as integration with other 3rd party tools supporting this and other OSLC domain specifications.
Additionally, IBM jazz.net products include test suites covering the OSLC RM specification v2.0 that still conforms to the v2.1 specification and which can be used for ensuring backwards compatibility of the OSLC RM 2.1 tools according to the relevant conformance clauses. 


41 - 60 of 157