5  Tổng quan về giao thức

5.1  Cung cấp dịch vụ

Giao thức được quy định trong tiêu chuẩn này cung cấp các dịch vụ được quy định trong ISO 10160. Các dịch vụ này được nêu trong Bảng 1.

Bảng 1 - Các dịch vụ ILL

Dịch vụ

Kiểu

YÊU CẦU ILL (ILL-REQUEST)

chưa được xác nhận

CHUYỂN TIẾP (FORWARD)

...

...

...

THÔNG BÁO CHUYỂN TIẾP (FORWARD- NOTIFICATION)

nhà cung cấp khởi tạo

ĐÃ CHUYỂN (SHIPPED)

chưa được xác nhận

TRẢ LỜI ILL (ILL-ANSWER)

chưa được xác nhận

TRẢ LỜI ĐIỀU KIỆN (CONDITONAL-REPLY)

chưa được xác nhận

HỦY (CANCEL)

...

...

...

TRẢ LỜI HỦY (CANCEL- REPLY)

chưa được xác nhận

ĐÃ NHẬN (RECEIVED)

chưa được xác nhận

ĐÒI/YÊU CẦU LẠI (RECALL)

chưa được xác nhận

ĐÃ TRẢ LẠI (RETURNED)

chưa được xác nhận

KIỂM NHẬN (CHECKED-IN)

...

...

...

QUÁ HẠN (OVERDUE)

chưa được xác nhận

GIA HẠN (RENEW)

chưa được xác nhận

TRẢ LỜI GIA HẠN (RENEW-ANSWER)

chưa được xác nhận

ĐÃ MẤT (LOST)

chưa được xác nhận

ĐÃ BỊ HƯ HẠI (DAMAGED)

...

...

...

THÔNG BÁO (MESSEAGE)

chưa được xác nhận

HỎI TÌNH TRẠNG (STATUS-QUERY)

chưa được xác nhận

BÁO CÁO TÌNH TRẠNG HOẶC LỖI (STATUS-OR-ERROR-REPORT)

chưa được xác nhận

HẾT HẠN (EXPIRY)

người cung cấp ban đầu

5.2  Dịch vụ hỗ trợ giả định

...

...

...

5.3  Mô hình

Về lý thuyết, hoạt động của giao thức ILL được mô hình hóa bởi sự tương tác của các máy tính giao thức ILL (ILLPM). Các ILLPM truyền thông bằng cách trao đổi các APDU ILL thông qua việc sử dụng các dịch vụ trừu tượng "gửi APDU" và "nhận APDU" tại ranh giới thấp hơn của chúng. Tại ranh giới cao hơn của chúng, các ILLPM cung cấp các dịch vụ được quy định trong ISO 10160.

Một ILLPM được điều khiển bởi việc tiếp nhận các sự kiện đầu vào từ người sử dụng dịch vụ ILL, hỗ trợ các nhà cung cấp dịch vụ hoặc từ một bộ đếm thời gian nội bộ. Các sự kiện đầu vào từ người sử dụng dịch vụ ILL là yêu cầu ban đầu và từ các dịch vụ hỗ trợ ILL là APDU nhận được. Sự kiện đầu vào từ bộ đếm thời gian nội bộ là bộ đếm thời gian hết hạn.

Một ILLPM trả lời các sự kiện đầu vào bằng cách đưa ra các sự kiện đầu ra cho dịch vụ hỗ trợ của nó và đến người sử dụng dịch vụ ILL của mình. Các sự kiện đầu ra cho dịch vụ hỗ trợ là việc gửi các APDU ILL. Các sự kiện đầu ra tới người sử dụng dịch vụ ILL của nó là các chỉ dẫn cơ bản ILL.

Việc nhận một sự kiện đầu vào, tạo ra những hành động phụ thuộc, và sự kiện đầu ra kết quả được coi là một hành động không thể tách riêng.

Về logic mỗi giao dịch ILL sẽ khởi tạo một tập ILLPM tương ứng riêng biệt. Những lệnh gọi này duy trì thông tin trạng thái cho một giao dịch ILL nhất định. Vòng đời của một lệnh gọi ILLPM dài như cần thiết để hoàn tất giao dịch ILL liên quan. Thông tin trạng thái này phải được lưu trữ bảo toàn trong tất cả các trường hợp sử dụng các dịch vụ hỗ trợ, ví dụ, nó phải được duy trì riêng biệt với mọi thông tin trạng thái liên quan đến các liên kết ứng dụng tiềm ẩn. Nhiều giao dịch ILL, và vì thế nhiều ILLPM, có thể cùng tồn tại.

Máy tính giao thức ILL kỳ vọng rằng các APDU của nó sẽ được chuyển giao đáng tin cậy không mất, thay đổi hoặc bổ sung bất kỳ thông tin nào. Nó cho phép các APDU lặp lại. Giao thức này cho phép lặp lại yêu cầu dịch vụ do người sử dụng khởi xướng để khôi phục lại mất mát, sai sót hoặc các APDU bị thay đổi. Các cơ chế theo đó những vấn đề như vậy được phát hiện và người dùng được thông báo nằm ngoài phạm vi của đặc tả này.

6  Đơn vị dữ liệu của giao thức ứng dụng ILL (APDU ILL)

APDU ILL là một đơn vị thông tin truyền qua giữa hai ASE ILL ngang hàng tham gia vào một giao dịch ILL. Điều khoản này liệt kê các APDU được sử dụng trong ứng dụng ILL và mô tả việc sử dụng và ý nghĩa của những APDU này.

...

...

...

được sử dụng bởi bên yêu cầu để yêu cầu mượn, vị trí, hoặc một bản sao của một tài liệu hoặc dự toán chi phí cho một dịch vụ từ một thư viện.

THÔNG BÁO CHUYỂN TIẾP

được sử dụng bởi các nhà cung cấp dịch vụ để thông báo cho bên yêu cầu rằng yêu cầu của họ đã được chuyển tiếp, và người nhận chuyển tiếp.

YÊU CẦU ILL

được sử dụng bởi bên yêu cầu để yêu cầu mượn, vị trí, hoặc một bản sao của một tài liệu hoặc dự toán chi phí cho một dịch vụ từ một thư viện.

VẬN CHUYỂN

được sử dụng bởi những người đáp ứng để cho biết rằng một tài liệu đã được vận chuyển.

TRẢ LỜI ILL

được sử dụng bởi bên đáp ứng để gửi một trả lời cho bên yêu cầu (trả lời có thể là: Điều kiện, Thực hiện lại, Không hoàn tất, Cung cấp địa điểm, Sẽ cung cấp, Đặt giữ và Đánh giá).

...

...

...

được sử dụng bởi bên yêu cầu để trả lời một Câu trả lời ILL với một trạng thái có điều kiện. Câu trả lời có thể là có (chúng tôi sẽ đáp ứng các điều kiện này) và không (chúng tôi không đồng ý đáp ứng các điều kiện này).

HỦY

được sử dụng bởi bên yêu cầu để bắt đầu hủy bỏ một giao dịch ILL

TRẢ LỜI HỦY

được sử dụng bởi người đáp ứng để đáp lại yêu cầu hủy.

ĐÃ NHẬN

được sử dụng bởi bên yêu cầu để cho biết đã nhận được một tài liệu

ĐÒI

được sử dụng bởi các bên đáp ứng để yêu cầu trả lại ngay một tài liệu

...

...

...

được sử dụng bởi bên yêu cầu để cho biết một tài liệu mượn đã được trả.

KIỂM NHẬN

được sử dụng bởi bên đáp ứng để xác nhận tài liệu mượn đã được trả

QUÁ HẠN

được sử dụng bởi bên đáp ứng để thông báo cho bên yêu cầu có một tài liệu quá hạn.

GIA HẠN

được sử dụng bởi bên yêu cầu để yêu cầu gia hạn một tài liệu mượn.

TRẢ LỜI GIA HẠN

được sử dụng bởi bên đáp ứng để đáp lại một yêu cầu gia hạn.

...

...

...

được sử dụng bởi một trong hai bên bên yêu cầu hoặc bên đáp ứng để thông báo cho bên kia một tài liệu đã bị mất.

HƯ HẠI

được sử dụng bởi một trong hai bên bên yêu cầu hoặc bên đáp ứng để thông báo cho bên kia một tài liệu đã bị hư hại.

THÔNG BÁO

được sử dụng bởi một trong hai bên bên yêu cầu hoặc bên đáp ứng để thông báo cho bên kia mà không ảnh hưởng đến trạng thái của giao dịch ILL

CÂU HỎI VỀ TRẠNG THÁI

được sử dụng bởi một trong hai bên bên yêu cầu hoặc của bên đáp ứng để thông báo về hiện trạng của giao dịch ILL ở xa

BÁO CÁO TRẠNG THÁI HOẶC LỖI

được sử dụng bởi một trong hai bên bên yêu cầu hoặc bên đáp ứng để thông báo về hiện trạng và bất kỳ thông tin liên quan nào sẵn có, hoặc để báo cáo một điều kiện lỗi của giao dịch ILL

...

...

...

được sử dụng bởi hệ thống của bên đáp ứng để thông báo cho bên yêu cầu hết hạn giao dịch ILL. Việc gửi APDU này được khởi xướng bởi người cung cấp dịch vụ ILL chứ không phải bởi người sử dụng dịch vụ.

7  Thông tin giao dịch

Hệ thống ILL phải duy trì các thông tin sau cho mỗi giao dịch ILL:

- Nhận dạng giao dịch;

- Trạng thái giao thức;

- Các biến giao thức;

- Bộ đếm thời gian hết hạn;

- Thông tin yêu cầu;

- Thông tin lịch sử.

...

...

...

APDU ILL hoặc dịch vụ ban đầu được kết hợp với một giao dịch ILL bằng một id giao dịch.

Id giao dịch đáp ứng các yêu cầu sau đây:

a) tính duy nhất trong trường hợp tổ chức theo chuỗi và phân khu;

b) cho phép các giao dịch con liên kết với giao dịch ILL chính;

c) cho phép nhiều giao dịch ILL liên kết với nhau thành một nhóm logic, ví dụ khi bên yêu cầu chuyển một yêu cầu ILL đến nhiều bên đáp ứng lần lượt; hoặc việc Lặp lại được liên kết đến yêu cầu ILL gốc.

Giao dịch bao gồm các thành phần sau:

Nhận dạng (ID) bên yêu cầu ban đầu (tùy chọn)

xác định người khởi xướng giao dịch ILL;

Dấu hạn định nhóm giao dịch (bắt buộc)

...

...

...

Dấu hạn định giao dịch (bắt buộc)

phân biệt một giao dịch ILL từ tất cả các giao dịch ILL khác trong một nhóm giao dịch ILL;

Dấu hạn định giao dịch con (tùy chọn)

phân biệt một giao dịch con từ tất cả các giao dịch con khác được khởi xướng bởi người trung gian

Bảng 2 tóm tắt việc sử dụng các thành phần của id giao dịch cho một giao dịch đơn giản. Bảng 3 liên kết đến một giao dịch theo chuỗi hoặc phân khu.

Bảng 2 - Các thành phần của id giao dịch

Giao dịch đơn giản

Id bên yêu cầu ban đầu

Dấu hạn định nhóm giao dịch

...

...

...

Dấu hạn định giao dịch con

Tùy chọn

Khai báo bởi bên yêu cầu

Bắt buộc

Khai báo bởi bên yêu cầu

Bắt buộc

Khai báo bởi bên yêu cầu

Không sử dụng

Bảng 3- Giao dịch theo chuỗi hoặc phân khu

...

...

...

Id bên yêu cầu ban đầu

Dấu hạn định nhóm giao dịch

Dấu hạn định giao dịch

Dấu hạn định giao dịch con

Bắt buộc

Khai báo bởi người trung gian

Bắt buộc

Khai báo bởi bên yêu cầu

Bắt buộc

...

...

...

Bắt buộc

Khai báo bởi người trung gian

Id bên yêu cầu ban đầu xác định người khởi xướng giao dịch ILL.id bên yêu cầu ban đầu có thể lấy bất kỳ biểu tượng đại diện nào như được xác định trong 7.5.1 để sử dụng làm id hệ thống, nhưng nếu sử dụng biểu tượng đại diện cho cá nhân hoặc tập thể, thì khi đó giao dịch ILL sẽ bị hạn chế và chỉ có thể thực hiện trong vùng có thể nhận diện rõ biểu tượng đại diện, ví dụ: trong một quốc gia. Nếu người trung gian gán giá trị cho thành phần này thì giá trị đó phải trùng với "id bên yêu cầu" trong YÊU CẦU ILL ban đầu.

CHÚ THÍCH: Các thành phần bên trong của id bên yêu cầu có thể cần phải được xác định rõ hơn trong một định nghĩa diện ứng dụng.

Đối với một giao dịch ILL hai bên đơn giản, thành phần id bên yêu cầu ban đầu không cần phải được đưa vào như một phần của id giao dịch vì thông tin này đã có sẵn trong loại id bên yêu cầu của APDU YÊU CẦU-ILL đó. Tuy nhiên, nếu id bên yêu cầu ban đầu hiện diện trong một APDU YÊU CẦU-ILL, thì nó phải đưa ra cùng một giá trị trong tất cả các thông báo khác có liên quan với giao dịch ILL. Ngoài ra, dấu hạn định giao dịch con là không cần thiết.

Dấu hạn định nhóm giao dịch là một thành phần bắt buộc của id giao dịch. Dấu này là duy nhất trong phạm vi của bên yêu cầu ban đầu. Bên yêu cầu ban đầu, có trách nhiệm gán các trị cho dấu hạn định này để đáp ứng quy tắc này. Chỉ được tái sử dụng dấu hạn định nhóm giao dịch khi tất cả các giao dịch ILL trong nhóm đã ngừng hoạt động và ít khả năng có giao dịch mới được khởi xướng liên quan đến các giao dịch của nhóm. Dấu hạn định có thể được sử dụng để liên kết nhiều giao dịch ILL, ví dụ trong trường hợp tham chiếu hay muốn phân biệt các lần thử lại giao dịch với các giao dịch ILL gốc.

Dấu hạn định giao dịch xác định duy nhất một giao dịch ILL trong một nhóm giao dịch. Dấu hạn định giao dịch là thành phần bắt buộc của một id giao dịch.

Đối với một giao dịch con, tất cả các thành phần đều cần thiết. Id bên yêu cầu ban đầu cùng với dấu hạn định nhóm giao dịch và dấu hạn định giao dịch đảm bảo rằng giao dịch ILL là duy nhất trong miền đơn trị của id bên yêu cầu ban đầu. Dấu hạn định giao dịch con cùng với thông tin id bên yêu cầu được chuyển vào một APDU YÊU CẦU-ILL của giao dịch con đảm bảo tính duy nhất của giao dịch con.

