Tiêu chuẩn Quốc gia TCVN 11642-1:2016 ISO 10161-1:2014 Thông tin và tư liệu-Liên kết hệ thống mở-Đặc tả giao thức ứng dụng mượn liên thư viện-Phần 1: Đặc tả giao thức

TIÊU CHUẨN QUỐC GIA

TCVN 11642-1:2016

ISO 10161-1:2014

THÔNG TIN VÀ TƯ LIỆU - LIÊN KẾT HỆ THỐNG MỞ - ĐẶC TẢ GIAO THỨC ỨNG DỤNG MƯỢN LIÊN THƯ VIỆN - PHẦN 1: ĐẶC TẢ GIAO THỨC

Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Protocol Specification - Part 1: Protocol specification

Lời nói đầu

TCVN 11642-1:2016 hoàn toàn tương đương với ISO 10161-1:2014

TCVN 11642-1:2016 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/TC 46 Thông tin và tư liệu biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Bộ tiêu chuẩn TCVN 11642 (ISO 10161) Thông tin và tư liệu - Liên kết hệ thống mở - Đặc tả giao thức ứng dụng mượn liên thư viện gồm các tiêu chuẩn sau:

- TCVN 11642-1:2016 (ISO 10161-1:2014), Phần 1: Đặc tả giao thức.

- TCVN 11642-2:2016 (ISO 10161-2:2014). Phần 2: Hình thức trình bày tuân thủ triển khai giao thức (PICS.).

Lời giới thiệu

Tiêu chuẩn này được xuất bản để tạo thuận lợi cho việc kết nối các hệ thống máy tính. Tiêu chuẩn liên quan đến các tiêu chuẩn quốc tế khác trong bộ tiêu chuẩn được định nghĩa trong mô hình tham chiếu cho kết nối hệ thống mở (ISO/IEC 7498), mô hình tham khảo này chia nhỏ lĩnh vực tiêu chuẩn hóa đối với kết nối thành một loạt các lớp đặc tả, mỗi lớp có kích thước quản lý được.

Mục đích của kết nối hệ thống mở là cho phép, với tối thiểu các thỏa thuận kỹ thuật ngoài các tiêu chuẩn kết nối, kết nối các hệ thống máy tính

a) từ các nhà sản xuất khác nhau,

b) dưới sự quản lý khác nhau,

c) có mức độ phức tạp khác nhau, và

d) có thời gian phục vụ khác nhau.

Tiêu chuẩn này cung cấp một đặc tả giao thức cho ứng dụng mượn liên thư viện (ILL). Giao thức ILL hoạt động trong lớp ứng dụng và cho phép các bên tham gia vào một giao dịch ILL để phát triển thông qua giao dịch ILL một cách trình tự.

Giao thức ILL đã được thiết kế để hỗ trợ các dịch vụ ILL được định nghĩa trong ISO 10160, Định nghĩa dịch vụ ứng dụng ILL, mà thường yêu cầu các dịch vụ cung cấp bên ngoài để thực hiện một yêu cầu ILL. Giao thức ILL mang thông tin cho phép gọi các dịch vụ cung cấp bên ngoài bao gồm cả tự động và qua người điều hành trung gian.

Tiêu chuẩn này là một trong một số tiêu chuẩn liên quan hỗ trợ việc kết nối các hệ thống thư viện. Tiêu chuẩn này có thể được sử dụng riêng hoặc sử dụng theo cách hỗ trợ các ứng dụng thư viện đòi hỏi một hỗn hợp của các dịch vụ truyền thông. Ví dụ, ISO 23950, hỗ trợ truy cập từ xa vào cơ sở dữ liệu thư mục, có thể được sử dụng kết hợp với giao thức ILL để có được thông tin xác định tài liệu. Việc kiểm soát và quản lý các tương tác giữa các ứng dụng thư mục đó là những vấn đề cục bộ nằm ngoài phạm vi của tiêu chuẩn này.

Các vấn đề an ninh và kế toán có liên quan đến hoạt động ILL cần được nghiên cứu thêm.

Kỹ thuật đặc tả được sử dụng trong tiêu chuẩn này là phù hợp với các kỹ thuật được sử dụng trong việc xác định các giao thức OSI khác. Trong hầu hết tiêu chuẩn này, kỹ thuật đặc tả này là tự diễn giải. Cú pháp trừu tượng của các đơn vị dữ liệu của giao thức ứng dụng (APDU) ILL được xác định bằng kỹ thuật đặc tả ASN.1 quy định trong ISO 8824.

Tiêu chuẩn này chứa bảy phụ lục. Phụ lục A đến D là quy định. Phụ lục A quy định các bảng trạng thái cho giao thức ILL. Phụ lục B quy định các quy tắc mã hóa để tạo ra một cú pháp truyền tương thích với EDIFACT như định nghĩa trong ISO 9735. Phụ lục C quy định các định danh đối tượng được gán trong tiêu chuẩn và yêu cầu đăng ký. Phụ lục D xác định các thủ tục đăng ký cho định nghĩa kiểu dữ liệu bên ngoài ILL. Phụ lục E là ví dụ về một mục đăng ký kiểu dữ liệu bên ngoài ILL. Phụ lục F mô tả các ánh xạ có thể có của giao thức này vào các dịch vụ hỗ trợ. Phụ lục G mô tả phương pháp có thể sử dụng một giao thức cung cấp tài liệu kèm theo giao thức ILL.

THÔNG TIN VÀ TƯ LIỆU - LIÊN KẾT HỆ THỐNG MỞ - ĐẶC TẢ GIAO THỨC ỨNG DỤNG MƯỢN LIÊN THƯ VIỆN - PHẦN 1: ĐẶC TẢ GIAO THỨC

Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Protocol Specification - Part 1: Protocol specification

1  Phạm vi áp dụng

Tiêu chuẩn này xác định giao thức cho một yếu tố dịch vụ ứng dụng ILL (ASE). Tiêu chuẩn quy định trạng thái phải được biểu hiện bởi một hệ thống để tham gia vào việc cung cấp các dịch vụ mượn liên thư viện.

Tiêu chuẩn cung cấp cách trình bày hình thái của quy tắc về trạng thái của từng đối tượng hoặc nhiều đối tượng tham gia vào một giao dịch ILL. Tiêu chuẩn quy định

a) các hành động được thực hiện khi nhận các dịch vụ ban đầu yêu cầu từ một người sử dụng dịch vụ ILL,

b) các hành động được thực hiện khi nhận các đơn vị dữ liệu giao thức ứng dụng (PDU), và

c) các hành động được thực hiện như là một kết quả của các sự kiện trong hệ thống cục bộ.

Tiêu chuẩn cung cấp một đặc tả (tại điều 9) của cú pháp trừu tượng cần thiết để truyền đạt các APDU của giao thức ILL.

Tiêu chuẩn nêu các yêu cầu phù hợp phải được đáp ứng bởi các bên triển khai giao thức này (điều 10).

Phạm vi của giao thức ILL được giới hạn với kết nối hệ thống; giao thức ILL này không quy định hoặc hạn chế khả năng triển khai của các giao diện trong một hệ thống máy tính. Hệ thống máy tính có thể bao gồm các cả các máy trạm độc lập cho đến máy tính lớn.

Tiêu chuẩn này được thiết kế để sử dụng bởi các thư viện, các dịch vụ thông tin như các trung tâm mục lục liên hợp và bất kỳ hệ thống nào xử lý thông tin thư mục. Những hệ thống này có thể tham gia vào một giao dịch mượn liên thư viện với vai trò của bên yêu cầu (tức là người khởi tạo các yêu cầu ILL); bên đáp ứng (tức là một người cung cấp tài liệu hoặc thông tin thư mục) và/hoặc người trung gian (tức là một cơ quan hoạt động với tư cách là đại diện cho bên yêu cầu tìm các bên đáp ứng phù hợp).

Các cấu trúc liên kết mạng khác nhau được hỗ trợ, từ tương tác hai bên đơn giản, đến tương tác nhiều bên.

