Tiêu chuẩn quốc gia TCVN 11642-1:2016 về Thông tin và tư liệu - Phần 1: Đặc tả giao thức

• Số hiệu: TCVN11642-1:2016
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2016

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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 đượ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)

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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)

...

...

...

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.

...

...

...

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)

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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 đượ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)

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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)

...

...

...

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)

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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ố 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)

...

...

...

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.

...

...

...

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

...

...

...

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)

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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

...

...

...

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)

...

...

...

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

...

...

...

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 ý 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)

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

Đ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

...

...

...

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)

...

...

...

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)

...

...

...

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

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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)

...

...

...

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

ACSE

yếu tố dịch vụ kiểm soát liên kết

...

...

...

đơn vị dữ liệu của giao thức ứng dụng

ASE

thành tố dịch vụ ứng dụng

ASN.1

ký hiệu cú pháp trừu tượng 1

ASO

đối tượng dịch vụ ứng dụng

EDI FACT

trao đổi dữ liệu điện tử về quản lý hành chính, thương mại và vận tải

...

...

...

mượn liên thư viện

ILL PM

máy tính giao thức ILL

MHS

hệ thống xử lý thông báo

MOTIS

hệ thống trao đổi văn bản định hướng thông báo

MTS

hệ thống truyền thông báo

...

...

...

kết nối hệ thống mở

5  Tổng quan về giao thức

5.1  Cung cấp dịch vụ

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

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

Dịch vụ

Kiểu

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

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

...

...

...

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

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

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

ĐÃ CHUYỂN (SHIPPED)

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

TRẢ LỜI ILL (ILL-ANSWER)

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

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

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

...

...

...

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

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

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

ĐÃ NHẬN (RECEIVED)

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

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

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

ĐÃ TRẢ LẠI (RETURNED)

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

...

...

...

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

QUÁ HẠN (OVERDUE)

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

GIA HẠN (RENEW)

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

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

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

ĐÃ MẤT (LOST)

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

...

...

...

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

THÔNG BÁO (MESSEAGE)

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

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

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

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

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

HẾT HẠN (EXPIRY)

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

...

...

...

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)

...

...

...

YÊU CẦU ILL

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

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

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

YÊU CẦU ILL

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

VẬN CHUYỂN

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

TRẢ LỜI ILL

...

...

...

TRẢ LỜI ĐIỀU KIỆN

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

HỦY

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

TRẢ LỜI HỦY

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

ĐÃ NHẬN

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

ĐÒI

...

...

...

ĐÃ TRẢ

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

KIỂM NHẬN

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

QUÁ HẠN

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

GIA HẠN

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

TRẢ LỜI GIA HẠN

...

...

...

MẤT

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

HƯ HẠI

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

THÔNG BÁO

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

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

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

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

...

...

...

HẾT HẠN

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

7  Thông tin giao dịch

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

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

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

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

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

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

...

...

...

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:

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

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

...

...

...

phân biệt một nhóm các giao dịch ILL với tất cả các nhóm giao dịch ILL khác hoạt động và liên quan đến người có yêu cầu ban đầu;

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

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

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

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

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

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

Giao dịch đơn giản

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

...

...

...

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

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

Tùy chọn

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

Bắt buộc

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

Bắt buộc

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

Không sử dụng

...

...

...

Giao dịch theo chuỗi hoặc phân khu

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

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

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

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

Bắt buộc

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

Bắt buộc

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

...

...

...

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

Bắt buộc

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

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

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

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

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

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

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

...

...

...

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:

NHÀN RỖI

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

ĐANG CHỜ

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

KHÔNG CUNG CẤP

...

...

...

ĐIỀU KIỆN

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

ĐANG CHỜ HỦY

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

ĐÃ HỦY

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

ĐÃ CHUYỂN

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

ĐÃ NHẬN

...

...

...

GIA HẠN/ĐANG CHỜ

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

GIA HẠN/QUÁ HẠN

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

QUÁ HẠN

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

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

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

ĐÒI

...

...

...

ĐÃ TRẢ

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

MẤT

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

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

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

NHÀN RỖI (IDLE)

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

ĐANG XỬ LÝ

...

...

...

CHUYỂN TIẾP

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

KHÔNG CUNG CẤP

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

ĐIỀU KIỆN

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

ĐANG CHỜ HỦY

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

ĐÃ HỦY

...

...

...

ĐÃ CHUYỂN

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

GIA HẠN/ĐANG CHỜ

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

GIA HẠN/QUÁ HẠN

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

QUÁ HẠN

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

ĐÒI

...

...

...

KIỂM NHẬN

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

MẤT

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

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

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

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

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

- KHÔNG-CUNG CẤP;

...

...

...

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

...

...

...

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.

...

...

...

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.

TRẢ (RETURN)

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

CHUYỂN TIẾP (FWD)

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

PHÂN KHU (PART)

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

CHUỖI (CHAIN)

...

...

...

DẤU THỜI GIAN THEO TUẦN TỰ (SEQUENCE-TIME-STAMP)

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

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

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

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

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

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

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

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

...

...

...

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

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

...

...

...

từ, cụm từ hoặc chữ viết tắt nhận dạng một người, thư viện, tổ chức hay công ty.

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ườ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.

...

...

...

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Ó

- 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

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

- 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

...

...

...

- 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

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

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;

...

...

...

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

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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 đó.

...

...

...

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Ờ

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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.

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

10  Sự phù hợp

10.1  Sự phù hợp tĩnh

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

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

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

...

...

...

• vai trò 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);

...

...

...

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.

...

...

...

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

...

...

...

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.

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

Mô tả

ILLreq

FWDreq

ANSreq-CO

ANSreq-RY

ANSreq-UN

ANSreq-LP

ANSreq-WS

ANSreq-HP

...

...

...

C-REPreq +

C-REPreq -

CANreq

CARreq +

CARreq -

SHIreq

RCVreq

RCLreq

DUEreq

...

...

...

RENreq

REAreq +

REAreq -

CHKreq

LSTreq

DAMreq

MSGreq

STQreq

STRreq

...

...

...

ILL-REQUEST.request

FORWARD.request

ILL-ANSWER.request: result = CONDITIONAL

ILL-ANSWER.request: result = RETRY

ILL-ANSWER.request: result = UNFILLED

ILL-ANSWER.request: result = LOCATION-PROVIDED

ILL-ANSWER.request: result = WILL-SUPPLY

ILL-ANSWER.request: result = HOLD PLACED

ILL-ANSWER.request: result = ESTIMATE

...

...

...

CONDITIONAL-REPLY.request: answer = no

CANCEL.request

CANCEL-REPLY.request: answer = yes

CANCEL-REPLY.request: answer = no

SHIPPED.request

RECEIVED.request

RECALL.request

OVERDUE.request

RETURNED.request

...

...

...

RENEW-ANSWER.request: answer = yes

RENEW-ANSWER.request: answer = no

CHECKED-IN.request

LOST.request

DAMAGED.request

MESSAGE.request

STATUS-QUERY.request

STATUS-OR-ERROR-RE PORT, request

receive ILL-REQUEST APDU

...

...

...

ANS-CO

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP+

C-REP-

...

...

...

CAR +

CAR -

SHI

RCV

RCL

DUE

RET

REN

REA +

...

...

...

CHK

LST

DAM

MSG

STQ

STR

EXP

EXPIRY timeout

receive FORWARD-NOTIFICATION APDU

...

...

...

receive ILL-ANSWER APDU: result = RETRY

receive ILL-ANSWER APDU: result = UNFILLED

receive ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

receive ILL-ANSWER APDU: result - WILL-SUPPLY

receive ILL-ANSWER APDU: result = HOLD PLACED

receive ILL-ANSWER APDU: result = ESTIMATE

receive CONDITIONAL-REPLY APDU: answer = yes

receive CONDITIONAL-REPLY APDU: answer = no

receive CANCEL APDU

...

...

...

receive CANCEL-REPLY APDU: answer = no

receive SHIPPED APDU

receive RECEIVED APDU

receive RECALL APDU

receive OVERDUE APDU

receive RETURNED APDU

receive RENEW APDU

receive RENEW-ANSWER APDU: answer = yes

receive RENEW-ANSWER APDU: answer = no

...

...

...

receive LOST APDU

receive DAMAGED APDU

receive MESSAGE APDU

receive STATUS-QUERY APDU

receive STATUS-OR-ERROR-REPORT APDU

receive EXPIRED APDU

Transaction Timer Expiry

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

Tên viết tắt

...

...

...

ILLind

FWDind

ANSind-CO

ANSind-RY

ANSind-UN

ANSind-LP

ANSind-WS

ANSind-HP

ANSind-ES

...

...

...

C-REPind -

CANind

CARind +

CARind -

SHIind

RCVind

RCLind

DUEind

RETind

...

...

...

REAind +

REAind -

CHKind

LSTind

DAMind

MSGind

STQind

STRind

EXPind

...

...

...

FWD

ANS-CO

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP +

...

...

...

ILL-REQUEST.indication

FORWARD.indication

ILL-ANSWER.indication: result = CONDITIONAL

ILL-ANSWER.indication: result = RETRY

ILL-ANSWER.indication: result = UNFILLED

ILL-ANSWER.indication: result = LOCATIONS-PROVIDED

ILL-ANSWER.indication: result = WILL-SUPPLY

ILL-ANSWER.indication: result = HOLD PLACED

ILL-ANSWER.indication: result = ESTIMATE

...

...

...

CONDITIONAL-REPLY.indication: answer = no

CANCEL.indication

CANCEL-REPLY.indication: answer = yes

CANCEL-REPLY.indication: answer = no

SHIPPED.indication

RECEIVED.indication

RECALL.indication

OVERDUE.indication

RETURNED.indication

...

...

...

RENEW-ANSWER.indication: answer = yes

RENEW-ANSWER.indication: answer = no

CHECKED-IN.indication

LGST.indication

DAMAGED.indication

MESSAGE.indication

STATUS-QUERY.indication

STATUS-OR-ERROR-REPORT.indication

EXPIRY,indication

...

...

...

send FORWARD-NOTIFICATION APDU

send ILL-ANSWER APDU: result = CONDITIONAL

send ILL-ANSWER APDU: result = RETRY

send ILL-ANSWER APDU: result = UNFILLED

send ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

send ILL-ANSWER APDU: result = WILL-SUPPLY

send ILL-ANSWER APDU: result = HOLD PLACED

send ILL-ANSWER APDU: result = ESTIMATE

send CONDITIONAL-REPLY APDU: answer = yes

...

...

...

CAN

CAR +

CAR -

SHI

RCV

RCL

DUE

RET

REN

...

...

...

REA -

CHK

LST

DAM

MSG

STQ

STR

EXP

send CANCELAPDU

...

...

...

send CANCEL-REPLY APDU: answer = no

send SHIPPED APDU

send RECEIVED APDU

send RECALL APDU

send OVERDUEAPDU

send RETURNED APDU

send RENEW APDU

send RENEW-ANSWER APDU: answer = yes

send RENEW-ANSWER APDU: answer = no

...

...

...

send LOST APDU

send DAMAGED APDU

send MESSAGE APDU

send STATUS-QUERY APDU

send STATUS-OR-ERROR-REPORT APDU

send EXPIRED APDU

Bảng A.3 - Vị từ

Mã

Ỹ nghĩa

...

...

...

returns TRUE if the transaction-type parameter of the ILL-REQUEST service is "simple"

p2

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

p3

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

p4

returns TRUE if the FWD protocol variable is TRUE

p5

returns TRUE if the RETURN protocol variable is TRUE

...

...

...

returns TRUE if the CHAIN protocol variable is TRUE

p7

returns TRUE if a received APDU is in sequence

p8

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

p9

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

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

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

...

...

...

IDLE

PENDING

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

SHIPPED

ILLreq

p1 ILL PENDING

...

...

...

ILLreq

ILL

...

...

...

repeat

PENDING

...

...

...

C-REPreq

C-REP +

...

...

...

PENDING

C-REPreq

...

...

...

+ repeat

PENDING

...

...

...

C-REPreq

C-REP-

...

...

...

-

NOT-SUP-PLIED

...

...

...

p1 ILL

PENDING

...

...

...

C-REPreq -

C-REP-

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

CANreq

CAN

...

...

...

CANCEL-

...

...

...

CANreq

...

...

...

CAN

repeat

CANCEL-

...

...

...

PENDING

...

...

...

RCV (opt)

RCV (opt)

RCV(opt)

...

...

...

set RETURN
var

set RETURN
var

LSTreq

LST

...

...

...

LST

LST

LOST

LOST

...

...

...

LOST

MSGreq

MSG
PENDING

MSG

MSG

MSG

MSG

MSG
SHIPPED

...

...

...

CONDITIONAL

STQreq

...

...

...

STQ

STQ
CONDITONAL

STQ

STQ
CANCELLED

STQ

SHIPPED

PENDING

...

...

...

PLIED

CANCEL-

PENDING

STRreq

...

...

...

STR

STR
CONDITIONAL

STR

CANCEL-

PENDING

STR
CANCELLED

STR

PENDING

...

...

...

SHIPPED

FWD

FWDind

FWDind

...

...

...

PENDING

PENDING

FWD

...

...

...

repeat

PENDING

...

...

...

ANS-CO

p7

ANSind-CO

ANSind-CO
CONDITIONAL

p7

...

...

...

ANSind-CO CONDITIONAL

NOT-SUP-PLIED

ANSind-CO CANCEL-

CANCELLED

...

...

...

PENDING

ANS-CO

^p7

...

...

...

ANSind-CO
CONDITIONAL

^p7

ANSind-CO
CANCELLED

ANSind-CO

...

...

...

ANSind-CO

NOT-SUP-

CANCEL-

ANS-CO

ANSind-CO

...

...

...

ANSind-CO
CONDITIONAL

ANSind-CO

ANSind-CO
CANCELLED

repeat

ANS-RY

...

...

...

ANSind-RY

ANSind-RY

ANSind-RY

NOT-SUP-
PLIED