Trong trường hợp các giao dịch ILL theo chuỗi, có thể có một chuỗi các giao dịch con được liên kết trong một chuỗi. Trong trường hợp này, mỗi giao dịch con được coi là một giao dịch con của giao dịch ILL gốc, vì vậy mỗi người trung gian khởi tạo một giao dịch con mới thay thế dấu hạn định giao dịch con hiện tại bằng một dấu mới là duy nhất trong phạm vi của người trung gian này. Tất cả các giao dịch con của một giao dịch ILL cụ thể được phân biệt trên cơ sở sự kết hợp của id giao dịch và id bên yêu cầu.

...

...

...

Các trạng thái giao thức giống hệt như các trạng thái giao dịch ILL được xác định trong định nghĩa dịch vụ ILL.

7.2.1  Trạng thái bên yêu cầu

Trạng thái bên yêu cầu là trạng thái xử lý của một giao dịch ILL ở bên yêu cầu. Nó có thể là một trong những trường hợp sau:

NHÀN RỖI

Giao dịch ILL chưa bắt đầu.

ĐANG CHỜ

Đã thực hiện một yêu cầu và đợi tài liệu từ bên đáp ứng; hoặc đã nhận một thông báo cho biết tài liệu sẽ được cung cấp hoặc đã được đặt giữ; hoặc cho biết yêu cầu đã được chuyển tiếp đến cơ quan khác.

KHÔNG CUNG CẤP

Giao dịch ILL đã đạt đến một giai đoạn mà yêu cầu không thể được thực hiện bởi người đáp ứng.

...

...

...

Giao dịch ILL đã đạt đến một giai đoạn mà yêu cầu chỉ có thể được thực hiện nếu bên yêu cầu đồng ý đáp ứng các điều kiện cụ thể.

ĐANG CHỜ HỦY

Bên yêu cầu đã bắt đầu hủy giao dịch ILL nhưng không nhận được phản hồi từ bên đáp ứng

ĐÃ HỦY

Giao dịch ILL đã được hủy bởi bên đáp ứng

ĐÃ CHUYỂN

Tài liệu đã được chuyển đi cho bên yêu cầu.

ĐÃ NHẬN

Tài liệu đã được nhận từ bên đáp ứng

...

...

...

Một yêu cầu đã được thực hiện để gia hạn tài liệu.

GIA HẠN/QUÁ HẠN

Một yêu cầu đã được thực hiện để gia hạn cho một tài liệu đã quá hạn.

QUÁ HẠN

Bên yêu cầu đã được thông báo rằng tài liệu đã quá hạn.

KHÔNG NHẬN ĐƯỢC/QUÁ HẠN

Bên đáp ứng đã gửi thông báo quá hạn cho một tài liệu chưa được nhận.

ĐÒI

Tài liệu đã bị bên đáp ứng đòi lại.

...

...

...

Tài liệu đã được chuyển lại cho bên đáp ứng

MẤT

Tài liệu đã bị mất

7.2.2  Trạng thái bên đáp ứng

Trạng thái bên đáp ứng là trạng thái xử lý một giao dịch ILL ở bên đáp ứng. Trạng thái bên đáp ứng có thể là một trong những trường hợp sau:

NHÀN RỖI (IDLE)

Người đáp ứng đã không nhận được yêu cầu.

ĐANG XỬ LÝ

Bên đáp ứng đã nhận được và đang xử lý yêu cầu; tài liệu chưa được gửi đi.

...

...

...

Yêu cầu đã được chuyển tiếp cho tổ chức khác.

KHÔNG CUNG CẤP

Bên đáp ứng phản hồi lại một yêu cầu bằng một TRẢ LỜI-ILL của THỬ LẠI, KHÔNG THỂ ĐÁP ỨNG. CUNG CẤP-ĐỊA ĐIỂM, DỰ TOÁN; hoặc giao dịch ILL đã hết hạn.

ĐIỀU KIỆN

Các yêu cầu chỉ có thể được thực hiện nếu bên yêu cầu đồng ý đáp ứng các điều kiện quy định.

ĐANG CHỜ HỦY

Bên yêu cầu đã bắt đầu hủy giao dịch ILL nhưng không có phản hồi từ bên đáp ứng

ĐÃ HỦY

Giao dịch ILL đã bị hủy bởi bên đáp ứng.

...

...

...

Tài liệu đã được chuyển đi cho bên yêu cầu.

GIA HẠN/ĐANG CHỜ

Một yêu cầu đã được thực hiện để gia hạn tài liệu.

GIA HẠN/QUÁ HẠN

Một yêu cầu đã được thực hiện để gia hạn cho tài liệu quá hạn.

QUÁ HẠN

Bên đáp ứng đã thông báo cho bên yêu cầu về tài liệu quá hạn.

ĐÒI

Tài liệu đã bị đòi lại bởi bên đáp ứng.

...

...

...

Tài liệu đã được nhận lại từ bên yêu cầu.

MẤT

Tài liệu đã bị mất.

7.2.3  Trạng thái thiết bị đầu cuối

Đối với bên yêu cầu, bên đáp ứng và người trung gian, có những trạng thái nhất định, được gọi là trạng thái thiết bị đầu cuối, khi đạt tới, sẽ không dẫn đến bất kỳ chuyển tiếp nào nữa cho một giao dịch ILL xác định. Ngoại lệ duy nhất là quá trình chuyển đổi sang một trạng thái thiết bị đầu cuối khác.

Giao dịch ILL thông thường sẽ được duy trì ở trạng thái thiết bị đầu cuối trong một khoảng thời gian nhất định trước khi thông tin giao dịch ILL không thể tiếp cận với các điểm ngang hàng hoặc bị xóa. Khoảng thời gian này do bên triển khai quyết định hoặc thỏa thuận quản lý cục bộ. Tuy nhiên, lưu ý rằng yêu cầu đáp ứng TRUY VẤN TRẠNG THÁI, và yêu cầu chuyển tiếp các thông báo chỉ ra rằng khoảng thời gian này phải đủ dài để có thể truy cập thông tin về thời gian mượn tối đa cộng, thời gian gia hạn và thời gian chuyển phát. Đối với các tài liệu không được trả lại, khoảng thời gian này phải đủ để bên yêu cầu xác định được tài liệu yêu cầu và khởi tạo một dịch vụ truy vấn-trạng thái hoặc Mất.

Các trạng thái thiết bị đầu cuối có thể cho bên yêu cầu là:

- KHÔNG-CUNG CẤP;

- ĐÃ HỦY;

...

...

...

- ĐÃ TRẢ;

- MẤT

Các trạng thái thiết bị đầu cuối có thể cho bên đáp ứng là:

- KHÔNG-CUNG CẤP;

- ĐÃ HỦY;

- CHUYỂN TIẾP;

- ĐÃ CHUYỂN ĐI (nếu một tài liệu không trả phải được chuyển đi);

- ĐÃ KIỂM NHẬN;

- MẤT

...

...

...

Các trạng thái thiết bị đầu cuối có thể cho người trung gian là:

- KHÔNG-CUNG CẤP;

- CHUYỂN TIẾP;

- ĐÃ HỦY

ĐÃ CHUYỂN ĐI

7.2.4  Trạng thái người trung gian

Người trung gian tham gia vào một giao dịch ILL theo chuỗi hoặc phân khu đóng cả hai vai trò vừa là bên đáp ứng (trong các tương tác với bên yêu cầu) và vừa là bên yêu cầu (trong các tương tác với bên đáp ứng). Người trung gian duy trì thông tin trạng thái riêng biệt cho mỗi một bộ các tương tác này.

Đối với các giao dịch con không thành công, các trạng thái thiết bị đầu cuối cho bên yêu cầu trung gian là KHÔNG-CUNG CẤP và HỦY; cho bên đáp ứng trung gian là KHÔNG-CUNG CẤP, HỦY; CHUYỂN TIẾP.

Đối với một giao dịch ILL thành công, trạng thái thiết bị đầu cuối cho một người trung gian trong cả hai vai trò của bên yêu cầu và bên đáp ứng là trạng thái ĐÃ CHUYỂN.

...

...

...

Các biến giao thức sau đây ảnh hưởng đến trạng thái giao thức ILL. Các biến này được duy trì bởi các ILLPM và được đặt theo các thông số của các dịch vụ ban đầu hoặc nhận các APDU. Người trung gian duy trì các biến giao thức riêng thích hợp phân ra cho từng vai trò của bên yêu cầu và bên đáp ứng.

TRẢ (RETURN)

sử dụng để chỉ ra một tài liệu đã vận chuyển phải được trả lại cho bên đáp ứng. Nó nhận các giá trị TRUE (ĐÚNG) hoặc FALSE (SAI)

CHUYỂN TIẾP (FWD)

sử dụng để thông báo bên đáp ứng có thể chuyển tiếp một yêu cầu hay không. Thông báo nhận TRUE (ĐÚNG) hoặc FALSE (SAI)

PHÂN KHU (PART)

được sử dụng bởi một người trung gian để chỉ ra một giao dịch ILL có thể được hoặc đã được phân khu. Biến này nhận các giá trị TRUE (ĐÚNG) hoặc FALSE (SAI)

CHUỖI (CHAIN)

được sử dụng bởi một người trung gian để cho biết một giao dịch ILL có thể được hoặc đã được thực hiện theo chuỗi. Chuỗi nhận các giá trị TRUE (ĐÚNG) hoặc FALSE (SAI)

...

...

...

dùng để lưu giữ dấu thời gian của APDU nhận cuối cùng. Biến này được đặt theo kiểu giá trị "Ngày-và-thời-gian-của-dịch vụ", trong APDU nhận được, và dùng để phát hiện các APDU không tuần tự

DẤU THỜI GIAN LẶP LẠI (REPEAT-TIME-STAMP)

dùng để lưu dấu thời gian của APDU nhận cuối cùng đã gây ra thay đổi trạng thái. Biến này được đặt theo kiểu giá trị "Ngày-và-thời-gian-của-dịch vụ", hoặc nếu APDU này bị lặp, thì biến giao thức được đặt theo kiểu giá trị "Ngày và thời gian của dịch vụ ban đầu".

ID ĐỐI TÁC HIỆN TẠI (CURRENT-PARTNER-ID)

dùng để lưu giữ nhận dạng đối tác hiện thời cho giao dịch ILL với mục đích xác nhận tuần tự APDU. Đối với bên yêu cầu, biến này ban đầu được đặt cho giá trị tham số "nhận dạng bên đáp ứng" trong một dịch vụ ban đầu YÊU CẦU ILL, sau đó mới được cập nhật vào giá trị "Nhận dạng bên đáp ứng" trong APDU nhận được khi giá trị này không trùng khớp với giá trị id đối tác hiện thời và cũng không phải là một trong các giá trị ID-ĐỐI TÁC-TRƯỚC ĐÓ. Tương tự đối với bên đáp ứng, biến này ban đầu được đặt cho trường giá trị "id bên yêu cầu" trong APDU Yêu cầu ILL và sau đó cập nhật vào giá trị cùng trường này trong các APDU tiếp theo.

ID CỦA CÁC ĐỐI TÁC TRƯỚC ĐÂY (PREVIOUS PARTNER-IDS)

dùng để lưu giữ nhận dạng các đối tác trước đây cho giao dịch ILL. Bất kỳ khi giá trị id đối tác hiện thời nào thay đổi, giá trị trước đó sẽ được thêm vào biến giao thức này. Vì việc nhận dạng đối tác hiện thời có thể thay đổi nhiều hơn một lần trong quá trình của một giao dịch ILL, ví dụ là kết quả của nhiều tình huống chuyển tiếp, biến giao thức này có thể bao gồm một chuỗi các giá trị.

7.4  Bộ đếm thời gian hết hạn

Bộ đếm thời gian sau đây phải được duy trì bởi bên đáp ứng nếu nó hỗ trợ dịch vụ HẾT HẠN:

...

...

...

Thông tin này được cung cấp bởi bên yêu cầu trong Yêu cầu ILL.

7.5  Thông tin yêu cầu

Toàn bộ nội dung của YÊU CẦU- ILL ban đầu phải được lưu giữ để hỗ trợ chuyển tiếp, phân khu và tổ chức xâu chuỗi giao dịch ILL. Tuy nhiên người trung gian có thể thay đổi nội dung của một Yêu cầu ILL khi yêu cầu được chuyển tiếp hoặc một giao dịch con được khởi xướng. Ví dụ, có thể sửa thông tin thư mục được cung cấp, hoặc có thể thay đổi Cho phép tổ chức chuỗi thành SAI trong một giao dịch con khi giá trị của YÊU CẦU ILL ban đầu là ĐÚNG.

Người trung gian phải luôn thay đổi giá trị id bên yêu cầu thành id riêng của mình khi một giao dịch con được khởi xướng. Lưu ý rằng danh tính của bên yêu cầu ban đầu được lưu giữ trong id giao dịch.

7.5.1  ID hệ thống

Thông tin Yêu cầu ILL bao gồm việc nhận dạng bên yêu cầu và bên đáp ứng, cả hai đều là loại id hệ thống, trong đó bao gồm một hoặc nhiều các thành phần sau:

Biểu tượng cá nhân hoặc tổ chức

một hoặc nhiều số, chữ cái hoặc mã dùng để xác định một cách rõ ràng bên đáp ứng, trong một định dạng viết tắt một cá nhân hoặc tổ chức tham gia vào một yêu cầu ILL.

Tên cá nhân hoặc tổ chức

...

...

...

Biểu tượng cá nhân hoặc tổ chức có thể có cấu trúc nội bộ, ví dụ để chỉ ra liên kết của một tổ chức với một dịch vụ đặc biệt, liên hiệp v.v, hoặc để xác định máy trạm cá nhân (ví dụ các quy trình ứng dụng) trong một tổ chức. Bất kỳ cấu trúc nào như vậy nằm ngoài phạm vi của tiêu chuẩn này và thuộc trách nhiệm của các cơ quan chức năng.

Do phạm vi của biểu tượng cá nhân hoặc tổ chức có hạn, các giao dịch ILL chỉ sử dụng thông tin này như một phần của id hệ thống được hạn chế hoạt động chỉ trong miền của biểu tượng này. Các giao dịch ILL liên quan đến cá nhân hay tổ chức bên ngoài miền đó phải bao gồm "tên cá nhân hoặc tổ chức" như một phần của id hệ thống.

Tên cá nhân hoặc tổ chức đại diện cho một mô tả dạng tự do của tên người hoặc tên tổ chức.

Bên yêu cầu và người đáp ứng cần sử dụng một id hệ thống có giá trị không đổi trong suốt một giao dịch ILL. Như vậy, nếu chỉ có biểu tượng tên cá nhân hoặc tổ chức được gán ban đầu bởi bên yêu cầu, thì sau đó chỉ có một biểu tượng sẽ được sử dụng và giá trị của biểu tượng này sẽ không thay đổi. Nếu cả biểu tượng tên cá nhân và tổ chức và tên cá nhân hoặc tổ chức được gán ban đầu bởi bên yêu cầu, thì cả biểu tượng và tên được sử dụng sau này và giá trị của biểu tượng và tên này không thay đổi.