2  Tài liệu viện dẫn

Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

TCVN 6380:2007 (ISO 2108:2005) Thông tin và Tư liệu - Mã số tiêu chuẩn quốc tế cho sách (ISBN).

TCVN 6381:2015 (ISO 3297:2007)Thông tin và Tư liệu - Mã số tiêu chuẩn quốc tế cho xuất bản phẩm nhiều kỳ (ISSN)).

TCVN 6558:2008 (ISO 4217:2001), Mã thể hiện các đồng tiền và quỹ.

TCVN ISO 8601, Định dạng trao đổi và phần tử dữ liệu - Trao đổi thông tin - Biểu diễn ngày tháng và thời gian.

TCVN ISO 9735, Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải (EDIFACT) - Các quy tắc cú pháp mức ứng dụng).

TCVN 10583-1:2014 (ISO/IEC 9834-1:2012), Công nghệ thông tin - Thủ tục điều hành của cơ quan đăng ký định danh đối tượng - Phần 1: Thủ tục chung và các cung trên cùng của cây định danh đối tượng quốc tế).

TCVN 10583-2:2014 (ISO/IEC 9834-2:2012), Công nghệ thông tin - Liên kết hệ thống mở - Thủ tục điều hành của cơ quan đăng ký OSI - Phần 2: Thủ tục đăng ký cho kiểu tài liệu OSI.

ISO 646, Information processing - ISO 7-bit coded character set for information interchange (Công nghệ thông tin - Bộ mã chuẩn 7-bit của ISO dùng trao đổi thông tin).

ISO/IEC 8824-1:2008, Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.I) (Công nghệ thông tin - Kết nối các hệ thống mở - Đặc tả ký hiệu cú pháp trừu tượng 1 (ASN.I)).

ISO/IEC 8825, Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.I) (Công nghệ thông tin - Kết nối các hệ thống mở - Đặc tả các quy tắc mã hóa cơ bản cho ký hiệu cú pháp trừu tượng 1 (ASN.I)).

ISO 10160, Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition (Thông tin và tư liệu - Kết nối các hệ thống mở - Định nghĩa dịch vụ ứng dụng mượn liên thư viện).

3  Thuật ngữ và định nghĩa

Trong tiêu chuẩn này, sử dụng các thuật ngữ và định nghĩa sau đây.

3.1

Các định nghĩa mô hình tham chiếu (reference model definitions)

CHÚ THÍCH: Tiêu chuẩn này dựa trên các khái niệm được quy định trong ISO 7498. Các thuật ngữ dưới đây được nhắc lại nhằm thuận tiện cho người đọc.

3.1.1

Lớp ứng dụng (application layer)

Lớp thứ bảy và lớp cao nhất trong mô hình tham chiếu cho liên kết hệ thống mở (OSI), mà sử dụng như cửa sổ giữa các quá trình-ứng dụng tương ứng mà đang sử dụng OSI để trao đổi thông tin có ý nghĩa.

3.1.2

Thực thể ứng dụng (application-entity)

Các khía cạnh của một quá trình ứng dụng thích hợp với OSl

3.1.3

Quá trình ứng dụng (application-process)

Yếu tố trong một hệ thống mở thực, thực hiện việc xử lý thông tin cho một ứng dụng cụ thể

3.1.4

Đơn vị dữ liệu giao thức ứng dụng (application-protocol-data-unit)

Đơn vị dữ liệu được quy định trong một giao thức ứng dụng và bao gồm thông tin giao thức ứng dụng và có thể gồm cả dữ liệu người sử dụng ứng dụng

3.1.5

Yếu tố dịch vụ ứng dụng (application-service-element)

Một phần của một thực thể ứng dụng cung cấp một khả năng môi trường OSI, sử dụng dịch vụ cơ bản khi thích hợp

3.1.6

Dịch vụ lớp N (N-service)

Khả năng của lớp (N) và các lớp bên dưới nó, mà được cung cấp cho (N + 1) thực thể tại ranh giới giữa lớp (N) và lớp (N + 1).

CHÚ THÍCH Dịch vụ ứng dụng không cung cấp khả năng cho các thực thể lớp cao hơn, mà là cho các quá trình ứng dụng.

3.1.7

Dịch vụ trình diễn (presentation-service)

Khả năng của lớp trình bày và các lớp bên dưới nó, được cung cấp cho các thực thể ứng dụng ở ranh giới giữa lớp trình bày và lớp ứng dụng

3.1.8

Cú pháp truyền (transfer-syntax)

Cú pháp cụ thể được sử dụng trong việc truyền dữ liệu giữa các hệ thống mở

3.2  Định nghĩa ký hiệu cú pháp trừu tượng 1

CHÚ THÍCH: Tiêu chuẩn này sử dụng các thuật ngữ dưới đây được định nghĩa trong ISO/IEC 8824.

3.2.1

Kiểu dữ liệu (data type)

Kiểu (type)

Tập các giá trị được đặt tên.

3.2.2

Kiểu đơn giản (simple type)

Kiểu được xác định bằng cách xác định trực tiếp các giá trị của nó.

3.2.3

Kiểu có cấu trúc (structured type)

Kiểu được xác định bằng cách tham chiếu tới một hoặc nhiều kiểu khác.

3.2.4

Kiểu thành phần (component type)

Một trong những kiểu được tham chiếu khi xác định một kiểu có cấu trúc.

3.2.5

Giá trị (value)

Thành tố được phân biệt của một tập các giá trị.

3.3  Định nghĩa dịch vụ trình diễn

CHÚ THÍCH: Tiêu chuẩn này sử dụng thuật ngữ sau đây được định nghĩa trong ISO 8822.

3.3.1

Cú pháp trừu tượng (abstract syntax)

Các khía cạnh về quy tắc được sử dụng trong đặc tả hình thức của dữ liệu mà độc lập với kỹ thuật mã hóa để thể hiện dữ liệu.

3.4  Định nghĩa cấu trúc lớp ứng dụng

CHÚ THÍCH: Tiêu chuẩn này sử dụng các thuật ngữ sau đây được định nghĩa trong ISO/IEC 9545.

3.4.1

Liên kết ứng dụng (application-association)

Mối quan hệ hợp tác giữa hai lệnh gọi thực thể ứng dụng với mục đích trao đổi thông tin và điều phối các hoạt động chung của chúng

CHÚ THÍCH 1: Mối quan hệ này được hình thành bởi sự trao đổi thông tin điều khiển giao thức ứng dụng bằng cách sử dụng dịch vụ trình diễn.

3.4.2

Ngữ cảnh ứng dụng (application-context)

Bộ các quy tắc dùng chung bởi hai lệnh gọi thực thể ứng dụng bằng cách quản trị cách vận hành của các lệnh gọi đó để cho phép chúng cùng vận hành.

CHÚ THÍCH 1 Một ngữ cảnh ứng dụng là một lược đồ khái niệm dùng chung để truyền thông cho toàn nhân loại (universe).

3.4.3

Định nghĩa ngữ cảnh ứng dụng (application-context-definition)

Mô tả một ngữ cảnh ứng dụng

3.4.4

Lệnh gọi thực thể ứng dụng (application-entity-invocation)

Sử dụng một phần hoặc tất cả các khả năng của một thực thể ứng dụng nhất định để hỗ trợ các yêu cầu truyền thông của một lệnh gọi quy trình ứng dụng.

3.4.5

Lệnh gọi quy trình ứng dụng (application-process-invocation)

Sử dụng của một phần hoặc tất cả các khả năng của một quá trình ứng dụng nhất định nhằm hỗ trợ một trường hợp xử lý thông tin cụ thể

3.5  Định nghĩa các giao thức dịch vụ

3.5.1

Chỉ thị ban đầu (indication primitive)

Thể hiện một tương tác trong đó bên cung cấp dịch vụ, hoặc:

a) chỉ ra rằng bản thân tương tác đó khởi tạo gọi một số thủ tục; hoặc