NOT-SUP-
PLIED

NOT-SUP-
PLIED

...

...

...

p1 ILL

PENDING

...

...

...

ANS-RY
repeat

ANSind-RY

...

...

...

NOT-SUP-
PLIED

...

...

...

ANS-UN

ANSind-UN

ANSind-UN

ANSind-UN

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-UN

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

ANS-LP

ANSind-LP

ANSind-LP

ANSind-LP

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-LP

...

...

...

ANSind-LP

repeat

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

...

...

...

ANSind-WS

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

...

...

...

SHIPPED

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

ANSind-WS

ANSind-WS

...

...

...

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

SHIPPED

ANS-HP

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

PENDING

...

...

...

CONDITIONAL

CANCEL-

SHIPPED

PENDING

...

...

...

ANS-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

...

...

...

PENDING

SHIPPED

repeat

...

...

...

CONDITIONAL

ANS-ES

ANSind-ES

ANSind-ES

...

...

...

ANSind-ES

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

...

...

...

ANS-ES

ANSind-ES

...

...

...

NOT-SUP-PLIED

CAR +

...

...

...

CARind +

CARind +

...

...

...

CANCELLED

CANCELLED

CAR +

...

...

...

repeat

CANCELLED

...

...

...

CARind -

CARind -

CARind -

...

...

...

PENDING

SHIPPED

CAR -

CARind -

...

...

...

CARind -

repeat

PENDING

...

...

...

SHIPPED

SHI

SHIind

SHIind

SHIind

...

...

...

SHIPPED

SHIPPED

SHIPPED

ILLeq

p1 ILL

...

...

...

PENDING

...

...

...

SHI

...

...

...

SHIind

repeat

SHIPPED

...

...

...

DUEind

DUEind

DUEind

...

...

...

set RETURN

set RETURN

var = TRUE

...

...

...

var = TRUE

var = TRUE

RCL

RCLind

RCLind

...

...

...

RCLind

set RETURN

set RETURN

set RETURN

...

...

...

CHKind

CHKind

CHKind

...

...

...

set RETURN

set RETURN

MSG

MSGind

MSGind

...

...

...

MSGind

MSGind

MSGind

PENDING

CONDITIONAL

...

...

...

SHIPPED

STQ

STQind

STQind

STQind
CONDITIONAL

STQind

STQind

STQind

...

...

...

PENDING

CANCELLED

STR

STRind

...

...

...

STRind
CONDITIONAL

STRind

STRind

STRind

PENDING

NOT-SUP-PLIED

CANCEL-

...

...

...

CANCELLED

SHIPPED

EXP

EXPind

EXPind

EXPind
NOT-SUP-PLIED

EXPind

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

LST

...

...

...

LSTind

LSTind

LSTind

LOST

...

...

...

LOST

LOST

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

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

...

...

...

RCVreq

RCV(opt)

OVERDUE

RCVreq

repeat

RCV(opt)

...

...

...

RET

req

p5

RET (opt)

RETURNED

RET (opt)

...

...

...

RET (opt)

RETURNED

RETreq repeat

.

RCVreq

...

...

...

RCV (opt)

RENreq

p5 REN

RENEW/PENDING

REN

...

...

...

REN

REN

LSTreq

p5 LST

LOST

LST LOST

LST LOST

...

...

...

LSTreq repeat

DAMreq

DAM

DAM

DAM

...

...

...

MSGreq

MSG

MSG

MSG

MSG

STQreq

STQ

...

...

...

STQ

STQ

STRreq

STR

SIR

STR

STR

...

...

...

ANSind-WS

RECEIVED

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/ OVERDUE

ANS-WS repeat

...

...

...

RECEIVED

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/OVERDUE

ANS-HP

ANSind-HP

...

...

...

ANSind-HP

RENEW/PENDING

ANSind-HP

RENEW/OVERDUE

ANSind-HP

NOT-RCVD/OVERDUE

ANS-HP repeat

ANSind-HP

RECEIVED

...

...

...

RENEW/PENDING

ANSind-HP

RENEW/OVERDUE

ANSind HP

NOT-RCVD/OVERDUE

CAR -

CARind -

RECEIVED

CARind-

...

...

...

CARind -

RENEW/OVERDUE

CARind -

NOT-RCVD/OVERDUE

CAR - repeat

CARind -

RECEIVED

CARind -

RENEW/PENDING

...

...

...

RENEW/OVERDUE

CARind -

NOT-RCVD/OVERDUE

SHI

SHIind

RECEIVED

SHIind

RENEW/PENDING

SHIind

...

...

...

SHIind

NOT-RCVD/OVERDUE

SHI
repeat

SHIind

RECEIVED

SHIind

RENEW/PENDING

SHIind

RENEW/OVERDUE

...

...

...

NOT-RCVD/OVERDUE

RCL

p5 RCLind

RECALL

RCLind RECALL

RCLind RECALL

RCLind RECALL

RCL
repeat

...

...

...

RCVreq

DUE

p5 DUEind

...

...

...

p7 and p8 DUEind

OVERDUE

OVERDUE

DUE

p5 DUEind

...

...

...

^p7

OVERDUE

DUE
repeat

...

...

...

DUEind

DUEind

LST

LSTind

LST
repeat

...

...

...

DAM

MSG

...

...

...

MSGind

MSGind

MSGind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/ OVERDUE

STQ

...

...

...

STQind

STQind

STQind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/ OVERDUE

STR

...

...

...

STRind

STRind

STRind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/OVERDUE

REA +

...

...

...

REAind + RECEIVED

REAind + RECEIVED

REAind + RECEIVED

REA +
repeat

...

...

...

RECEIVED

REA-

p5

...

...

...

REAind- OVERDUE

REAind - RECEIVED

REA-
repeat

REAind -

...

...

...

RECEIVED

CHK

p5

CHKind

...

...

...

CHKind

CHKind

RETURNED

RETURNED

RETURNED

RETURNED

...

...

...

CHK
repeat

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

OVERDUE

...

...

...

LOST

RECALL

RCVreq

RCV(opt)

...

...

...

RECALL

RCVreq

repeat

...

...

...

RCVreq

RCV (opt)

RETreq

...

...

...

p9

RET (opt) RETURNED

RET (opt) RETURNED

RETreq

...

...

...

RET (opt)

RENreq

REN

...

...

...

RENEW/OVERDUE

RENreq

...

...

...

LSTreq

LST

LST

LST

LST

LOST

LOST

LOST

...

...

...

LSTreq

LST

repeat

LOST

...

...

...

DAMreq

DAM

DAM

DAM

OVERDUE

RETURNED

...

...

...

MSGreq

MSG

MSG

MSG

MSG

OVERDUE

RETURNED

LOST

...

...

...

STQreq

STQ

STQ

STQ

STQ

OVERDUE

RETURNED

LOST

...

...

...

STRreq

STR

STR

STR

STR

OVERDUE

RETURNED

LOST

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS

ANSind-WS

OVERDUE

RETURNED

LOST

...

...

...

ANS-WS
repeat

ANSind-WS

ANSind-WS

ANSind-WS

ANSind-WS

OVERDUE

. RETURNED

LOST

RECALL

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

OVERDUE

RETURNED

LOST

RECALL

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

OVERDUE

RETURNED

LOST

RECALL

CAR -

...

...

...

CARind -

CARind -

CARind -

OVERDUE

RETURNED

LOST

RECALL

CAR -
repeat

...

...

...

CARind -

CARind -

CARind -

OVERDUE

RETURNED

LOST

RECALL

SHI

SHIind

...

...

...

SHIind

SHIind

OVERDUE

RETURNED

LOST

RECALL

SHI
repeat

SHIind

...

...

...

SHIind

SHIind

OVERDUE

RETURNED

LOST

RECALL

RCL

RCLind

RCLind

...

...

...

RCLind

RCL

RCLind

RCLind

RCLind

...

...

...

LOST

RECALL

RCVreq

RCV (opt)

...

...

...

RECALL

DUE

DUEind

DUEind

DUEind

DUEind

OVERDUE

...

...

...

LOST

RECALL

DUE

DUEind

DUEind

DUEind

DUEind

...

...

...

LOST

RECALL

LST

LSTind

LSTind

LSTind

...

...

...

LOST

LOST

LST

LSTind

...

...

...

LOST

DAM

DAMind

...

...

...

MSG

MSGind

MSGind

MSGind

MSGind

OVERDUE

...

...

...

LOST

RECALL

STQ

STQind

STQind

STQind

STQind

OVERDUE

...

...

...

LOST

RECALL

STR

STRind

STRind

STRind

STRind

OVERDUE

...

...

...

LOST

RECALL

REA +

REAind +

REAind +

REAind +

...

...

...

LOST

RECALL

REA +

REAind +

REAind +

REAind +

...

...

...

LOST

RECALL

REA -

REAind -

REAind -

REAind -

REAind -

OVERDUE

...

...

...

LOST

RECALL

REA -

REAind -

REAind -

REAind -

REAind -

OVERDUE

...

...

...

LOST

RECALL

CHK

CH Kind

CHKind

CHKind

RETURNED

...

...

...

RETURNED

CHK

repeat

CHKind

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

...

...

...

IDLE

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

FORWARD

ILL

ILLind

...

...

...

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

ILLind

NOT-SUP-PLIED

ILLind

...

...

...

ILLind

FORWARD

ILL

repeat

ILLind

IN-PROCESS

...

...

...

NOT-SUP-PLIED

ILLind

CONDITIONAL

ILLind

FORWARD

FWDreq

...

...

...

ILL

FW

D

disable EXPIRY timer

FORWARD

...

...

...

ANSreq-CO

ANS-
CO

reset
EXPIRY
timer
CONDI-TIONAL

...

...

...

repeat

ILL

FWD

...

...

...

ANS-COreq

ANS-
CO

reset
EXPIRY
timer
CONDI-
TIONAL

...

...

...

repeat

ANS-CO

CONDITIONAL

...

...

...

ANS-RY

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

repeat

ANS-RY

NOT-SUP-PLIED

...

...

...

ANS-UN

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

UNreq

repeat

ANS-UN

NOT-SUP-PLIED

...

...

...

NS-LPreq

ANS-LP

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

ANS-

LPreq

repeat

ANS-LP

NOT-SUP-PLIED

...

...

...

ANS-WSreq

ANS-WS

disable EXPIRY timer

IN-PROCESS

...

...

...

ANS-WSreq

repeat

ANS-WS

IN-PROCESS

...

...

...

ANS-HPreq

ANS-HP

disable EXPIRY timer

IN-PROCESS

...

...

...

ANS-HPreq

repeat

ANS-HP

IN-PROCESS

...

...

...

ANS-ESreq

ANS-ES

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

ANS-
ESreq
repeat

ANS-ES

NOT-SUP-
PLIED

...

...

...

CARreq +

CAR +

CANCELLED

...

...

...

+ repeat

CAR + CANCELLED

CARreq-

...

...

...

CAR-

enable EXPIRY timer

IN-PROCESS

CARreq-

...

...

...

CAR -

IN-PROCESS

SHIreq

...

...

...

SHI (opt)

set RETURN var

disable EXPIRY timer

SHIPPED

...

...

...

repeat

MSGreq

...

...

...

MSG

IN-PROCESS

MSG

NOT-SUP-PLIED

MSG

CONDITIONAL

MSG

CANCEL-PENDING

MSG

...

...

...

MSG

FORWARD

STQreq

STQ

IN-PROCESS

STQ

NOT-SUP-PLIED

STQ

...

...

...

STQ

CANCEL-PENDING

STQ

CANCELLED

STQ

FORWARD

STRreq

STR

...

...

...

STR

NOT-SUP-PLIED

STR

CONDITIONAL

STR

CANCEL-PENDING

STR

CANCELLED

STR

...

...

...

C-REP +

C-REPind + IN- PROCESS

C-REPind+

NOT-SUP-PLIED

C-REPind+

reset EXPIRY timer

IN-PROCESS

...

...

...

C-REP + repeat

C-REPind + IN- PROCESS

C-REPind +

NOT-SUP-PLIED

...

...

...

C-REP-

C-REPind-

NOT-SUP-PLIED

C-REPind - NOT-SUPPLIED

...

...

...

C-REPind-

NOT-SUP-PLIED

CAN

...

...

...

p7

CANind

CANCEL-PEND-ING

CANind

NOT-SUP-PLIED

CANind

CANCEL-PEND-ING

CANind

CANCEL-PENDING

...

...

...

CANCELLED

CANind

FORWARD

CAN

^p7

CANind

IN-PROCESS

CANind

...

...

...

CANind

CANCEL-PEND-ING

CANind

CANCEL-PENDING

CANind

CANCELLED

CANind

FORWARD

CAN

...

...

...

CANind

IN-PROCESS

CANind

NOT-SUP-PLIED

CANind

CANCEL-PEND-ING

CANind

CANCEL-PENDING

...

...

...

CANCELLED

CANind

FORWARD

MSG

MSGind

IN-PROCESS

MSGind

NOT-SUP-PLIED

...

...

...

CONDITIONAL

MSGind

CANCEL-PENDING

MSGind

CANCELLED

MSGind

FORWARD

STQ

...

...

...

IN-PROCESS

STQind

NOT-SUP-PLIED

STQind

CONDITIONAL

STQind

CANCEL-PENDING

STQind

CANCELLED

...

...

...

FORWARD

STR

STRind

IN-PROCESS

STRind

NOT-SUP-PLIED

STRind

CONDITIONAL

...

...

...

CANCEL-PENDING

STRind

CANCELLED

STRind

FORWARD

EXPIRY

Timeout

EXPind

...

...

...

NOT-SUPPLIED

EXPind

EXP

NOT-SUPPLIED

Bảng A.8 - Bảng trạng thái bên đáp ứng: Giai đoạn theo dõi

...

...

...

SHIPPED

RENEWPENDING

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

LOST

SHIreq

...

...

...

SHIreq

SHI (opt)

...

...

...

repeat

SHIPPED

...

...

...

CHKreq

p5

CHK (opt)