7.6  Thông tin lịch sử

Các thông tin lịch sử bổ sung sau đây được cung cấp như một phần của BÁO CÁO-TÌNH-TRẠNG- HOẶC-LỖI cho giao dịch ILL đang diễn ra và, do đó, cần duy trì trong suốt vòng đời của giao dịch ILL:

- Ngày tháng diễn tiến cuối cùng;

- Dịch vụ gần đây nhất;

- Ngày tháng của dịch vụ gần đây nhất;

...

...

...

- Loại dịch vụ vận chuyển;

- Kết quả giao dịch;

- Chú thích dịch vụ gần đây nhất.

"Dịch vụ gần đây nhất" chỉ dịch vụ gốc ILL nào đã được gọi lần cuối cùng hay APDU (dấu hiệu) cuối cùng nhận được bởi người sử dụng dịch vụ ILL này. Các dấu hiệu dịch vụ không hợp lệ/ ngoài luồng phải được xem là dấu hiệu dịch vụ hợp lệ cho mục đích của thành phần "dịch vụ gần đây nhất" của báo cáo lịch sử. Một ngoại lệ là khi một BÁO CÁO TÌNH TRẠNG hoặc LỖI được gửi để đáp ứng một Yêu cầu trạng thái, trong trường hợp này "dịch vụ gần đây nhất " là một dịch vụ trước YÊU CẦU TRẠNG THÁI.

"Ngày tháng của Dịch vụ gần đây nhất" cho biết ngày tháng của "dịch vụ gần đây nhất"

"Người khởi xướng dịch vụ gần đây nhất" xác định bên yêu cầu hoặc bên đáp ứng khởi xướng dịch vụ gần đây nhất.

"Loại dịch vụ chuyển đi" phải phản ánh các thông tin mới nhất trong tham số "loại dịch vụ chuyển đi" từ dịch vụ ĐÃ CHUYỂN hoặc ĐÃ NHẬN hoặc từ APDU ĐÃ CHUYỂN hoặc ĐÃ NHẬN, ví dụ nếu bên yêu cầu đã nhận được một APDU ĐÃ CHUYỂN và sau đó thực hiện một yêu cầu ĐÃ NHẬN, thì lúc này, cần sử dụng giá trị trong yêu cầu ĐÃ NHẬN. Thông tin này có thể không có sẵn cho tất cả các giao dịch ILL.

"Các kết quả giao dịch" cần phản ánh giá trị của tham số "kết quả giao dịch" chứa trong Trả lời ILL. Thông tin này có thể không có sẵn cho tất cả các giao dịch ILL.

"Chú thích dịch vụ gần đây nhất" cung cấp nội dung của các tham số Chú thích từ dịch vụ gốc gần đây nhất.

...

...

...

8  Các yếu tố của thủ tục

8.1  Sự kiện và hành động

Khoản này mô tả các sự kiện và hành động cho một giao dịch ILL đơn lẻ. Bên yêu cầu, bên đáp ứng và người trung gian phải phản ứng với các sự kiện khác nhau bằng việc thực hiện những hành động cụ thể. Một sự kiện được định nghĩa là việc nhận một APDU từ một ASE ILL hoặc nhận một dịch vụ gốc từ người sử dụng dịch vụ ILL cục bộ. Một hành động có thể dưới hình thức đưa ra một dịch vụ gốc cho người sử dụng dịch vụ ILL cục bộ, hoặc truyền tải một hoặc nhiều APDU cho một ASE ILL ở xa.

Các mục sau đây xác định các sự kiện và hành động được phép đối với bên yêu cầu, bên đáp ứng và người trung gian và những gì có thể được hiểu ngầm là không được phép.

8.1.1  Sự kiện của bên yêu cầu

Khoản này mô tả các sự kiện được phép đối với một bên yêu cầu.

Các sự kiện liên quan đến yêu cầu dịch vụ gốc từ người sử dụng dịch vụ ILL sau đây:

- YÊU CẦU-ILL. yêu cầu

- TRẢ LỜI-CÓ ĐIỀU KIỆN: yêu cầu

...

...

...

- TRẢ LỜI-CÓ ĐIỀU KIỆN: yêu cầu

Trả lời = KHÔNG

- HỦY-YÊU CẦU

- ĐÃ NHẬN. yêu cầu

- ĐÃ TRẢ. yêu cầu

- GIA HẠN. yêu cầu

- HỦY. yêu cầu

- HƯ HẠI. yêu cầu

- THÔNG BÁO. yêu cầu

...

...

...

- BÁO CÁO TRẠNG THÁI HOẶC LỖI. yêu cầu

Các sự kiện liên quan đến các APDU ILL nhận được ASE ILL từ xa sau đây:

- THÔNG BÁO CHUYỂN TIẾP

- ĐÃ CHUYỂN ĐI

- CÂU TRẢ LỜI- ILL

Kết quả yêu cầu = ĐIỀU KIỆN

- CÂU TRẢ LỜI- ILL: Kết quả yêu cầu = LÀM LẠI

- CÂU TRẢ LỜI- ILL: Kết quả yêu cầu = KHÔNG THỰC HIỆN

- CÂU TRẢ LỜI- ILL:

...

...

...

- CÂU TRẢ LỜI ILL:

Kết quả yêu cầu = SẼ CUNG CẤP

- CÂU TRẢ LỜI ILL:

Kết quả yêu cầu = ĐẶT - GIỮ

- CÂU TRẢ LỜI ILL:

Kết quả yêu cầu = DỰ TÍNH

- TRẢ LỜI -HỦY

- ĐÒI

- KIỂM NHẬN

...

...

...

- TRẢ LỜI GIA HẠN: Câu trả lời = CÓ

- TRẢ LỜI GIA HẠN: Câu trả lời = KHÔNG

- MẤT

- HƯ HẠI

- THÔNG BÁO

- HỎI TRẠNG THÁI

- BÁO CÁO TRẠNG THÁI HOẶC LỖI

- HẾT HẠN.

8.1.2  Hành động của bên yêu cầu

...

...

...

- THÔNG BÁO CHUYỂN TIẾP. chỉ thị

- VẬN CHUYỂN. chỉ thị

- CÂU TRẢ LỜI ILL. chỉ thị

Kết quả yêu cầu = CÓ ĐIỀU KIỆN

- CÂU TRẢ LỜI ILL. chỉ thị

Kết quả yêu cầu = LÀM LẠI

- CÂU TRẢ LỜI ILL. chỉ thị

Kết quả yêu cầu = ĐỊA ĐIỂM ĐƯỢC CUNG CẤP

- CÂU TRẢ LỜI ILL .Chỉ thị

...

...

...

- CÂU TRẢ LỜI ILL. chỉ thị

Kết quả yêu cầu = ĐẶT GIỮ

- CÂU TRẢ LỜI ILL. chỉ thị

Kết quả yêu cầu = DỰ TÍNH

- CÂU TRẢ LỜI HỦY. chỉ thị

- ĐÒI. chỉ thị

- KIỂM NHẬN. chỉ thị

- CÂU TRẢ LỜI GIA HẠN

- QUÁ HẠN. chỉ thị

...

...

...

Câu trả lời = CÓ

- CÂU TRẢ LỜI GIA HẠN. chỉ thị

Câu trả lời = KHÔNG

- MẤT. chỉ thị

- HƯ HẠI. chỉ thị

- THÔNG BÁO. chỉ thị

- YÊU CẦU TRẠNG THÁI. chỉ thị

- BÁO CÁO TRẠNG THÁI HOẶC LỖI. chỉ thị

- HẾT HẠN. chỉ thị

...

...

...

- Yêu cầu ILL

- TRẢ LỜI CÓ ĐIỀU KIỆN

Câu trả lời=Có

- TRẢ LỜI CÓ ĐIỀU KIỆN

Câu trả lời=Không

- Hủy

- ĐÃ NHẬN- Đây là hành động tùy chọn

- ĐÃ TRẢ- Đây là hành động tùy chọn

- GIA HẠN

...

...

...

- HƯ HẠI

- THÔNG BÁO

- YÊU CẦU TRẠNG THÁI

- BÁO CÁO- TRẠNG THÁI HOẶC- LỖI

8.1.3  Sự kiện của bên đáp ứng

Điều này mô tả các sự kiện cho phép đối với một người đáp ứng.

Các sự kiện liên quan đến yêu cầu dịch vụ ban đầu từ người sử dụng dịch vụ ILL như sau:

- CHUYỂN TIẾP. yêu cầu

- CHUYỂN ĐI. yêu cầu

...

...

...

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = LÀM LẠI

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = KHÔNG THỰC HIỆN

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = CUNG CẤP ĐỊA ĐIỂM

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = SẼ CUNG CẤP

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = ĐẶT GIỮ

- CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = DỰ TÍNH

- TRẢ LỜI HỦY.yêu cầu

- ĐÒI.yêu cầu

- KIỂM NHẬN.yêu cầu

...

...

...

- CÂU TRẢ LỜI GIA HẠN.yêu cầu: Câu trả lời = CÓ

- CÂU TRẢ LỜI GIA HẠN.yêu cầu: Câu trả lời = KHÔNG

- MẤT.yêu cầu

- HƯ HẠI.yêu cầu

- THÔNG BÁO.yêu cầu

- CÂU HỎI TRẠNG THÁI.yêu cầu

- BÁO CÁO TRẠNG THÁI HOẶC LỖI.yêu cầu

Các sự kiện liên quan đến các APDU ILL nhận được từ ASE ILL ở xa như sau:

- YÊU CẦU ILL

...

...

...

- TRẢ LỜI ĐIỀU KIỆN: Câu trả lời = KHÔNG

- HỦY

- ĐÃ NHẬN

- ĐÃ TRẢ

- GIA HẠN

- MẤT

- HƯ HẠI

- THÔNG BÁO

- HỎI TRẠNG THÁI

...

...

...

- Những sự kiện cục bộ sau đây có thể xảy ra trong nội bộ nhà cung cấp dịch vụ ILL

- HẾT THỜI HẠN

8.1.4  Hành động của bên đáp ứng

Các dịch vụ ban đầu ILL sau đây có thể được đưa ra cho người sử dụng dịch vụ ILL:

- YÊU CẦU ILL.chỉ thị

- ĐÁP ỨNG CÓ ĐIỀU KIỆN.chỉ thị: Câu trả lời = CÓ

- ĐÁP ỨNG CÓ ĐIỀU KIỆN.chỉ thị: Câu trả lời = KHÔNG

- HỦY.chỉ thị

- ĐÃ NHẬN.chỉ thị

...

...

...

-GIA HẠN.chỉ thị

- MẤT.chỉ thị

- HƯ HẠI.chỉ thị

- THÔNG BÁO.chỉ thị

- HỎI TRẠNG THÁI.chỉ thị

- BÁO CÁO TRẠNG THÁI HOẶC LỖI.chỉ thị

- HẾT HẠN.chỉ thị

Các APDU ILL sau đây có thể được gửi đến ASE ILL ở xa:

- YÊU CẦU ILL

...

...

...

- THÔNG BÁO CHUYỂN TIẾP

- CÂY TRẢ LỜI ILL: Kết quả yêu cầu = ĐIỀU KIỆN

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = LÀM LẠI

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = KHÔNG THỰC HIỆN ĐƯỢC

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = CUNG CẤP ĐỊA ĐIỂM

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = SẼ CUNG CẤP

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = ĐẶT GIỮ

- CÂU TRẢ LỜI ILL: Kết quả yêu cầu = DỰ TÍNH

- TRẢ LỜI HỦY

...

...

...

- KIỂM NHẬN - Hoạt động này là tùy chọn

- QUÁ HẠN

- CÂU TRẢ LỜI GIA HẠN: Câu trả lời = CÓ

- CÂU TRẢ LỜI GIA HẠN: Câu trả lời = KHÔNG

- MẤT

- HƯ HẠI

- THÔNG BÁO

- CÂU HỎI TRẠNG THÁI

- BÁO CÁO TRẠNG THÁI HOẶC LỖI

...

...

...

8.1.5  Sự kiện và hành động của người trung gian

Điều này mô tả các sự kiện cho phép đối với một người trung gian. Người trung gian tham gia vào một giao dịch ILL theo chuỗi hoặc phân khu đóng cả hai vai trò của bên yêu cầu và bên đáp ứng .

Trong vai trò của bên yêu cầu, các sự kiện và hoạt động của người trung gian cũng giống như đối với bên yêu cầu, mặc dù các trạng thái có thể khác nhau.

Trong vai trò của bên đáp ứng, các sự kiện và hoạt động của người trung gian cũng giống như đối với bên đáp ứng, mặc dù các trạng thái có thể khác nhau. Khác biệt là bắt buộc phải có APDU ĐÃ CHUYỂN.

8.2  Quy định thủ tục cho tất cả các bên

8.2.1  Gửi và nhận APDU

Trừ ngoại lệ với dịch vụ CHUYỂN TIẾP, mỗi dịch vụ ban đầu yêu cầu tạo ra việc chuẩn bị và truyền tải các APDU có tên tương ứng.

Trong trường hợp Yêu cầu Chuyển tiếp, hai APDU được chuẩn bị: một APDU YÊU CẦU- ILL được gửi tới bên đáp ứng mới, trong khi một APDU THÔNG BÁO-CHUYỂN TIẾP được gửi cho bên yêu cầu.

Việc nhận một APDU hợp lệ dẫn đến một dịch vụ ban đầu chỉ thị tương ứng.

...

...

...

8.2.2  Các giai đoạn giao dịch

Một giao dịch ILL có thể có hai giai đoạn: xử lý và theo dõi. Giai đoạn xử lý là bắt buộc đối với tất cả các giao dịch ILL trong khi giai đoạn theo dõi chỉ áp dụng cho giao dịch ILL khi một tài liệu có trả lại, ví dụ một chuyên khảo, được cung cấp.

Giai đoạn xử lý cho bên yêu cầu bao gồm tất cả các sự kiện và hành động đến khi và bao gồm cả việc tiếp nhận các tài liệu yêu cầu. Giai đoạn này thường kết thúc ở trạng thái NHẬN

Giai đoạn xử lý cho bên đáp ứng bao gồm tất cả các sự kiện và hành động đến và bao gồm cả việc chuyển đi tài liệu yêu cầu. Giai đoạn này thường kết thúc ở trạng thái ĐÃ CHUYỂN ĐI.