b) chỉ ra rằng thủ tục được gọi bởi người sử dụng dịch vụ tại một điểm truy cập dịch vụ ngang hàng.

3.5.2

Dịch vụ không xác nhận (non-confirmed service)

Phần phân biệt của dịch vụ (N) tổng mà không dẫn đến một xác nhận rõ ràng từ các bên cung cấp dịch vụ với người sử dụng dịch vụ khởi tạo.

3.5.3

Dịch vụ bên cung cấp khởi tạo (provider-initiated service)

Phần phân biệt của dịch vụ (N) tổng được khởi tạo bởi bên cung cấp dịch vụ chứ không phải là người sử dụng dịch vụ.

3.5.4

Yêu cầu ban đầu (request primitive)

Thể hiện một tương tác, trong đó một người sử dụng dịch vụ gọi một số thủ tục

3.5.5

Dịch vụ ban đầu (service primitive)

Thể hiện một tương tác độc lập với phần mềm triển khai giữa người sử dụng dịch vụ và bên cung cấp dịch vụ.

3.5.6

Bên cung cấp dịch vụ (service-provider)

Một số thực thể cung cấp dịch vụ cho người sử dụng ngang hàng.

3.5.7

Người sử dụng dịch vụ (service-user)

Thực thể trong một hệ thống mở sử dụng một dịch vụ.

3.6  Các định nghĩa ILL

CHÚ THÍCH: Tiêu chuẩn này sử dụng cho các định nghĩa sau đây cho các tên và giá trị tham chiếu giá trị ASN.1 tương ứng với các kiểu dữ liệu đơn giản, như quy định tại Điều 9.

3.6.1

Sổ tài khoản (account-number)

Số hiệu một tài khoản được tạo ra của một thẻ tín dụng hoặc thẻ ghi nợ.

CHÚ THÍCH 1: Bên yêu cầu thường đã được chỉ định một tài khoản riêng biệt cho từng bên đáp ứng.

3.6.2

Chữ cái-số bổ sung (additional-no-letters)

Chữ cái-số bổ sung (additional-numbers-letters)

Số hoặc mã xác định một tài liệu.

3.6.3

Đã được chuyển tiếp (already-forwardes)

Chỉ thị của bên đáp ứng rằng một yêu cầu ILL đã được chuyển tiếp.

3.6.4

Danh sách đã được thử (already-tried-list)

Danh sách các tổ chức đã được tiếp cận nhưng chưa thể cung cấp tài liệu được yêu cầu.

3.6.5

Câu trả lời (answer)

Mã thể hiện một phản hồi có hoặc không có

3.6.6

Đang đóng bìa (at bindery)

Có tài liệu yêu cầu nhưng đang đóng bìa

3.6.7

Tác giả (author)

Tên cá nhân hoặc tập thể chịu trách nhiệm về nội dung trí tuệ và nghệ thuật của một tài liệu, bao gồm cả các nhà soạn nhạc, người sáng tạo hoặc khởi tạo tài liệu này

3.6.8

Tác giả bài (author-of-article)

Tác giả của một tài liệu là một phần cấu thành của một tài liệu khác

3.6.9

APDU cấu trúc kém (badly-structured-APDU)

Cấu trúc của một APDU nhận được không phù hợp với ký hiệu và mã hóa chuẩn được định nghĩa trong ISO 8824 và ISO 8825, hoặc với mã hóa EDIFACT được định nghĩa trong ISO 9735 và Phụ lục B của tiêu chuẩn này.

VÍ DỤ: APDU nhận được không đáp ứng độ dài đã đề ra.

3.6.10

Được xử lý để cung cấp (being-processed-for-supply)

Tài liệu được tìm thấy, sao chụp, và/hoặc bao gói để cung cấp.

3.6.11

Ký hiệu xếp giá (call-number)

ký hiệu gán cho một tài liệu cho biết vị trí vật lý của nó trong tổ chức chủ sở hữu

3.6.12

Có thể gửi kiểm nhận (can-send-CHECKED-IN)

Chỉ thị bởi bên đáp ứng là có khả năng cung cấp CHECKED-IN APDU( APDU Kiểm nhận)

3.6.13

Có thể gửi Nhận (can-send- RECEIVED)

Chỉ thị bởi bên yêu cầu là có khả năng cung cấp RECEIVED-APDU( APDU Nhận)

3.6.14

Có thể gửi Trả (can-send- RETURNED)

Chỉ thị bởi bên yêu cầu là có khả năng cung cấp RETURNED-APDU (APDU Trả)

3.6.15

Có thể gửi Vận chuyển (can-send- SHIPPED)

Chỉ thị bởi bên đáp ứng là có khả năng cung cấp SHIPPED-APDU (APDU chuyển)

3.6.16

Không thể gửi tiếp (cannot-send- onward)

Chỉ thị cho thấy người trung gian không thể chuyển đi một yêu cầu do các vấn đề truyền thông

3.6.17

Các đơn vị tính phí (chargeable-units)

Số đơn vị được cung cấp phải tính phí

3.6.18

Phí (charges)

Phí của bên đáp ứng cho việc cung cấp các dịch vụ yêu cầu

3.6.19

Thành phố (city)

Cụm từ được sử dụng để xác định một thành phố

3.6.20

Định danh khách hàng (client-identifier)

Số hoặc mã được sử dụng để xác định khách hàng duy nhất

3.6.21

Tên khách (client-name)

Tên cá nhân hoặc tổ chức đã yêu cầu tài liệu

3.6.22

Yêu cầu về chữ ký khách (client-signature-required)

Quy định của bên đáp ứng rằng khách phải ký vào bản chữ ký kèm theo tài liệu

3.6.23

Vị thế của khách (client-status)

Trình độ chuyên môn hoặc chức vụ của khách hàng

3.6.24

Điều kiện (conditions)

Mã được sử dụng để chỉ ra các điều kiện để một tài liệu có thể được mượn

3.6.25

Tuân thủ bản quyền (copyright-compliance)

Ký hiệu của bên yêu cầu chỉ ra các quy định hoặc luật về bản quyền đang áp dụng mà bên yêu cầu đang tuân thủ

3.6.26

Thông tin tương quan (correlation-information)

Thông tin được sử dụng có tương quan một báo cáo lỗi với yêu cầu dịch vụ mà báo cáo đó liên quan

3.6.27

Chi phí (cost)

Số tiền yêu cầu, thu hoặc lập hóa đơn bởi bên đáp ứng cho dịch vụ được cung cấp

3.6.28

Dự toán chi phí (cost-estimate)

Dự toán chi phí để cung cấp các dịch vụ được yêu cầu

3.6.29

Chi phí vượt quá giới hạn (cost-exceeds-limit)

Chỉ thị của bên đáp ứng là chi phí tối thiểu để cung cấp theo yêu cầu lớn hơn số tiền được phép

3.6.30

Nước (country)

Cụm từ được sử dụng để xác định một quốc gia

3.6.31

Mã tiền tệ (currency-code)

Mã nhận dạng đồng tiền của một số lượng tiền, theo TCVN 6558 (ISO 4217)

3.6.32

Trạng thái hiện hành (current-state)

Mã nhận dạng trạng thái của giao dịch ILL

3.6.33

Ngày kiểm nhận (date-checked-in)

Ngày một tài liệu cho mượn được nhận lại bởi bên đáp ứng

3.6.34

Ngày đến hạn trả (date-due)

Ngày một tài liệu cho mượn phải được trả lại cho bên đáp ứng

CHÚ THÍCH 1 Điều này phản ánh ngày đến hạn muộn nhất.

3.6.35

Ngày hồi âm (date-for-reply)

Ngày bên đáp ứng đưa lại câu trả lời

3.6.36

Ngày chuyển đổi cuối cùng (date-of-last-transition)

Ngày sự chuyển đổi trạng thái cuối cùng xảy ra

3.6.37

Ngày phục vụ gần đây nhất (date-of-most-recent-service)