CHK (opt)

CHK (opt)

CHK (opt)

...

...

...

CHK (opt) CHECKED-IN

CHECKED-IN

CHECKED-IN

CHECKED-IN

CHECKED-IN

CHKreq

...

...

...

CHK (opt)

repeat

...

...

...

CHECKED-IN

RCLreq

p5 RCL

RCL

RCL

RCL

...

...

...

RECALL

RECALL

RECALL

RECALL

...

...

...

RCL

repeat

...

...

...

RECALL

DUEreq

p5 DUE

DUE

...

...

...

OVERDUE

RENEW OVERDUE

DUE

...

...

...

OVERDUE

...

...

...

DUE

DUE

repeat

...

...

...

RENEW OVERDUE

OVERDUE

LSTreq

LST

LST

LST

...

...

...

LST

LST

LOST

LOST

LOST

LOST

LOST

...

...

...

LOST

LSTreq

LST

...

...

...

LOST

DAMreq

...

...

...

DAM

...

...

...

CHECKED-IN

MSGreq

MSG

MSG

MSG

MSG

MSG

...

...

...

MSG

SHIPPED

RENEW/
PENDING

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

LOST

...

...

...

STQ

STQ

STQ

STQ

STQ

STQ

STQ

SHIPPED

...

...

...

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

LOST

STRreq

STR

STR

STR

...

...

...

STR

STR

STR

SHIPPED

RENEW PENDING

RENEW OVERDUE

OVERDUE

RECALL

...

...

...

LOST

REAreq +

REA +

REA +

...

...

...

SHIPPED

SHIPPED

REAreq +

REA+

...

...

...

repeat

SHIPPED

...

...

...

REAreq -

REA -

REA -

...

...

...

SHIPPED

OVERDUE

...

...

...

REA -

REA -

repeat

SHIPPED

...

...

...

OVERDUE

ILL

ILLind

...

...

...

ILLind

ILLind

ILLind

SHIPPED

OVERDUE

RECALL

...

...

...

LOST

ILL

ILLind

ILLind

ILLind

ILLind

ILLind

...

...

...

SHIPPED

OVERDUE

RECALL

CHECKED-IN

LOST

CAN

CANind

...

...

...

CANind

CANind

CANind

CANind

CANind

SHIPPED

RENEW PENDING

RENEW OVERDUE

...

...

...

RECALL

CHECKED-IN

LOST

CAN

repeat

CANind

SHIPPED

CANind

RENEW PENDING

...

...

...

RENEW OVERDUE

CANind

OVERDUE

CANind

RECALL

CANind

CHECKED-IN

CANind

LOST

...

...

...

RCVind

SHIPPED

RCVind

RENEW PENDING

RCVind

RENEW OVERDUE

RCVind

OVERDUE

RCVind

...

...

...

RCVind

CHECKED-IN

RCVind

LOST

RCV

repeat

RCVind

SHIPPED

RCVind

...

...

...

RCVind

RENEW OVERDUE

RCVind

OVERDUE

RCVind

RECALL

RCVind

CHECKED-IN

RCVind

...

...

...

RET

RETind

SHIPPED

RETind

RENEW PENDING

RETind

RENEW OVERDUE

RETind

OVERDUE

...

...

...

RECALL

RETind

CHECKED-IN

RETind

LOST

RET repeat

RETind

SHIPPED

RETind

...

...

...

RETind

RENEW OVERDUE

RETind

OVERDUE

RETind

RECALL

RETind

CHECKED-IN

RETind

...

...

...

REN

p7 RENind

RENEWPENDING

RENind

RENEW PENDING

RENind

RENEW OVERDUE

RENind

RENEW OVERDUE

...

...

...

RECALL

RENind

CHECKED-IN

RENind

LOST

REN

^p7

RENind

SHIPPED

...

...

...

RENEW PENDING

RENind

RENEW OVERDUE

RENind

RENEW OVERDUE

RENind

RECALL

RENind

CHECKED-IN

...

...

...

LOST

REN

repeat

RENind

SHIPPED

RENind

RENEW PENDING

RENind

RENEW OVERDUE

...

...

...

OVERDUE

RENind

RECALL

RENind

CHECKED-IN

RENind

LOST

LST

LSTind

...

...

...

LSTind

LOST

LSTind

LOST

LSTind

LOST

LSTind

LOST

LSTind

...

...

...

LSTind

LOST

LST

repeat

...

...

...

CHECKED-IN

LSTind

LOST

DAM

DAMind

SHIPPED

DAMind

RENEW PENDING

DAMind

...

...

...

DAMind

OVERDUE

DAMind

RECALL

DAMind

CHECKED-IN

DAMind

LOST

MSG

...

...

...

SHIPPED

MSGind

RENEW PENDING

MSGind

RENEW OVERDUE

MSGind

OVERDUE

MSGind

RECALL

...

...

...

CHECKED-IN

MSGind

LOST

STQ

STQind

SHIPPED

STQind

RENEW PENDING

STQind

...

...

...

STQind

OVERDUE

STQind

RECALL

STQind

CHECKED-IN

STQind

LOST

STR

...

...

...

SHIPPED

STRind

RENEW PENDING

STRind

RENEW OVERDUE

STRind

OVERDUE

STRind

RECALL

...

...

...

CHECKED-IN

STRind

LOST

Bảng A.9 - Bảng trạng thái người trung gian: Vai trò bên yêu cầu

IDLE

PENDING

NOT-SUP-PLIED

CONDITIONAL

...

...

...

CANCELLED

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

update PART var

PENDING

...

...

...

ILLreq

repeat

ILL

PENDING

...

...

...

NOT-SUP-PLIED

ILL

CONDITIONAL

ILL

SHIPPED

C-REPreq

+

...

...

...

C-REP +

NOT-SUP-PLIED

C-REP + PENDING

ILlreq

p2 or p3

...

...

...

update CHAIN var

update PART var

PENDING

...

...

...

repeat

C-REP +

PENDING

C-REP +

NOT-SUP-PLIED

...

...

...

C-REPreq

C-REP-

NOT-SUP-PLIED

C-REP-

NOT-SUPPLIED

...

...

...

C-REPreq-

repeat

C-REP-

NOT-SUP-PLIED

...

...

...

CANreq

CAN

CANCEL-PEND-ING

CAN

NOT-SUP-PLIED

CAN

CANCEL-PEN-DING

...

...

...

CAN

SHIPPED

CANreq

repeat

CAN

PENDING

CAN

NOT-SUP-PLIED

...

...

...

CAN

CANCEL-PENDING

CAN

CANCELLED

CAN

SHIPPED

RCVreq

RCV (opt)

...

...

...

SHIPPED

RCV (opt)

set RETURN var

SHIPPED

p6

RCV (opt)

...

...

...

SHIPPED

RCVreq

repeat

...

...

...

RETreq

RET (opt) SHIPPED

p6

RET

...

...

...

RETreq

repeat

RET

...

...

...

RENreq

REN

SHIPPED

p6

...

...

...

SHIPPED

RENreq

repeat

...

...

...

SHIPPED

LSTreq

LST

SHIPPED

...

...

...

LST

SHIPPED

LSTreq

repeat

...

...

...

LST

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

update PART var PENDING

...

...

...

DAMreq

DAM

SHIPPED

...

...

...

SHIPPED

p6

DAM

SHIPPED

MSGreq

MSG

PENDING

...

...

...

NOT-SUP-PLIED

MSG

CONDITIONAL

MSG

CANCEL-PENDING

MSG

CANCELLED

MSG

SHIPPED

...

...

...

STQ

PENDING

STQ

NOT-SUP-PLIED

STQ

CONDITIONAL

STQ

CANCEL-PENDING

...

...

...

CANCELLED

STQ

SHIPPED

STRreq

STR

PENDING

STR

NOT-SUP-PLIED

...

...

...

CONDITIONAL

STR

CANCEL-PENDING

STR

CANCELLED

STR

SHIPPED

FWD

...

...

...

PENDING

FWDind

PENDING

FWD

repeat

...

...

...

FWDind

PENDING

ANS-CO

...

...

...

ANSindCO

CONDITIONAL

ANSind-CO

NOT-SUP-PLIED

ANSind-CO

CONDITIONAL

ANSind-CO

CANCEL-PENDING

ANSind-CO

...

...

...

ANS-CO

^p7

ANSind-CO

PENDING

ANSind-CO

NOT-SUP-PLIED

ANSind-CO

...

...

...

ANSind-CO

CANCEL-PENDING

ANSind-CO

CANCELLED

ANS-CO

repeat

ANSind-CO

...

...

...

ANSind-CO

NOT-SUP-PLIED

ANSind-CO

CONDITIONAL

ANSind-CO

CANCEL-PENDING

ANSind-CO

CANCELLED

...

...

...

ANSind-RY

NOT-SUPPLIED

ANSind-RY

NOT-SUP-PLIED

ANSind-RY

NOT-SUPPLIED

...

...

...

ANS-RY

repeat

ANSind-RY

NOT-SUP-PLIED

...

...

...

ANS-UN

ANSind-UN

NOT-SUPPLIED

ANSind-UN

NOT-SUP-PLIED

ANSind-UN NOT- SUPPLIED

...

...

...

ANS-UN

repeat

ANSind-UN

NOT-SUP-PLIED

...

...

...

ANS-LP

ANSind-LP NOT- SUPPLIED

ANSind-LP

NOT-SUP-PLIED

ANSind-LP NOT- SUPPLIED

...

...

...

p2 or p3

ILL

update CHAIN var

update PART var

PENDING

...

...

...

ANS-LP

repeat

ANSind-LP

NOT-SUP-

PLIED

...

...

...

ANS-WS

ANSind-WS

PENDING

ANSind-WS

NOT-SUP-PLIED

ANSind-WS

...

...

...

ANSind-WS

CANCEL-PENDING

ANSind

CANCELLED

WSAN-Sind-WS

SHIPPED

ANS-WS

repeat

...

...

...

PENDING

ANSind-WS

NOT-SUP-PLIED

ANSind-WS

CONDITIONAL

ANSind-WS

CANCEL- PENDING

ANSind-WS

CANCELLED

...

...

...

SHIPPED

ANS-HP

ANSind-HP

PENDING

ANSind-HP

NOT-SUP-PLIED

ANSind-HP

CONDITIONAL

...

...

...

CANCEL-PENDING

ANSind-HP

CANCELLED

ANSind- HP

SHIPPED

ANS-HP

repeat

ANSind-HP

...

...

...

ANSind-HP

NOT-SUP-PLIED

ANSind-HP

CONDITIONAL

ANSind-HP

CANCEL-PENDING

ANSind-HP

CANCELLED

ANSind-HP

...

...

...

ANS-ES

ANSind-ES NOT- SUPPLIED

ANSind-ES

NOT-SUP-PLIED

ANSind-ES

NOT-SUPPLIED

...

...

...

ANS-ES

repeat

ANSind-ES

NOT-SUP- PLIED

...

...

...

CAR +

CARind + CANCELLED

CARind + CANCELLED

CAR + repeat

...

...

...

CARind + CANCELLED

CAR -

CARind - PENDING

...

...

...

CARind - PENDING

CARind - SHIPPED

CAR -

repeat

CARind - PENDING

...

...

...

CARind - SHIPPED

SHI

SHIind

SHIPPED

...

...

...

SHIPPED

SHIind

SHIPPED

SHI

repeat

...

...

...

SHIind

SHIPPED

DUE

DUEind

SHIPPED

...

...

...

p6

DUEind

SHIPPED

DUE

repeat

...

...

...

DUEind

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

...

...

...

PENDING

REA +

...

...

...

p6

REAind + SHIPPED

REA + repeat

...

...

...

REAind + SHIPPED

REA-

...

...

...

p6

REAind-

SHIPPED

REA-

repeat

...

...

...

REAind-

SHIPPED

LST

LSTind

SHIPPED

...

...

...

LSTind

SHIPPED

p6

LSTind

SHIPPED

LST

repeat

...

...

...

LSTind

SHIPPED

DAM

...

...

...

p6

DAMind

SHIPPED

RCL

RCLind

...

...

...

p6

RCLind

RCL

repeat

...

...

...

RCLind

SHIPPED

MSG

MSGind

...

...

...

MSGind

NOT-SUP-PLIED

MSGind

CONDITIONAL

MSGind

CANCEL-PENDING

MSGind

CANCELLED

MSGind

...

...

...

STQ

STQind

PENDING

STQind

NOT-SUP-PLIED

STQind

CONDITIONAL

STQind

...

...

...

STQind

CANCELLED

STQind

SHIPPED

STR

STRind

PENDING

STRind

...

...

...

STRind

CONDITIONAL

STRind

CANCEL-PENDING

STRind

CANCELLED

STRind

SHIPPED

EXP

...

...

...

EXPind

NOT-SUPPLIED

EXPind

NOT-SUP-PLIED

EXPind

NOT-SUPPLIED

EXPind

NOT-SUPPLIED

...

...

...

ILLreq

p2 or p3 ILL

update CHAIN var

update PART var PENDING

...

...

...

CHK

CHKind

SHIPPED

CHKind

SHIPPED

...

...

...

CHKind

SHIPPE

CHK

repeat

...

...

...

CHKind

SHIPPED

Bảng A.10 - Bảng trạng thái người trung gian: Vai trò bên đáp ứng

IDLE

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

...

...

...

FORWARD

SHIPPED

ILL

ILLind

set FWDvar

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

...

...

...

IN-PROCESS

ILLind

NOT-SUP-PLIED

ILLind

CONDITIONAL

ILLind

FORWARD

...

...

...

SHIPPED

ILL

repeat

ILLind

IN-PROCESS

ILLind

NOT-SUP-PLIED

ILLind

...

...

...

ILLind

FORWARD

ILLind

SHIPPED

FWDreq

p4

...

...

...

FWD

disable EXPIRY timer

FORWARD

...

...

...

repeat

ILL

FWD

...

...

...

ANSreq-CO

ANS-CO

reset EXPIRY timer

CONDITIONAL

