DICOM : Is this a valid Associate Response?

My application is Storage SCU. It pushes NM and CT instances to third party PACS. I am proposing four presentation context in my association (Associate Request). PACS is responding (Associate Response) like below:

Application Context:     DICOM Application Context Name
Implementation Class:    1.2........
Implementation Version:  XYZ
Maximum PDU Size:        32768
Called AE Title:         PACS
Calling AE Title:        MyApp
Presentation Contexts:   4
  Presentation Context:  1 [Accept]
      Abstract:  Nuclear Medicine Image Storage
      Transfer:  Explicit VR Little Endian
  Presentation Context:  3 [Reject - Transfer Syntaxes Not Supported]
      Abstract:  Nuclear Medicine Image Storage
      Transfer:  JPEG 2000 Lossy
  Presentation Context:  5 [Proposed]
      Abstract:  CT Image Storage
      Transfer:  Explicit VR Little Endian
  Presentation Context:  7 [Reject - Transfer Syntaxes Not Supported]
      Abstract:  CT Image Storage
      Transfer:  JPEG 2000 Lossy

Second and fourth (id 3 and 7) presentation context is rejected as expected. PACS DICOM Conformance statement states that it does not support that transfer syntax.

First (id 1) presentation context is accepted as expected.

Look at third (id 5) presentation context. It's status says [Proposed].

In my understanding, PACS should either accept the presentation context or reject it. It must not keep the status [Proposed] as is which was set by SCU i.e. my application.

Is my understanding correct?
I am looking in to specifications to find something concluding; no success so far. Please point me to the location in specifications where this is explained.

Edit 1:

PS 3.7-2011 - Message Exchange
D.3.2 Presentation contexts negotiation

c. the Association-acceptor may accept or reject each Presentation Context individually.

Look at the may in specifications. What does this mean? Is it up to the SCP to "accept or reject (or leave as is i.e. [proposed])" the status?

Solution

"Proposed" means that the SCP didn't include in the reply the abstract syntax with the proper code:

0 acceptance
1 user-rejection
2 no-reason (provider rejection)
3 abstract-syntax-not-supported (provider rejection)
4 transfer-syntaxes-not-supported (provider rejection)

Therefore DCMTK leaves in the abstract syntax the original status of "Not yet negotiated" (printed as "proposed" in the logs).

In DCMTK this status is represented by the constant ASC_P_NOTYETNEGOTIATED.

It looks like the SCP is to blame here