Ngày sự kiện dịch vụ gần đây nhất xảy ra tại hệ thống cung cấp các báo cáo tình trạng

CHÚ THÍCH 1 Dịch vụ xuất hiện trong hệ thống cung cấp các báo cáo trạng thái hoặc dịch vụ phản ánh trong một APDU nhận được.

3.6.38

Ngày phát sinh dịch vụ (date-of-service)

Ngày một dịch vụ liên quan đến một giao dịch ILL được gọi

3.6.39

Ngày nhận (date-received)

ngày bên yêu cầu nhận được tài liệu

3.6.40

Ngày yêu cầu (date-requested)

Ngày yêu cầu ILL được khởi xướng bởi bên yêu cầu

3.6.41

Ngày trả (date-returned)

Ngày một tài liệu được trả lại cho bên đáp ứng

3.6.42

Ngày vận chuyển (date-shipped)

Ngày tài liệu được vận chuyển cho bên yêu cầu

3.6.43

Dịch vụ cung cấp (desired-due-date)

Dịch vụ hoặc phương pháp cung cấp được sử dụng trong vận chuyển một tài liệu được yêu cầu

CHÚ THÍCH 1 có thể sử dụng cách cung cấp vật lý hoặc điện tử.

3.6.44

Ngày đến hạn mong muốn (desired-due-date)

Ngày đến hạn đề xuất cho lần mượn gia hạn

3.6.45

Id giao dịch trùng lặp (duplicate-transaction-id)

Giá trị id giao dịch của một APDU YÊU CẦU ILL bị trùng lặp không hợp lệ, tức là giá trị giống hệt một YÊU CẦU ILL hiện có từ cùng một bên yêu cầu.

3.6.46

Phiên bản (edition)

Tất cả các bản của một tài liệu được xuất bản từ một bản chính hoặc các hình ảnh thuộc cùng một loại, tài liệu có cùng một nội dung, và, trong trường hợp các tài liệu không phải là sách, do một cơ quan xuất bản cụ thể hoặc nhóm các cơ quan đó phát hành

3.6.47

Cung cấp điện tử (electronic delivery)

Cung cấp bản điện tử của tài liệu thông qua một cơ chế truyền dữ liệu dựa trên cơ sở hạ tầng viễn thông

CHÚ THÍCH 1 Không bao gồm việc cung cấp các vật mang tin dưới dạng từ tính hoặc quang học hữu hình.

3.6.48

Ngày dự kiến có được tài liệu (estimated-date-available)

Ngày một tài liệu được đặt giữ dự kiến sẽ trở thành sẵn có

3.6.49

Ngày hết hạn (expiry date)

Ngày một giao dịch ILL hết hạn tự động

3.6.50

Cờ hết hạn (expiry flag)

Chỉ thị cho biết ngày hết hạn đã được đặt cho một giao dịch ILL, và nếu như vậy, cho dù ngày đó là "cần trước ngày", hoặc một ngày khác nào đó

3.6.51

Địa chỉ cung cấp bưu chính mở rộng (extended-postal-delivery-address)

Thông tin bổ sung tại địa chỉ bưu chính cần thiết để xác định chính xác điểm cung cấp, ví dụ phòng và số tầng trong một tòa nhà lớn

3.6.52

Bên đáp ứng cuối cùng (final-responder)

Tổ chức cung cấp một tài liệu yêu cầu

CHÚ THÍCH 1: Thuật ngữ này được sử dụng khi cần thiết phân biệt bên đáp ứng một giao dịch ILL và bên đáp ứng một giao dịch con ILL

3.6.53

Cờ chuyển tiếp (forward flag)

Chỉ thị một YÊU CẦU- ILL đã được chuyển tiếp từ một trung gian

3.6.54

Chú thích chuyển tiếp (forward note)

Chú thích bổ sung vào YÊU CẦU- ILL bởi bên đáp ứng khi nó được chuyển tiếp đến một bên đáp ứng mới.

3.6.55

Vấn đề chung (general-problem)

Mã cho biết nhà cung cấp dịch vụ ILL phát hiện một vấn đề chung xảy ra với một APDU nhận được mà không có liên quan đến một trong hai id giao dịch hoặc chuyển đổi trạng thái cho phép

3.6.56

Loại APDU ILL (ILL-APDU-type)

Mã nhận dạng loại APDU nhận được

3.6.57

Loại dịch vụ ILL (ILL-service-type)

Mã cho loại dịch vụ ILL yêu cầu

CHÚ THÍCH 1 Các mã này có thể được liệt kê theo thứ tự ưu tiên.

3.6.58

Giao dịch ILL (ILL-transaction)

Ví dụ hoàn chỉnh duy nhất của toàn bộ chu trình ILL, bao gồm tất cả các hành động, dịch vụ gốc và các thông báo liên quan từ yêu cầu ILL ban đầu cho đến khi chu trình được kết thúc, như bằng sự trả lại các tài liệu yêu cầu

3.6.59

Đang xử lý (in-process)

Tài liệu đã nhận được nhưng vẫn chưa sẵn sàng cho sử dụng

3.6.60

Đang sử dụng/cho mượn (in use/on-loan)

Có sở hữu tài liệu nhưng hiện đang được sử dụng bởi một khách hàng hoặc là cho cơ quan khác mượn

3.6.61

Bên yêu cầu ban đầu (initial-requester)

Cá nhân hoặc tổ chức khởi tạo giao dịch ILL

CHÚ THÍCH 1 Thuật ngữ này được sử dụng khi cần thiết phân biệt giữa bên yêu cầu một giao dịch ILL và bên yêu cầu một giao dịch thứ phát ILL.

3.6.62

Địa chỉ bên yêu cầu ban đầu (initial-requester-address) Thông tin xác định dịch vụ viễn thông và địa chỉ mà theo đó có thể đến được bên yêu cầu ban đầu

3.6.63

Người khởi tạo dịch vụ gần đây nhất (initiator-of-most-recent service)

Thông tin nhận dạng bên yêu cầu hoặc bên đáp ứng khởi tạo dịch vụ gần đây nhất

3.6.64

Biểu tượng hướng dẫn (instruction-symbol)

Một hoặc nhiều số, chữ hoặc mã phục vụ cho việc xác định một cách rõ ràng và trong một định dạng viết tắt một thư viện, tổ chức hoặc công ty tham gia vào một giao dịch ILL, ví dụ biểu tượng mục lục liên hợp quốc gia của tổ chức

3.6.65

Bảo hiểm cho (insured-for)

Ký hiệu của số tiền bảo hiểm được mua phòng mất mát hoặc hư hỏng các tài liệu

3.6.66

Id trung gian (intermediary-id)

Thông tin nhận dạng một bên trung gian giao dịch ILL

3.6.67

Vấn đề trung gian (intermediary-problem)

Mã chỉ ra rằng bên trung gian có vấn đề trong lúc xử lý yêu cầu

3.6.68

Id giao dịch không hợp lệ (invalid-transaction-id)

Giá trị id giao dịch của một YÊU CẦU- ILL không hợp lệ, ví dụ giá trị này vi phạm các quy tắc gán ở tiêu chuẩn này, hoặc một biểu tượng cá nhân hoặc tổ chức không biết hoặc tên cá nhân hoặc tổ chức đã biết

3.6.69

Mã số tiêu chuẩn quốc tế cho sách (ISBN)

Mã số tiêu chuẩn quốc tế cho sách gán cho một chuyên khảo theo quy định của TGVN 6381 ( ISO 3297)

3.6.70

Mã số tiêu chuẩn quốc tế cho xuất bản phẩm nhiều kỳ (ISSN)

Mã số tiêu chuẩn quốc tế cho xuất bản phẩm nhiều kỳ gán cho một xuất bản phẩm nhiều kỳ theo quy định của TCVN 6380 (ISO 2108)

3.6.71

Loại tài liệu (item-type)

Mã nhận dạng hình thức thư mục trong đó tài liệu này được xuất bản

3.6.72

Thiếu (lacking)