Đối với bên yêu cầu trung gian, giai đoạn xử lý bao gồm tất cả các sự kiện và hành động cho đến khi nhận chỉ thị ĐÃ CHUYỂN ĐI, bao gồm cả việc chuyển đi; với bên đáp ứng trung gian giai đoạn xử lý bao gồm tất cả các sự kiện đến khi yêu cầu ĐÃ CHUYỂN, bao gồm cả việc đã chuyển đi. Đối với cả bên yêu cầu và bên đáp ứng trung gian, các giai đoạn xử lý thường chấm dứt ở trạng thái ĐÃ CHUYỂN ĐI.

Giai đoạn theo dõi bao gồm tất cả các sự kiện và hành động sau khi đã chuyển và nhận một tài liệu phải trả lại, kể cả gia hạn, quá hạn và trả tài liệu.

Sự tồn tại của giai đoạn theo dõi với một giao dịch ILL được chỉ định bởi biến giao thức TRẢ LẠI. Giá trị ĐÚNG chỉ ra rằng giai đoạn theo dõi được áp dụng và phải có các thủ tục liên quan kèm theo. Giá trị SAI chỉ ra rằng giai đoạn theo dõi không cần thiết và các sự kiện tương ứng không được phép. Không có giai đoạn theo dõi cho các giao dịch ILL liên quan đến các tài liệu không trả lại, ví dụ bản sao chụp.

Bên đáp ứng đặt biến TRẢ LẠI khi sự kiện phát sinh là ĐÃ NHẬN yêu cầu. Nếu phần tử dữ liệu Loại - dịch vụ - chuyển là MƯỢN, thì đặt ĐÚNG cho biến TRẢ LẠI; nếu phần tử dữ liệu Loại -dịch vụ - chuyển đi là SAO CHỤP/KHÔNG TRẢ LẠI thì đặt SAI cho biến TRẢ LẠI.

Bên yêu cầu đặt biến Trả khi kích hoạt sự kiện là ĐÃ NHẬN yêu cầu. Nếu các phần tử dữ liệu Loại - dịch vụ - vận chuyển là MƯỢN, khi đó TRẢ được đặt là ĐÚNG, nếu các phần tử dữ liệu Loại dịch vụ chuyển đi là SAO CHỤP/KHÔNG TRẢ LẠI, khi đó TRẢ LẠI được đặt là SAI.

...

...

...

8.2.3.1  Giao dịch đơn giản

Đối với một giao dịch ILL đơn giản, bốn trong số những hành động Giao thức ILL là không bắt buộc:

- Gửi APDU ĐÃ CHUYỂN;

- Gửi APDU ĐÃ NHẬN;

- Gửi APDU ĐÃ TRẢ;

- Gửi APDU ĐÃ KIỂM NHẬN .

Một yêu cầu thực thể ứng dụng có thể gửi các APDU tùy chọn bất cứ khi nào nó muốn, ngoài ra có nhiệm vụ gửi chúng trong những tình huống nhất định.

Người khởi xướng một giao dịch ILL có thể thông báo cho bên đáp ứng có thể cung cấp những gì và yêu cầu là gì thông qua các thông báo tùy chọn bên trong yêu cầu ILL.

Yêu cầu ILL có thể xác định như sau:

...

...

...

b) bên yêu cầu có khả năng gửi ĐÃ TRẢ hay không;

c) bên yêu cầu có yêu cầu ĐÃ CHUYỂN hay không;

d) bên yêu cầu có yêu cầu KIỂM NHẬN hay không

e) bên yêu cầu có muốn ĐÃ CHUYỂN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn c) ở trên là KHÔNG

f) bên yêu cầu có muốn ĐÃ KIỂM NHẬN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn d) ở trên là KHÔNG

Tương ứng, TRẢ LỜI ILL và ĐÃ CHUYỂN có thể được xác định như sau:

a) bên đáp ứng có khả năng gửi ĐÃ CHUYỂN hay không;

b) bên đáp ứng có khả năng gửi KIỂM NHẬN hay không;

c) bên đáp ứng có yêu cầu ĐÃ NHẬN hay không;

...

...

...

e) bên đáp ứng có muốn ĐÃ NHẬN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn c) ở trên là KHÔNG;

f) bên đáp ứng có muốn TRẢ hay không; lựa chọn này chỉ có ý nghĩa nếu chọn d) ở trên là KHÔNG.

Khi bên đáp ứng nhận YÊU CẦU ILL chỉ ra rằng

a) bên yêu cầu đó không thể gửi thông báo theo yêu cầu của bên đáp ứng, hoặc

b) bên yêu cầu đó cần thông báo rằng bên đáp ứng không thể gửi,

Khi đó bên đáp ứng có thể gửi một thông báo KHÔNG-HOÀN-THÀNH-CÂU-TRẢ-LỜI-ILL . Nếu bên đáp ứng vẫn chọn cung cấp tài liệu yêu cầu, tức là bên đáp ứng đã hiểu rằng các thông báo ĐÃ NHẬN và ĐÃ TRẢ sẽ không được gửi đi.

Trong tất cả các trường hợp không cần thiết thông báo, có thể gửi hoặc không gửi thông báo dù có mong muốn thông báo hay không. Nhận một APDU tùy chọn không được yêu cầu không phải một lỗi giao thức thức và không gây ra một thay đổi trạng thái, trừ APDU ĐÃ CHUYỂN.

8.2.3.2  Giao dịch theo chuỗi và phân khu

Đối với các giao dịch ILL xâu chuỗi và phân khu, APDU ĐÃ CHUYỂN là bắt buộc, cả giữa bên đáp ứng và người trung gian và giữa người trung gian và bên yêu cầu.

...

...

...

8.2  Danh sách gửi đến

"Danh sách gửi đến" xác định điểm đến tiềm năng cho chuyển tiếp, theo chuỗi và phân khu. Mỗi mục trong danh sách quy định một id bên đáp ứng cụ thể, một số tài khoản tùy chọn và một địa chỉ hệ thống. Người khởi xướng giao dịch ILL luôn có thể cung cấp cho các mục trong danh sách này, có thể không bao giờ điền vào nó, hoặc có thể dựa vào người trung gian để bổ sung các mục. Giao thức này không giới hạn số lượng các mục trong Danh sách gửi đến, cũng không cấm các mục lặp lại, với điều kiện là các mục lặp lại như vậy không thể được sử dụng khi chuyển tiếp (xem 8.2.5).

Người trung gian có thể thay đổi danh sách này giá trị "Cho phép thay đổi danh sách gửi đến" là ĐÚNG. Những hình thức thay đổi danh sách này có thể là bổ sung hoặc xóa.

Việc giải thích danh sách này được điều chỉnh bởi loại "Ưu tiên".

Giá trị "Trình tự" cho biết thứ tự ưu tiên cho việc chuyển tiếp, v.v, được quy định trong "danh sách gửi đến". Những thay đổi với danh sách, khi được phép, chỉ có thể bằng hình thức thêm vào cuối danh sách.

Giá trị "Không có trình tự" cho biết rằng bất kỳ thành viên nào của danh sách có thể được lựa chọn mà không ưu tiên. Những thay đổi với danh sách, khi được phép, có thể ở mọi hình thức.

8.2.5  Danh sách đã thử

Danh sách này xác định các tổ chức đã được gửi yêu cầu ILL. Các địa điểm này phải được loại trừ khỏi bất kỳ chuyển tiếp tiếp theo, tức là không cho phép cho một bên đáp ứng đã chuyển tiếp một yêu cầu ILL nhận một yêu cầu ILL tiếp theo với cùng một id giao dịch. Danh sách này không áp đặt các ràng buộc khác về xử lý giao dịch ILL.

Danh sách này được cập nhật với id hệ thống của bên đáp ứng bất cứ khi nào một yêu cầu ILL được chuyển tiếp, hoặc một giao dịch con cho một ILL giao dịch theo chuỗi hoặc hoặc phân khu được khởi tạo. Trong YÊU CẦU ILL ban đầu dữ liệu có thể được chứa trong Danh sách đã thử. Bất kỳ sự bổ sung vào danh sách phải được đặt ở cuối danh sách.

...

...

...

Các APDU CHUYỂN ĐI, QUÁ HẠN VÀ CÂU TRẢ LỜI GIA HẠN với cùng một id giao dịch sẽ cho biết một tài liệu mượn có thể được gia hạn hay không. Thông tin này được cung cấp cho bên yêu cầu, người được dự kiến sẽ không khởi xướng một Yêu cầu gia hạn trừ khi tài liệu này có thể được gia hạn. Không phải là lỗi nếu một yêu cầu GIA HẠN được thực hiện khi tài liệu không thể gia hạn.

8.2.7  Xác nhận trình tự APDU

Ngoại trừ các APDU THÔNG BÁO, HỎI TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và HƯ HẠI người nhận xác nhận tất cả các APDU nhận được với cùng id giao dịch và từ cùng một người khởi tạo với trình tự chính xác, dựa trên giá trị của loại "Ngày và thời gian của dịch vụ" trong mỗi APDU. Giá trị của tham số "Ngày và thời gian dịch vụ" phải phân biệt cho từng yêu cầu dịch vụ được thực hiện bởi cùng một bên (bên yêu cầu, bên đáp ứng hoặc người trung gian) cho một giao dịch cụ thể.

Giá trị này được so sánh với giá trị của các biến giao thức DẤU THỜI GIAN TUẦN TỰ. Nếu DẤU THỜI GIAN TUẦN TỰ có giá trị bằng hoặc lớn hơn giá trị trong APDU nhận được, APDU nhận được không gây ra thay đổi trạng thái, DẤU THỜI GIAN TUẦN TỰ không được cập nhật, và chỉ thị dịch vụ ban đầu được đưa ra cho người sử dụng. Không thực hiện kiểm tra đối với APDU lặp lại (xem 8.2.8). Nếu DẤU THỜI GIAN TUẦN TỰ có giá trị thấp hơn giá trị của loại "Ngày và thời gian của dịch vụ" trong APDU nhận, APDU được chấp nhận, sự thay đổi trạng thái được thực hiện nếu thích hợp và DẤU THỜI GIAN TUẦN TỰ được cập nhật. Việc xác nhận trình tự được thực hiện sau khi xác nhận hệ thống và trước các xử lý khác bởi người nhận ILLPM.

Việc xác nhận trình tự được thực hiện chỉ cho các APDU từ cùng một người khởi tạo. Đối với bên yêu cầu, và bên yêu cầu trung gian, điều này được xác định bằng cách so sánh các biến giao thức ID ĐỐI TÁC HIỆN TẠI với một trường trong một số hoặc tất cả các APDU được nhận. Trong một giao dịch đơn giản, so sánh được thực hiện với trường id bên đáp ứng trong đó mỗi APDU nhận được, ngoại trừ trường hợp của APDU THÔNG BÁO CHUYỂN TIẾP nơi so sánh thực hiện với trường id người trung gian. Trong một giao dịch theo chuỗi hoặc phân khu, việc so sánh thực hiện với trường "id người trung gian" bất kỳ THÔNG BÁO CHUYỂN TIẾP hoặc ĐÃ CHUYỂN nào nhận được. Biến giao thức ID ĐỐI TÁC HIỆN TẠI được lấy giá trị ban đầu như mô tả trong 7.3. Khi một APDU đến từ một bên đáp ứng khác, ví dụ như chỉ thị ĐÃ CHUYỂN đi từ một tổ chức đã được chuyển tiếp một yêu cầu ILL, khi đó không thực hiện kiểm tra trình tự và biến giao thức ID ĐỐI TÁC TRƯỚC ĐÓ được kiểm tra để xác định xem có các APDU đến từ một bên đã tham gia vào giao dịch ILL không. Nếu APDU nhận được là từ một bên đáp ứng mới, khi đó

a) APDU nhận được được xử lý như một thông báo trong trình tự và được xử lý phù hợp,

b) biến giao thức DẤU THỜI GIAN TUẦN TỰ được đặt để khai báo dấu thời gian của APDU nhận được, và

c) giá trị ID ĐỐI TÁC HIỆN TẠI được thêm vào các ID ĐỐI TÁC TRƯỚC ĐÓ và được cập nhật để phản ánh giá trị của id bên đáp ứng trong APDU nhận được.

Nếu bên đáp ứng là một người trước đó, thì APDU nhận được xử lý theo cùng một cách như một chuỗi không tuần tự và DẤU THỜI GIAN TUẦN TỰ, ID ĐỐI TÁC HIỆN TẠI và các ID ĐỐI TÁC TRƯỚC ĐÓ không được cập nhật.

...

...

...

Lưu ý rằng, với ngoại lệ trình tự (Yêu cầu ILL, Hủy), giao thức ILL linh hoạt với tất cả các kết hợp không tuần tự, theo nghĩa là APDU không tuần tự thứ hai trong chuỗi sẽ được chấp nhận bởi giao thức ngay cả khi nó được nhận đầu tiên. Điều này cần tránh đối với các quy tắc đặc biệt cho từng tình huống có thể, miễn là APDU thứ hai nhận được không bao giờ gây ra một thay đổi trạng thái.

8.2.8 APDU được lặp

Có thể lặp lại một yêu cầu dịch vụ cụ thể một hoặc nhiều lần mà không gây ra lỗi giao thức. Ví dụ về các tình huống mà một yêu cầu dịch vụ có thể cần lặp bao gồm:

- Yêu cầu QUÁ HẠN khi nhiều thông báo quá hạn được gửi trước khi hành động được thực hiện;

- YÊU CẦU- ILL, HỦY, GIA HẠN, hoặc ĐIỀU KIỆN khi không nhận được câu trả lời cho yêu cầu trước đó:

- YÊU CẦU- ILL hoặc bất kỳ yêu cầu khác, khi một vấn đề được phát hiện với các dịch vụ truyền thông tin cơ bản mà có thể cản trở việc cung cấp APDU tương ứng.

Chỉ có yêu cầu dịch vụ gần đây nhất gây ra một thay đổi trạng thái trong hệ thống xuất phát có thể được lặp. Các yêu cầu dịch vụ mà không bao giờ gây ra một thay đổi trạng thái, nghĩa là THÔNG BÁO, HỎI TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và HƯ HẠI không được lặp; mỗi yêu cầu dịch vụ là một yêu cầu mới.

Nếu một CÂU TRẢ LỜI- ILL (CÓ ĐIỀU KIỆN) được theo sau TRẢ LỜI- ĐIỀU KIỆN (CÓ) , bên đáp ứng có thể gửi một TRẢ LỜI- ILL (CÓ ĐIỀU KIỆN) khác, với điều kiện bổ sung. Điều này không được coi là một yêu cầu dịch vụ lặp.

Một yêu cầu dịch vụ lặp được xác định bằng cách cung cấp một giá trị cho kiểu "Ngày và thời gian của dịch vụ ban đầu" khi yêu cầu lặp được thực hiện. Ngày và thời gian này là của yêu cầu ban đầu đang được lặp. Khi yêu cầu dịch vụ được lặp, chỉ có các tham biến "ngày và thời gian dịch vụ" và "chú thích" có thể có các giá trị khác nhau. Không có thay đổi trạng thái được thực hiện trong hệ thống mà việc lặp lại yêu cầu được khởi xướng.