ANS-CO

...

...

...

ANS-CO

CANCELLED

ANS-
COreq

repeat

ANS-CO

disable EXPIRY timer

...

...

...

ANS-CO

NOT-SUP-PLIED

ANS-CO

CONDITIONAL

ANS-CO

CANCEL-PENDING

ANS-CO

CANCELLED

...

...

...

ILL

ILLind

set FWD var

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

...

...

...

NOT-SUP-PLIED

ILLind

CONDITIONAL

ILLind

FORWARD

ILLind

SHIPPED

...

...

...

ANS-RY

disable EXPIRY timer

NOT-SUP-PLIED

ANS-RY

disable EXPIRY timer

NOT-SUP-PLIED

...

...

...

ANS-RYreq

repeat

ANS-RY

NOT-SUP-PLIED

...

...

...

ANS-UNreq

ANS-UN

disable EXPIRY timer

NOT-SUP-PLIED

...

...

...

ANS-UN

disable EXPIRY timer

NOT-SUP-PLIED

ANS-UNreq

repeat

...

...

...

ANS-UN

NOT-SUP-PLIED

ANS-LPreq

...

...

...

disable EXPIRY timer

NOT-SUP-PLIED

ANS-LP

disable EXPIRY timer

NOT-SUP-PLIED

...

...

...

ANS-
LPreq

repeat

ANS-LP

NOT-SUP-PLIED

...

...

...

ANS-WSreq

ANS-WS

disable EXPIRY timer

IN-PROCESS

ANS-WS

NOT-SUP-PLIED

ANS-WS

...

...

...

ANS-WS

CANCEL-PENDING

ANS-WS

CANCELLED

ANS-WS

SHIPPED

ANS-WSreq

repeat

...

...

...

ANS-WS

IN-PROCESS

ANS-WS

NOT-SUP-PLIED

ANS-WS

CONDITIONAL

ANS-WS

CANCEL-PENDING

ANS-WS

...

...

...

ANS-WS

SHIPPED

ANS-HPreq

ANS-HP

disable EXPIRY timer

IN-PROCESS

ANS-HP

...

...

...

ANS-HP

CONDITIONAL

ANS-HP

CANCEL-PENDING

ANS-HP

CANCELLED

ANS-HP

SHIPPED

...

...

...

ILLind

set FWDvar

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

ILLind

...

...

...

ILLind

CONDITIONAL

ILLind

FORWARD

ILLind

SHIPPED

ANS-HPreq

...

...

...

ANS-HP

IN-PROCESS

ANS-HP

NOT-SUP-PLIED

ANS-HP

CONDITIONAL

ANS-HP

CANCEL-PENDING

...

...

...

CANCELLED

ANS-HP

SHIPPED

ANS-ESreq

ANS-E

disable EXPIRY timer

NOT-SUP-PLIED

...

...

...

ANS-ES

disable EXPIRY timer

NOT-SUP-PLIED

ANS-ESreq

repeat

...

...

...

ANS-ES

NOT-SUP-PLIED

CARreq +

...

...

...

CAR +

CANCELLED

CARreq + repeat

...

...

...

CAR +

CANCELLED

CARreq-

...

...

...

CAR-

enable EXPIRY timer

IN-PROCESS

CAR-

...

...

...

CARreq-

repeat

CAR-

IN-PROCESS

...

...

...

CAR-

SHIPPED

Bảng A.11 - Bảng trạng thái người trung gian: vai trò bên đáp ứng

SHIreq

SHI

set RETURN var

disable EXPIRY timer

SHIPPED

...

...

...

SHI

set RETURN variable

disable EXPIRY timer

SHIPPED

SHI

SHIPPED

...

...

...

repeat

SHI

...

...

...

MSGreq

MSG

IN-PROCESS

MSG

NOT-SUP-PLIED

MSG

CONDITIONAL

MSG

...

...

...

MSG

CANCELLED

MSG

FORWARD

MSG

SHIPPED

STQreq

STQ

...

...

...

STQ

NOT-SUP-PLIED

STQ

CONDITIONAL

STQ

CANCEL-PENDING

STQ

CANCELLED

STQ

...

...

...

STQ

SHIPPED

STRreq

STR

IN-PROCESS

STR

NOT-SUP-PLIED

STR

...

...

...

STR

CANCEL-PENDING

STR

CANCELLED

STR

FORWARD

STR

SHIPPED

CHKreq

...

...

...

CHK (opt) SHIPPED

CHK(opt)

SHIPPED

p6

CHK (opt) SHIPPED

...

...

...

repeat

CHK (opt) SHIPPED

...

...

...

DUE

SHIPPED

p6

...

...

...

SHIPPED

DUEreq repeat

...

...

...

SHIPPED

REAreq +

...

...

...

REA + SHIPPED

REAreq + repeat

...

...

...

SHIPPED

REAreq -

...

...

...

REA-

SHIPPED

REAreq

-repeat

...

...

...

REA-

SHIPPED

RCLreq

RCL

SHIPPED

...

...

...

p6

RCL

SHIPPED

RCLreq

repeat

...

...

...

RCL

SHIPPED

LSTreq

LST

...

...

...

LST

SHIPPED

p6

LST

SHIPPED

...

...

...

repeat

LST

...

...

...

DAMreq

p6

...

...

...

DAM

...

...

...

SHIPPED

C-REP +

...

...

...

C-REPind +

C-REPind +

PROCESS

...

...

...

reset EXPIRY timer

...

...

...

C-REP +

C-REPind + IN-

C-REPind +

...

...

...

repeat

PROCESS

NOT-SUP-PLIED

...

...

...

C-REP-

C-REPind-

C-REPind-

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

...

...

...

C-REP

C-REPind-

...

...

...

NOT-SUP-PLIED

CAN

...

...

...

P7

CANind

CANind

CANind

CANind

CANind

CANind

...

...

...

CANCEL-PENDING

NOT-SUP-PLIED

CANCEL-PENDING

CANCEL-PENDING

CANCELLED

FORWARD

SHIPPED

CAN

...

...

...

CANind

CANind

CANind

CANind

CANind

CANind

CANind

...

...

...

NOT-SUP-PLIED

CANCEL-PENDING

CANCEL-PENDING

CANCELLED

FORWARD

SHIPPED

CAN

CANind

...

...

...

CANind

CANind

CANind

CANind

CANind

repeat

IN-PROCESS

NOT-SUP-PLIED

...

...

...

CANCEL-PENDING

CANCELLED

FORWARD

SHIPPED

MSG

MSGind

MSGind

MSGind

...

...

...

MSGind

MSGind

MSGind

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

...

...

...

FORWARD

SHIPPED

STQ

STQind

IN-PROCESS

STQind

NOT-SUP-PLIED

STQind

...

...

...

STQind

CANCEL-PENDING

STQind

CANCELLED

STQind

FORWARD

STQind

SHIPPED

STR

...

...

...

STRind

IN-PROCESS

STRind

NOT-SUP-PLIED

STRind

CONDITIONAL

STRind

CANCEL-PENDING

STRind

...

...

...

STRind

FORWARD

STRind

SHIPPED

RCV

RCVind

SHIPPED

...

...

...

RCVind

SHIPPED

p6

RCVind

SHIPPED

RCV

repeat

...

...

...

RCVind

SHIPPED

RET

...

...

...

RETind

SHIPPED

p6

RETind

...

...

...

RET

repeat

...

...

...

SHIPPED

REN

RENind

SHIPPED

...

...

...

p6

RENind

SHIPPED

REN

repeat

...

...

...

RENind

SHIPPED

LST

LSTind

SHIPPED

...

...

...

p6 LSTind SHIPPED

LST

repeat

...

...

...

LSTind

SHIPPED

DAM

DAMind

SHIPPED

...

...

...

DAMind

SHIPPED

p6

DAMind

SHIPPED

EXPIRY

...

...

...

EXPind

EXP

NOT-SUP-PLIED

EXPind

EXP

NOT-SUP-PLIED

...

...

...

Phụ lục B

(Quy định)

Cú pháp truyền

B.1  Tổng quan

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

Phụ lục này quy định quy tắc để mã hóa các APDU ILL sử dụng EDIFACT. Nếu mã hóa EDIFACT được sử dụng như cú pháp truyền ILL (ví dụ như một phần bổ sung cho ASN.I), phải áp dụng các quy tắc mã hóa được cung cấp trong phụ lục này.

...

...

...

B.2  Tính năng EDIFACT không được hỗ trợ

Các tính năng EDIFACT sau đây không được hỗ trợ. Chúng không được sử dụng trong một trao đổi:

- Sử dụng các nhóm chức năng

CHÚ THÍCH: Các nhóm chức năng được sử dụng để truyền các nhóm thông báo cùng loại; đây là một tính năng không cần thiết, khác biệt với khả năng bao gồm nhiều thông báo, có thể các loại khác nhau, trong một cuộc truyền. Khả năng sau cũng có sẵn và có thể được sử dụng.

- Dấu hiệu lồng đoạn rõ ràng

B.3  Bộ ký tự và mức cú pháp

Trong số hai mức cú pháp theo quy định của tiêu chuẩn ISO 9735, mức B sẽ được sử dụng với các bộ ký tự tương ứng. Tuy nhiên, sẽ áp dụng các ký tự dấu phân cách theo quy định tại mức A, nghĩa là các ký tự "+' : ?" trong hai lựa chọn được định nghĩa cho chuỗi ILL tại điều 9. Chỉ có chuỗi EDIFACT có thể được sử dụng với mã hóa EDIFACT.

B.4  Trao đổi EDIFACT

EDIFACT định nghĩa một trao đổi là đơn vị dữ liệu được truyền giữa hai địa điểm. Các APDU ILL được mã hóa như là một phần của một trao đổi EDIFACT.

...

...

...

Nội dung đoạn được tạo thành từ một hoặc nhiều phần tử dữ liệu. Các phần tử dữ liệu được phân cách nhau bởi ký tự "+". Một phần tử dữ liệu được tạo thành từ một chuỗi ký tự của chuỗi EDL FACT, hoặc bởi hai hoặc nhiều phần tử con. Thứ tự của các phần tử dữ liệu và các phần tử dữ liệu con trong một đoạn là cố định.

Các phần tử dữ liệu tùy chọn không chứa dữ liệu cần phải được truyền nếu chúng xuất hiện như phần tử dữ liệu cuối cùng của một đoạn. Ví dụ, một đoạn với mã phân khu "ABC", tạo thành từ ba phần tử dữ liệu, phần tử đầu tiên chứa dữ liệu "12345" và phần tử thứ hai và thứ ba tùy chọn và trống, có thể được truyền đi theo bất kỳ trong ba hình thức sau đây:

ABC+12345++'

ABC+12.345+*

ABC+12345'

Các phần tử con được phân cách với nhau bởi ký tự "":. Một phần tử con được tạo thành từ một chuỗi ký tự EDIFACT. Một phần tử có thể được lặp đến số lần được quy định bởi Đặc tả ASN.I tương ứng tại điều 9.

Các phần tử con tùy chọn không chứa dữ liệu không cần phải được truyền nếu chúng xuất hiện như những phần tử con cuối cùng của một phần tử dữ liệu. Ví dụ, một phần tử dữ liệu đứng trước và sau là các phần tử dữ liệu cùng đoạn và được tạo thành từ hai phần tử con, phần tử đầu tiên chứa dữ liệu "12345" và phần tử thứ hai tùy chọn và trống, có thể được truyền theo một trong hai hình thức sau đây:

...+12345:+...

...+12345+...

...

...

...

Sau đây là định nghĩa của một trao đổi dưới dạng Bachus-Naur. (Tất cả các ký tự chữ, được nằm trong dấu ngoặc kép).

interchange:: = segment_list

segmentjist:: = segment I segment segment_list

segment:: = segment_code "+" segment_content

segment_code:: = alpha alpha alpha

segment_content:: = data_element I data_element"+" segment_content

data_element:: = content_string I content_string data_element

content_string:: = string_part I string_part content_string

string_part:: = normal_string I special_character

...

...

...

normal_string:: = {A variable length string of 0 or more EDIFACTString characters excluding "?+:'"}

alpha:: = {any character a-z or A-Z)

Mỗi trao đổi chứa chính xác một đoạn Tư vấn Chuỗi Dịch vụ (mã đoạn UNA) và một đoạn tiêu đề trao đổi (Mã đoạn UNB), mà cần phải có các đoạn đầu tiên và thứ hai để trao đổi, tương ứng.

Sau các đoạn Tư vấn chuỗi dịch vụ các Đầu trao đổi, trao đổi chứa một hoặc nhiều thông báo. Mỗi thông báo có chứa chính xác một mã Đầu thông báo (mã đoạn UNH) và nó phải là đoạn đầu tiên của một thông báo.

Một thông báo chứa chính xác một đoạn Cuối thông báo (mã đoạn UNT) và nó phải là đoạn kết thúc của thông báo.

Đoạn tiêu đề thông báo, đoạn kết thúc thông báo, và tất cả các đoạn nằm giữa đoạn tiêu đề và kết thúc một thông báo đơn hoàn chỉnh.

Các kiểu dữ liệu ASN.I, bao gồm các APDU, được quy định là kiểu dữ liệu TUẦN TỰ được ánh xạ vào một chuỗi các đoạn EDIFACT. Trật tự của các đoạn này rất quan trọng.

Các đoạn đi sau đoạn kết thúc thông báo phải là đoạn kết thúc trao đổi (mã đoạn UNZ). Chỉ có duy nhất một đoạn kết thúc trao đổi cho mỗi trao đổi, và nó phải là đoạn cuối cùng của trao đổi.

B.5  Các đoạn

...

...

...

Các đoạn kiểm soát bao gồm Tư vấn Chuỗi dịch vụ, Tiêu đề trao đổi, Tiêu đề thông báo, Kết thúc thông báo, Cuối trao đổi. Những đoạn này không chứa bất kỳ thông tin nội dung APDU ILL như quy định tại điều 9. Cấu trúc của các đoạn này được đưa ra trong B.6.