Có sở hữu tên tài liệu này nhưng không có phần cấu thành hoặc các trang được yêu cầu

3.6.73

Thiếu thông tin tuân thủ bản quyền (lacks-copyright-compliance)

Việc tuân thủ các quy định hoặc luật bản quyền áp dụng phải được thể hiện trước khi có thể thực hiện sao chép

3.6.74

Mức dịch vụ (level-of-service)

Mã chỉ ra mức độ chi tiết của cuộc tìm được yêu cầu hoặc thời hạn trả lời được yêu cầu

CHÚ THÍCH 1: Lưu ý rằng mã này phản ánh các quy ước khu vực hoặc quốc gia.

3.6.75

Chỉ sử dụng trong thư viện (library-use-only)

Dấu hiệu của bên đáp ứng cho thấy tài liệu này có thể không được lấy từ tổ chức đang yêu cầu

3.6.76

Địa chỉ địa điểm (location-address)

Thông tin xác định các dịch vụ viễn thông và địa chỉ hoặc địa chỉ bưu chính nhờ đó có thể tìm được tổ chức sở hữu tài liệu.

3.6.77

Id địa điểm (location-id)

Biểu tượng hoặc tên của tổ chức sở hữu tài liệu được yêu cầu

3.6.78

Chú thích địa điểm (location-note)

Thông tin bổ sung thêm hoặc sửa đổi các dữ liệu thư mục được cung cấp trong YÊU CẦU- ILL hoặc làm rõ địa điểm cung cấp

3.6.79

Không thấy địa điểm (location-not-found)

Không xác định được bên đáp ứng tiềm năng.

3.6.80

Mất (lost)

Tài liệu được tuyên bố bị mất và/hoặc rút khỏi bộ sưu tập

3.6.81

Không hỗ trợ gửi thông báo bắt buộc (mandatory-messaging-not-supported)

Bên đáp ứng không cung cấp thông tin KIỂM NHẬN và/hoặc VẬN CHUYỂN.

3.6.82

Chi phí tối đa (maximum-cost)

Số tiền tối đa sẽ được trả để có được một dịch vụ ILL

3.6.83

Đặc tính của vật mang tin (medium-characteristic)

Thông số kỹ thuật của dạng vật lý chứa tài liệu được cung cấp cho yêu cầu

3.6.84

Loại hình vật mang tin (medium-type)

Mã nhận dạng vật mang tin chứa tài liệu được xuất bản

3.6.85

APDU nhập sai (mistyped-APDU)

Cấu trúc của APDU không phù hợp với cấu trúc được định nghĩa của tiêu chuẩn này.

VÍ DỤ Nó chứa một kiểu dữ liệu không được định nghĩa cho phiên bản này của giao thức.

3.6.86

Giá trị tiền tệ (monetary-value)

Giá trị của một số tiền

3.6.87

Dịch vụ gần đây nhất (most-recent-service)

Mã nhận dạng các sự kiện dịch vụ gần đây nhất xảy ra tại hệ thống cung cấp các báo cáo trạng thái

CHÚ THÍCH 1: Đây là dịch vụ gọi bởi hệ thống cung cấp các báo cáo trạng thái hoặc là dịch vụ được phản ánh trong một APDU nhận được. Báo cáo trạng thái gửi đi để đáp ứng với một yêu cầu trạng thái sẽ không chỉ ra yêu cầu trạng thái là dịch vụ gần đây nhất - vì điều này sẽ không được thông tin.

3.6.88

Chú thích về dịch vụ gần đây nhất (most-recent-service-note)

Nội dung của các tham số chú thích từ dịch vụ ban đầu gần đây nhất

3.6.89

Tên tổ chức (name-of-institution)

Từ, cụm từ hoặc chữ viết tắt xác định một thư viện, cơ quan hoặc công ty

3.6.90

Tên cá nhân (name-of-person)

Từ hoặc tổ hợp các từ và/hoặc tên viết tắt chữ cái đầu theo đó một cá nhân thường được biết đến hoặc được chỉ định và nó xác định người tham gia vào giao dịch ILL

3.6.91

Số thư mục quốc gia (national-bibliography-no)

Thông tin xác định thư mục quốc gia và số biểu ghi tương ứng với tài liệu mong muốn, ví dụ Số phiếu Thư viện Quốc hội (LCCN)

3.6.92

Cần trước ngày (need-before-date)

Ngày cần một tài liệu hoặc sự trả lời

3.6.93

Số đơn vị tài liệu theo loại vật mang tin (no-of-units-per-medium)

Số lượng các đơn vị vật lý được vận chuyển theo vật mang tin cung cấp

3.6.94

Không sao chép (no-reproduction)

Tài liệu không được phép sao chép hay tái bản toàn bộ hoặc một phần bằng máy móc

3.6.95

Không luân chuyển (not-circulating)

Tài liệu được lưu giữ nhưng không cho mượn

3.6.96

Không sẵn có (not-available)

Do một số vấn đề kỹ thuật, người sử dụng dịch vụ tạm thời không thể yêu cầu dịch vụ

3.6.97

Không tìm thấy như trích dẫn (not-found-as-cited)

Thông tin nhận dạng tài liệu được bên đáp ứng cho là không chính xác hoặc không đầy đủ.

3.6.98

Không có trên giá (not-on-self)

Tài liệu thuộc sở hữu của tổ chức nhưng chưa được cho mượn và không có trên giá

3.6.99

Không sở hữu (not-owned)

Nhan đề không được sở hữu bởi bên đáp ứng.

3.6.100

Chú thích (note)

Thông tin bổ sung không bao gồm bất kỳ phần tử dữ liệu nào khác.

3.6.101

Chú thích thông báo (notification note)

Chú thích thêm vào THÔNG BÁO-CHUYỂN TIẾP bởi bên đáp ứng.

3.6.102

Đang giữ (on-hold)

Tài liệu đã được yêu cầu bởi một tổ chức hoặc cá nhân và sẽ được cung cấp cho tổ chức hay cá nhân ngay khi nó có sẵn.

3.6.103

Đang đặt (on-order)

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

3.6.104

Đang lưu giữ (on-reserve)

Tài liệu được sở hữu nhưng dành cho sử dụng hạn chế.

3.6.105

Đánh số trang (pagination)

Việc đánh số các trang của một tài liệu hoặc một phần cấu thành của tài liệu.

3.6.106

Thực hiện thanh toán (payment-provided)

Thông báo của bên yêu cầu là việc thanh toán phí cho bên đáp ứng đã được phép, đang được gửi đi, hoặc sẽ được kèm theo tài liệu trả.

3.6.107

Cho phép thực hiện theo chuỗi (permission-to-chain)

Chỉ thị việc cho phép bên đáp ứng khởi tạo một giao dịch con theo chuỗi với bên đáp ứng khác.

3.6.108

Cho phép thay đổi danh sách gửi (permission-to-change-send-to-list)

Chỉ thị cho phép bên đáp ứng thay đổi nội dung của danh sách địa chỉ gửi đến. Bản chất của các thay đổi được phép tùy thuộc vào giá trị của loại "ưu tiên".

3.6.109

Cho phép chia phần (permission-to-partition)

Chỉ thị cho phép bên đáp ứng khởi tạo một giao dịch con thêm chia phần với bên đáp ứng khác.

3.6.110

Cho phép chuyển tiếp (permission-to-forward)

Chỉ thị cho phép bên đáp ứng chuyển tiếp yêu cầu tới bên đáp ứng khác.

3.6.111

Biểu tượng cá nhân (person-symbol)

Một hoặc nhiều số, chữ hoặc mã dùng để xác định một cách rõ ràng và trong dạng viết tắt một cá nhân đang tham gia vào một giao dịch ILL

3.6.112

Vật mang tin vật lý (physical-medium)

Mã nhận dạng vật mang tin trong đó tài liệu được xuất bản.

CHÚ THÍCH: Giống loại hình vật mang tin.

3.6.113

Nơi xuất bản (place-of-publication)