...

...

...

Nếu chưa nhận APDU trước đó, nghĩa là các giá trị "Ngày-giờ-của-dịch-vụ-ban-đầu" khác với DẤU-THỜI-GIAN-LẶP-LẠI, thì APDU được xử lý như là yêu cầu ban đầu với chỉ thị dịch vụ và thay đổi trạng thái tương ứng. Ngoài ra, các DẤU-THỜI-GIAN-LẶP-LẠI, được cập nhật để bằng "Ngày và thời gian của dịch vụ ban đầu". Nếu nhận được một APDU trước đó, như được tính bằng "Ngày và thời gian của dịch vụ ban đầu" và "DẤU THỜI GIAN LẶP", khi đó không có thay đổi trạng thái được thực hiện. Tuy nhiên, một chỉ thị dịch vụ gốc được cấp cho người sử dụng dịch vụ bởi vì khả năng là trường"Chú thích" có thể có thông tin mới. Người nhận một chỉ thị dịch vụ lặp sẽ lặp lại phân ứng trước đó của mình, nếu có một dịch vụ đã được thực hiện.

Cơ chế, theo đó quyết định được thực hiện để lặp lại một yêu cầu dịch vụ nằm ngoài phạm vi của tiêu chuẩn này.

Lưu ý rằng Dịch vụ hết hạn không thể lặp bởi vì nó là một dịch vụ nhà cung cấp khởi xướng.

8.2.9  Thực hiện lại

Khi một giao dịch ILL hoặc giao dịch con trước đó kết thúc với kết quả giao dịch là THỬ LẠI, KHÔNG HOÀN THÀNH, ĐỊA ĐIỂM CUNG CẤP HOẶC DỰ TÍNH, có thể bắt đầu một giao dịch mới như là việc thử lại rõ ràng vào một ngày sau đó. Khi giao dịch ILL là thử lại của giao dịch lần trước, "Cờ Thử lại " của APDU YÊU CẦU- ILL được đặt là ĐÚNG.

Đối với bên yêu cầu khởi tạo, thực hiện lại là một giao dịch mới, và do đó, dấu hạn định giao dịch ILL phải khác với dấu được sử dụng trong yêu cầu ban đầu, nhưng dấu hạn định nhóm giao dịch ILL và dấu hạn định giao dịch ILL phải giống nhau (để cho phép bên đáp ứng hoặc người trung gian liên kết cuộc thực hiện lại này với giao dịch ILL trước đó).

Đối với người trung gian, thực hiện lại là một giao dịch con mới, vì vậy dấu hạn định giao dịch con phải khác với dấu được sử dụng trong yêu cầu ban đầu, nhưng cả dấu hạn định nhóm giao dịch ILL và dấu hạn định giao dịch ILL phải giống nhau (để cho phép bên đáp ứng hoặc người trung gian tiếp theo liên kết cuộc thực hiện này với giao dịch con trước đó).

8.2.10  Hết hạn giao dịch

Bên yêu cầu, tại thời điểm YÊU CẦU- ILL, có thể chọn để đặt một giới hạn thời gian về vòng đời của giao dịch ILL. Thời hạn này được chỉ định theo một trong hai cách:

...

...

...

b) bằng cách cung cấp một giá trị cho loại "Ngày hết hạn" và khai báo "Cờ hết hạn" với "NGÀY THÁNG KHÁC".

Nếu một trong hai điều kiện này được đáp ứng, khi đó bộ đếm thời gian "HẾT HẠN" được đặt với thời hạn sử dụng theo quy định ở bên đáp ứng khi APDU YÊU CẦU- ILL nhận được.

Nếu không có thời gian giới hạn được đặt cho Hết hạn giao dịch ILL khi đó "cờ hết hạn" được gán giá trị "KHÔNG- HẾT HẠN".

Nếu không có phản hồi nào được đưa ra (dưới hình thức của một câu trả lời ILL hoặc dịch vụ đã chuyển) trước khi giá trị bộ đếm thời gian "HẾT HẠN" bằng thời gian theo lịch hiện tại, bên đáp ứng sẽ gửi một APDU HẾT HẠN đến bên yêu cầu. Một dịch vụ ban đầu chỉ thị Hết hạn được đưa ra ở cả hai bên bên yêu cầu và bên đáp ứng và giao dịch ILL đi vào trạng thái KHÔNG-CUNG CẤP.

CHÚ THÍCH 1 Có hai khả năng để đặt ngày hết hạn cho một giao dịch ILL sẽ cho phép bên yêu cầu linh hoạt trong việc gán hay không gán nghĩa hết hạn cho "cần-trước-ngày". Một ví dụ về việc sử dụng Ngày hết hạn khác với "Cần trước ngày" sẽ cho phép một thời gian trả lời ngắn hơn do đó những bên đáp ứng tiềm năng khác có thể được liên hệ trước "Cần trước ngày'.

CHÚ THÍCH 2: Trong các trường hợp "Cờ hết hạn" được đặt là "NGÀY KHÁC", nó vẫn còn có thể cung cấp một giá trị cho "Cần trước ngày" nhưng nó không có ý nghĩa hết hạn.

CHÚ THÍCH 3: Đây là một cân nhắc thực hiện để chống lại khả năng mất một APDU HẾT HẠN, bên yêu cầu cũng có thể duy trì một bộ đếm thời gian hết hạn. Nếu bộ đếm thời gian này phải hết hạn, điều này có thể kích hoạt người sử dụng gửi một Yêu cầu trạng thái đến bên đáp ứng. Hạn sử dụng bộ đếm thời gian của bên yêu cầu không được gây ra hết thời hạn tự động của giao dịch ILL, vì là bên đáp ứng có thể không thực sự hết thời gian (ví dụ thông báo ĐÃ CHUYỂN có thể đang chuyển đến hoặc có thể đã bị mất).

Nếu một yêu cầu CÂU TRẢ LỜI- ILL với kết quả CÓ ĐIỀU KIỆN được đưa ra bởi bên đáp ứng, khi đó bộ đếm thời gian HẾT HẠN được đặt lại giá trị kiểu "Ngày đáp ứng". Nếu bộ đếm thời gian này hết hạn, khi đó các hành động tương tự mô tả ở trên xảy ra. Nếu không có giá trị cho loại này, thời gian HẾT HẠN không có tác động, tức là tắt nếu bị vô hiệu hóa trước đó hoặc giữ nguyên giá trị nếu được đặt trước đó.

CHÚ THÍCH "ngày đáp ứng" trong CÂU TRẢ LỜI ILL (CÓ ĐIỀU KIỆN) có thể sớm hơn ngày bên yêu cầu khai báo ban đầu cho Hết hạn.

...

...

...

Các sự kiện sau đây ở bên đáp ứng sẽ vô hiệu hóa bộ đếm thời gian HẾT HẠN:

- CÂU TRẢ LỜI ILL.yêu cầu có kết quả khác với ĐIỀU KIỆN

- ĐÃ CHUYỂN.yêu cầu

- CHUYỂN TIẾP.yêu cầu

- Nhận APDU HỦY

CHÚ THÍCH Nếu CÂU TRẢ LỜI- ILL nhận được có kết quả là SẼ-CUNG CẤP hoặc ĐẶT- GIỮ.có ngày muộn hơn trong "Cần trước ngày" hoặc "Hết hạn" trên YÊU CẦU ILL ban đầu, thì tùy thuộc bên yêu cầu quyết định xem phải chờ đợi hoặc hủy bỏ yêu cầu.

8.2.11  Hủy giao dịch

Bên yêu cầu có thể bắt đầu hủy một giao dịch ILL bất cứ lúc nào trong khi ở trạng thái CHỜ

Khi bên đáp ứng nhận được chỉ thị HỦY, cần phải trả lời bằng TRẢ LỜI HỦY. yêu cầu, với ngoại lệ sau.

...

...

...

Khi bên đáp ứng đưa ra TRẢ LỜI HỦY.yêu cầu với câu trả lời = CÓ, thì APDU TRẢ LỜI HỦY được gửi và bên đáp ứng nhập vào đầu cuối trạng thái ĐÃ HỦY. Khi APDU TRẢ LỜI - HỦY được nhận, bên yêu cầu đưa ra TRẢ LỜI HỦY. chỉ thị và nhập vào trạng thái thiết bị đầu cuối HỦY.

Khi bên đáp ứng đưa ra TRẢ LỜI HỦY. yêu cầu với câu trả lời = KHÔNG, thì APDU TRẢ LỜI HỦY được gửi và bên đáp ứng đáp ứng nhập trạng thái ĐANG XỬ LÝ. Khi APDU TRẢ LỜI HỦY được nhận bên yêu cầu đưa ra TRẢ LỜI HỦY. chỉ thị và nhập vào trạng thái ĐANG CHỜ.

8.2.12  Tuổi thọ của thông tin Giao dịch ILL

Khoảng thời gian thông tin giao dịch ILL được duy trì bởi hệ thống một khi một giao dịch ILL đạt đến một trạng thái thiết bị đầu cuối là vấn đề cục bộ nằm ngoài phạm vi của tiêu chuẩn này. Quá trình theo đó thông tin này không có sẵn được gọi là đóng giao dịch hoặc loại bỏ giao dịch.

Một hệ thống phải đáp ứng tất cả các yêu cầu HỎI TRẠNG THÁI. Nếu giao dịch ILL liên quan không có sẵn, thì BÁO CÁO TRẠNG THÁI HOẶC LỖI sẽ chỉ ra một trong hai lý do sau đây:

- "Thông tin không có sẵn - tạm thời"

- "Thông tin không có sẵn - vĩnh viễn"

Điều kiện đầu tiên được sử dụng để thông báo sự không có sẵn thông tin tạm thời, ví dụ như do một lỗi của hệ thống lưu trữ. Điều kiện thứ hai được sử dụng khi một giao dịch ILL đã bị đóng.

8.2.13  Lỗi giao thức

...

...

...

Khi một lỗi giao thức được phát hiện, không có thay đổi trạng thái xảy ra và một APDU BÁO CÁO TRẠNG THÁI HOẶC LỖI mô tả bản chất của lỗi được gửi bởi ILLPM.

Nếu phát hiện một lỗi giao thức xảy ra khi hồi đáp một APDU yêu cầu ILL ban đầu, bên yêu cầu có thể để giao dịch ở trạng thái thiết bị đầu cuối là ĐÃ HỦY hoặc KHÔNG-CUNG CẤP. Ngoài ra bên yêu cầu có thể đưa lại APDU này trong một phiên bản khác.

8.2.14  Quy tắc để mở rộng

Tất cả các lỗi cú pháp trong các APDU nhận được coi là lỗi giao thức ngoại trừ một giá trị chưa biết của một tham biến đã biết (khác với phiên bản giao thức), mà không gây ra một lỗi giao thức.

Một giá trị chưa biết của giao thức phiên bản không tạo thành lỗi giao thức.

8.2.15  Thông tin riêng của bên đáp ứng

Giao thức ILL cho phép truyền thông tín riêng của bên đáp ứng để mô tả một dịch vụ yêu cầu hoặc kết quả của một yêu cầu ILL.

Thông tin riêng của bên đáp ứng có thể được cung cấp để bổ sung các giá trị chuẩn hóa cho loại dịch vụ ILL và giải thích kết quả được định nghĩa trong tiêu chuẩn này. Trong trường hợp như vậy, bất kỳ giá trị chuẩn hóa khác với "riêng của bên đáp ứng" được sử dụng cho loại dịch vụ ILL hoặc lý do kết quả và các thông tin riêng của bên đáp ứng bổ sung được cung cấp trong loại dịch vụ riêng của bên đáp ứng hoặc kết quả riêng của bên đáp ứng, tương ứng.

Ngoài ra, thông tin riêng của bên đáp ứng có thể được cung cấp để thay thế các giá trị chuẩn hóa cho loại dịch vụ ILL và giải thích kết quả được định nghĩa trong tiêu chuẩn này. Trong trường hợp này, giá trị chuẩn hóa "riêng cho bên đáp ứng" được sử dụng cho loại dịch vụ ILL hoặc lý do kết quả và Thông tin riêng cho bên đáp ứng phải được cung cấp trong loại Dịch vụ riêng cho bên đáp ứng hoặc Kết quả riêng cho bên đáp ứng, tương ứng. Việc sử dụng các kiểu BÊN NGOÀI của ASN.1 để xác định Thông tin riêng cho bên đáp ứng được mô tả trong Phụ lục D.

...

...

...

Khi một yêu cầu được chuyển tiếp, theo chuỗi hoặc phân khu, các số tài khoản trong Kiểu- thông tin - Chi phí được thay bằng số tài khoản của tổ chức yêu cầu với tổ chức tiếp theo tới đó yêu cầu được gửi như chứa trong mục tương ứng ở Loại -Danh sách -Gửi đến (loại danh sách địa chỉ gửi). Nếu không có sẵn đề mục như vậy, trường này được để trống.

8.2.17  Mô tả tài liệu bổ sung

Ngoài thông tin định danh tài liệu được xác định trong tiêu chuẩn này, có thể cung cấp thông tin bổ sung khác về bản chất hoặc về định dạng. Ví dụ, thông tin có thể được cung cấp trong định dạng, hoặc ở định dạng mã vạch để nhận dạng tài liệu nhanh chóng theo ISO 2709. Mô tả tài liệu bổ sung có thể được cung cấp trong các yêu cầu YÊU CẦU- ILL, ĐÃ CHUYỂN, CÂU TRẢ LỜI ILL, ĐÃ NHẬN và ĐÃ TRẢ.

Thông tin này có thể được cung cấp bởi bên yêu cầu ban đầu hoặc bổ sung sau bởi bên đáp ứng hoặc người trung gian (ví dụ là kết quả của việc kiểm tra thư mục).

8.2.18 Thông báo gửi

Tham số này là một tham số dịch vụ trừu tượng không tạo ra một tham số giao thức tương ứng.

8.3  Quy định về thủ tục cho người trung gian

Tất cả giao dịch ILL ban đầu là đơn giản. Khi được sự cho phép của bên yêu cầu, bên đáp ứng có thể chọn chuyển tiếp, theo chuỗi hay phân khu một giao dịch ILL, hoặc có thể đặt các giao dịch ILL riêng biệt. Những người trung gian là đối tượng của các quy tắc quy định tại khoản này, ngoài các quy tắc tại các khoản trên đây.

8.3.1  Chuyển tiếp giao dịch

...

...

...

Bên đáp ứng có thể cung cấp hai kiểu ghi chú khác nhau khi chuyển tiếp một YÊU CẦU- ILL: ghi chú chuyển tiếp trong YÊU CẦU- ILL được chuyển tiếp và ghi chú thông báo trong THÔNG BÁO - CHUYỂN TIẾP.