Các đoạn dữ liệu là những đoạn nằm giữa đoạn tiêu đề của thông báo và đoạn kết thúc thông báo. Cấu trúc của các đoạn dữ liệu này được tạo ra bằng cách áp dụng các quy tắc B.7 vào Đặc tả ASN.I tại Điều 9.

Giá trị dữ liệu của một APDU ILL hoàn toàn chứa trong các đoạn dữ liệu của một thông báo đơn.

B.6  Mã hóa đoạn kiểm soát

B.6.1  Cấu trúc đoạn kiểm soát

Mục này định nghĩa cấu trúc các đoạn kiểm soát. Mỗi đoạn được gán một tên và một mã đoạn ba ký tự được sử dụng để xác định trong việc trao đổi EDIFACT. Một mô tả đoạn được quy định theo sau là danh sách các phần tử dữ liệu chứa trong đoạn này. Các phần tử dữ liệu này được mô tả trong B.6.2. Tất cả phần tử dữ liệu trong các đoạn kiểm soát là bắt buộc.

Tên đoạn

Mã đoạn

Mô tả

...

...

...

UNA

Xác định các ký tự được lựa chọn để sử dụng như các dấu phân cách và các chỉ số trong một trao đổi.

Đây phải là đoạn đầu trong trao đổi và phải xuất hiện ngay trước Đầu trao đổi (UNB)

Tên đoạn

Mã đoạn

Mô tả

Các phần tử dữ liệu

Đầu trao đổi (Interchange Header)

UNB

...

...

...

Ký hiệu nhận dạng cú pháp

Người gửi trao đổi

Người nhận trao đổi

Ngày/thời gian chuẩn bị

Tham chiếu kiểm soát trao đổi

ID thỏa thuận truyền thông

Tên đoạn

Tên đoạn

Mã đoạn

...

...

...

Tư vấn Chuỗi Dịch vụ

Cuối trao đổi

UNZ

Cho biết kết thúc của một trao đổi. Phải là đoạn cuối cùng của một trao đổi.

Các phần tử dữ liệu

Đếm kiểm soát trao đổi

Tham chiếu kiểm soát trao đổi

Tên đoạn

Mã đoạn

...

...

...

Các phần tử dữ liệu

Đầu thông báo

UNH

Cho biết bắt đầu một thông báo

Tham chiếu thông báo

Ký hiệu nhận dạng thông báo bằng số

Tên đoạn

Mã đoạn

Mô tả

...

...

...

Cuối thông báo

UNT

Cho biết kết thúc một thông báo

Số đoạn trong thông báo

Số tham chiếu thông báo

B.6.2  Các phần tử dữ liệu trong đoạn kiểm soát

Phần tử dữ liệu

Ký hiệu nhận dạng cú pháp

Mô tả

...

...

...

Ký hiệu nhận dạng và

Số phiên bản

Biểu diễn

Cả hai phần tử dữ liệu con là bắt buộc

Ký hiệu nhận dạng phải được biểu diễn bằng bốn ký tự "UNOB"

Số phiên bản được biểu diễn bằng ký tự đơn "1"

Phần tử dữ liệu

Người gửi trao đổi

...

...

...

Xác định người gửi trao đổi. Chứa một trong các thành phần của hệ thống ASN.I loại-id hệ thống

Biểu diễn

Biến, độ dài 35, chuỗi EDIFACT

Phần tử dữ liệu

Người nhận trao đổi

Mô tả

Xác định người nhận trao đổi. Chứa một trong các thành phần của hệ thống ASN.I loại-id hệ thống

Biểu diễn

Biến, độ dài 35, chuỗi EDIFACT

...

...

...

Ngày/thời gian chuẩn bị

Mô tả

Ngày và thời gian chuẩn bị trao đổi. Bao gồm hai phần tử con: Ngày và thời gian. Ngày dài sáu ký tự theo định dạng YYMMDD, trong khi thời gian dài bốn ký tự trong định dạng hhmm

Phần tử dữ liệu

Ký hiệu nhận dạng cú pháp

Biểu diễn

Ngày: chuỗi số, độ dài = 6, cố định. Thời gian: chuỗi số, độ dài = 4, cố định.

Phần tử dữ liệu

Tham chiếu kiểm soát trao đổi

...

...

...

Một tham chiếu duy nhất được người gửi gán cho trao đổi

Biểu diễn

Biến, độ dài 14, chuỗi EDIFACT

Phần tử dữ liệu

ID thỏa thuận truyền thông

Mô tả

Xác định thỏa thuận truyền thông điều chỉnh nội dung thông tin của cuộc trao đổi. Nó có giá trị TCVN (ISO-10161a) ILL-1 trong đó TCVN (10161) đại diện cho số ISO của tiêu chuẩn giao thức ILL. Ký hiệu nhận dạng này tương ứng với định nghĩa APDU ILL quy định tại điều 9 của tiêu chuẩn này.

Phần tử dữ liệu

Đếm kiểm soát trao đổi

...

...

...

Tổng số thông báo trong trao đổi này

Biểu diễn

Biến, độ dài =6, chuỗi số

Phần tử dữ liệu

Ký hiệu nhận dạng thông báo

Mô tả

Xác định loại và phiên bản của APDU ILL được chứa trong thông báo. Loại APDU là một chuỗi 6 ký tự như quy định tại B.7.1. Số phiên bản là một chuỗi ba ký tự số.

Biểu diễn

Loại - chuỗi EDIFACT, độ dài ~ 6, cố định. Số phiên bản-chuỗi EDIFACTS, độ dài = 3, biến

...

...

...

Số tham chiếu thông báo

Mô tả

Cung cấp một tham chiếu thông báo duy nhất. Nó không liên quan đến bất kỳ loại APDU ILL nào và, do đó, được dành riêng cho việc mã hóa EDIFACT.

Biểu diễn

Biến, độ dài = 14, chuỗi EDIFACT

Phần tử dữ liệu

Số đoạn trong thông báo

Mô tả

Tính tổng số đoạn trong thông báo, bao gồm cả Đầu thông báo và Cuối thông báo.

...

...

...

biến, độ dài = 6, chuỗi số

B.7  Mã hóa các APDU ILL sử dụng EDIFACT

B.7.1  Ánh xạ kiểu dữ liệu ASN.l vào thông báo

Mỗi thông báo trong một trao đổi EDIFACT tương ứng với một APDU ILL duy nhất. Bảng sau đây liệt kê các kiểu ASN.I được ánh xạ vào thông báo EDIFACT (nghĩa là các APDU ILL) và giá trị ký hiệu nhận dạng thông báo tương ứng với nó.

ASN.I TYPE

(Kiểu ANS. 1)

EDIFACT MESSAGE IDENTIFIER VALUE

(Giá trị ký hiệu nhận dạng EDIFACT)

lll-Request (Yêu cầu ILL)

...

...

...

Forward-Notification (Thông báo chuyển tiếp)

FORNOT

Shipped (Đã chuyển)

SHIPED

ILL-Answer (Câu trả lời ILL)

ILLANS