Vị trí địa lý của nhà xuất bản, hoặc của nhà in, nhà phát hành hoặc sản xuất nếu không có nhà xuất bản.

3.6.114

Đặt giữ (place-on-hold)

Yêu cầu đặt giữ tài liệu để cung cấp tài liệu ngay khi nó sẵn có

3.6.115

Vấn đề chính sách (policy-problem)

Chỉ định của bên đáp ứng cho biết không có chính sách cho phép hoàn thành yêu cầu

3.6.116

Điều kiện chất lượng kém (poor-condition)

Tài liệu được sở hữu nhưng tình trạng vật lý của nó không cho phép mượn hoặc tái bản.

3.6.117

Hòm thư (post-office-box)

Số hòm thư được gán bởi bưu điện

3.6.118

Mã bưu chính (postal-code)

Mã xác định một khu vực nhất định trong một thành phố hoặc khu vực địa lý khác.

3.6.119

Ưu tiên (preference)

Chỉ định cho biết các tổ chức được liệt kê trong danh sách gửi phải được tiếp cận theo thứ tự của danh sách hoặc theo bất kỳ thứ tự nào

3.6.120

Yêu cầu thanh toán trước (prepayment-required)

Chỉ định của bên đáp ứng yêu cầu phải thanh toán trước khi xử lý giao dịch ILL

3.6.121

Phiên bản giao thức không được hỗ trợ (protocol-version-not-supported)

Một APDU đã được nhận có thành phần số phiên bản giao thức xác định một phiên bản của giao thức không được hỗ trợ

3.6.122

Số phiên bản giao thức (protocol-version-num)

Số xác định phiên bản của giao thức đang sử dụng

3.6.123

Năm xuất bản (publication-date)

Năm phát hành một tác phẩm như được định rõ bởi nhà xuất bản tác phẩm này

3.6.124

Năm xuất bản phần cấu thành (publication-date-of-components)

Năm xuất bản được định rõ bởi nhà xuất bản để xác định các phần cấu thành thư mục duy nhất của một tác phẩm

3.6.125

Nhà xuất bản (publisher)

Một hoặc nhiều cá nhân hoặc tổ chức chịu trách nhiệm về việc xuất bản một tài liệu

3.6.126

Lý do các địa điểm được cung cấp (reason-locs-provided)

Mã được sử dụng để cho biết lý do tại sao các địa điểm được cung cấp để đáp ứng yêu cầu ILL.

3.6.127

Lý do không báo cáo (reason-not-report)

Mã được sử dụng để cho biết lý do tại sao không cung cấp báo cáo để đáp lại một câu hỏi về trạng thái

3.6.128

Lý do không sẵn có (reason-not-available)

Mã được sử dụng để cho biết lý do tài liệu không sẵn có

3.6.129

Lý do không thực hiện được (reason-unfilled)

Mã được sử dụng để cho biết lý do không hoàn thành một yêu cầu ILL

3.6.130

Thỏa thuận đối ứng (reciprocal agreement)

Chỉ thị của bên yêu cầu về một thỏa thuận ưu tiên cho những gì có thể được cung cấp và điều kiện cung cấp

3.6.131

Khu vực/ Vùng (region)

Cụm từ được sử dụng để xác định một tỉnh, bang, vùng, hoặc địa phương

3.6.132

Có thể gia hạn được (renewable)

Dấu hiệu cho biết tài liệu được cung cấp có gia hạn được hay không

3.6.133

Nguồn báo cáo (report-source)

Mã số cho biết nguồn khởi tạo báo cáo lỗi là người dùng dịch vụ hoặc nhà cung cấp dịch vụ

3.6.134

Loại báo cáo (report-type)

Dấu hiệu cho biết một báo cáo có hay không và nếu có, thì đó là một báo cáo trạng thái, báo cáo lỗi hoặc cả hai.

3.6.135

Id được yêu cầu (requested-id)

Thông tin nhận dạng bên yêu cầu giao dịch ILL

3.6.136

Lưu ý của bên yêu cầu (requester-note)

Lưu ý cung cấp bởi bên yêu cầu giao dịch ILL

3.6.137

Các thông báo tùy chọn của bên yêu cầu (requester-optional-messages)

Dấu hiệu cho biết hoặc bên yêu cầu có khả năng gửi các thông báo tùy chọn ĐÃ NHẬN và ĐÃ TRẢ và hoặc các thông báo tùy chọn ĐÃ CHUYỂN và/hoặc ĐÃ KIỂM NHẬN là yêu cầu hoặc mong muốn từ bên đáp ứng

3.6.138

Dấu đã kiểm nhận từ phía bên yêu cầu (requester CHECKED-IN)

Dấu hiệu của bên yêu cầu là có hay không yêu cầu hoặc mong muốn nhận được APDU Kiểm nhận

3.6.139

Dấu đã vận chuyển từ phía bên yêu cầu (requester-SHIPPED)

Dấu hiệu của bên yêu cầu là có hay không việc yêu cầu hoặc mong muốn APDU Vận chuyển

3.6.140

Hạn chế nguồn lực (resource-limitation)

Người sử dụng dịch vụ không thể thực hiện dịch vụ yêu cầu do các hạn chế về nguồn lực

3.6.141

Địa chỉ bên đáp ứng (responder-note)

Thông tin xác định các dịch vụ viễn thông và địa chỉ có thể đến nơi bên đáp ứng

3.6.142

Id bên đáp ứng (responder-id)

Thông tin nhận dạng của bên đáp ứng giao dịch ILL

3.6.143

Lưu ý của người đáp ứng (responder-note)

Lưu ý cung cấp bởi bên đáp ứng giao dịch ILL

3.6.144

Các thông báo tùy chọn của bên đáp ứng (responder-optional-messages)

Dấu hiệu cho biết hoặc bên đáp ứng có khả năng gửi các thông báo tùy chọn ĐÃ CHUYỂN và/hoặc ĐÃ KIỂM NHẬN (cho mục đích chẩn đoán) và hoặc các thông báo ĐÃ NHẬN và/hoặc ĐÃ TRẢ được bên yêu cầu yêu cầu hoặc mong muốn.

3.6.145

Dấu đã nhận từ phía Bên đáp ứng (responder-RECEIVED)

Dấu hiệu của bên đáp ứng là có hay không yêu cầu hoặc mong muốn nhận được APDU đã Nhận.

3.6.146

Dấu đã trả từ phía Bên đáp ứng (responder-RETURNED)

Dấu hiệu của bên đáp ứng là có hay không yêu cầu hoặc mong muốn nhận được APDU ĐÃ TRẢ.

3.6.147

Kết quả cụ thể của bên đáp ứng (responder-specific-result)

Lý do được cung cấp để đáp ứng yêu cầu ILL là cụ thể với bên đáp ứng, tức là không được quy định trong tiêu chuẩn này.

3.6.148

Dịch vụ cụ thể của bên đáp ứng (responder-specific-service)

Dịch vụ được cung cấp bởi bên đáp ứng là cụ thể với bên đáp ứng, tức là không được quy định trong tiêu chuẩn này.

3.6.149

Ngày thử lại (retry-date)

Ngày sau khi một yêu cầu có thể được thực hiện lại.

3.6.150

Cờ thử lại (retry-flag)

Dấu hiệu của bên yêu cầu cho biết giao dịch ILL có phải là lần thực hiện lại của một lần trước hay không.

3.6.151

Yêu cầu bảo hiểm trả lại (return-insurance-required)

Số tiền bảo hiểm đối với việc mất hoặc hư hỏng được yêu cầu bởi bên đáp ứng cho việc trả lại tài liệu đã mượn.

3.6.152

Trả lại qua (returned-via)

Phương pháp bên yêu cầu vận chuyển tài liệu để trả.

3.6.153

Vấn đề an ninh (security-problem)

Dấu hiệu cho thấy người nhận đã gặp vấn đề bảo mật cản trở họ xử lý yêu cầu dịch vụ.