Khi chuyển tiếp xảy ra, bên đáp ứng không còn tham gia vào giao dịch ILL nữa. Từ thời điểm đó, người chuyển tiếp chỉ có thể thực hiện các dịch vụ CHUYỂN TIẾP, YÊU CẦU TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và THÔNG BÁO có thể được gọi bởi bên đáp ứng. Nếu trong trạng thái ĐANG CHỜ, bên yêu cầu gửi một YÊU CẦU- ILL lặp, một APDU HỦY, THÔNG BÁO hoặc HỎI TRẠNG THÁI đến bên đáp ứng, bên đáp ứng khi đã chuyển tiếp yêu cầu đến bên đáp ứng mới, người trung gian (bên đáp ứng đầu tiên) sẽ gửi một BÁO CÁO TRẠNG THÁI HOẶC LỖI với một giá trị báo cáo lỗi của "Đã chuyển tiếp" với thông tin trong trường Chú thích là nơi yêu cầu được chuyển tiếp.

Biến giao thức Bool Chuyển tiếp được sử dụng bởi bên đáp ứng cho biết một yêu cầu có thể được chuyển tiếp hay không. Biến giao thức này được đặt sau khi nhận được APDU YÊU CẦU- ILL với giá trị được chuyển bằng kiểu "Cho phép chuyển tiếp". Nếu Chuyển tiếp có giá trị là ĐÚNG, thì được phép chuyển tiếp. Nếu Chuyển tiếp có giá trị là SAI, thì không được phép chuyển tiếp.

Kiểu "Cho phép chuyển tiếp" cũng có thể được đặt là SAI tại thời điểm một yêu cầu được chuyển tiếp khi muốn hạn chế việc chuyển tiếp sau đó.

Chuyển tiếp có thể được kết hợp giữa xâu chuỗi hoặc phân khu giao dịch ILL.

CHÚ THÍCH Chuyển tiếp không nhằm để sử dụng khi một tài liệu được yêu cầu dự kiến sẽ có sẵn trong tương lai; trong những trường hợp như vậy, một CÂU TRẢ LỜI ILL có giá trị THỬ LẠI và ngày THỬ LẠI được quy định là đáp ứng thích hợp.

8.3.2  Xâu chuỗi giao dịch

Giao thức ILL hỗ trợ xâu chuỗi không giới hạn của một ILL giao dịch.

Giao dịch ILL theo chuỗi được xác định bởi giá trị của "Kiểu giao dịch" trong APDU Yêu cầu ILL.

...

...

...

Người sử dụng dịch vụ ILL trung gian có trách nhiệm phối hợp các sự kiện trên các giao dịch chính và phụ. Về mặt khái niệm, sự kết hợp này là các dịch vụ gốc: chỉ thị dịch vụ gốc trên một giao dịch ILL được ánh xạ vào yêu cầu dịch vụ gốc tương ứng trên các chỉ thị khác, ví dụ việc nhận chỉ thị chuyển đi được ánh xạ vào một yêu cầu chuyển đi được gửi cho bên yêu cầu.

Người trung gian có thể thay đổi các giá trị của tham số dịch vụ như thực hiện ánh xạ giữa giao dịch chính và giao dịch con, trừ trường hợp đặc biệt không được phép. Nếu nó làm thay đổi giá trị của bộ đếm thời gian hết hạn, thời hạn sử dụng đối với giao dịch con phải bằng hoặc ít hơn thời hạn sử dụng cho yêu cầu ban đầu.

Điểm kết nối giữa giao dịch chính và phụ là những gì sự kiện giao dịch chính ILL luôn được ánh xạ vào các sự kiện giao dịch con tương ứng. Tương tự như vậy, tất cả các sự kiện giao dịch con, ngoại trừ chỉ thị CÂU TRẢ LỜI- ILL có giá trị THỬ LẠI, KHÔNG HOÀN THÀNH, hoặc ĐỊA ĐIỂM CUNG CẤP, chỉ thị HẾT HẠN và chỉ thị THÔNG BÁO CHUYỂN TIẾP, được ánh xạ lên các sự kiện giao dịch ILL chính tương ứng.

Trong các trường hợp chỉ thị CÂU TRẢ LỜI ILL với một trong các giá trị quy định ở trên, nó có thể được ánh xạ lên một yêu cầu CÂU TRẢ LỜI -ILL của giao dịch ILL chính, hoặc nó có thể không theo sự lựa chọn của người trung gian. Một ví dụ về trường hợp sau là tình huống người trung gian, khi nhận được phản hồi từ chối từ một bên đáp ứng, chọn khởi tạo một giao dịch con mới với bên đáp ứng khác chứ không phải báo cáo ngay lập tức một câu trả lời từ chối cho bên yêu cầu giao dịch ILL chính.

Chỉ thị CÂU TRẢ LỜI -ILL với một giá trị CÓ ĐIỀU KIỆN phải được ánh xạ vào yêu cầu Câu trả lời ILL của giao dịch ILL chính.

Trả lời Điều kiện tiếp theo với giá trị Không được ánh xạ vào giao dịch con. Lưu ý rằng trong trường hợp này người trung gian có thể không bắt đầu một giao dịch con mới với bên đáp ứng khác.

Trong trường hợp của chỉ thị Thông báo chuyển tiếp và chỉ thị Hết hạn, không có ánh xạ bất kỳ sự kiện giao dịch ILL chính được thực hiện. Những dịch vụ ban đầu này có ý nghĩa chỉ với các giao dịch con. Nếu bên yêu cầu trung gian trong trạng thái Chờ hủy nhận chỉ thị Thông báo chuyển tiếp từ bên đáp ứng và kết quả là trở lại trạng thái Chờ, cần đưa ra yêu cầu Hủy đến bên đáp ứng mới.

Người trung gian tham gia vào cả giao dịch chính và con trong suốt vòng đời của chúng, nhưng không thực hiện chuyển đổi trạng thái trong giai đoạn theo dõi các giao dịch ILL như vậy, tức là các hành vi người trung gian trong chế độ xuyên suốt. Trong phạm vi người trung gian, trạng thái ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho cả giao dịch ILL chính thành công và một giao dịch con thành công. Sự chuyển trạng thái tiếp theo chỉ xảy ra đối với bên yêu cầu và bên đáp ứng. Các quy tắc chuyển đổi trạng thái cho người trung gian khác với các quy tắc của bên yêu cầu và bên đáp ứng ở một số trạng thái. Những quy tắc cụ thể cho người trung gian được nêu trong các bảng tại Phụ lục A.

Biến giao thức Bool theo CHUỖI được sử dụng để cho biết có hay không một giao dịch ILL theo chuỗi. Biến giao thức này được đặt sau khi nhận được một APDU YÊU CẦU- ILL với giá trị chuyển bằng kiểu "Cho phép theo chuỗi". Nếu thực hiện theo CHUỖI là ĐÚNG, thì việc theo chuỗi có thể được phép. Người trung gian có thể chọn thay đổi giá trị của kiểu "Cho phép theo chuỗi" khi bắt đầu một giao dịch con.

...

...

...

Khi người trung gian đáp ứng bên yêu cầu với APDU ĐÃ CHUYỂN, tham số "Thông báo tùy chọn của bên đáp ứng" phải lấy giá trị được cung cấp trong một APDU ĐÃ CHUYỂN nhận được từ bên đáp ứng

8.3.3  Phân khu giao dịch

Giao thức ILL hỗ trợ phân khu không giới hạn một giao dịch ILL.

Các giao dịch ILL phân khu được xác định bởi giá trị của "Kiểu giao dịch" trong APDU Yêu cầu ILL.

Khi việc phân khu giao dịch ILL xảy ra, bên đáp ứng lúc này trở thành người trung gian và khởi tạo một giao dịch con với một bên đáp ứng mới. Khi giao dịch con được khởi tạo, biến PHÂN KHU vẫn ĐÚNG trong khi biến Xâu chuỗi được đặt là SAI.

Người trung gian tham gia vào giao dịch ILL chính chỉ trong giai đoạn xử lý, nghĩa là cho đến khi một APDU ĐÃ CHUYỂN được nhận được từ bên đáp ứng và chuyển cho bên yêu cầu. Các giao dịch con chỉ có một giai đoạn xử lý. Trong phạm vi của người trung gian, trạng thái ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho cả giao dịch ILL chính thành công và giao dịch con thành công.

Giai đoạn theo dõi thường liên quan đến sự tương tác trực tiếp giữa bên yêu cầu và bên đáp ứng và bỏ qua người trung gian. Tuy nhiên, nếu người trung gian nhận một APDU THÔNG BÁO, HỎI TRẠNG THÁI, BÁO CÁO TRẠNG THÁI HOẶC LỖI thì ở trong trạng thái thiết bị đầu cuối, người trung gian không trả lời mà chuyển tiếp APDU này.

Các định danh của giao dịch chính và phụ chỉ khác nhau ở sự có mặt của dấu hạn định giao dịch con. Sau khi hoàn thành giai đoạn xử lý, bên đáp ứng bỏ dấu hạn định giao dịch con khỏi Dấu hạn định giao dịch ILL (xem 7.1) và sử dụng phần còn lại khi tương tác với bên yêu cầu.

Trong giai đoạn xử lý, các giao dịch chính và con được kết hợp theo cách tương tự như các giao dịch ILL theo chuỗi.

...

...

...

Khi người trung gian khởi tạo một giao dịch con, luôn chỉ ra yêu cầu cho các thông báo Vận chuyển trong tham số "Thông báo tùy chọn của bên yêu cầu" của dịch vụ YÊU CẦU- ILL. Tất cả các thành phần khác của tham số này có cùng giá trị như được cung cấp trong YÊU CẦU-ILL ban đầu.

Khi người trung gian đáp ứng cho bên yêu cầu với APDU ĐÃ CHUYỂN, tham số "Thông báo tùy chọn của bên đáp ứng" phải nhận giá trị được cung cấp trong APDU ĐÃ CHUYỂN nhận được từ bên đáp ứng. Bên yêu cầu gửi bất kỳ APDU được yêu cầu này trực tiếp đến bên đáp ứng, không phải tới người trung gian.

8.3.4  Chuyển tiếp, xâu chuỗi và phân khu hỗn hợp

Chuyển tiếp, theo chuỗi và phân khu có thể được kết hợp theo bất kỳ cách thức nào trong một giao dịch ILL. Các quy tắc áp dụng khác nhau tùy theo sự kết hợp cụ thể được sử dụng.

Các trường hợp sau đây được phân biệt:

a) Chuỗi theo sau là chuyển tiếp: người nhận YÊU CẦU- ILL chuyển tiếp tương tác trong suốt giao dịch ILL với người trung gian, được xác định bởi tham số "id bên yêu cầu" trong Yêu cầu ILL nhận được.

b) Chuyển tiếp theo chuỗi tiếp theo: người khởi xướng giao dịch con theo chuỗi tương tác trực tiếp với bên yêu cầu ban đầu sau khi đã nhận được YÊU CẦU -ILL chuyển tiếp. Người nhận YÊU CẦU -ILL theo chuỗi tương tác với người trung gian thực hiện theo chuỗi, như với một giao dịch ILL theo chuỗi bình thường.

c) Phân khu có Chuyển tiếp tiếp theo: người nhận YÊU CẦU ILL chuyển tiếp tương tác trong suốt quá trình xử lý với người trung gian được xác định bởi tham số "id bên yêu cầu" của YÊU CẦU ILL nhận được. Trong giai đoạn theo dõi, nó tương tác trực tiếp với bên yêu cầu ban đầu.

d) Chuyển tiếp có Phân khu tiếp theo: người khởi xướng giao dịch con phân khu tương tác trực tiếp với bên yêu cầu ban đầu trong giai đoạn xử lý, sau khi nó đã nhận được YÊU CẦU ILL chuyển tiếp. Người nhận YÊU CẦU ILL phân khu tương tác với người trung gian phân khu trong giai đoạn xử lý, và với bên yêu cầu ban đầu trong giai đoạn theo dõi, như với một giao dịch ILL bình thường.

...

...

...

f) Phân khu theo chuỗi tiếp theo: Không giống như các trường hợp trên, người nhận mà YÊU CẦU ILL được thực hiện theo chuỗi không nhận thức được sự phân khu và do đó không thể sửa đổi hành vi của mình cho phù hợp. Do đó, không bao giờ tương tác trực tiếp với bên yêu cầu ban đầu. Giai đoạn xử lý tiến hành bình thường, ngoại trừ việc xử lý APDU ĐÃ CHUYỂN. Nếu người trung gian trong chuỗi, tức là người được phân khu YÊU CẦU ILL, nhận được chỉ thị ĐÃ CHUYỂN từ bên đáp ứng cuối cùng thì trước khi chuyển thông báo đi, người trung gian phải khai báo tham số "id nhà cung cấp" vào giá trị "id bên đáp ứng" và khai báo "id bên đáp ứng" vào nhận dạng của người trung gian. Tham số "kiểu giao dịch" được đặt với giá trị "phân khu". Bằng cách này, chỉ thị ĐÃ CHUYỂN gửi tới bên yêu cầu ban đầu sẽ chỉ ra rằng sự tương tác tiếp theo trong giai đoạn theo dõi sẽ thực hiện trực tiếp với người trung gian theo chuỗi. Tuy nhiên, "id nhà cung cấp" sẽ xác định nhà cung cấp thực tế tài liệu này. Người trung gian thực hiện theo chuỗi vẫn chịu trách nhiệm tiếp tục với việc theo chuỗi tất cả các tương tác với bên yêu cầu ban đầu cho tới bên đáp ứng cuối cùng, và ngược lại.

Những thay đổi với các tham số "kiểu giao dịch ", "id nhà cung cấp" và "id bên đáp ứng" được thực hiện chỉ khi tham số "kiểu giao dịch" không có giá trị "phân khu". Quy tắc này đảm bảo rằng người trung gian cuối cùng trong một chuỗi phân khu luôn được xác định với bên yêu cầu đầu.

g) Chuyển tiếp, theo chuỗi và phân khu: Không có quy định bổ sung được áp dụng. Hành vi của bất kỳ sự kết hợp quy định nào được xác định bởi áp dụng lặp lại các quy tắc này cho các kết hợp theo cặp đã nêu ở trên.

8.3.4.1  Các giao dịch ILL riêng biệt

Nếu hệ thống đặt các giao dịch đặc biệt hoạt động thay thế cho người trung gian, tiêu chuẩn này không đặt quy định thủ tục cụ thể cho việc liên kết các giao dịch ILL riêng biệt.

Tuy nhiên, lưu ý rằng một hệ thống vai trò kép phải sử dụng một cơ chế nào đó để theo dõi tiến trình của hai giao dịch này để đảm bảo rằng chúng tiếp cận trạng thái thiết bị đầu cuối; điều này có thể đạt được bằng nhiều cách khác nhau, ví dụ:

a) Đối với tất cả các tài liệu, hoặc là một APDU ĐÃ CHUYỂN phải được cung cấp bởi người đáp ứng hoặc tài liệu này phải được chuyển qua người trung gian.

b) Đối với các tài liệu được trả lại, hoặc là một APDU KIỂM NHẬN phải được cung cấp bởi người trả lời hoặc các tài liệu này phải được trả lại thông qua người trung gian.

Cách hoạt động này, vì nó liên quan đến việc phân biệt các giao dịch ILL đơn giản, không có ý nghĩa giao thức và không được mô tả cụ thể hơn trong tiêu chuẩn này.

...

...

...

9.1  ASN.1 đặc tả các APDU ILL

Điều này mô tả cú pháp trừu tượng của các APDU ILL trong Giao thức ILL đã được liệt kê tại điều 6. Các APDU ILL được định nghĩa bằng cách sử dụng ký hiệu ASN.1 định nghĩa trong Phụ lục 2 của ISO 8824.

Mỗi APDU được định nghĩa như là một kiểu có cấu trúc trong đó kiểu là một tập các giá trị có tên. Kiểu có cấu trúc được xác định bằng cách tham chiếu tới một hoặc nhiều kiểu khác mà có thể là kiểu có cấu trúc hoặc kiểu đơn giản. Kiểu đơn giản được định nghĩa bằng cách trực tiếp xác định các giá trị của nó.

Khi định nghĩa các kiểu có cấu trúc, ASN.1 xác định loại thành phần nào tạo nên kiểu có cấu trúc là tùy chọn, các loại thành phần nào là bắt buộc, và các giá trị cho phép của các loại này.

Các thông tin khác, ví dụ như một chuỗi là cố định hoặc biến đổi về kích thước, và các giá trị mặc định cũng được cung cấp.

Các chú giải bao gồm trong đặc tả ASN.1 là một phần của tiêu chuẩn này.

Một số kiểu tùy chọn được cung cấp các giá trị mặc định. Nếu giá trị của kiểu không tồn tại trong APDU đã mã hóa, giá trị mặc định sẽ được sử dụng. Nếu một kiểu không có giá trị mặc định, và giá trị cho kiểu đó không tồn tại trong APDU đã mã hóa, thì không có giá trị được kết hợp với kiểu đó.

Nếu một kiểu có cấu trúc là bắt buộc, nhưng được tạo duy nhất từ các kiểu thành phần tùy chọn thì ít nhất một trong các kiểu tùy chọn phải có, ví dụ id hệ thống.

Nếu một kiểu có cấu trúc là tùy chọn, nhưng được xây dựng từ một kiểu bắt buộc, thì kiểu thành phần là bắt buộc chỉ nếu kiểu có cấu trúc có mặt, ví dụ kiểu -vật mang tin-thông tin-cung cấp.

...

...

...

FILE ĐƯỢC ĐÍNH KÈM THEO VĂN BẢN

10  Sự phù hợp

10.1  Sự phù hợp tĩnh

Việc thực hiện tuyên bố phù hợp này phải có khả năng:

a) tuân thủ các quy định đối với một trong các vai trò sau:

• vai trò bên yêu cầu,

• vai trò bên đáp ứng,

...

...

...

• bất kỳ sự kết hợp của các bên nêu trên;

b) tối thiểu hỗ trợ các giao dịch đơn giản trong vai trò của bên yêu cầu hoặc bên đáp ứng; và hỗ trợ một hoặc cả hai giao dịch theo chuỗi và phân khu trong vai trò người trung gian;

c) hỗ trợ ít nhất là một trong các loại dịch vụ "mượn" và "sao chụp/không trả lại";

d) các loại dịch vụ bắt buộc YÊU CẦU, TRẢ LỜI ĐIỀU KIỆN, ĐÃ NHẬN, MẤT VÀ BÁO CÁO TRẠNG THÁI HOẶC LỖI cho tất cả các loại dịch vụ; và dịch vụ có điều kiện ĐÃ TRẢ LẠI với loại dịch vụ "cho mượn" (xem Chú thích 1);

e) hỗ trợ gọi các dịch vụ sau cho vai bên đáp ứng: các dịch vụ bắt buộc đã chuyển, Trả lời ILL, Trả lời hủy, Mất, Báo cáo trạng thái hoặc lỗi khi hỗ trợ bất kỳ loại hình dịch vụ nào; và các dịch vụ có điều kiện Đòi, Kiểm nhận quá hạn, Gia hạn, Trả lời gia hạn, Trả khi hỗ trợ loại hình dịch vụ "cho mượn" (xem Chú thích 1);

f) hỗ trợ gọi các dịch vụ sau đây cho vai trò người trung gian: các dịch vụ bắt buộc Yêu cầu ILL, Trả lời điều kiện, Báo cáo trạng thái, Báo cáo trạng thái hoặc lỗi, Đã chuyển, Đã Nhận, Trả lời ILL, Hủy, Trả lời Hủy, Mất; Hư hại và Thông báo khi hỗ trợ bất kỳ loại hình dịch vụ nào; và các dịch vụ có điều kiện Đòi, Quá hạn, đã Kiểm nhận, Gia hạn. Trả lời gia hạn, Đã Trả khi hỗ trợ loại hình dịch vụ "cho mượn" (xem Chú thích 1);

g) nhận các APDU với dữ liệu được định nghĩa cho tất cả các kiểu như quy định tại khoản 9;

h) hỗ trợ tất cả các loại bắt buộc đối với APDU được truyền như quy định tại khoản 9 (xem Chú thích 2);

i) xác định dữ liệu với nhiều tùy chọn được hỗ trợ bởi việc thực hiện (xem Chú thích 3).

...

...

...

CHÚ THÍCH 2: Khi hỗ trợ một kiểu bắt buộc, việc thực hiện phải luôn luôn xác định dữ liệu cho loại đó. Nếu kiểu có cấu trúc là bắt buộc, nhưng chỉ được cấu tạo từ các kiểu tùy chọn này không, khi đó ít nhất một trong các kiểu tùy chọn sẽ có mặt. Nếu kiểu có cấu trúc là tùy chọn, nhưng được xây dựng từ một kiểu bắt buộc, khi đó kiểu này là bắt buộc chỉ nếu kiểu có cấu trúc là hiện thời.

CHÚ THÍCH 3: Hỗ trợ một kiểu tùy chọn là chỉ khả năng việc thực hiện để xác định dữ liệu cho kiểu được hỗ trợ khi truyền các APDU. Dữ liệu cho các tùy chọn không cần phải luôn luôn có mặt. Các điều kiện cho sự hiện diện của dữ liệu trong các kiểu tùy chọn là một vấn đề thực hiện cục bộ. Không hỗ trợ một kiểu tùy chọn nghĩa là việc thực hiện không có khả năng cung cấp các dữ liệu được xác định cho kiểu này. Lưu ý rằng việc thực hiện vẫn có thể nhận được các kiểu tùy chọn không được hỗ trợ.

10.2  Sự phù hợp động

Để phù hợp với tiêu chuẩn này, việc thực hiện phải thể hiện chế độ/tính năng bên ngoài nhất quán với:

a) khi thực hiện một ASE ILL theo quy định của điều 8 của tiêu chuẩn này;

b) khả năng đề ra và các yêu cầu liên quan về thông báo tùy chọn, như được chỉ ra trong các APDU Yêu cầu ILL, Trả lời ILL và Đã chuyển;

c) đã thực hiện khả năng luôn gửi và nhận các APDU Đã chuyển, Đã Nhận, Đã Trả và Đã Kiểm nhận khi đóng vai trò người trung gian;

d) mã hóa các APDU như quy định tại điều 9 của tiêu chuẩn này. Có thể áp dụng nhiều lược đồ mã hóa cho giá trị của các kiểu dữ liệu được xác định bằng cách sử dụng ASN.1. Lược đồ mã hóa bắt buộc là các Quy tắc mã hóa cơ bản cho xác định cú pháp trừu tượng 1 trong ISO/IEC 8825. Một khả năng khác là lược đồ mã hóa được xác định bởi tiêu chuẩn EDIFACT, ISO 9735, và Phụ lục B.

10.3  Yêu cầu trình bày tuân thủ thực hiện giao thức

...

...

...

a) các vai trò nào được hỗ trợ;

b) các loại dịch vụ nào được hỗ trợ;

c) các loại giao dịch nào được hỗ trợ;

d) các dịch vụ nào được hỗ trợ;

e) các APDU nào được hỗ trợ;

f) các kiểu dữ liệu APDU nào được hỗ trợ;

g) các yêu cầu đối với các hệ thống khác liên quan đến APDU tùy chọn cho phép liên kết mạng, tức là một hệ thống có thể yêu cầu các hệ thống khác phải hỗ trợ tất cả các APDU tùy chọn khi liên kết mạng với hệ thống đó;

h) các quy tắc mã hóa nào được hỗ trợ;

i) một hoặc các phiên bản giao thức nào được hỗ trợ.

...

...

...

Phụ lục A

(Quy định)

Bảng trạng thái ILL

A.1  Tổng quan

Giao thức ILL định nghĩa một tập các trạng thái thông qua đó một giao dịch ILL tiến hành.

Trong Phụ lục này các bảng trạng thái được trình bày cho mỗi bên yêu cầu, bên đáp ứng và người trung gian. Các bảng này cho thấy mối tương quan giữa trạng thái của một máy giao thức ILL (ILLPM), những sự kiện đến xảy ra trong giao thức, các hành động thực hiện, và cuối cùng, trạng thái kết quả của ILLPM.

Phụ lục này chứa các bảng dưới đây:

a) Bảng A.1 quy định tên viết tắt và mô tả của mỗi sự kiện đến.

b) Bảng A.2 quy định tên viết tắt và mô tả của mỗi sự kiện đi.

...

...

...

d) Bảng A.4 quy định bảng trạng thái cho bên yêu cầu cho giai đoạn xử lý một giao dịch ILL. Bảng này mô tả đầy đủ tất cả các trạng thái với một giao dịch ILL liên quan đến một tài liệu không trả lại ví dụ như một bản sao chụp.

e) Bảng A.5 và A.6 quy định bảng trạng thái cho bên yêu cầu cho giai đoạn theo dõi một giao dịch ILL. Các bảng này chỉ áp dụng cho các giao dịch ILL liên quan đến một tài liệu trả lại ví dụ như một chuyên khảo.

f) Bảng A.7 quy định bảng trạng thái cho bên đáp ứng cho giai đoạn xử lý. Bảng này áp dụng cho tất cả các loại dịch vụ ILL, bao gồm các yêu cầu đối với các tài liệu được trả lại và không trả lại.

g) Bảng A.8 quy định bảng trạng thái cho bên đáp ứng cho giai đoạn theo dõi. Bảng này áp dụng cho tất cả các loại dịch vụ ILL, bao gồm các yêu cầu đối với các tài liệu được trả lại và không trả lại.

h) Bảng A.9 quy định bảng trạng thái cho người trung gian đóng vai trò của bên yêu cầu.

i) Bảng A.10 và A.11 quy định bảng trạng thái cho người trung gian đóng vai trò của bên đáp ứng

A.2  Quy ước

Giao của một sự kiện đến (hàng) và một trạng thái (cột) tạo thành một ô.

Trong bảng trạng thái, một ô trống là sự kết hợp của một sự kiện đến và một trạng thái không được định nghĩa cho giao thức ILL.

...

...

...

Một danh sách hành động bắt buộc bao gồm:

a) một sự kiện đi;

b) tùy chọn thay đổi với một biến giao thức cục bộ hoặc bộ hẹn giờ; và

c) trạng thái kết quả.

Một danh sách hành động có điều kiện bao gồm:

a) một biểu thức vị từ bao gồm các vị từ và các toán tử Bool (^ đại diện cho toán tử Bool Không); và

b) danh sách hành động bắt buộc. Danh sách này chỉ được sử dụng nếu biểu thị vị ngữ có giá trị đúng

Các hàng riêng biệt được cung cấp cho các sự kiện ban đầu và lặp để phân biệt giữa các danh sách hành động có thể khác nhau. Lưu ý rằng các hàng riêng biệt không được cung cấp cho các sự kiện lặp lại liên quan đến các dịch vụ và các APDU Thông báo, Yêu cầu trạng thái, Báo cáo trạng thái hoặc lỗi, Hư hỏng vì chúng không phải là lặp; mỗi lần xuất hiện như vậy được coi là một sự kiện ban đầu.

Các sự kiện yêu cầu dịch vụ ban đầu và lặp được phân biệt trên cơ sở các tiêu chí sau:

...

...

...

b) Đối với một người trung gian, yêu cầu dịch vụ ban đầu có thể có giá trị "Ngày và thời gian dịch vụ ban đầu" miễn là không có ngay trước yêu cầu dịch vụ cùng loại. Yêu cầu dịch vụ lặp có một giá trị xác định cho "Ngày và thời gian của dịch vụ ban đầu" và đứng ngay trước là một yêu cầu dịch vụ cùng loại với cùng giá trị ngày và thời gian trong các trường "Ngày và thời gian dịch vụ ban đầu" hoặc ";"Ngày và thời gian của dịch vụ" này. Một yêu cầu dịch vụ lặp có thể được gọi trong một trạng thái khác với yêu cầu ban đầu, do khả năng của các sự kiện đến.

CHÚ THÍCH: Yêu cầu dịch vụ tiếp theo có một hoặc nhiều Thông báo, Yêu cầu trạng thái, Báo cáo trạng thái hoặc lỗi và Hư hại, sau đó tiếp theo là một yêu cầu dịch vụ cùng loại như dịch vụ đầu tiên được xem xét ngay lập tức trước giá trị lặp thứ hai của cùng một dịch vụ.

Các sự kiện APDU ban đầu và lặp được phân biệt trên cơ sở là một APDU lặp đáp ứng các tiêu chuẩn sau đây:

a) một giá trị được cung cấp cho kiểu "Ngày và thời gian của dịch vụ ban đầu" và kiểu cấu trúc "Ngày thời gian dịch vụ".

b) giá trị này giống như biến giao thức Con dấu thời gian lặp.

A.3  Hành động phải được thực hiện theo Giao thức ILL

A.3.1  Tổng quan

Các bảng trạng thái Giao thức ILL xác định các hành động được thực hiện bởi máy Giao thức ILL về một sự kiện đi, những thay đổi với các biến giao thức cục bộ hoặc bộ tính giờ và trạng thái kết quả của ILLPM.

A.3.2  Nút giao không hợp lệ

...

...

...

A.3.3  Nút giao hợp lệ

Nếu nút giao của các sự kiện và trạng thái đến là hợp lệ, một trong những hành động sau đây được thực hiện:

a) nếu một ô chứa một danh sách hành động bắt buộc, các ILLPM có các hành động cụ thể;