Conditional-Reply (Trả lời có điều

CONREP

Cancel (Hủy)

...

...

...

Cancel-Reply (Trả lời Hủy)

CNLREP

Received (Đã Nhận)

RCEIVD

Recall (Đòi)

RECALL

Returned (Đã Trả)

RETRND

Checked-ln (Kiểm nhận)

...

...

...

Overdue (Quá hạn)

OVERDU

Renew (Gia hạn)

RENEWL

Renew-Answer (Câu trả lời Gia

RENANS

Lost (Mất)

LOSTIT

Damaged (Hư hại)

...

...

...

Message (Thông báo)

MESSAG

Status-Query (Yêu cầu trạng thái

STATQY

Status-Or-Error-Report (Báo cáo

STATRP

Expired (Hết hạn)

EXPIRD

B.7.2  Ánh xạ kiểu ASN.I vào đoạn EDIFACT

...

...

...

Mỗi đoạn EDIFACT được xác định tên của ký hiệu nhận dạng loại ASN.I tương ứng, Nghĩa là: nếu một ký hiệu nhận dạng kiểu trong đặc tả ASN.I tại điều 9 được định nghĩa là một tên đoạn trong khoản này, thì kiểu ASN.I tương ứng được biểu diễn trong EDIFACT là một đoạn. Đoạn là tùy chọn nếu kiểu tương ứng trong đặc tả ASN.I được khai báo là tùy chọn.

Theo sau tên đoạn là mã đoạn ba ký tự được sử dụng để xác định đoạn trong trao đổi EDIFACT.

Theo sau mã đoạn là danh sách các phần tử dữ liệu tạo nên đoạn này. Tên của các phần tử dữ liệu tương ứng với các ký hiệu nhận dạng kiểu giá trị ASN.I, nghĩa là nếu một ký hiệu nhận dạng kiểu ASN.I của điều 9 xuất hiện trong danh sách thành phần dữ liệu của điều này thì nó được mã hóa trong EDIFACT như một phần tử dữ liệu EDIFACT. Phần tử dữ liệu là tùy chọn nếu kiểu tương ứng trong đặc tả ASN.I được khai báo là tùy chọn.

Một kiểu ASN.I ánh xạ vào một phần tử dữ liệu con EDIFACT hoặc tương ứng với một kiểu đơn giản ASN.I (liệt kê, số nguyên, chuỗi EDIFACT, BOOL hoặc Ký hiệu nhận dạng đối tượng), hoặc chứa phần tử con EDIFACT.

Nếu một phần tử dữ liệu EDIFACT được tạo thành từ các phần tử con, thì các phần tử con được liệt kê sau các phần tử dữ liệu, và được đặt trong dấu ngoặc ({}), ngoại trừ trong trường hợp của các phần tử dữ liệu được định nghĩa là Bên ngoài (EXTERNAL), trong trường hợp đó cấu trúc phải được định nghĩa bên ngoài. Tên của các phần tử con EDIFACT tương ứng với ký hiệu nhận dạng kiểu ASN.I, ví dụ nếu ký hiệu nhận dạng kiểu ASN.I xuất hiện trong danh sách phần tử con, được mã hóa trong EDIFACT như một phần tử con EDIFACT. Phần tử con là tùy chọn nếu kiểu tương ứng trong đặc tả ASN.I được khái báo là tùy chọn.

Một kiểu ASN.I ánh xạ vào một phần tử con EDIFACT phải tương ứng với một kiểu đơn giản ASN.I (Liệt kê, Số nguyên, Chuỗi EDIFACT, BOOL hoặc Ký hiệu nhận dạng đối tượng).

Thứ tự của danh sách các thành phần dữ liệu tương ứng với thứ tự mà trong đó các phần tử dữ liệu phải xuất hiện trong đoạn.

Thứ tự của danh sách các phần tử con tương ứng với thứ tự mà trong đó các phần tử con phải xuất hiện trong phần dữ liệu.

Bất kỳ giá trị mặc định được giả định nếu các phần tử dữ liệu hoặc phần tử con không có mặt được đưa ra trong đặc tả ASN.I.

...

...

...

Tên đoạn

số tài khoản

Mã đoạn

CAN

Phần tử dữ liệu

số tài khoản

Tên đoạn

danh sách đã được thử

Mã đoạn

...

...

...

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn phụ thuộc

- id hệ thống

được lặp lại cho mỗi mục trong danh sách

Tên đoạn

Câu trả lời

Mã đoạn

ANS

Tên đoạn

...

...

...

Mã đoạn

BAD

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm những đoạn sau đây:

địa chỉ bưu điện

địa chỉ hệ thống

Tên đoạn

ID khách hàng

Mã đoạn

...

...

...

Phần tử dữ liệu

tên khách hàng

trạng thái khách hàng

ký hiệu nhận dạng khách hàng

Tên đoạn

kết quả có điều kiện

Mã đoạn

CRE

Phần tử dữ liệu

...

...

...

điều kiện

ngày trả lời

thông tin vị trí

- đoạn phụ thuộc cuối cùng có thể được lặp

Tên đoạn

điều kiện

Mã đoạn

CON

Phần tử dữ liệu

...

...

...

Tên đoạn

tuân thủ bản quyền

Mã đoạn

COC

Phần tử dữ liệu

tuân thủ bản quyền

Tên đoạn

Thông tin tương quan

Mã đoạn

...

...

...

Phần tử dữ liệu

thông tin tương quan

Tên đoạn

dự toán

Mã đoạn

CST

Phần tử dữ liệu

dự toán

Tên đoạn

...

...

...

Mã đoạn

CIT

Phần tử dữ liệu

số tài khoản

chi phí tối đa

{

mã tiền tệ

giá trị tiền tệ

}

...

...

...

sẽ trả lệ phí

thanh toán cung cấp

Tên đoạn

trạng thái hiện thời

Mã đoạn

CUS

Phần tử dữ liệu

trạng thái hiện thời

Tên đoạn

...

...

...

Mã đoạn

DCI

Phần tử dữ liệu

ngày Kiểm nhận

Tên đoạn

ngày đến hạn

Mã đoạn

DUE

Phần tử dữ liệu

...

...

...

gia hạn

Tên đoạn

Ngày trả lời

Mã đoạn

DFR

Phần tử dữ liệu

ngày trả lời

Tên đoạn

ngày nhận

...

...

...

DRC

Phần tử dữ liệu

ngày nhận

Tên đoạn

ngày trả

Mã đoạn

DRT

Phần tử dữ liệu

ngày trả

...

...

...

địa chỉ cung cấp

Mã đoạn

DAD

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm những đoạn sau đây:

địa chỉ bưu điện

địa chỉ hệ thống

Tên đoạn

[dịch vụ cung cấp]

...

...

...

Tên đoạn

ngày đến hạn mong muốn

Mã đoạn

DDD

Phần tử dữ liệu

ngày đến hạn mong muốn

Tên đoạn

dịch vụ cung cấp điện tử

Mã đoạn

...

...

...

Phần tử dữ liệu

phương thức cung cấp điện tử

tham số cung cấp điện tử

id loại tài liệu

tham số loại tài liệu

mô tả cung cấp điện tử

- ba yếu tố tiếp theo cùng nhau tạo thành các chi tiết giao hàng điện tử

- chỉ có một địa chỉ cung cấp điện tử hoặc

id cung cấp điện tử sẽ có mặt

...

...

...

{

ký hiệu nhận dạng dịch vụ viễn thông

địa chỉ dịch vụ viễn thông

}

- hai yếu tố sau cùng nhau tạo thành id cung cấp điện tử

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

{

biểu tượng cá nhân

biểu tượng tổ chức

...

...

...

có mặt

}

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

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con này có thể

có mặt

}

...

...

...

thời gian cung cấp

- đoạn này có thể được lặp

Tên đoạn

báo cáo lỗi

Mã đoạn

ERR

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

thông tin tương quan

...

...

...

báo cáo lỗi người dùng

báo cáo lỗi bên cung cấp

Tên đoạn

kết quả dự tính

Mã đoạn

ESR

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

dự toán

...

...

...

- đoạn phụ thuộc cuối cùng có thể được lặp

Tên đoạn

ngày có sẵn ước tính

Mã đoạn

EDA

Phần tử dữ liệu

ngày có sẵn ước tính

Tên đoạn

phần mở rộng

...

...

...

EXT

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

ký hiệu nhận dạng phần mở rộng

miền giới hạn mở rộng

- đoạn này cũng sẽ chứa một hoặc nhiều đoạn khác mã hóa các phần tử dữ liệu của phần mở rộng giao thức, tức là các loại "tài liệu";

- các đoạn có thể được bao gồm

ở đây được định nghĩa bởi các giá trị của

"Ký hiệu nhận dạng phần mở rộng".

...

...

...

Hoặc 2 của giao thức

Tên đoạn

miền xác định phần mở rộng

Mã đoạn

ECR

Phần tử dữ liệu

miền xác định

Tên đoạn

Ký hiệu nhận dạng phần mở rộng

...

...

...

EID

Phần tử dữ liệu

ký hiệu nhận dạng

Tên đoạn

cờ chuyển tiếp

Mã đoạn

FWD

Phần tử dữ liệu

Cờ chuyển tiếp

...

...

...

thông báo chuyển tiếp

Mã đoạn

FWN

Phần tử dữ liệu

thông báo chuyển tiếp

Tên đoạn

báo cáo lịch sử

Mã đoạn

HRP

...

...

...

ngày yêu cầu

tác giả

nhan đề

tác giả bài báo

nhan đề bài báo

ngày chuyển tiếp cuối cùng

dịch vụ gần đây nhất

ngày dịch vụ gần đây

- hai phần tử dữ liệu kế tiếp theo cùng nhau tạo thành người khởi tạo dịch vụ gần đây nhất:

...

...

...

{

biểu tượng cá nhân

biểu tượng tổ chức

- chỉ một trong những phần tử con này có thể có mặt

}

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

{

tên cá nhân

tên tổ chức

...

...

...

}

loại dịch vụ vận chuyển

kết quả chuyển giao

lưu ý dịch vụ gần đây nhất

Tên đoạn

loại vật mang tin đặt giữ

Mã đoạn

HPM

Phần tử dữ liệu

...

...

...

Tên đoạn

kết quả đặt giữ

Mã đoạn

HPR

Phần tử dữ liệu

không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

ngày có sẵn dự kiến

loại vật mang tin đặt giữ

thông tin địa điểm

...

...

...

Tên đoạn

loại dịch vụ ILL

Mã đoạn

ISV

Phần tử dữ liệu

loại dịch vụ ILL

có thể các các phần tử dữ liệu con lặp

Tên đoạn

đảm bảo cho

...

...

...

ISF

Phần tử dữ liệu

số lượng

{

mã tiền tệ

giá trị tiền tệ

}

Tên đoạn

Id người trung gian

...

...

...

INT

Phần tử dữ liệu

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

{

biểu tượng cá nhân

biểu tượng tổ chức

- chỉ có một trong những phần tử con này có thể

- có mặt

}

...

...

...

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con có thể có mặt

}

Tên đoạn

Id tài liệu

Mã đoạn

HD

...

...

...

loại tài liệu

loại vật mang tin được tổ chức

chỉ số xếp giá

tác giả

nhan đề

phụ đề

cơ quan tài trợ

nơi xuất bản

nhà xuất bản

...

...

...

tập số

phiên bản (lần xuất bản)

ngày xuất bản

ngày xuất bản của phần cấu thành

tác giả bài

nhan đề bài

đánh số thư mục quốc gia- số

ISBN

ISSN

...

...

...

sổ chữ cái bổ sung

nguồn tài liệu tham khảo xác minh

Tên đoạn

thông tin vị trí

Mã đoạn

LOC

Phần tử dữ liệu

- hai phần tử dữ liệu đầu tiên cùng nhau tạo thành các id vị trí biểu tượng cá nhân hoặc tổ chức

{

...

...

...

biểu tượng tổ chức

- chỉ có một trong các phần tử con này có thể có mặt

}

tên cá nhân

tên tổ chức

{

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

- chỉ có một trong các phần tử con này có thể có mặt

}

...

...

...

{

ký hiệu nhận dạng dịch vụ viễn thông

địa chỉ dịch vụ viễn thông

}

chú thích địa điểm

Tên đoạn

kết quả địa điểm

Mã đoạn

LRE

...

...

...

- không; đoạn này bao gồm các đoạn khác phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

lý do thông tin địa điểm (LOC) được cung cấp thông tin vị trí

- đoạn phụ thuộc cuối cùng có thể được lặp

Tên đoạn

chú thích

Mã đoạn

NOT

Phần tử dữ liệu

chú thích

...

...

...

chú thích thông báo

Mã đoạn

NNO

Phần tử dữ liệu

chú thích thông báo

Tên đoạn

cho phép chuyển tiếp

Mã đoạn

PTF

...

...

...

cho phép chuyển tiếp

Tên đoạn

cho phép theo chuỗi

Mã đoạn

PTC

Phần tử dữ liệu

cho phép theo chuỗi

Tên đoạn

cho phép phân khu

...

...

...

PTP

Phần tử dữ liệu

cho phép phân khu

Tên đoạn

cho phép thay đổi danh sách gửi

Mã đoạn

PCL

Phần tử dữ liệu

cho phép thay đổi danh sách gửi

...

...

...

cung cấp vật lý

Mã đoạn

DLS

Chú thích: vì lý do lịch sử mã đoạn này là DLS (trước là "dịch vụ cung cấp")

Phần tử dữ liệu

phương thức vận chuyển

Tên đoạn

địa điểm lưu giữ

Mã đoạn

...

...

...

Phần tử dữ liệu

loại địa điểm lưu giữ

Tên đoạn

địa chỉ bưu điện

Mã đoạn

PAD

Phần tử dữ liệu

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

{

...

...

...

tên tổ chức

- chỉ có một trong những phần tử này có thể có mặt

}

địa chỉ cung cấp bưu chính mở rộng

đường phố và số nhà

hộp thư

thành phố

khu vực

nước

...

...

...

Tên đoạn

Mã đoạn

Phần tử dữ liệu

Tên đoạn

Mã đoạn

Phần tử dữ liệu

Tên đoạn

Mã đoạn

Phần tử dữ liệu

...

...

...

PRF

ưu tiên

số phiên bản giao thức

PVN

số phiên bản giao thức

báo cáo lỗi bên cung cấp

PER

vấn đề chung

vấn đề id giao dịch

...

...

...

{

loại APDU ILL

trạng thái hiện thời

}

- chỉ có một trong những phần tử dữ liệu này có thể xuất hiện

Tên đoạn

Mã đoạn

Phần tử dữ liệu

Tên đoạn

...

...

...

Phần tử dữ liệu

Tên đoạn

lý do thông tin vị trí được cung cấp

RLP

lý do thông tin vị trí được cung cấp

lý do không có thông báo

RNR

lý do không có thông báo

lý do không sẵn có

...

...

...

RNA

Phần tử dữ liệu

lý do không sẵn có

Tên đoạn

lý do không thực hiện

Mã đoạn

RUF

Phần tử dữ liệu

lý do không thực hiện

...

...

...

lý do sẽ cung cấp

Mã đoạn

RWI

Phần tử dữ liệu

lý do sẽ cung cấp

Tên đoạn

nguồn báo cáo

Mã đoạn

RES

...

...

...

nguồn báo cáo

Tên đoạn

Id bên yêu cầu

Mã đoạn

RQI

Phần tử dữ liệu

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

{

biểu tượng cá nhân

...

...

...

- chỉ có một trong những phần tử con này có thể có mặt

}

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

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

Tên đoạn

...

...

...

Mã đoạn

RQN

Phần tử dữ liệu

chú thích bên yêu cầu

Tên đoạn

thông báo tùy chọn của bên yêu cầu

Mã đoạn

ROM

Phần tử dữ liệu

...

...

...

có thể gửi Trả

bên yêu cầu đã chuyển

bên yêu cầu đã Kiểm nhận

Tên đoạn

địa chỉ bên đáp ứng

Mã đoạn

RSA

Phần tử dữ liệu

ký hiệu nhận dạng dịch vụ viễn thông

...

...

...

Tên đoạn

Id bên đáp ứng

Mã đoạn

RSI

Phần tử dữ liệu

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

{

biểu tượng cá nhân

biểu tượng tổ chức

...

...

...

}

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

{

tên cá nhân

tên trường

- chỉ có một trong những phần tử con này có thể có mặt

}

Tên đoạn

chú thích bên đáp ứng

...

...

...

RSN 

Phần tử dữ liệu

chú thích bên yêu cầu

Tên đoạn

Thông báo tùy chọn của bên đáp ứng

Mã đoạn

ROP

Phần tử dữ liệu

có thể gửi đã chuyển đi

...

...

...

bên đáp ứng đã Nhận

bên đáp ứng đã Trả

Tên đoạn

kết quả cụ thể của bên đáp ứng

Mã đoạn

RSR

Phần tử dữ liệu

ký hiệu nhận dạng đối tượng

- phần còn lại được xác định bên ngoài

...

...

...

kết quả cụ thể của bên đáp ứng

Mã đoạn

RSS

Phần tử dữ liệu

ký hiệu nhận dạng đối tượng

- phần còn lại được xác định bên ngoài

Tên đoạn

ngày thực hiện lại

Mã đoạn

...

...

...

Phần tử dữ liệu

ngày thực hiện lại

Tên đoạn

cờ thực hiện lại

Mã đoạn

RYF

Phần tử dữ liệu

cờ thực hiện lại

Tên đoạn

...

...

...

Mã đoạn

RYR

Phần tử dữ liệu

không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

lý do không có sẵn

ngày thực hiện lại

thông tin địa điểm

- đoạn phụ thuộc cấp dưới cuối cùng có thể được lặp lại:

Tên đoạn

...

...

...

Mã đoạn

RTV

Phần tử dữ liệu

phương thức vận chuyển

Tên đoạn

địa chỉ trả

Mã đoạn

RTA

Phần tử dữ liệu

...

...

...

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

địa chỉ cung cấp bưu chính mở rộng

đường phố và số nhà

hộp thư

thành phố

...

...

...

nước

mã bưu điện

Tên đoạn

hình thức tìm

Mã đoạn

SCH

Phần tử dữ liệu

mức độ dịch vụ

cần trước ngày

...

...

...

cờ hết hạn/ngày hết hạn

Tên đoạn

danh sách gửi đến

Mã đoạn

STL

Phần tử dữ liệu

- không;

đoạn này bao gồm các đoạn khác phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

id hệ thống,

...

...

...

địa chỉ hệ thống.

- những đoạn này được lặp lại cho mỗi mục trong danh sách

Tên đoạn

ngày, thời gian dịch vụ

Mã đoạn

SDT

Phần tử dữ liệu

ngày thời gian của dịch vụ này

{

...

...

...

thời gian

}

ngày thời điểm dịch vụ ban đầu

{

ngày

thời gian

}

Tên đoạn

loại dịch vụ chuyển đi

...

...

...

SST

Phần tử dữ liệu

loại dịch vụ chuyển đi

Tên đoạn

báo cáo trạng thái

Mã đoạn

SRP

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác các phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

...

...

...

trạng thái hiện thời

Tên đoạn

mô tả tài liệu bổ sung

Mã đoạn

SDE

Phần tử dữ liệu

ký hiệu nhận dạng đối tượng

- phần còn lại được xác định ở bên ngoài

- đoạn này có thể được lặp lại cho từng loại mô tả riêng biệt

...

...

...

ld bên cung cấp

Mã đoạn

SID

Phần tử dữ liệu

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

{

biểu tượng cá nhân

biểu tượng tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

...

...

...

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

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

Tên đoạn

Mã đoạn

Phần tử dữ liệu

...

...

...

Mã đoạn

Phần tử dữ liệu

ngày cung cấp

SUD

ngày cung cấp

phiên bản 1 chi tiết cung cấp

SUP

Đoạn này chỉ có thể có mặt trong các APDU với một số phiên bản giao thức

- giá trị 1

...

...

...

- hai phần tử dữ liệu kế tiếp cùng nhau tạo thành

ngày đến hạn

trường ngày đến hạn

gia hạn

đơn vị tính phí

giá cả

{

mã tiền tệ

giá trị tiền tệ

...

...

...

điều kiện vận chuyển

phương thức vận chuyển

- 10 phần tử tiếp theo cùng nhau tạo thành

dịch vụ cung cấp điện tử

phương thức cung cấp điện tử

tham số cung cấp điện tử

id dạng tài liệu

tham số dạng tài liệu

mô tả cung cấp điện tử

...

...

...

- chi tiết cung cấp điện tử

- Chỉ có một trong các địa chỉ cung cấp điện tử

hoặc id cung cấp điện tử có mặt

địa chỉ cung cấp điện tử

{

ký hiệu nhận dạng dịch vụ viễn thông

địa chỉ dịch vụ viễn thông

}

- hai phần tử tiếp theo cùng nhau tạo nên địa chỉ cung cấp điện tử;

...

...

...

{

biểu tượng cá nhân

biểu tượng tổ chức

- chỉ có một trong các phần tử con này có thể có mặt

}

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

{

tên cá nhân

tên tổ chức

...

...

...

}

tên hoặc mã

thời gian cung cấp

- kết thúc dịch vụ cung cấp điện tử

đảm bảo cho

{

mã tiền tệ

giá trị tiền tệ

}

...

...

...

{

loại vật mang tin

không có đơn vị

}

- đây là một phần tử dữ liệu lặp

Tên đoạn

Mã đoạn

Phần tử dữ liệu

loại thông tin vật mang cung cấp

...

...

...

loại thông tin vật mang cung cấp

{

loại vật mang cung cấp

đặc điểm vật mang tin

- phần tử dữ liệu này lặp

Tên đoạn

địa chỉ hệ thống

Mã đoạn

SYA

...

...

...

ký hiệu nhận dạng dịch vụ viễn thông

địa chỉ viễn thông

Tên đoạn

 Id hệ thống

Mã đoạn

SYI

Phần tử dữ liệu

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

{

...

...

...

biểu tượng tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

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

{

tên cá nhân

tên tổ chức

- chỉ có một trong những phần tử con này có thể

- có mặt

...

...

...

Tên đoạn

loại thông tin bên thứ ba

Mã đoạn

TPI

Phần tử dữ liệu

- không; đoạn này bao gồm các đoạn khác

phần tử dữ liệu thực tế. Nó bao gồm các đoạn sau đây:

cho phép chuyển tiếp

cho phép theo chuỗi

...

...

...

cho phép thay đổi gửi vào danh sách

ưu tiên địa chỉ hệ thống

danh sách gửi

danh sách đã thực hiện lại

Tên đoạn

Id giao dịch

Mã đoạn

TRI

Phần tử dữ liệu

...

...

...

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

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

{

biểu tượng cá nhân

biểu tượng tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

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

{

...

...

...

tên tổ chức

- chỉ có một trong những phần tử con này có thể có mặt

}

ký hiệu nhận dạng nhóm giao dịch

ký hiệu nhận dạng giao dịch

ký hiệu nhận dạng giao dịch con

Tên đoạn

kết quả giao dịch

Mã đoạn

...

...

...

Phần tử dữ liệu

kết quả giao dịch

Tên đoạn

loại giao dịch

Mã đoạn

TRT

Phần tử dữ liệu

loại giao dịch

Tên đoạn

...

...

...

Mã đoạn

URE

Phần tử dữ liệu

- không: đoạn này bao gồm các đoạn khác

- phần tử dữ liệu thực tế. Nó bao gồm những đoạn sau đây:

lý do không thực hiện

thông tin vị trí

- đoạn phụ thuộc cuối cùng này có thể được lặp

Tên đoạn

...

...

...

Mã đoạn

UER

Phần tử dữ liệu

ba phần tử dữ liệu đầu tiên cùng nhau

- hình thành các kiểu dữ liệu "đã được chuyển tiếp"

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

{

biểu tượng cá nhân

biểu tượng tổ chức

...

...

...

}

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

{

tên cá nhân

tên tổ chức

- Chỉ có một trong những phần tử con này có thể có mặt

}

địa chỉ bên đáp ứng

{

...

...

...

địa chỉ dịch vụ viễn thông

}

vấn đề của người trung gian

vấn đề an ninh

không thể thực hiện

- chỉ có một "đã chuyển"

- (bao gồm 3 phần tử đầu tiên),

- vấn đề người trung gian, vấn đề an ninh

- hoặc không thể thực hiện có thể có mặt

...

...

...

kết quả sẽ cung cấp

Mã đoạn

WSR

Phần tử dữ liệu

không; đoạn khúc này bao gồm các đoạn khác

- phần tử dữ liệu thực tế. Nó bao gồm những đoạn sau đây:

lý do sẽ cung cấp

ngày cung cấp

địa chỉ trả lại

...

...

...

- đoạn phụ thuộc này có thể lặp lại

dịch vụ cung cấp điện tử

- chỉ có một dịch vụ cung cấp điện tử có thể có mặt

B.7.3  Ánh xạ các kiểu ASN.I vào chuỗi nội dung

Tất cả các phần tử dữ liệu EDIFACT không chứa các phần tử con và tất cả các phần tử con EDIFACT tương ứng với một trong những kiểu đơn giản ASN.I sau: liệt kê; số nguyên; BOOL; Ký hiệu nhận dạng đối tượng hoặc Chuỗi EDIFACT.

B.7.3.1  Mã hóa chuỗi EDIFACT

Chuỗi EDIFACT chứa bất kỳ ký tự nào quy định tại khoản 9. Mỗi một ký tự (ngoại trừ các ký tự "?: '+"V @ #) được mã hóa là một octet đơn theo tiêu chuẩn ISO 646:1983. Quy tắc mã hóa, với 8 bit mỗi octet bằng không và các bit 1 đến 7 tương đương với giá trị b1 đến b7 quy định trong ISO 646. Các ký tự "?:’+" phải đi trước bởi ký tự thoát "?" và do đó chúng được mã hóa bằng hai octet theo các cách sau đây:

? 03/15,03/15

: 03/15,03/10

...

...

...

+ 03/15,02/11

B.7.3.2  Mã hóa số nguyên và liệt kê

Một giá trị nguyên hoặc liệt kê được mã hóa như một chuỗi số bằng cách sử dụng các ký tự ISO 646 "0" đến "9". Mỗi ký tự được mã hóa trong EDIFACT như một octet duy nhất, sử dụng quy tắc mã hóa quy định tại ISO 646. Bit 8 của mỗi octet là 0, và bit 1-7 bằng giá trị của b1 đến b7 quy định trong ISO 646. Do đó các ký tự "0" đến "9"sẽ được mã hóa như 03/00 đến 03/09. Tất cả các số không đứng đầu được bỏ qua.

B.7.3.3  Mã hóa Bool

Bool được mã hóa bằng cách sử dụng các ký tự "0" và "1" theo ISO 646. Giá trị Bool Sai được mã hóa là "0"; giá trị Bool Đúng được mã hóa là "1". Mỗi giá trị được mã hóa là một octet đơn, Sai tương ứng với chuỗi bit 03/00, và Đúng tương ứng với chuỗi bit 03/01.

B.7.3.4  Mã hóa Ký hiệu nhận dạng đối tượng

Ký hiệu nhận dạng đối tượng quy về một danh sách số nguyên có thứ tự. Danh sách này được mã hóa bằng cách sử dụng các quy tắc B.7.3.2 để mã hóa số nguyên và phân cách mỗi số với mã hóa của chuỗi EDIFACT bằng " " (khoảng cách). Lưu ý rằng hai ký hiệu nhận dạng con đầu tiên là Không được gói vào một số nguyên duy nhất như quy định trong tiêu chuẩn ISO/IEC 8825.

Phụ lục C

...

...

...

Ký hiệu nhận dạng đối tượng được gán trong tiêu chuẩn này và yêu cầu đăng ký

C.1  Ký hiệu nhận dạng đối tượng được gán trong tiêu chuẩn này

Tiêu chuẩn này gán các giá trị ký hiệu nhận dạng đối tượng sau đây theo thủ tục được quy định trong tiêu chuẩn ISO/IEC 9834-1.

C.1.1  Tiêu chuẩn này

TCVN (ISO 10161-1)

C.1.2  Module ASN.I, chứa trong 9.1.1. định nghĩa các APDU ILL

TCVN 11642 (ISO 10161) các apdu ill (1) cú pháp trừu tượng (2)

C.1.3  Cú pháp truyền cho các APDU ILL được quy định tại Phụ lục B

TCVN 11642( ISO 10161) mã hóa EDI FACT (1)cú pháp truyền (3)

...

...

...

- {TCVN (ISO 10161 apdu ill (1) cú pháp trừu tượng (2)}

- {iso chung ccitt asnl (1) mã hóa cơ bản (1)}

C.2  Yêu cầu đăng ký

Tiêu chuẩn này có yêu cầu đăng ký theo sau được đề cập bởi ISO/IEC 9834-1 và ISO/IEC 9834-2.

a) Ngữ cảnh áp dụng (xem ISO/IEC 9834-1 và ISO/IEC 9834-2).

b) Tên thực thể áp dụng (xem ISO/IEC 9834-1 và ISO/IEC 9834-2).

c) Tên hệ thống (xem ISO/IEC 9834-1 và ISO/IEC 9834-2).

Ngoài ra, có thể có yêu cầu đăng ký của các kiểu dữ liệu bên ngoài (xem Phụ lục D).

Phụ lục D

...

...

...

Thủ tục đăng ký cho định nghĩa các kiểu dữ liệu Bên ngoài (EXTERNAL) của ILL

D.1  Sự cần thiết của việc đăng ký các kiểu dữ liệu Bên ngoài của ILL

Cú pháp trừu tượng giao thức ILL bao gồm các loại sau đây được định nghĩa là Bên ngoài:

- Dịch vụ riêng của bên đáp ứng (trong Yêu cầu ILL)

- Kết quả riêng của bên đáp ứng (trong Trả lời ILL)

- Số thư mục quốc gia (một thành phần của Item-id)

- Số hệ thống (một thành phần của Id Tài liệu)

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

Cấu trúc của các loại bên ngoài như vậy không được định nghĩa trong tiêu chuẩn này. Bất kỳ người dùng nào có nhu cầu sử dụng của các kiểu này phải xác định trong ASN.I thành phần cho phép của các kiểu này như một cú pháp trừu tượng cần phải được đăng ký phù hợp với các thủ tục quy định tại phụ lục này.

...

...

...

Định nghĩa kiểu dữ liệu Bên ngoài ILL được áp dụng để sử dụng giao thức ILL được xác định trong tiêu chuẩn này, (10161).

ISO TC 46/SC 4/WG 4 là nhóm thuộc trong ISO chịu trách nhiệm về việc định nghĩa những gì tạo thành một kiểu dữ liệu Bên ngoài ILL và định nghĩa kiểu dữ liệu Bên ngoài ILL.

D.3  Hình thức của tham chiếu kiểu dữ liệu Bên ngoài ILL

Cấu trúc của kiểu Bên ngoài được mô tả trong ISO/EC 8824-1:2008, khoản 37. Các kiểu tham chiếu trực tiếp xác định các thông tin bên ngoài cần được sử dụng. Kiểu bên ngoài khi đó được nhận biết duy nhất bằng cách sử dụng ký hiệu nhận dạng đối tượng ASN.I. Hình thức nguyên của ký hiệu nhận dạng đối tượng cần được sử dụng, như quy định trong tiêu chuẩn ISO/IEC 9834-1 cho "Tên có cấu trúc của cơ quan đăng ký".

D.4  Nội dung tối thiểu của mục đăng ký cho một định nghĩa kiểu dữ liệu Bên ngoài ILL

Một mục trong sổ đăng ký định nghĩa kiểu dữ liệu Bên ngoài ILL phải bao gồm tối thiểu:

a) tham chiếu đăng ký cho kiểu dữ liệu Bên ngoài, ở dạng nguyên của ký hiệu nhận dạng đối tượng theo tiêu chuẩn ISO/IEC 9834-1:2012, Điều 5;

b) tên cơ quan bảo trợ chịu trách nhiệm về việc tạo ra và duy trì định nghĩa;

c) các ngày nộp đơn, ngày đăng ký; và

...

...

...

Ngoài định nghĩa ASN.I của từng kiểu dữ liệu, một ánh xạ tương ứng với mã hóa EDIFACT phải được cung cấp nếu mã hóa như vậy được hỗ trợ.

D.5  Định dạng đề nghị cho một mục của sổ đăng ký

Phụ lục F. chứa ví dụ về một mục định nghĩa kiểu dữ liệu Bên ngoài ILL.

D.6  Thủ tục lấy từ tiêu chuẩn ISO/IEC 9834-1

Các thủ tục để tạo tên có cấu trúc của cơ quan đăng ký, dạng số nguyên của ký hiệu nhận dạng đối tượng (ISO/IEC 9834-1:2012, điều 7) áp dụng để tạo ra các tên cho định nghĩa kiểu dữ liệu bên ngoài ILL.

Việc đăng ký trong phạm vi một tiêu chuẩn có thể được thực hiện theo tiêu chuẩn ISO/IEC 9834-1:2012, 6.1.3.

Việc đăng ký của các tổ chức hoạt động như cơ quan đăng ký trong phạm vi quốc gia riêng biệt có thể được thực hiện theo tiêu chuẩn ISO/IEC 9834-1:1993, Điều 8.

D.7  Thủ tục để hoàn thành đăng ký các định nghĩa kiểu dữ liệu Bên ngoài ILL

D.7.1  Phương pháp để xác định chấp nhận hay từ chối một mục đề xuất

...

...

...

D.7.2  Phương pháp giải quyết tranh chấp

[Để nghiên cứu tiếp]

D.7.3  Sửa đổi các mục

Cú pháp trừu tượng của một kiểu dữ liệu Bên ngoài ILL có thể được mở rộng, nhưng các yếu tố hiện có của một định nghĩa kiểu dữ liệu đã đăng ký không thể được sửa đổi.

Ký hiệu nhận dạng đối tượng được gán cho một định nghĩa kiểu dữ liệu Bên ngoài ILL không bao giờ có thể được sử dụng lại cho bất kỳ đối tượng khác đã đăng ký.

D.8  Yêu cầu cho công bố định nghĩa kiểu dữ liệu Bên ngoài lLL

Phụ lục E

(Tham khảo)

...

...

...

TÊN MỤC ĐĂNG KÝ: iso (1) canada (302) bệnh (9) dịch vụ cụ thể bên đáp ứng (1)

Cơ QUAN TÀI TRỢ: Thư viện Quốc gia Canada

NGÀY NỘP HỒ SƠ: 890717

NGÀY ĐẢNG KÝ: 890724

ĐỊNH NGHĨA CÚ PHÁP TRỪU TƯỢNG:

EXTERNAL:: = [UNIVERSAL 8] IMPLICIT SEQUENCE {

            direct-reference OBJECT IDENTIFIER,

- value is that specified above

encoding CHOICE {

...

...

...

}

}

NLC-Responder-Spedfic-Services:: = ENUMERATED {

Urgent Action (1),

Delivery by Facsimile (2),

Abstract Acceptable (3)

}

Phụ lục F

...

...

...

Sử dụng các dịch vụ hỗ trợ

F.1  Tổng quan

Đối với phần tử dịch vụ ứng dụng ILL (ILL ASE) quy định trong tiêu chuẩn này, ranh giới thấp hơn được xác định trong các điều khoản của dịch vụ trừu tượng "Gửi APDU" và "Nhận APDU". Cách tiếp cận này cho phép tách quy tắc giao thức ngang hàng từ các quy tắc kết hợp với ánh xạ để hỗ trợ các dịch vụ và tính đến hoạt động của giao thức trong các chế độ khác nhau.

Đối với hoạt động thực tế của giao thức ILL, cần xác định ánh xạ của giao thức vào các dịch vụ hỗ trợ cụ thể theo chế độ hoạt động mong muốn. Ánh xạ này có thể đòi hỏi định nghĩa các thủ tục bổ sung và thông tin trạng thái để bổ sung cho các quy tắc giao thức được định nghĩa trong nội dung của tiêu chuẩn này. Đặc tả các ánh xạ như vậy dự kiến sẽ được cung cấp trong các định nghĩa ngữ cảnh áp dụng.

Hai loại hình dịch vụ giao tiếp đã được xác định có thể hỗ trợ giao thức ILL này:

a) hệ thống xử lý thông báo lưu trữ và chuyển tiếp (MHS), như đã định nghĩa trong các tiêu chuẩn MOTIS, ISO/IEC 10021,

b) dịch vụ trực tiếp sử dụng dịch vụ P-DATA, được định nghĩa trong ISO/IEC 8822 về một liên kết áp dụng, kết hợp với ACSE, ISO 8649 và các ASR có thể khác.

Hình F.1 - Ánh xạ lưu trữ và chuyển tiếp của giao thức ILL

...

...

...

Trong môi trường lưu trữ và chuyển tiếp, ASE ILL sẽ tương tác với hệ thống xử lý thông báo như trong Hình F.I.

Có hai phương pháp để hỗ trợ giao thức ILL trong môi trường này:

a) Giao thức ILL được hỗ trợ bởi một định danh trình duyệt người dùng mới thay thế định danh trình duyệt người dùng gửi thông báo giữa các cá nhân X.400. Nói cách khác, UA ILL thay thế UA IPM. Mỗi APDU ILL sẽ được truyền bằng cách sử dụng các hoạt động Gửi thông báo, Cung cấp thông báo và Cung cấp báo cáo của Hệ thống truyền thông báo (MTS), như quy định trong tiêu chuẩn ISO/IEC 10.021-4.

b) Các APDU ILL được truyền như các phần chính của thông báo Gửi thông báo giữa các cá nhân. Nói cách khác, UA IPM được bảo tồn, với ASE ILL sử dụng dịch vụ IPM hơn là MTS trực tiếp như trong phương pháp 1 ở trên.