CHÚ THÍCH 1 Các lý do có thể nằm ngoài phạm vi của tiêu chuẩn này.

3.6.154

Tùng thư- Nhan đề-Số (series-title-number)

Tên đặt cho một số xuất bản phẩm riêng biệt nhưng liên quan với nhau và trên thực tế là mỗi xuất bản phẩm vừa mang một nhan đề chung dùng cho cả nhóm hoặc nhóm con như một chỉnh thể vừa mang cả nhan đề và số riêng của nó trong nhóm đó

3.6.155

Danh sách gửi đến (send-to-list)

Danh sách những bên đáp ứng tiềm năng cho các giao dịch ILL để chuyển tới tổ chức thành chuỗi hoặc phân khu

3.6.156

Điều kiện vận chuyển (shipped-conditions)

Điều kiện theo đó một tài liệu có thể được sử dụng

3.6.157

Loại hình dịch vụ vận chuyển (shipped-service-type)

Mã cho loại hình dịch vụ ILL được cung cấp

3.6.158

Vận chuyển qua (shipped-via)

Phương pháp vận chuyển được dùng để gửi tài liệu của người cho mượn.

3.6.159

Yêu cầu giám sát bộ sưu tập đặc biệt (special-collections-supervision-required)

Dấu hiệu bên đáp ứng cho biết tài liệu phải được sử dụng trong phòng hoặc cơ quan lưu trữ bộ sưu tập đặc biệt

3.6.160

Cơ quan tài trợ (sponsoring-body)

Cơ quan hoặc tổ chức phát hành tài liệu hoặc có liên kết với tác giả của nó

3.6.161

Đường phố và số nhà (street-and-number)

Số và/hoặc cụm từ được sử dụng để xác định vị trí của một tòa nhà trong một thành phố hoặc một khu vực nông thôn

3.6.162

Mô tả tài liệu bổ sung (supplemental-item-description)

Thông tin mô tả tài liệu bổ sung có thể được trình bày theo khổ mẫu đọc máy, ví dụ biểu ghi MARC

3.6.163

Id nhà cung cấp (supplier-id)

Thông tin nhận dạng nhà cung cấp tài liệu được yêu cầu khi nhà cung cấp khác với bên đáp ứng.

3.6.164

Loại vật mang tin cung cấp (supply-medium-type)

Mã nhận dạng vật mang tin của tài liệu yêu cầu

CHÚ THÍCH mã này có thể được liệt kê theo thứ tự ưu tiên.

3.6.165

Số hệ thống (system-no)

Số cung cấp nhận dạng cụ thể hệ thống của biểu ghi thư mục cho một tài liệu yêu cầu

3.6.166

Địa chỉ dịch vụ viễn thông (telecom-service-address)

Số hoặc mã duy nhất được gán cho một hộp thư hoặc một dịch vụ điện tử hoặc một người tham gia vào mạng lưới truyền thông

3.6.167

Ký hiệu định danh dịch vụ viễn thông (telecom-service-identifier)

Tên hoặc mã duy nhất của dịch vụ viễn thông được sử dụng cho giao dịch ILL

3.6.168

Thời gian dịch vụ (time-of-service)

Thời gian khi một dịch vụ được gọi

3.6.169

Nhan đề (title)

Tên của một tài liệu gồm một từ hoặc nhóm từ dùng để xác định nó.

3.6.170

Nhan đề bài (title-of-article)

Nhan đề của một tài liệu là phần cấu thành của một tài liệu khác

3.6.171

Dấu hạn định nhóm giao dịch (transaction-group-qualfier)

Chuỗi chữ số duy nhất xác định một tập hợp các giao dịch ILL liên quan, ví dụ một loạt các tham chiếu hoặc một yêu cầu ILL và các lần lặp lại tiếp theo của nó

CHÚ THÍCH 1 Dấu hạn định này là duy nhất trong phạm vi của hệ thống giao dịch ILL ban đầu của bên yêu cầu. Bằng cách kết hợp với id của bên yêu cầu, nó cung cấp một nhận dạng duy nhất phổ biến cho nhóm giao dịch ILL.

3.6.172

Vấn đề id giao dịch (transaction-id-problem)

Mã cho biết một vấn đề với id giao dịch trong một APDU nhận được

3.6.173

Dấu hạn định giao dịch (transaction-qualfier)

Chuỗi chữ số xác định tất cả các dịch vụ và các thông báo liên quan đến một giao dịch ILL duy nhất

CHÚ THÍCH 1 Đây là một chuỗi duy nhất được gán bởi bên yêu cầu ban đầu giao dịch ILL và được áp dụng bởi các đối tác ILL cho tất cả các dịch vụ tiếp theo và thông báo liên quan đến giao dịch ILL. Bằng cách kết hợp với id của bên yêu cầu và dấu hạn định nhóm giao dịch, nó cung cấp một nhận dạng duy nhất phổ biến cho giao dịch ILL.

3.6.174

Loại hình giao dịch (transaction-type)

Mã xác định loại hình giao dịch ILL

3.6.175

Phương thức vận chuyển (transportation-mode)

Phương tiện vật chất hay phi điện tử để vận chuyển tài liệu yêu cầu khi được trình bày hay được lưu trữ trên một vật mang tin hữu hình

3.6.176

Không thể thực hiện (unable-to-perform)

Mã cho biết lý do tại sao những người sử dụng dịch vụ không thể thực hiện dịch vụ yêu cầu

3.6.177

Id giao dịch không biết (unknown-transaction-id)

Không có giao dịch ILL tương ứng với giá trị id giao dịch của một APDU nhận được

3.6.178

APDU không được công nhận (unrecognized-APDU)

Loại APDU nhận được không phải là một trong các APDU được xác định trong tiêu chuẩn này.

3.6.179

Nguồn tham chiếu kiểm chứng (vertification-reference-source)

Nguồn thông tin thư mục chuẩn được sử dụng để xác định hoặc định vị một tài liệu hoặc bất kỳ nguồn nào được dùng để xác định hoặc định vị một tài liệu

3.6.180

Tập-số (volume-issue)

Ký hiệu định danh một đơn vị vật lý của một chuyên khảo nhiều tập hoặc nhiều kỳ, hoặc một số, chữ cái hay từ xác định một đơn vị của một tài liệu hoặc các tập của nó được xuất bản thành các phần.

3.6.181

Chưa có tập/số (volume-issue-not-yet-available)

Nhan đề là thuộc sở hữu nhưng phần cấu thành được yêu cầu chưa nhận được.

3.6.182

Sẽ trả phí (will-pay-fee)

Dấu hiệu của bên yêu cầu cho biết đồng ý trả phí áp dụng

3.6.183

Sẽ cung cấp kết quả (will-supply-results)

Mã xác định thông tin bổ sung liên quan đến việc "sẽ cung cấp" kết quả để đáp ứng cho một yêu cầu ILL

4  Từ viết tắt

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

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

Giao thức ILL được định ra để có thể hoạt động ở cả hai chế độ: chế độ lưu trữ-và-chuyển tiếp và chế độ định hướng kết nối. Các yêu cầu kỹ thuật của ánh xạ tới các dịch vụ hỗ trợ cụ thể sẽ được cung cấp trong các định nghĩa về ngữ cảnh ứng dụng và các diện chức năng. Phụ lục F mô tả một số ánh xạ có thể đến các dịch vụ hỗ trợ.

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.

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ử.

7.1  Nhận dạng giao dịch

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:

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

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

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.

7.2  Trạng thái giao thức

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:

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:

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;

- ĐÃ NHẬN (nếu nhận được một tài liệu không phải trả lại);

- ĐÃ 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

Trạng thái thiết bị đầu cuối cho một giao dịch ILL cụ thể sẽ phụ thuộc vào các trường hợp giao dịch của nó. Ví dụ, khi một bản sao được cung cấp, ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho bên đáp ứng, trong khi NHẬN là trạng thái thiết bị đầu cuối cho bên yêu cầu.

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.

7.3  Các biến giao thức

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.

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:

Hết HẠN          xác định ngày hết hạn giao dịch ILL.

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 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;

- Người khởi tạo 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.

Nếu thông tin trạng thái được yêu cầu cho một giao dịch ILL đã kết thúc, thông tin lịch sử không thể được cung cấp.

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Ó

- 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

- YÊU CẦU 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 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:

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

- 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

- QUÁ HẠ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

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

- 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ị

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

- 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 Gia 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ị

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

- 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

- MẤT

- 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 = CÓ ĐIỀU KIỆN

- 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

- QUÁ HẠ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 = CÓ

- 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

- BÁO CÁO TRẠNG THÁI HOẶC LỖ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ị

- ĐÃ TRẢ.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

- ĐÃ CHUYỂN ĐI-APDU này là tùy chọn

- 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

- ĐÒI

- 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

- HẾT HẠN

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.

Các APDU được chuẩn bị và chỉ gửi theo yêu cầu rõ ràng của người sử dụng dịch vụ ILL, với ngoại lệ của APDU HẾT HẠN được gửi bởi hệ thống của bên đáp ứng trong trường hợp hết hạn bộ đếm thời gian.

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  Thông báo tùy chọn

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:

a) bên yêu cầu có khả năng gửi ĐÃ NHẬN hay không;

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;

d) bên đáp ứng có yêu cầu ĐÃ TRẢ 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.

Các APDU NHẬN, TRẢ và KIỂM NHẬN là tùy chọn. Tuy nhiên, người trung gian, khi hành động như một bên yêu cầu, phải có khả năng tạo ra NHẬN và/hoặc TRẢ nếu có yêu cầu của bên đáp ứng, và khi hoạt động như bên đáp ứng, phải có khả năng tạo ra KIỂM NHẬN nếu có yêu cầu của 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.

8.2.6  Kiểm soát gia hạn

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.

Nếu bên yêu cầu 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.

Người nhận APDU lặp giải quyết nó khác nhau tùy theo APDU lặp ban đầu hoặc trước đó đã được nhận hay chưa.

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:

a) bằng cách đưa ra một giá trị cho loại "Cần trước ngày" và đặt "Cờ hết hạn" cho biến "CẦN TRƯỚC NGÀY"; hoặc là

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.

Nếu bên đáp ứng nhận TRẢ LỜI CÓ ĐIỀU KIỆN với câu trả lời CÓ, khi đó bộ đếm thời gian HẾT HẠN được đặt lại giá trị ban đầu của 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.

Nếu bên đáp ứng đã đưa ra ĐÃ CHUYỂN.yêu cầu, CHUYỂN TIẾP.yêu cầu hoặc TRẢ LỜI- ILL. yêu cầu với kết quả là THỬ LẠI, KHÔNG HOÀN THÀNH, ĐỊA ĐIỂM-CUNG CẤP hoặc DỰ TÍNH hoặc đã nhận được chỉ thị HẾT HẠN, thì chỉ thị HỦY được bỏ qua và không có yêu cầu TRẢ LỜI HỦY được đưa ra.

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

Bất kỳ sự kiện nào không được liệt kê trong các bảng giao thức của Phụ lục A là không hợp lệ và được coi là lỗi giao thức. Với ngoại lệ quy định tại khoản 8.2.14., các APDU định dạng sai hoặc APDU với dữ liệu không hợp lệ cũng được coi là 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.

8.2.16  Thông tin số tài khoản

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

Giao thức ILL hỗ trợ chuyển tiếp không giới hạn một yêu cầu ILL, với ràng buộc duy nhất là một yêu cầu không thể được chuyển tiếp hai lần đến cùng một bên đáp ứng trong cùng một nhóm giao dịch ILL.

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.

Khi việc thực hiện chuỗi giao dịch ILL xảy ra, bên đáp ứng khi đó 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 theo CHUỖI vẫn là ĐÚNG trong khi biến PHÂN KHU được đặt là Sai. Người trung gian đảm nhận vai trò của bên yêu cầu cho các giao dịch con và giữ vai trò của bên đáp ứng cho giao dịch ILL chính. Giao dịch con được phân biệt với giao dịch ILL chính vì vậy giao dịch trước đây có thể không thành công không ảnh hưởng đến giao dịch sau này.

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 khởi tạo một giao dịch con, nó luôn luôn chỉ ra một yêu cầu về thông báo Đã 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 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.

Biến giao thức Bool CHUỖI được sử dụng để cho biết giao dịch ILL có thể được phân khu hay không. Biến giao thức đượ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 phân khu". Nếu Phân khu có giá trị ĐÚNG, thì phân khu là được phép.

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.

e) Thực hiện theo chuỗi có Phân khu tiếp theo: khi phân khu theo chuỗi, các quy tắc cho phân khu chi phối các quy tắc cho thực hiện theo chuỗi. Người nhận YÊU CẦU ILL phân khu tương tác trong giai đoạn 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. Nếu giai đoạn này hoàn thành với việc gửi một APDU ĐÃ CHUYỂN, thì tham số "kiểu giao dịch" phải được trả lại cho người yêu cầu ban đầu với giá trị "phân khu" mà không phải là "theo chuỗi". Giá trị của tham số "id bên đáp ứng" là Ký hiệu nhận dạng bên đáp ứng với nó yêu cầu được phân khu. Trong giai đoạn theo dõi, bên yêu cầu ban đầu tương tác trực tiếp với bên đáp ứ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  Cú pháp trừu tượng

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.

Các APDU ILL được định nghĩa trong 9.1.1 là các kiểu có cấu trúc. 9.1.2 liệt kê các kiểu mà từ đó các kiểu có cấu trúc được xây dựng và chưa được quy định trong 9.1.1.

Click Tải về để xem Phần 9.1.1 - 9.1.2

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,

• vai trò người trung gian,

• 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 1: Dịch vụ tùy chọn cho các vai trò bên yêu cầu và bên đáp ứng bao gồm các dịch vụ đã bị hư hại Thông báo, Yêu cầu trạng thái. Khi các dịch vụ tùy chọn này không được hỗ trợ, thì dù việc thực hiện không có khả năng truyền các APDU được kết hợp với dịch vụ này nhưng vẫn có khả năng tiếp nhận các APDU liên quan. Khi các dịch vụ có điều kiện không được hỗ trợ, việc thực hiện không cần phải có khả năng truyền hoặc nhận các APDU được kết hợp với các dịch vụ.

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

Mỗi khi thực hiện phải cung cấp một trình bày tuân thủ thực hiện giao thức (PICS). Các PICS phải nêu:

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.

c) Bảng A.3 quy định các vị từ

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 ô không trống thể hiện một sự kiện đến và trạng thái được xác định cho Giao thức ILL. Một ô như thế chứa một danh sách hành động. Một danh sách hành động có thể là bắt buộc hoặc có điều kiện.

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:

a) Đối với một bên yêu cầu hoặc bên đáp ứng, yêu cầu dịch vụ ban đầu không có giá trị cho trường "Ngày và thời gian của dịch vụ ban đầu". Sự kiện lặp có một giá trị xác định cho trường này; yêu cầu dịch vụ lặp chỉ có thể được gọi trong khi không có sự thay đổi trạng thái trong lệnh gọi thực thể ứng dụng ban đầu từ sự kiện yêu cầu dịch vụ ban đầu.

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ệ

Các ô trống chỉ một nút giao không hợp lệ của một sự kiện đến và trạng thái. Nếu một nút giao như vậy xảy ra, nó được coi là một lỗi giao thức. ILLPM bỏ qua sự kiện đến, sẽ gửi một APDU Báo cáo trạng thái hoặc lỗi để thông báo cho người gửi lỗi giao thức này, và không thay đổi trạng thái. Các hành động cục bộ bổ sung, chẳng hạn như thông báo của người sử dụng dịch vụ, cũng có thể được thực hiện, nhưng không được quy định trong tiêu chuẩn này.

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

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

Bảng A.3 - Vị từ

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ý