b) nếu một ô chứa một danh sách hành động có điều kiện và nếu biểu thức vị từ là đúng, ILPM thực hiện các hành động theo quy định. Nếu biểu thức vị từ là sai, khi đó thay đổi hành động và trạng thái quy định cho ô này không được thực hiện.

CHÚ THÍCH: Đối với một số kết hợp của trạng thái và sự kiện đầu vào, các hành động khác nhau và thay đổi trạng thái là có thể, tùy theo giá trị của vị từ. Trong trường hợp này, cả hai khả năng được phản ánh trong bảng trạng thái trên các hàng riêng biệt.

A.4  Mối quan hệ với dịch vụ hỗ trợ

Các bảng trạng thái quy định trong phụ lục này không tính đến các tương tác với dịch vụ hỗ trợ, vì chúng phụ thuộc vào các ánh xạ được định nghĩa ngoài phạm vi tiêu chuẩn này. Đối với mỗi ánh xạ được định nghĩa, các trạng thái bổ sung và dịch chuyển trạng thái có thể được yêu cầu.

Bảng A.1 - Danh sách sự kiện đến

Tên viết tắt

...

...

...

ILLreq

FWDreq

ANSreq-CO

ANSreq-RY

ANSreq-UN

ANSreq-LP

ANSreq-WS

ANSreq-HP

ANSreq-ES

...

...

...

C-REPreq -

CANreq

CARreq +

CARreq -

SHIreq

RCVreq

RCLreq

DUEreq

RETreq

...

...

...

REAreq +

REAreq -

CHKreq

LSTreq

DAMreq

MSGreq

STQreq

STRreq

ILL

...

...

...

FORWARD.request

ILL-ANSWER.request: result = CONDITIONAL

ILL-ANSWER.request: result = RETRY

ILL-ANSWER.request: result = UNFILLED

ILL-ANSWER.request: result = LOCATION-PROVIDED

ILL-ANSWER.request: result = WILL-SUPPLY

ILL-ANSWER.request: result = HOLD PLACED

ILL-ANSWER.request: result = ESTIMATE

CONDITIONAL-REPLY.request: answer = yes

...

...

...

CANCEL.request

CANCEL-REPLY.request: answer = yes

CANCEL-REPLY.request: answer = no

SHIPPED.request

RECEIVED.request

RECALL.request

OVERDUE.request

RETURNED.request

RENEW.request

...

...

...

RENEW-ANSWER.request: answer = no

CHECKED-IN.request

LOST.request

DAMAGED.request

MESSAGE.request

STATUS-QUERY.request

STATUS-OR-ERROR-RE PORT, request

receive ILL-REQUEST APDU

FWD

...

...

...

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP+

C-REP-

CAN

...

...

...

CAR -

SHI

RCV

RCL

DUE

RET

REN

REA +

REA -

...

...

...

LST

DAM

MSG

STQ

STR

EXP

EXPIRY timeout

receive FORWARD-NOTIFICATION APDU

receive ILL-ANSWER APDU: result = CONDITIONAL

...

...

...

receive ILL-ANSWER APDU: result = UNFILLED

receive ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

receive ILL-ANSWER APDU: result - WILL-SUPPLY

receive ILL-ANSWER APDU: result = HOLD PLACED

receive ILL-ANSWER APDU: result = ESTIMATE

receive CONDITIONAL-REPLY APDU: answer = yes

receive CONDITIONAL-REPLY APDU: answer = no

receive CANCEL APDU

receive CANCEL-REPLY APDU: answer = yes

...

...

...

receive SHIPPED APDU

receive RECEIVED APDU

receive RECALL APDU

receive OVERDUE APDU

receive RETURNED APDU

receive RENEW APDU

receive RENEW-ANSWER APDU: answer = yes

receive RENEW-ANSWER APDU: answer = no

receive CHECKED-IN APDU

...

...

...

receive DAMAGED APDU

receive MESSAGE APDU

receive STATUS-QUERY APDU

receive STATUS-OR-ERROR-REPORT APDU

receive EXPIRED APDU

Transaction Timer Expiry

Bảng A.2 - Danh sách sự kiện đi

Tên viết tắt

Mô tả

...

...

...

FWDind

ANSind-CO

ANSind-RY

ANSind-UN

ANSind-LP

ANSind-WS

ANSind-HP

ANSind-ES

C-REPind +

...

...

...

CANind

CARind +

CARind -

SHIind

RCVind

RCLind

DUEind

RETind

RENind

...

...

...

REAind -

CHKind

LSTind

DAMind

MSGind

STQind

STRind

EXPind

ILL

...

...

...

ANS-CO

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP +

C-REP -

...

...

...

FORWARD.indication

ILL-ANSWER.indication: result = CONDITIONAL

ILL-ANSWER.indication: result = RETRY

ILL-ANSWER.indication: result = UNFILLED

ILL-ANSWER.indication: result = LOCATIONS-PROVIDED

ILL-ANSWER.indication: result = WILL-SUPPLY

ILL-ANSWER.indication: result = HOLD PLACED

ILL-ANSWER.indication: result = ESTIMATE

CONDITIONAL-REPLY.indication: answer = yes

...

...

...

CANCEL.indication

CANCEL-REPLY.indication: answer = yes

CANCEL-REPLY.indication: answer = no

SHIPPED.indication

RECEIVED.indication

RECALL.indication

OVERDUE.indication

RETURNED.indication

RENEW.indication

...

...

...

RENEW-ANSWER.indication: answer = no

CHECKED-IN.indication

LGST.indication

DAMAGED.indication

MESSAGE.indication

STATUS-QUERY.indication

STATUS-OR-ERROR-REPORT.indication

EXPIRY,indication

send ILL-REQUEST APDU

...

...

...

send ILL-ANSWER APDU: result = CONDITIONAL

send ILL-ANSWER APDU: result = RETRY

send ILL-ANSWER APDU: result = UNFILLED

send ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

send ILL-ANSWER APDU: result = WILL-SUPPLY

send ILL-ANSWER APDU: result = HOLD PLACED

send ILL-ANSWER APDU: result = ESTIMATE

send CONDITIONAL-REPLY APDU: answer = yes

send CONDITIONAL-REPLY APDU: answer = no

...

...

...

CAR +

CAR -

SHI

RCV

RCL

DUE

RET

REN

REA +

...

...

...

CHK

LST

DAM

MSG

STQ

STR

EXP

send CANCELAPDU

send CANCEL-REPLY APDU: answer = yes

...

...

...

send SHIPPED APDU

send RECEIVED APDU

send RECALL APDU

send OVERDUEAPDU

send RETURNED APDU

send RENEW APDU

send RENEW-ANSWER APDU: answer = yes

send RENEW-ANSWER APDU: answer = no

send CHECKED-IN APDU

...

...

...

send DAMAGED APDU

send MESSAGE APDU

send STATUS-QUERY APDU

send STATUS-OR-ERROR-REPORT APDU

send EXPIRED APDU

Bảng A.3 - Vị từ

Mã

Ỹ nghĩa

p1

...

...

...

p2

returns TRUE if the transaction-type parameter of the ILL-REQUEST service is chained, the protocol variable is TRUE and the transaction-id is valid for a sub-transaction

p3

returns TRUE if the transaction-type parameter of the ILL-REQUEST service is partitioned, the protocol variable is TRUE and the transaction-id is valid for a sub-transaction

p4

returns TRUE if the FWD protocol variable is TRUE

p5

returns TRUE if the RETURN protocol variable is TRUE

p6

...

...

...

p7

returns TRUE if a received APDU is in sequence

p8

returns TRUE if the most recent event that caused a state change is NOT (DUEreq, DUE)

p9

returns TRUE if the most recent event that caused a state change is NOT (RETreq, RET)

CHÚ THÍCH: Với các sự kiện lặp, khi một yêu cầu hoặc một APDU đến, các bảng trạng thái này không bao gồm một vị từ vì vị từ đã được đánh giá cho sự kiện ban đầu.

Bảng A.4 - Bảng trạng thái bên yêu cầu: Giai đoạn xử lý

...

...

...

PENDING

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

SHIPPED

ILLreq

p1 ILL PENDING

...

...

...

ILLreq

ILL

...

...

...

repeat

PENDING

...

...

...

C-REPreq

C-REP +

+

...

...

...

PENDING

C-REPreq

C-REP +

...

...

...

+ repeat

PENDING

...

...

...

C-REPreq

C-REP-

...

...

...

-

NOT-SUP-PLIED

ILUeq

...

...

...

PENDING

...

...

...

C-REPreq -

C-REP-

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

CANreq

CAN

...

...

...

CANCEL-

PENDING

...

...

...

CANreq

...

...

...

repeat

CANCEL-

...

...

...

PENDING

RCVreq

...

...

...

RCV (opt)

RCV (opt)

RCV(opt)

set RETURN
var

...

...

...

set RETURN
var

set RETURN
var

LSTreq

LST

...

...

...

LST

LOST

LOST

...

...

...

MSGreq

MSG
PENDING

MSG

MSG

MSG

MSG

MSG
SHIPPED

...

...

...

CONDITIONAL

STQreq

STQ

...

...

...

STQ
CONDITONAL

STQ

STQ
CANCELLED

STQ

SHIPPED

PENDING

NOT-SUP-

...

...

...

CANCEL-

PENDING

STRreq

STR

...

...

...

STR
CONDITIONAL

STR

CANCEL-

PENDING

STR
CANCELLED

STR

PENDING

NOT-SUP-PLIED

...

...

...

FWD

FWDind

FWDind

...

...

...

PENDING

PENDING

FWD

FWDind

...

...

...

repeat

PENDING

...

...

...

ANS-CO

p7

ANSind-CO

ANSind-CO
CONDITIONAL

p7

ANSind-CO

...

...

...

ANSind-CO CONDITIONAL

NOT-SUP-PLIED

ANSind-CO CANCEL-

CANCELLED

...

...

...

PENDING

ANS-CO

^p7

ANSind-CO

...

...

...

^p7

ANSind-CO
CANCELLED

ANSind-CO

...

...

...

ANSind-CO

NOT-SUP-

CANCEL-

ANS-CO

ANSind-CO

ANSind-CO

...

...

...

ANSind-CO

ANSind-CO
CANCELLED

repeat

ANS-RY

...

...

...

ANSind-RY

ANSind-RY

NOT-SUP-
PLIED

NOT-SUP-
PLIED

NOT-SUP-
PLIED

ILLreq

...

...

...

PENDING

...

...

...

ANS-RY
repeat

ANSind-RY

...

...

...

NOT-SUP-
PLIED

...

...

...

ANSind-UN

ANSind-UN

ANSind-UN

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-UN

ANSind-UN

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

ANS-LP

ANSind-LP

ANSind-LP

ANSind-LP

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-LP

...

...

...

ANSind-LP

repeat

NOT-SUP-PLIED

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

ANSind-WS

...

...

...

ANSind-WS

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

ANSind-WS

ANSind-WS

repeat

...

...

...

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

SHIPPED

ANS-HP

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

PENDING

NOT-SUP-PLIED

...

...

...

CANCEL-

SHIPPED

PENDING

...

...

...

ANS-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

...

...

...

PENDING

SHIPPED

repeat

...

...

...

CONDITIONAL

ANS-ES

ANSind-ES

ANSind-ES

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

...

...

...

ANS-ES

ANSind-ES

repeat

...

...

...

NOT-SUP-PLIED

CAR +

...

...

...

CARind +

CARind +

...

...

...

CANCELLED

CAR +

CARind +

...

...

...

repeat

CANCELLED

CAR -

...

...

...

CARind -

CARind -

CARind -

PENDING

...

...

...

PENDING

SHIPPED

CAR -

CARind -

...

...

...

CARind -

repeat

PENDING

...

...

...

SHI

SHIind

SHIind

SHIind

...

...

...

SHIPPED

SHIPPED

SHIPPED

ILLeq

p1 ILL

...

...

...

PENDING

...

...

...

SHI

...

...

...

repeat

SHIPPED

DUE

...

...

...

DUEind

DUEind

DUEind

set RETURN

...

...

...

set RETURN

set RETURN

var = TRUE

...

...

...

var = TRUE

RCL

RCLind

RCLind

...

...

...

set RETURN

set RETURN

set RETURN

CHK

...

...

...

CHKind

CHKind

CHKind

set RETURN

...

...

...

set RETURN

set RETURN

MSG

MSGind

MSGind

MSGind

...

...

...

MSGind

MSGind

PENDING

CONDITIONAL

...

...

...

STQ

STQind

STQind

STQind
CONDITIONAL

STQind

STQind

STQind

...

...

...

PENDING

CANCELLED

STR

STRind

STRind

...

...

...

STRind

STRind

STRind

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

...

...

...

SHIPPED

EXP

EXPind

EXPind

EXPind
NOT-SUP-PLIED

EXPind

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

LST

...

...

...

LSTind

LSTind

LOST

...

...

...

LOST

LOST

Bảng A.5 - Bảng trạng thái bên yêu cầu: Giai đoạn theo dõi (Phần 1)

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/OVERDUE

...

...

...

RCV(opt)

OVERDUE

RCVreq

repeat

RCV(opt)

RECEIVED

...

...

...

RET

req

p5

RET (opt)

RETURNED

RET (opt)

RETURNED

...

...

...

RETURNED

RETreq repeat

.

RCVreq

...

...

...

RCV (opt)

RENreq

p5 REN

RENEW/PENDING

REN

RENreq Repeat

...

...

...

REN

REN

LSTreq

p5 LST

LOST

LST LOST

LST LOST

LST LOST

...

...

...

DAMreq

DAM

DAM

DAM

...

...

...

MSGreq

MSG

MSG

MSG

MSG

STQreq

STQ

STQ

...

...

...

STQ

STRreq

STR

SIR

STR

STR

ANS-WS

...

...

...

RECEIVED

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/ OVERDUE

ANS-WS repeat

ANSind-WS

...

...

...

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/OVERDUE

ANS-HP

ANSind-HP

RECEIVED

...

...

...

RENEW/PENDING

ANSind-HP

RENEW/OVERDUE

ANSind-HP

NOT-RCVD/OVERDUE

ANS-HP repeat

ANSind-HP

RECEIVED

ANSind-HP

...

...

...

ANSind-HP

RENEW/OVERDUE

ANSind HP

NOT-RCVD/OVERDUE

CAR -

CARind -

RECEIVED

CARind-

RENEW/PENDING

...

...

...

RENEW/OVERDUE

CARind -

NOT-RCVD/OVERDUE

CAR - repeat

CARind -

RECEIVED

CARind -

RENEW/PENDING

CARind -

...

...

...

CARind -

NOT-RCVD/OVERDUE

SHI

SHIind

RECEIVED

SHIind

RENEW/PENDING

SHIind

RENEW/OVERDUE

...

...

...

NOT-RCVD/OVERDUE

SHI
repeat