Với một trong hai phương pháp tiếp cận, ASE ILL sẽ cung cấp tất cả các thông số cần thiết cho MHS, bao gồm thông tin địa chỉ điểm đến. Điều này cung cấp một chế độ dịch vụ cung cấp thông báo của sự tương tác giữa các hệ thống ILL. Việc truyền tải các APDU ILL liên quan đến nhiều giao dịch ILL với nhiều hệ thống từ xa có thể được xen kẽ theo bất kỳ cách thức phù hợp với các quy định về trình tự cho mỗi giao dịch ILL cá nhân.

Đặc tả ánh xạ của giao thức ILL tới các dịch vụ gửi thông báo lưu trữ và chuyển tiếp như vậy sẽ bao gồm các thủ tục để xử lý các vấn đề gửi thông báo hoặc báo cáo không cung cấp.

F.3  Ánh xạ chế độ kết nối

Trong môi trường chế độ kết nối, được minh họa trong Hình F.2, một ASE ILL sẽ thành lập các liên kết ứng dụng khi cần thiết với các hệ thống ILL từ xa với người tham gia vào giao dịch ILL. ASE ILL, có thể kết hợp với các ASE khác như ROSE, FTAM, SR, v.v, khi đó có thể sử dụng dịch vụ P-DATA được định nghĩa trong ISO/IEC 8822 để truyền trực tiếp các APDU ILL. Điều này cung cấp một phương thức tương tác trực tiếp giữa các hệ thống ILL. Một liên kết ứng dụng đơn có thể được sử dụng để gửi một chuỗi các APDU ILL liên quan đến các giao dịch ILL tách riêng; Id Giao dịch ILL được sử dụng để định tuyến APDU ILL nhận được đến đúng ASE ILL gọi. Một hệ thống duy nhất có thể được tham gia vào nhiều liên kết ứng dụng với nhiều hệ thống từ xa cùng một lúc. Bởi vì vòng đời của một cuộc gọi ASE ILL có thể kéo dài (ngày, tuần hoặc thậm chí nhiều năm), nên nhiều kết hợp ứng dụng và kết nối trình bày đều có khả năng được đặt và phát hành để hỗ trợ cho một ASE ILL nhất định.

Ánh xạ từ giao thức ILL tới môi trường này sẽ xác định các thủ tục để đặt liên kết, phát hành, tạo gói APDU và để đối phó với những thất bại liên lạc.

...

...

...

Hình F.2 - Ánh xạ chế độ kết nối của giao thức ILL

Phụ lục G

(tham khảo)

Gọi dịch vụ cung cấp tài liệu bên ngoài

Yêu cầu ILL một tài liệu điện tử thường đòi hỏi gọi một dịch vụ cung cấp tài liệu điện tử. Có nhiều dịch vụ cung cấp tiềm năng, dựa trên cả hai giao thức OSI và phi OSI, có thể được đề xuất trong yêu cầu ILL. Chúng bao gồm, nhưng không giới hạn:

- CCITT X.400 IPM (Gửi thông báo giữa các cá nhân): IPM cho phép bao gồm các loại thông tin được mã hóa khác nhau (ví dụ văn bản 1A5) để đưa vào nội dung thông báo IPM

- ISO 8571-1 vv hoặc FTAM (quản lý và truy cập truyền tệp): FTAM rõ ràng có thể mang theo bất kỳ loại thông tin nào bao gồm các tài liệu điện tử thành phần.

- CCITT T.4, T.5 và T.30 cho bản sao Nhóm 3 và Nhóm 4 qua các mạng điện thoại chuyển mạch công.

...

...

...

- Internet RFC 821/822 Giao thức truyền thư tín đơn giản (SMTP): SMTP có thể mang tài liệu điện tử với các thông điệp mã hóa ký tự (7-bit ASCII).

- Internet RFC 1341. Mở rộng thư tín Internet đa mục đích (MIME): MIME cho phép các thông báo thư tín SMTP mang tài liệu điện tử thành phần, bao gồm cả các định dạng xử lý văn bản, hình ảnh, âm thanh, video, vv

Tùy thuộc vào các dịch vụ cung cấp cụ thể được sử dụng, có hoặc không có sự can thiệp của người điều hành, có một số cách khác nhau để cung cấp một tài liệu được yêu cầu. Khi những thông báo giao thức ILL được thực hiện trong IPM X.400, các APDU Vận chuyển ILL có thể chiếm một phần của một IPM, với các tài liệu chính chiếm một hay nhiều phần chính của cùng một IPM. Mỗi phần chính của một IPM có thể được mã hóa khác nhau- văn bản, đồ họa, âm thanh, G4-fax, mã hóa, vv..

Ngoài ra, một cuộc gọi riêng biệt dịch vụ X.400 IPM hoặc một dịch vụ truyền dữ liệu số lượng lớn khác như FTAM của FTP có thể được sử dụng để cung cấp các tài liệu yêu cầu. Việc cung cấp không đồng bộ như vậy sẽ đòi hỏi rằng tài liệu này có liên quan rõ ràng đến các giao dịch ILL nó đáp ứng.

Mỗi dịch vụ cung cấp điện tử có cách duy nhất để xử lý cấu trúc và mã hóa các thông tin người dùng với số lượng lớn mà nó mang theo. Thông số kỹ thuật và đăng ký loại tài liệu FTAM, loại phần nội dung X.400 IPM, vv... là sự phản ánh cách xử lý dữ liệu người dùng của các vật mang số lượng lớn OSI. Giao thức ILL cung cấp các tham số thích hợp để thực hiện tham chiếu đến các kiểu dữ liệu số lượng lớn.

Cho dù bất kỳ dịch vụ nào trong số này thực sự có thể bằng cách gọi - tự động hoặc thông qua các can thiệp của người điều hành- sẽ phụ thuộc vào việc có bên yêu cầu và bên đáp ứng khi đã thực hiện giao thức tương ứng trong hệ thống tương ứng đó hay không. Trong một môi trường hoàn toàn tự động, các chi tiết chính xác về cách thức như thế nào và khi nào một dịch vụ như vậy có thể được áp dụng trong quá trình thực hiện một yêu cầu ILL tùy thuộc hoàn toàn vào các đặc tả của ASO (đối tượng dịch vụ ứng dụng) thích hợp; Chức năng kiểm soát ASO, nếu đúng quy định, có thể phối hợp việc sử dụng kết hợp giao thức và ánh xạ tới dịch cung cấp.

Đặc tả một hoặc nhiều ASO thuộc loại này sẽ thúc đẩy thực hiện nhất quán và khả năng tương tác của các ứng dụng cung cấp tài liệu ILL. Tuy nhiên, đặc điểm các ASO nằm ngoài phạm vi của tiêu chuẩn ILL

Thư mục tài liệu tham khảo

...

...

...

[2] ISO 8459, Documentation-Bibliographic data element directory (Tư liệu - Danh mục phần tử dữ liệu thư mục).

[3] ISO/TR 8509:1987, Information processing systems - Open Systems Interconnection - Service conventions (Hệ thống xử lý thông tin - Liên kết các hệ thống mở - Quy ước dịch vụ).

[4] ISO 8571-1:1988, Information processing systems - Open Systems Interconnection - File Transfer, Access and Management - Part 1: General introduction (Hệ thống xử lý thông tin - Liên kết các hệ thống mở - Truyền tệp, truy cập và quản lý - Phần 1: Giới thiệu chung).

[5] ISO 8649:1988, Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element (Hệ thống xử lý thông tin - Liên kết các hệ thống mở - định nghĩa vụ cho phần tử dịch vụ kiểm soát liên kết).

[6] ISO 8650:1988, Information processing systems-Open Systems Interconnection - Protocol specification for the Association Control Service Element (Hệ thống xử lý thông tin - Liên kết các hệ thống mở - Đặc tả giao thức cho phần tử dịch vụ kiểm soát liên kết).

[7] ISO 10163-1:1993, Information and documentation-Open Systems Interconnection-Search and Retrieve Application Protocol Specification - Part 1: Protocol specification (Thông tin và Tư liệu - Liên kết các hệ thống mở - Đặc tả giao thức ứng dụng tìm kiếm và truy hồi - Phần 1: Đặc tả giao thức).

[8] ISO 23950:1998, Information and documentation - Information retrieval (Z39.50) -Application service definition and protocol specification (Thông tin và Tư liệu - Tìm kiếm thông tin (Z39.50) - Định nghĩa dịch vụ ứng dụng và đặc tả giao thức).

[9] ISO/IEC 7498, Information technology - Open Systems Interconnection-Basic Reference Model: Naming and addressing (Công nghệ thông tin - Liên kết các hệ thống mở - Mẫu tham khảo cơ bản: Cách đặt tên và địa chỉ).

[10] ISO/IEC 8822, Information technology - Open Systems Interconnection - Presentation service definition (Công nghệ thông tin - Liên kết các hệ thống mở - Định nghĩa dịch vụ trình diễn).

...

...

...

[13] ISO/IEC 10021-4:1990, Information technology - Text Communication - Message - Oriented Text Interchange Systems (MOTISJ - Part 4: Message Transfer System: Abstract Service Definition and Procedures (Công nghệ thông tin - Truyền thông văn bản - Hệ thống chuyển văn bản hướng thông báo. (MOTIS) - Phần 4: Hệ thống chuyển thông báo: Định nghĩa dịch vụ trừu tượng và thủ tục).

MỤC LỤC

Lời nói đầu

Lời giới thiệu

1  Phạm vi áp dụng

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

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

4  Từ viết tắt

...

...

...

5.1  Cung cấp dịch vụ

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

5.3  Mô hình

6  APDU ILL

7  Thông tin giao dịch

7.1  Nhận dạng giao dịch

7.2  Trạng thái giao thức

7.3  Các biến giao thức

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

...

...

...

7.6  Thông tin lịch sử

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

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

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

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

9  Cú pháp trừu tượng

9.1  ASN.I Đặc tả các APDU ILL

10  Sự phù hợp

10.1  Sự phù hợp tĩnh

...

...

...

10.3  Yêu cầu tuân thủ phần mềm triển khai giao thức

Phụ lục A (Quy định) Bảng trạng thái ILL

Phụ lục B (Quy định) Cú pháp truyền

Phụ Lục C (Quy định) Ký hiệu nhận dạng đối tượng được gán trong tiêu chuẩn này và các yêu cầu đăng ký

Phụ lục D (Quy định) Thủ tục đăng ký cho định nghĩa các kiểu dữ liệu Bên ngoài (EXTERNAL) của ILL

Phụ lục E (Tham khảo) Ví dụ về một mục của sổ đăng ký định nghĩa kiểu dữ liệu Bên ngoài ILL

Phụ lục F (Tham khảo) Sử dụng các dịch vụ hỗ trợ

Phụ lục G (Tham khảo) Gọi dịch vụ cung cấp tài liệu bên ngoài