TCVN11642-1:2016

Tiêu chuẩn quốc gia TCVN 11642-1:2016 (ISO 10161-1:2014) về Thông tin và tư liệu - Liên kết hệ thống mở - Đặc tả giao thức ứng dụng mượn liên thư viện - Phần 1: Đặc tả giao thức TIÊU CHU Ẩ N QUỐC GIA TCVN 11642-1:2016 ISO 10161-1:2014 THÔNG TIN VÀ TƯ LIỆU - LIÊN KẾT HỆ THỐNG MỞ - ĐẶC TẢ GIAO THỨC ỨNG DỤNG MƯỢN LIÊN THƯ VIỆN - PHẦN 1: ĐẶC TẢ GIAO THỨC Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Protocol Specification - Part 1: Protocol specification Lời nói đầu TCVN 11642-1:2016 hoàn toàn tương đương với ISO 10161-1:2014 TCVN 11642-1:2016 do Ban kỹ thuật tiêu chuẩn quốc gia TCVN/TC 46 Thông tin và tư liệu biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố. Bộ tiêu chuẩn TCVN 11642 (ISO 10161) Thông tin và tư liệu - Liên kết hệ thống mở - Đặc tả giao thức ứ ng dụng mượn liên thư viện gồm các tiêu chuẩn sau: - TCVN 11642-1:2016 (ISO 10161-1:2014), Phần 1: Đặc tả giao thức. - TCVN 11642-2:2016 (ISO 10161-2:2014). Phần 2: Hình thức trình bày tuân thủ triển khai giao thức (PICS.). Lời giới thiệu Tiêu chuẩn này được xuất b ả n để tạo thuận lợi cho việc kết nối các hệ thống máy tính. Tiêu chuẩn liên quan đến các tiêu chuẩn quốc tế khác trong bộ tiêu chuẩn được định nghĩa trong mô hình tham chiếu cho kết nối hệ thống mở (ISO/IEC 7498), mô hình tham kh ả o này chia nhỏ l ĩnh vực tiêu chuẩn hóa đối với kết nối thành một loạt các lớp đặc tả, mỗi lớp có kích thước quản lý được. Mục đ íc h của kết nối hệ thống mở là cho phép, với tối thiểu các thỏa thuận kỹ thuật ngoài các tiêu chuẩn kết nối, kết nối các hệ thống máy t í nh a) từ các nhà sản xuất khác nhau, b) dưới sự quản lý khác nhau, c) có mức độ phức tạp khác nhau, và d) có thời gian phục vụ khác nhau. Tiêu chuẩn này cung cấp một đặc tả giao thức cho ứng dụng mượn liên thư viện (ILL). Giao thức ILL hoạt động trong lớp ứng dụng và cho phép các bên tham gia vào một giao dịch ILL để phát triển thông qua giao dịch ILL một cách tr ì nh tự. Giao thức ILL đã được thiết kế để hỗ trợ các dịch vụ ILL được định nghĩa trong ISO 10160 , Định nghĩa dịch vụ ứng dụng ILL, mà thường yêu cầu các dịch vụ cung cấp bên ngoài để thực hiện một yêu cầu ILL. Giao thức ILL mang thông tin cho phép gọi các dịch vụ cung cấp bên ngoài bao gồm cả tự động và qua người điều hành trung gian. Tiêu chuẩn này là một trong một số tiêu chuẩn liên quan hỗ trợ việc kết nối các hệ thống thư viện. Tiêu chuẩn này có thể được sử dụng ri ê ng hoặc sử dụng theo cách hỗ trợ các ứng dụng thư viện đòi hỏi một hỗn hợp của các dịch vụ truyền thông. V í dụ, ISO 23950, hỗ trợ truy cập từ xa vào cơ sở dữ liệu thư mục, có thể được sử dụng kết hợp với giao thức ILL để có được thông tin xác định tài liệu. Việc kiểm soát và quản lý các tương tác giữa các ứng dụng thư mục đó là những vấn đề cục bộ nằm ngoài phạm vi của tiêu chuẩn này. Các vấn đề an ninh và kế toán có liê n quan đến hoạt động ILL cần được nghiên cứu thêm. Kỹ thuật đặc tả được sử dụng trong tiêu chuẩn này là phù hợp với các kỹ thuật được sử dụng trong việc xác định các giao thức OSI khác. Trong hầu hết tiêu chuẩn này, kỹ thuật đặc tả này là tự diễn gi ả i. Cú pháp trừu tượng của các đơn vị dữ liệu của giao thức ứng dụng (APDU) ILL được xác định bằng kỹ thuật đặc tả ASN.1 quy định trong ISO 8824. Tiêu chuẩn này chứa bảy phụ lục. Phụ lục A đến D là quy định. Phụ lục A quy định các bảng trạng thái cho giao thức ILL. Phụ lục B quy định các quy tắc mã hóa để tạo ra một cú pháp truyền tương thích với EDIFACT như định nghĩa trong ISO 9735. Phụ lục C quy định các định danh đối tượng được gán trong tiêu chuẩn và y êu cầu đăng ký. Phụ lục D xác định các thủ tục đăng ký cho định nghĩa kiểu dữ liệu bên ngoài ILL. Phụ lục E là v í dụ về một mục đăng ký kiểu dữ liệu bên ngoài ILL. Phụ lục F mô tả các ánh xạ có thể có của giao thức này vào các dịch vụ hỗ trợ. Phụ lục G mô tả phương pháp có thể sử dụng một giao thức cung cấp tài liệu kèm theo giao thức ILL. THÔNG TIN VÀ TƯ LIỆU - LIÊN KẾT HỆ THỐNG MỞ - ĐẶC TẢ GIAO THỨC ỨNG DỤNG MƯỢN LIÊN THƯ VIỆN - PHẦN 1: ĐẶC TẢ GIAO THỨC Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Protocol Specification - Part 1: Protocol specification 1 Phạm vi áp dụng Tiêu chuẩn này xác định giao thức cho một yếu tố dịch vụ ứng dụng ILL (ASE). Tiêu chuẩn quy định trạng thái phải được biểu hiện bởi một hệ thống để tham gia vào việc cung cấp các dịch vụ mượn liên th ư viện. Tiêu chuẩn cung cấp cách trình bày hình thái của quy tắc về trạng thái của từng đối tượng hoặc nhiều đối tượng tham gia vào một giao dịch ILL. Tiêu chuẩn quy định a) các hành động được thực hiện khi nhận các dịch vụ ban đầu yêu cầu từ một người sử dụng dịch vụ ILL, b ) các hành động được thực hiện khi nhận các đơn vị dữ liệu giao thức ứng dụng (P D U), và c) các hành động được thực hiện như là một kết quả của các sự kiện trong hệ thống cục bộ. Tiêu chuẩn cung cấp một đặc tả (tại điều 9) của cú pháp trừu tượng cần thiết đ ể truyền đạt các APDU của giao thức ILL. Tiêu chuẩn nêu các yêu cầu phù hợp phải được đáp ứng bởi các bên triển khai giao thức này (điều 10). Ph ạ m vi của giao thức ILL được giới hạn với kết nối hệ thống; giao thức ILL này không quy định hoặc hạn chế khả năng triển khai của các giao diện trong một hệ thống máy tính. Hệ thống máy tính có thể bao gồm các cả các máy trạm độc lập cho đến máy tính lớn. Tiêu chuẩn này được thiết kế để sử dụng bởi các thư viện, các dịch vụ thông tin như các trung tâm mục lục liên hợp và bất kỳ hệ thống nào xử lý thông tin thư mục. Những hệ thống này có thể tham gia vào một giao dịch mượn liên thư viện với vai trò của bên yêu cầu (tức là người kh ở i tạo các yêu cầu ILL); bên đáp ứng (tức là một người cung cấp tài liệu hoặc thông tin thư mục) và/hoặc người trung gian (tức là một cơ quan hoạt động với tư cách là đại diện cho bên yêu cầu tìm các bên đáp ứng phù hợp). Các cấu trúc liên kết mạng khác nhau được hỗ trợ, từ tương tác hai bên đơn giản, đến tương tác nhiều bên. 2 Tài liệu viện dẫn Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có). TCVN 6380:2007 (ISO 2108:2005) Th ông tin và Tư liệu - Mã số tiêu chuẩn quốc tế cho sách (ISBN). TCVN 6381:2015 (ISO 3297:2007) Thông tin và Tư liệu - Mã số tiêu chuẩn quốc tế cho xuất b ả n phẩm nhiều kỳ (ISSN)). TCVN 6558:2008 (ISO 4217:2001), Mã thể hiện các đồng tiền và quỹ. TCVN ISO 8601, Định dạng trao đổi và phần tử dữ liệu - Trao đổi thông tin - Biểu diễn ngày tháng và thời gian. TCVN ISO 9735, Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải (EDIFACT) - Các quy tắc cú pháp mức ứng dụng). TCVN 10583-1:2014 (ISO/IEC 9834-1:2012), Công nghệ thông tin - Thủ tục điều hành của cơ quan đăng ký định danh đối tượng - Phần 1: Thủ tục chung và các cung trên cùng của cây định danh đối tượng quốc tế). TCVN 10583-2:2014 (ISO/IEC 9834-2:2012), Công nghệ thông tin - Liên kết hệ thống mở - Thủ tục điều hành của cơ quan đ ă ng ký OSI - Phần 2: Thủ tục đăng ký cho kiểu tài liệu OSI. ISO 646, Information processing - ISO 7-bit coded character set for information interchange (Công nghệ thông tin - Bộ mã chuẩn 7-bit của ISO dùng trao đổi thông tin). ISO/IEC 8824-1:2008, Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.I) (Công nghệ thông tin - Kết nối các hệ thống mở - Đặc tả ký hiệu cú pháp trừu tượng 1 (ASN.I)). ISO/IEC 8825, Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.I) (Công nghệ thông tin - Kết n ố i các hệ thống mở - Đặc tả các quy tắc mã hóa cơ bản cho ký hiệu cú pháp trừu tượng 1 (ASN.I)). ISO 10160, Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition (Thông tin và tư liệu - Kết nối các hệ thống mở - Định nghĩa dịch vụ ứng dụng mượn liên thư viện). 3 Thuật ngữ và định nghĩa Trong tiêu chuẩn này, sử dụng các thuật ngữ và định nghĩa sau đây. 3.1 Các định nghĩa mô hình tham chiếu (reference model definitions) CHÚ THÍCH: Tiêu chuẩn này dựa trên các khái niệm được quy định trong ISO 7498. Các thuật ngữ dưới đây được nhắc lại nh ằ m thuận tiện cho người đọc. 3.1.1 L ớ p ứng dụng (application layer) Lớp thứ bảy và lớp cao nhất trong mô hình tham chiếu cho liên kết hệ thống mở (OSI), mà sử dụng như cửa sổ giữa các quá trình-ứng dụng tương ứng mà đang sử dụng OSI để trao đổi thông tin có ý nghĩa. 3.1.2 Thực thể ứng dụng (application-entity) Các kh í a cạnh của một quá trình ứng dụng thích hợp với OSl 3.1.3 Quá trình ứng dụng (application-process) Yếu tố trong một hệ thống mở thực, thực hiện việc xử lý thông tin cho một ứng dụng cụ thể 3.1.4 Đơn vị dữ liệu giao thức ứng dụng (application-protocol-data-unit) Đơn vị dữ liệu được quy định trong một giao thức ứng dụng và bao gồm thông tin giao thức ứng dụng và có thể gồm cả dữ liệu người sử dụng ứng dụng 3.1.5 Yếu tố dịch vụ ứng dụng (application-service-element) Một phần của một thực thể ứng dụng cung cấp một khả năng môi trường OSI, sử dụng dịch vụ cơ bản khi thích hợp 3.1.6 Dịch vụ lớp N (N-service) Khả năng của lớp (N) và các lớp bên dưới nó, mà được cung cấp cho (N + 1) thực thể tại ranh giới giữa lớp (N) và lớp (N + 1). CHÚ THÍCH Dịch vụ ứng dụng không cung cấp khả năng cho các thực thể lớp cao h ơn , mà là cho các quá trình ứng dụng. 3.1.7 Dịch vụ trình diễn (presentation-service) Khả năng của lớp trình bày và các lớp bên dưới nó, được cung cấp cho các thực thể ứng dụng ở ranh giới giữa lớp trình bày và lớp ứng dụng 3.1.8 Cú pháp truyền (transfer-syntax) Cú pháp cụ thể được sử dụng trong việc tr uyền dữ liệu giữa các hệ thống mở 3.2 Định nghĩa ký hiệu cú pháp trừu tượng 1 CHÚ THÍCH: Tiêu chuẩn này sử dụng các thuật ngữ dưới đây được định nghĩa trong ISO/IEC 8824. 3.2.1 Kiểu dữ liệu (data type) Kiểu (type) Tập các giá trị được đặt tên. 3.2.2 Kiểu đơn giản (simple type) Kiểu được xác định bằng cách xác định trực tiếp các giá trị của nó. 3.2.3 Kiểu có cấu trúc (structured type) Kiểu được xác định bằng cách tham chiếu tới một hoặc nhiều kiểu khác. 3.2.4 Kiểu thành phần (component type) Một trong những kiểu được tham chiếu khi xác định một kiểu có cấu trúc. 3.2.5 Giá trị (value) Thành tố được phân biệt của một tập các giá trị. 3.3 Định nghĩa dịch vụ trình diễn CHÚ THÍCH: Tiêu chuẩn này sử dụng thuật ngữ sau đây được định nghĩa trong ISO 8822. 3.3.1 Cú pháp trừu tượng (abstract syntax) Các khía cạnh về quy tắc được sử dụng trong đặc tả hình thức của dữ liệu mà độc lập với kỹ thuật mã hóa để thể hiện dữ liệu. 3.4 Định nghĩa cấu trúc lớp ứng dụng CHÚ THÍCH: Tiêu chuẩn này sử dụng các thuật ng ữ sau đây được định nghĩa trong ISO/IEC 9545. 3.4.1 Liên kết ứng dụng (application-association) Mối quan hệ hợp tác giữa hai lệnh gọi thực thể ứng dụng với mục đích trao đổi thông tin và điều phối các hoạt động chung của chúng CHÚ THÍCH 1: Mối quan hệ này được hình thành bởi sự trao đổi thông tin điều khiển giao thức ứng dụng bằng cách sử dụng dịch vụ trình diễn. 3.4.2 Ngữ cảnh ứng dụng (application-context) Bộ các quy tắc dùng chung bởi hai lệnh gọi thực thể ứng dụng bằng cách quản trị cách vận hành của các lệnh gọi đó để cho phép chúng cùng vận hành. CHÚ THÍCH 1 Một ngữ cảnh ứng dụng là một lược đ ồ khái niệm dùng chung để truy ề n thông cho toàn nhân loại (universe). 3 .4. 3 Định nghĩa ngữ cảnh ứng dụng (application-context-definition) Mô tả một ngữ cảnh ứng dụng 3.4.4 Lệnh gọi thực thể ứng dụng (application-entity-invocation) Sử dụng một phần hoặc tất cả các khả năng của một thực thể ứng dụng nhất định để hỗ trợ các yêu cầu truyền thông của một lệnh gọ i quy trình ứng dụng. 3.4.5 Lệnh gọi quy trình ứng dụng (application-process-invocation) Sử dụng của một phần hoặc tất cả các khả năng của một quá trình ứng dụng nhất định nhằm hỗ trợ một trường hợp xử lý thông tin cụ thể 3.5 Định nghĩa các giao thức dịch vụ 3.5.1 Chỉ thị ban đầu (indication primitive) Thể hiện một tương tác trong đó bên cung cấp dịch vụ, hoặc: a) chỉ ra rằng bản thân tương tác đó khởi tạo gọi một số thủ tục; hoặc b) ch ỉ ra rằng thủ tục được gọi bởi người sử dụng dịch vụ tại một điểm truy cập dịch vụ ngang hàng. 3.5.2 Dịch vụ không xác nhận (non-confirmed service) Phần phân biệt của dịch vụ (N) tổng mà không dẫn đến một xác nhận rõ ràng từ các bên cung cấp dịch vụ với người sử dụng dịch vụ khởi tạo. 3.5.3 Dịch vụ bên cung cấp khởi tạo (provider-initiated service) Phần phân biệt của dịch vụ (N) tổng được khởi tạo bởi bên cung cấp dịch vụ chứ không phải là người sử dụng dịch vụ. 3.5.4 Yêu cầu ban đầu (request primitive) Thể hiện một tương tác, trong đó một người sử dụng dịch vụ gọi một số thủ tục 3.5.5 Dịch vụ ban đầu (service primitive) Thể hiện một tương tác độc lập với phần mềm triển khai giữa người sử dụng dịch vụ và bên cung cấp dịch vụ. 3.5.6 Bên cung cấp dịch vụ (service-provider) Một số thực thể cung cấp dịch vụ cho người sử dụng ngang hàng. 3.5.7 Người sử dụng dịch vụ (service-user) Thực thể trong một hệ thống mở sử dụng một dịch vụ. 3.6 Các định nghĩa ILL CHÚ THÍCH: Tiêu chuẩn này sử dụng cho các định nghĩa sau đây cho các tên và giá trị tham chiếu giá trị ASN.1 tương ứng với các kiểu dữ liệu đơn giản, như quy định tại Điều 9. 3.6.1 Sổ tài khoản (account-number) Số hiệu một tài khoản được tạo ra của một th ẻ tín dụng hoặc thẻ ghi nợ. CHÚ THÍCH 1: B ê n yêu cầu thường đã được chỉ định một tài khoản riêng biệt cho từng bên đáp ứng. 3.6.2 Chữ cái-số bổ sung (additional-no-letters) Chữ cái-s ố bổ sung (additional-numbers-letters) Số hoặc mã xác định một tài liệu. 3.6.3 Đã được chuyển tiếp (already-forwardes) Ch ỉ thị của bên đáp ứng rằng một yêu cầu ILL đã được chuyển tiếp. 3.6.4 Danh sách đã được thử (already-tried-list) Danh sách các tổ chức đã được tiếp cận nhưng chưa thể cung cấp tài liệu được yêu cầu. 3.6.5 Câu trả lời (answer) Mã thể hiện một phản hồi có hoặc không có 3.6.6 Đang đ ó ng bìa (at bindery) Có tài liệu yêu cầu nhưng đang đóng bìa 3.6.7 Tác giả (author) Tên cá nhân hoặc tập thể chịu trách nhiệm về nội dung trí tuệ và nghệ thuật của một tài liệu, bao gồm cả các nhà soạn nhạc, người sáng tạo hoặc khởi tạo tài liệu này 3.6.8 Tác giả bài (author-of-article) Tác giả của một tài liệu là một phần cấu th à nh của một tài liệu khác 3.6.9 APDU cấu trúc kém (badly-structured-APDU) Cấu trúc của một APDU nhận được không phù hợp với ký hiệu và mã hóa chuẩn được định nghĩa trong ISO 8824 và ISO 8825, hoặc với mã hóa EDIFACT được định nghĩa trong ISO 9735 và Phụ lục B của tiêu chuẩn này. VÍ DỤ: APDU nhận được không đáp ứng độ dài đã đề ra. 3.6.10 Được xử lý để cung cấp (being-processed-for-supply) Tài liệu được tìm thấy, sao chụp, và/hoặc bao gói để cung cấp. 3.6.11 Ký hiệu xếp giá (call-number) ký hiệu gán cho một tài liệu cho biết vị trí vật lý của nó trong tổ chức chủ sở hữu 3.6.12 Có thể gửi kiểm nhận (can-send-CHECK E D-IN) Chỉ thị bởi bên đáp ứng là có khả năng cung cấp CHECKED-IN APDU( APDU Kiểm nhận) 3.6.13 Có thể gửi Nhận (can-send- RECEIVED) Chỉ thị bởi bên yêu cầu là có khả năng cung cấp RECEIVED-APDU( APDU Nhận) 3.6.14 Có thể g ử i Trả (can-send- RETURNED) Chỉ thị bởi bên yêu cầu là có khả năng cung cấp RETURNED-APDU (APDU Trả) 3.6.15 Có th ể gửi Vận chuyển (can-send- SHIPPED) Ch ỉ thị bởi bên đáp ứng là có khả năng cung cấp SHIPPED-APDU (APDU chuyển) 3.6.16 Không thể gửi tiếp (cannot-send- onward) Chỉ thị cho thấy người trung gian không thể chuyển đi một yêu cầu do các vấn đề truyền thông 3.6.17 Các đơn vị tính phí (chargeable-units) Số đơn vị được cung cấp phải tính phí 3.6.18 Phí (charges) Phí của bên đáp ứng cho việc cung cấp các dịch vụ yêu cầu 3.6.19 Thành phố (city) Cụm từ được sử dụng để xác định một thành phố 3.6.20 Định danh khách hàng (client-identifier) Số hoặc mã được sử dụng để xác định khách hàng duy nhất 3.6.21 Tên khách (client-name) Tên cá nhân hoặc tổ chức đã yêu cầu tài liệu 3.6.22 Yêu cầu về chữ ký khách (client-signature-required) Quy định của bên đáp ứng rằng khách phải ký vào bản chữ ký kèm theo tài liệu 3.6.23 Vị thế của khách (client-status) Trình độ chuyên môn hoặc chức vụ của khách hàng 3.6.24 Điều kiện (conditions) Mã được sử dụng để chỉ ra các điều kiện để một tài liệu có thể được mượn 3.6.25 Tuân thủ bản quyền (copyright-compliance) Ký hiệu của bên yêu cầu chỉ ra các quy định hoặc luật về bản quyền đang áp dụng mà bên yêu cầu đang tuân thủ 3.6.26 Thông tin tương quan (correlation-information) Thông tin được sử dụng có tương quan một báo cáo lỗi với yêu cầu dịch vụ mà báo cáo đó liên quan 3.6.27 Chi phí (cost) Số tiền yêu cầu, thu hoặc lập hóa đơn bởi bên đáp ứng cho dịch vụ được cung cấp 3.6.28 Dự toán chi phí (cost-estimate) Dự toán chi phí để cung cấp các dịch vụ được yêu cầu 3.6.29 Chi phí vư ợ t quá giới hạn (cost-exceeds-limit) Chỉ thị của bên đáp ứng là chi phí tối thiểu đ ể cung cấp theo yêu cầu lớn hơn số tiền được phép 3.6.30 Nước (country) Cụm từ được sử dụng để xác định một quốc gia 3.6.31 Mã tiền tệ (currency-code) Mã nhận dạng đồng tiền của một số lượng tiền, theo TCVN 6558 (ISO 4217) 3.6.32 Trạng thái hiện hành (current-state) Mã nhận dạng trạng thái của giao dịch ILL 3.6.33 Ngày kiểm nhận (date-check e d-in) Ngày một tài liệu cho mượn được nhận lại bởi bên đáp ứng 3.6.34 Ngày đến hạn tr ả (date-due) Ngày một tài liệu cho mượn phải được trả lại cho bên đáp ứng CHÚ THÍCH 1 Điều này phản ánh ngày đến hạn muộn nhất. 3.6.35 Ngày hồi âm (date-for-reply) Ngày bên đáp ứng đưa lại câu trả lời 3.6.36 Ngày chuyển đổi cuối cùng (date-of-last-transition) Ngày sự chuyển đổi trạng thái cuối cùng xảy ra 3.6.37 Ngày phục vụ gần đây nhất (date-of-most-recent-service) Ngày sự kiện dịch vụ gần đây nhất xảy ra tại hệ thống cung cấp các báo cáo tình trạng CHÚ THÍCH 1 Dịch vụ xuất hiện trong hệ thống cung cấp các báo cáo trạng thái hoặc dịch vụ ph ả n ánh trong một APDU nhận được. 3.6.38 Ngày phát sinh dịch vụ (date-of-service) Ng à y một dịch vụ liên quan đến một giao dịch ILL được gọi 3.6.39 Ngày nhận (date-received) ngày bên yêu cầu nhận được tài liệu 3.6.40 Ngày yêu cầu (date-requested) Ngày yêu cầu ILL được khởi xướng bởi bên yêu cầu 3.6.41 Ngày trả (date-returned) Ngày một tài liệu được trả lại cho bên đáp ứng 3.6.42 Ngày vận chuyển (date-shipped) Ngày tài liệu được vận chuyển cho bên yêu cầu 3.6.43 Dịch vụ cung cấp (desired-due-date) Dịch vụ hoặc phương pháp cung cấp được sử dụng trong vận chuyển một tài liệu được yêu cầu CHÚ THÍCH 1 có thể sử dụng cách cung cấp vật lý hoặc điện t ử . 3.6.44 Ngày đến hạn mong muốn (desired-due-date) Ngày đến hạn đề xuất cho lần mượ n gia hạn 3.6.45 Id giao dịch trùng lặp (duplicate-transaction-id) Giá trị id giao dịch của một APDU YÊU C ẦU ILL bị trùng lặp không hợp lệ, tức là giá trị giống hệt một YÊU C Ầ U ILL hiện c ó từ cùng một bên yêu cầu. 3.6.46 Phiên bản (edition) Tất cả các bản của một tài liệu được xuất bản từ một bản ch í nh hoặc các hình ảnh thuộc cùng một loại, tài liệu có cùng một nội dung, và, trong trường hợp các tài liệu không phải là sách, do một cơ quan xuất bản cụ thể hoặc nhóm các cơ quan đó phát hành 3.6.47 Cung c ấ p điện tử (electronic delivery) Cung cấp bản điện tử của tài liệu thông qua một cơ chế truyền dữ liệu dựa trên cơ sở hạ tầng viễn thông CHÚ THÍCH 1 Không bao gồm việc cung cấp các vật mang tin dưới dạng t ừ tính hoặc quang học hữu hình. 3.6.48 Ngày dự kiến có được tài liệu (estimated-date-available) Ngày một tài liệu được đặt giữ dự kiến sẽ trở thành sẵn có 3.6.49 Ngày hết hạn (expiry date) Ngày một giao dịch ILL hết hạn tự động 3.6.50 C ờ hết hạn (expiry flag) Chỉ thị cho biết ng à y hết hạn đã được đặt cho một giao dịch ILL, và nếu như vậy, cho dù ngày đó là "cần trước ngày", hoặc một ngày khác nào đó 3.6.51 Địa ch ỉ cung cấp bưu chính mở rộng (extended-postal-delivery-address) Thông tin bổ sung tại địa chỉ bưu chính cần thiết để xác định chính xác điểm cung cấp, ví dụ phòng và số tầng trong một tòa nhà lớn 3.6.52 Bên đáp ứng cuối cùng (final-responder) Tổ chức cung cấp một tài liệu yêu cầu CHÚ THÍCH 1: Thuật ngữ này được sử dụng khi cần thiết phân biệt b ê n đáp ứng một giao dịch ILL và b ê n đáp ứng một giao dịch con ILL 3.6.53 Cờ chuyển tiếp (forward flag) Chỉ th ị một YÊU C Ầ U- ILL đã được chuyển tiếp từ một trung gian 3.6.54 Chú thích chuyển tiếp (forward note) Chú thích bổ sung vào YÊU C Ầ U- ILL bởi bên đáp ứng khi nó được chuyển tiếp đến một bên đáp ứng mới . 3.6.55 Vấn đề chung (general-problem) Mã cho biết nhà cung cấp dịch vụ ILL phát hiện một vấn đề chung xảy ra với một APDU nhận được mà không có liên quan đến một trong hai id giao dịch hoặc chuyển đổi trạng thái cho phép 3.6.56 Loại APDU ILL (ILL-APDU-type) Mã nhận dạng loại APDU nhận được 3.6.57 Loạ i dịch vụ ILL (ILL-service-type) Mã cho loại dịch vụ ILL yêu cầu CHÚ THÍCH 1 Các mã này có thể được liệt kê theo thứ tự ưu tiên. 3.6.58 Giao dịch ILL (ILL-transaction) Ví dụ hoàn chỉnh duy nhất của toàn bộ chu trình ILL, bao gồm tất cả các hành động, dịch vụ gốc và các thông báo liên quan từ yêu cầu ILL ban đầu cho đến khi chu trình được kết thúc, như bằng sự trả lại các tài liệu yêu cầu 3.6.59 Đang xử lý (in-process) Tài liệu đã nhận được nhưng vẫn chưa sẵn sàng cho sử dụng 3.6.60 Đang sử dụng/cho mượn (in use/on-loan) Có sở hữu tài liệu nhưng hiện đang được sử dụng bởi một khách hàng hoặc là cho cơ quan khác mượn 3.6.61 Bên yêu cầu ban đ ầ u (initial-requester) Cá nhân hoặc tổ chức khởi tạo giao dịch ILL CHÚ THÍCH 1 Thuật ngữ này được sử dụng khi c ầ n thiết phân biệt giữa bên yêu cầu một giao dịch ILL và b ê n yêu cầu một giao dịch thứ phát ILL . 3.6.62 Địa chỉ bên yêu cầu ban đầu (initial-requester-address) Thông tin xác định dịch vụ viễn thông và địa chỉ m à theo đó có thể đến được bên yêu cầu ban đ ầ u 3.6.63 Ngườ i khởi tạo dịch vụ g ầ n đây nhất (initiator-of-most-recent service) Thông tin nhận dạng bên yêu cầu hoặc bên đáp ứng khởi tạo dịch vụ gần đây nhất 3.6.64 Biểu tượng hướng dẫn (instruction-symbol) Một hoặc nhiều số, chữ hoặc mã phục vụ cho việc xác định một cách rõ ràng và trong một định dạng viết tắt một thư viện, tổ chức hoặc công ty tham gia vào một giao dịch ILL, ví dụ biểu tượng mục lục liên hợp quốc gia của tổ chức 3.6.65 Bảo hi ể m cho (insured-for) Ký hiệu của số tiền bảo hiểm được mua phòng mất mát hoặc hư h ỏ ng các tài liệu 3.6.66 Id trung gian (intermediary-id) Thông tin nhận dạng một bên trung gian giao dịch ILL 3.6.67 Vấn đề trung gian (intermediary-problem) Mã chỉ ra rằng bên trung gian có vấn đề trong lúc xử lý yêu cầu 3.6.68 Id giao dịch không hợp lệ (invalid-transaction-id) Giá trị id giao dịch của một YÊU CẦU- ILL không hợp lệ, ví dụ giá trị này vi phạm các quy tắc gán ở tiêu chuẩn này, hoặc một biểu tượng cá nhân hoặc tổ chức không biết hoặc tên cá nhân hoặc tổ chức đã biết 3.6.69 Mã số tiêu chuẩn quốc tế cho sách (ISBN) Mã số tiêu chuẩn quốc tế cho sách gán cho một chuyên khảo theo quy định của TGVN 6381 ( ISO 3297) 3.6.70 Mã số tiêu chuẩn quốc tế cho xuất bản phẩm nhiều kỳ (ISSN) Mã số tiêu chuẩn quốc tế cho xuất bản phẩm nhiều kỳ gán cho một xuất bản phẩm nhiều kỳ theo quy định của TCVN 6380 (ISO 2108) 3.6.71 Loại tài liệu (item-type) Mã nhận dạng hình thức thư mục trong đó tài liệu này được xuất bản 3.6.72 Thiếu (lacking) Có sở hữu tên tài liệu này nhưng không có phần cấu thành hoặc các trang được yêu cầu 3.6.73 Thiếu thông tin tuân thủ bản quyền (lacks-copyright-compliance) Việc tuân thủ các quy định hoặc luật bản quyền áp dụng phải được thể hiện trước khi có thể thực hiện sao chép 3.6.74 Mức dịch vụ (level-of-service) Mã chỉ ra mức độ chi tiết của cuộc tìm được yêu cầu hoặc thời hạn trả lời được yêu cầu CHÚ THÍCH 1: Lưu ý rằng mã này phản ánh các quy ước khu vực hoặc quốc gia. 3.6.75 Ch ỉ sử dụng trong thư viện (library-use-only) Dấu hiệu của bên đáp ứng cho thấy tài liệu này có thể không được lấy từ tổ chức đang yêu cầu 3.6.76 Đ ị a chỉ địa điểm (location-address) Thông tin xác định các dịch vụ viễn thông và địa chỉ hoặc địa chỉ bưu chính nhờ đó có thể tìm được tổ chức sở hữu tài liệu. 3.6.77 Id địa điểm (location-id) Biểu tượng hoặc tên của tổ chức sở hữu tài liệu được yêu cầu 3.6.78 Chú thích địa điểm (location-note) Thông tin bổ sung thêm hoặc sửa đổi các dữ liệu thư mục được cung cấp trong YÊU CẦU- ILL hoặc làm rõ địa điểm cung cấp 3.6.79 Không thấy địa điểm (location-not-found) Không xác định được bên đáp ứng tiềm năng . 3.6.80 Mất (lost) Tài liệu được tuyên bố bị mất và/hoặc rút khỏi bộ sưu tập 3.6.81 Không hỗ trợ gửi thông báo bắt buộc (mandatory-messaging-not-supported) Bên đáp ứng không cung cấp thông tin KI Ể M NH Ậ N và/hoặc VẬN CHUY Ể N. 3.6.82 Chi phí tối đa (maximum-cost) Số tiền tối đa sẽ được trả để có được một dịch vụ ILL 3.6.83 Đặc tính của vật mang tin (medium-characteristic) Thông số kỹ thuật của dạng vật lý chứa tài liệu được cung cấp cho yêu cầu 3.6.84 Loại hình vật mang tin (medium-type) Mã nhận dạng vật mang tin chứa tài liệu được xuất bản 3.6.85 APDU nhập sai (mistyped-APDU) Cấu trúc của APDU không phù hợp với cấu trúc được định nghĩa của tiêu chuẩn này. VÍ DỤ Nó chứa một kiểu dữ liệu không được định nghĩa cho phiên bản này của giao thức. 3.6.86 G i á trị tiền tệ (monetary-value) Giá trị của một số tiền 3.6.87 Dịch vụ gần đây nhất (most-recent-service) Mã nhận dạng các sự kiện dịch vụ gần đây nhất xảy ra tại hệ thống cung cấp các báo cáo trạng thái CHÚ THÍCH 1: Đây là dịch vụ gọi bởi hệ thống cung cấp các báo cáo trạng thái hoặc là dịch vụ được phản ánh trong một AP D U nhận được. Báo cáo trạng thái gửi đi đ ể đáp ứng với một yêu cầu trạng thái sẽ không chỉ ra yêu cầu trạng thái là dịch vụ gần đây nhất - v ì điều này sẽ không được thông tin. 3.6.88 Chú thích về dịch vụ gần đây nhất (most-recent-service-note) Nội dung của các tham số chú thích từ dịch vụ ban đầu gần đây nhất 3.6.89 Tên tổ chức (name-of-institution) Từ, cụm từ hoặc chữ viết tắt xác định một thư viện, cơ quan hoặc công ty 3.6.90 Tên cá nhân (name-of-person) Từ hoặc tổ hợp các từ và/hoặc tên viết tắt chữ cái đầu theo đ ó một cá nhân thường được biết đến hoặc được chỉ định và nó xác định người tham gia vào giao dịch ILL 3.6.91 Số thư mục quốc gia (national-bibliography-no) Thông tin xác định thư mục quốc gia và số biểu ghi tương ứng với tài liệu mong muốn, ví dụ Số phiếu Thư viện Quốc hội (LCCN) 3.6.92 Cần trước ngày (need-before-date) Ngày cần một tài liệu hoặc sự trả lời 3.6.93 Số đơn vị tài liệu theo loại vật mang tin (no-of-units-per-medium) Số lượng các đơn vị vật lý được vận chuyển theo vật mang tin cung cấp 3.6.94 Không sao chép (no-reproduction) Tài liệu không được phép sao chép hay tái bản toàn bộ hoặc một phần bằng máy móc 3.6.95 Không luân chuyển (not-circulating) Tài liệu được lưu giữ nhưng không cho mượn 3.6.96 Không sẵn có (not-available) Do một số vấn đề kỹ thuật, người sử dụng dịch vụ tạm thời không thể yêu cầu dịch vụ 3.6.97 Không tìm thấy như trích d ẫ n (not-found-as-cited) Thông tin nhận dạng tài liệu được bên đáp ứng cho là không ch í nh xác hoặc không đầy đủ. 3.6.98 Không có trên giá (not-on-self) Tài liệu thuộc sở hữu của tổ chức nhưng chưa được cho mượn và không có trên giá 3.6.99 Không sở hữu (not-owned) Nhan đề không được sở hữu bởi bên đáp ứng . 3.6.100 Chú thích (note) Thông tin bổ sung không bao gồm bất kỳ phần tử dữ liệu nào khác . 3.6.101 Chú thích thông báo (notification note) Chú thích thêm vào THÔNG BÁO-CHUY Ể N TIẾP bởi bên đáp ứng . 3.6.102 Đang giữ (on-hold) Tài liệu đã được yêu cầu bởi một tổ chức hoặc cá nhân và sẽ được cung cấp cho tổ chức hay cá nh â n ngay khi nó có sẵn. 3.6.103 Đang đặt (on-order) Tài liệu được đặt nhưng đã không nhận được từ bên đáp ứng. 3.6.104 Đang lưu giữ (on-reserve) Tài liệu được sở hữu nhưng dành cho sử dụng hạn chế. 3.6.105 Đánh số trang (pagination) Việc đánh số các trang của một tài liệu hoặc một phần cấu thành của tài liệu. 3.6.106 Thực hiện thanh toán (payment-provided) Thông báo của bên yêu cầu là việc thanh toán phí cho bên đáp ứng đã được phép, đang được gửi đi, hoặc sẽ được kèm theo tài liệu trả. 3.6.107 Cho phép thực hiện theo chuỗi (permission-to-chain) Chỉ thị việc cho phép bên đáp ứng khởi tạo một giao dịch con theo chuỗi với bên đáp ứng khác. 3.6.108 Cho phép thay đổi danh sách gửi (permission-to-change-send-to-list) Chỉ thị cho phép bên đáp ứng thay đổi nội dung của danh sách địa chỉ gửi đến. B ả n chất của các thay đổi được phép tùy thuộc vào giá trị của loại "ưu tiên" . 3.6.109 Cho phép chia ph ầ n (permission-to-partition) Chỉ thị cho phép bên đáp ứng khởi tạo một giao dịch con thêm chia phần với bên đáp ứng khác. 3.6.110 Cho phép chuyển tiếp (permission-to-forward) Chỉ thị cho phép bên đáp ứng chuyển tiếp yêu cầu tới bên đáp ứng khác . 3.6.111 Biểu tượng cá nhân (person-symbol) Một hoặc nhiều số, chữ hoặc mã dùng để xác định một cách rõ ràng và trong dạng viết tắt một cá nhân đang tham gia vào một giao dịch ILL 3.6.112 Vật mang tin vật lý (physical-medium) Mã nhận dạng vật mang tin trong đó tài liệu được xuất bản. CHÚ THÍCH: Giống loại hình vật mang tin. 3.6.113 Nơi xuất bản (place-of-publication) Vị trí địa lý của nhà xuất bản, hoặc của nhà in, nhà phát hành hoặc sản xuất nếu không có nhà xuất bản. 3.6.114 Đặt g i ữ (place-on-hold) Yêu cầu đặt giữ tài liệu để cung cấp tài liệu ngay khi nó sẵn có 3.6.115 Vấn đề chính sách (policy-problem) Chỉ định của bên đáp ứng cho biết không có chính sách cho phép hoàn thành yêu cầu 3.6.116 Điều kiện chất lượng kém (poor-condition) Tài liệu được sở hữu nhưng tình trạng vật lý của nó không cho phép mượn hoặc tái bản. 3.6.117 Hòm thư (post-office-box) Số hòm thư được gán bởi bưu điện 3.6.118 Mã bưu chính (postal-code) Mã xác định một khu vực nhất định trong một thành phố hoặc khu vực địa lý khác . 3.6.119 Ưu tiên (preference) Chỉ định cho biết các tổ chức được liệt kê trong danh sách gửi phải được tiếp cận theo thứ tự của danh sách hoặc theo bất kỳ thứ tự nào 3.6.120 Yêu cầu thanh toán trước (prepayment-required) Chỉ định của bên đáp ứng yêu cầu phải thanh toán trước khi xử lý giao dịch ILL 3.6.121 Phiên bản giao thức không được hỗ trợ (protocol-version-not-supported) Một APDU đã được nhận có thành phần số phiên bản giao thức xác định một phiên bản của giao thức không được hỗ trợ 3.6.122 Số phiên bản giao thức (protocol-version-num) Số xác định phiên bản của giao thức đang sử dụng 3.6.123 Năm xuất bản (publication-date) Năm phát hành một tác phẩm như được định rõ bởi nhà xuất bản tác phẩm này 3.6.124 Năm xuất bản phần cấu thành (publication-date-of-components) Năm xuất bản được định rõ bởi nhà xuất bản để xác định các phần cấu thành thư mục duy nhất của một tác phẩm 3.6.125 Nhà xuất bản (publisher) Một hoặc nhiều cá nhân hoặc tổ chức chịu trách nhiệm về việc xuất bản một tài liệu 3.6.126 Lý do các địa điểm được cung cấp (reason-locs-provided) Mã được sử dụng để cho biết lý do tại sao các địa điểm được cung cấp để đáp ứng yêu cầu ILL . 3.6.127 Lý do không báo cáo (reason-not-report) Mã được sử dụng để cho biết lý do tại sao không cung cấp báo cáo để đáp lại một câu hỏi về trạng thái 3.6.128 Lý do không sẵn có (reason-not-available) Mã được sử dụng để cho biết lý do tài liệu không sẵn có 3.6.129 Lý do không thực hiện được (reason-unfilled) Mã được sử dụng để cho biết lý do không hoàn thành một yêu cầu ILL 3.6.130 Thỏa thuận đối ứng (reciprocal agreement) Chỉ thị của bên yêu cầu về một thỏa thuận ưu tiên cho những g ì có thể được cung cấp và điều kiện cung cấp 3.6.131 Khu vực/ Vùng (region) Cụm từ được sử dụng để xác định một t ỉ nh, bang, vùng, hoặc địa phương 3.6.132 Có thể gia hạn được (renewable) Dấu hiệu cho biết tài liệu được cung cấp có gia hạn được hay không 3.6.133 Nguồn báo cáo (report-source) Mã số cho biết nguồn khởi tạo báo cáo lỗi là người dùng dịch vụ hoặc nhà cung cấp dịch vụ 3.6.134 Loại báo cáo (report-type) Dấu hiệu cho biết một báo cáo có hay không và nếu có, th ì đó là một báo cáo trạng thái, báo cáo lỗi hoặc cả hai. 3.6.135 Id được yêu cầu (requested-id) Thông tin nhận dạng bên yêu cầu giao dịch ILL 3.6.136 Lưu ý của bên yêu cầu (requester-note) Lưu ý cung cấp bởi bên yêu cầu giao dịch ILL 3.6.137 Các thông báo tùy chọn của bên yêu cầu (requester-optional-messages) Dấu hiệu cho biết hoặc bên yêu cầu có khả năng gửi các thông báo tùy chọn ĐÃ NHẬN và Đ Ã TRẢ và hoặc các thông báo tùy chọn ĐÃ CHUY Ể N và/hoặc Đ Ã KI Ể M NH Ậ N là yêu cầu hoặc mong muốn từ bên đáp ứng 3.6.138 Dấu đ ã kiểm nhận từ phía bên yêu cầu (requester CHECKED-IN) Dấu hiệu của bên yêu cầu là có hay không yêu cầu hoặc mong muốn nhận được APDU Kiểm nhận 3.6.139 Dấu đã vận chuyển từ phía bên yêu cầu (requester-SHIPPED) Dấu hiệu của bên yêu cầu là có hay không việc yêu cầu hoặc mong muốn APDU Vận chuyển 3.6.140 Hạn chế nguồn lực (resource-limitation) Người sử dụng dịch vụ không thể thực hiện dịch vụ yêu cầu do các hạn chế về nguồn lực 3.6.141 Địa chỉ bên đáp ứng (responder-note) Thông tin xác định các dịch vụ viễn thông và địa chỉ có thể đến nơi bên đáp ứng 3.6.142 Id bên đáp ứng (responder-id) Thông tin nhận dạng của bên đáp ứng giao dịch ILL 3.6.143 Lưu ý của người đáp ứng (responder-note) Lưu ý cung cấp bởi bên đáp ứng giao dịch ILL 3.6.144 Các thông báo tùy chọn của bên đáp ứng (responder-optional-messages) Dấu hiệu cho biết hoặc bên đáp ứng có khả năng gửi các thông báo tùy chọn ĐÃ CHUY Ể N và/hoặc ĐÃ KI Ể M NHẬN (cho mục đích chẩn đoán) và hoặc các thông báo ĐÃ NH Ậ N và/hoặc ĐÃ TRẢ được bên yêu cầu yêu cầu hoặc mong muốn. 3.6.145 Dấu đã nhận từ phía Bên đáp ứng (responder-RECEIVED) Dấu hiệu của bên đáp ứng là có hay không yêu cầu hoặc mong muốn nhận được APDU đã Nhận. 3.6.146 Dấu đã trả từ phía Bên đáp ứng (responder-RETURNED) Dấu hiệu của bên đáp ứng là có hay không yêu cầu hoặc mong muốn nhận được APDU ĐÃ TRẢ. 3.6.147 Kết quả cụ thể của bên đáp ứng (responder-specific-result) Lý do được cung cấp để đáp ứng yêu cầu ILL là cụ thể với bên đáp ứng, tức là không được quy định trong tiêu chuẩn này. 3.6.148 Dịch vụ cụ thể của bên đáp ứng (responder-specific-service) Dịch vụ được cung cấp bởi bên đáp ứng là cụ thể với bên đáp ứng, tức là không được quy định trong tiêu chuẩn này. 3.6.149 Ngày thử lại (retry-date) Ngày sau khi một yêu cầu có thể được thực hiện lại. 3.6.150 Cờ thử lại (retry-flag) Dấu hiệu của bên yêu cầu cho biết giao dịch ILL có phải là lần thực hiện lại của một lần trước hay không. 3.6.151 Yêu cầu bảo hiểm trả lại (return-insurance-required) Số tiền bảo hiểm đối với việc mất hoặc hư hỏng được yêu cầu bởi bên đáp ứng cho việc trả lại tài liệu đã mượn. 3.6.152 Trả lại qua (retu rn ed-via) Phương pháp bên yêu cầu vận chuyển tài liệu để trả. 3.6.153 Vấn đề an ninh (security-problem) Dấu hiệu cho thấy người nhận đã gặp vấn đề bảo mật c ả n trở họ xử lý yêu cầu dịch vụ. CHÚ THÍCH 1 Các lý do có thể nằm ngoài phạm vi của tiêu chuẩn này. 3.6.154 Tùng thư- Nhan đề-Số (series-title-number) Tên đặt cho một số xuất bản phẩm riêng biệt nhưng liên quan với nhau và trên thực tế là mỗi xuất bản phẩm vừa mang một nhan đề chung dùng cho cả nhóm hoặc nhóm con như một chỉnh thể vừa mang cả nhan đề và số riêng của nó trong nhóm đó 3.6.155 Danh sách gử i đến (send-to-list) Danh sách những bên đáp ứng tiềm năng cho các giao dịch ILL để chuyển tới tổ chức thành chuỗi hoặc phân khu 3.6.156 Điều kiện vận chuyển (shipped-conditions) Điều kiện theo đó một tài liệu có thể được sử dụng 3.6.157 Loại hình dịch vụ vận chuyển (shipped-service-type) Mã cho loại hình dịch vụ ILL được cung cấp 3.6.158 Vận chuyển qua (shipped-via) Phương pháp vận chuyển được dùng để gửi tài liệu của người cho mượn. 3.6.159 Yêu cầu giám sát bộ sưu tập đặc biệt (special-collections-supervision-required) Dấu hiệu bên đáp ứng cho biết tài liệu phải được sử dụng trong phòng hoặc cơ quan lưu trữ bộ sưu tập đặc biệt 3.6.160 Cơ quan tài trợ (sponsoring-body) Cơ quan hoặc tổ chức phát hành tài liệu hoặc có liên kết với tác giả của nó 3.6.161 Đường phố và số nhà (street-and-number) Số và/hoặc cụm từ được sử dụng để xác định vị trí của một tòa nhà trong một thành phố hoặc một khu vực nông thôn 3.6.162 Mô tả tài liệu bổ sung (supplemental-item-description) Thông tin mô tả tài liệu bổ sung có thể được trình bày theo kh ổ mẫu đọc máy, ví dụ biểu ghi MARC 3.6.163 Id nhà cung cấp (supp li er-id) Thông tin nhận dạng nhà cung cấp tài liệu được yêu cầu khi nhà cung cấp khác với bên đáp ứng. 3.6.164 Loại vật mang tin cung cấp (supply-medium-type) Mã nhận dạng vật mang tin của tài liệu yêu cầu CHÚ THÍCH mã này có thể được liệt k ê theo thứ tự ưu tiên. 3.6.165 Số hệ thống (system-no) S ố cung cấp nhận dạng cụ thể hệ thống của biểu ghi thư mục cho một tài liệu yêu cầu 3.6.166 Địa ch ỉ dịch vụ viễn thông (te l ecom-service-address) Số hoặc mã duy nhất được gán cho một hộp thư hoặc một dịch vụ điện tử hoặc một người tham gia vào mạng lưới truyền thông 3.6.167 Ký hiệu định danh dịch vụ viễn thông (telecom-service-identifier) Tên hoặc mã duy nhất của dịch vụ viễn thông được sử dụng cho giao dịch ILL 3.6.168 Thời gian dịch vụ (time-of-service) Thời gian khi một dịch vụ được gọi 3.6.169 Nhan đề (title) Tên của một tài liệu gồm một từ hoặc nhóm từ dùng để xác định nó . 3.6.170 Nhan đề bài (title-of-article) Nhan đề của một tài liệu là phần cấu thành của một tài liệu khác 3.6.171 Dấu hạn định nhóm giao dịch (transaction-group-qualfier) Chuỗi chữ số duy nhất xác định một tập hợp các giao dịch ILL liên quan, ví dụ một loạt các tham chiếu hoặc một yêu cầu ILL và các lần lặp lại tiếp theo của nó CHÚ THÍCH 1 Dấu hạn định này là duy nhất trong phạm vi của hệ thống giao dịch ILL ban đầu của bên yêu cầu. Bằng cách kết hợp với id của bên yêu cầu, n ó cung cấp một nhận dạng duy nhất phổ biến cho nhóm giao dịch ILL. 3.6.172 Vấn đề id giao dịch (transaction-id-problem) Mã cho biết một vấn đề với id giao dịch trong một APDU nhận được 3.6.173 D ấ u hạn định giao dịch (transaction-qualfier) Chuỗi chữ số xác định tất cả các dịch vụ và các thông báo liên quan đến một giao dịch ILL duy nhất CHÚ THÍCH 1 Đây là một chuỗi duy nhất được gán bởi bên yêu cầu ban đầu giao dịch ILL và được áp dụng bởi các đối tác ILL cho tất cả các dịch vụ tiếp theo và thông báo liên quan đến giao dịch ILL. Bằng cách kết hợp với id của bên yêu cầu và dấu hạn định nhóm giao dịch, nó cung cấp một nhận dạng duy nhất phổ biến cho giao dịch ILL. 3.6.174 Loại hình giao dịch (transaction-type) Mã xác định loại hình giao dịch ILL 3.6.175 Phương thức vận chuyển (transportation-mode) Phương tiện vật chất hay phi điện tử để vận chuyển tài liệu yêu cầu khi được trình bày hay được lưu trữ trên một vật mang tin hữu hình 3.6.176 Không thể thực hiện (unable-to-perform) Mã cho biết lý do tại sao những người sử dụng dịch vụ không thể thực hiện dịch vụ yêu cầu 3.6.177 Id giao dịch không biết (unknown-transaction-id) Không có giao dịch ILL tương ứng với giá trị id giao dịch của một APDU nhận được 3.6.178 APDU không được công nhận (unrecognized-APDU) Loại APDU nhận được không phải là một trong các APDU được xác định trong tiêu chuẩn này. 3.6.179 Nguồn tham chiếu kiểm chứng (vertification-reference-source) Nguồn thông tin thư mục chuẩn được sử dụng để xác định hoặc định vị một tài liệu hoặc bất kỳ nguồn nào được dùng để xác định hoặc định vị một tài liệu 3.6.180 Tập-s ố (volume-issue) Ký hiệu định danh một đơn vị vật lý của một chuyên khảo nhiều tập hoặc nhiều kỳ, hoặc một số, chữ cái hay từ xác định một đơn vị của một tài liệu hoặc các tập của nó được xuất bản thành các phần. 3.6.181 Chưa có tập/s ố (volume-issue-not-yet-available) Nhan đề là thuộc sở hữu nhưng phần cấu thành được yêu cầu chưa nhận được. 3.6.182 Sẽ trả phí (will-pay-fee) Dấu hiệu của bên yêu cầu cho biết đồng ý trả phí áp dụng 3.6.183 Sẽ cung cấp kết quả (w i ll-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 APDU đơ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 ILL 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 OSI 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 CHUY Ể N TIẾP (FORWARD) 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 HỦY (CANCEL) 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 KIỂM NHẬN (CHECKED-IN) 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 ĐÃ B Ị HƯ HẠI (DAMAGED) 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 (ST A TUS-QUERY) chưa được xác nhận BÁO CÁO TÌNH TRẠNG HOẶC LỖI (STATUS-OR-ERROR-REPORT) chưa được xác nhận H Ế T HẠN (EXPIRY) người cung cấp ban đầu 5.2 Dịch vụ hỗ trợ giả định Giao thức ILL được định ra để có thể hoạt động ở cả hai chế độ: chế độ lưu trữ-và-chuyển tiếp và chế độ định hướng kết nối. Các yêu cầu kỹ thuật của ánh xạ tới các dịch vụ hỗ trợ cụ thể sẽ được cung cấp trong các định nghĩa về ngữ cảnh ứng dụng và các diện chức năng. Phụ lục F mô tả một số ánh xạ có thể đến các dịch vụ hỗ trợ. 5.3 M ô hình Về lý thuyết, hoạt động của giao thức ILL được mô hình hóa bởi sự tương tác của các máy tính giao thức ILL (ILLPM). Các ILLPM truyền thông bằng cách trao đổi các APDU ILL thông qua việc sử dụng các dịch vụ trừu tượng "gửi APDU" và "nhận APDU" tại ranh giới thấp hơn của chúng. Tại ranh giới cao hơn của chúng, các ILLPM cung cấp các dịch vụ được quy định trong ISO 10160. Một ILLPM được điều khiển bởi việc tiếp nhận các sự kiện đầu vào từ người sử dụng dịch vụ ILL, hỗ trợ các nhà cung cấp dịch vụ hoặc từ một bộ đếm thời gian nội bộ. Các sự kiện đầu vào từ người sử dụng dịch vụ ILL là yêu cầu ban đầu và từ các dịch vụ hỗ trợ ILL là APDU nhận được. Sự kiện đầu vào từ bộ đếm thời gian nội bộ là bộ đếm thời gian hết hạn. Một ILLPM trả lời các sự kiện đầu vào bằng cách đưa ra các sự kiện đầu ra cho dịch vụ hỗ trợ của nó và đến người sử dụng dịch vụ ILL của m ì nh. Các sự kiện đầu ra cho dịch vụ hỗ trợ là việc gửi các APDU ILL. Các sự kiện đầu ra tới người sử dụng dịch vụ ILL của nó là các chỉ dẫn cơ bản ILL. Việc nhận một sự kiện đầu vào, tạo ra những hành động phụ thuộc, và sự kiện đầu ra kết quả được coi là một hành động không thể tách riêng. Về logic mỗi giao dịch ILL sẽ khởi tạo một tập ILLPM tương ứng riêng biệt. Những lệnh gọi này duy trì thông tin trạng thái cho một giao dịch ILL nhất định. Vòng đời của một lệnh gọi ILLPM dài như cần thiết để hoàn tất giao dịch ILL liên quan. Thông tin trạng thái này phải được lưu trữ bảo toàn trong tất cả các trường hợp sử dụng các dịch vụ hỗ trợ, ví dụ, nó phải được duy trì riêng biệt với mọi thông tin trạng thái liên quan đến các liên kết ứng dụng tiềm ẩn. Nhiều giao dịch ILL, và vì thế nhiều ILLPM, có thể cùng tồn tại. Máy tính giao thức ILL kỳ vọng rằng các APDU của nó sẽ được chuyển giao đáng tin cậy không mất, thay đổi hoặc bổ sung bất kỳ thông tin nào. Nó cho phép các APDU lặp lại. Giao thức này cho phép lặp lại yêu cầu dịch vụ do người sử dụng kh ởi xướng để khôi phục lại mất mát, sai sót hoặc các APDU bị thay đổi. Các cơ chế theo đó những vấn đề như vậy được phát hiện và người dùng được thông báo nằm ngoài phạm vi của đặc tả này. 6 Đơn vị dữ liệu của giao thức ứng dụng ILL (APDU ILL) APDU ILL là một đơn vị thông tin truyền qua giữa hai ASE ILL ngang hàng tham gia vào một giao dịch ILL. Điều khoản n à y liệt kê các APDU được sử dụng trong ứng dụng ILL và mô tả việc sử dụng và ý nghĩa của những APDU này. 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 được sử dụng bởi bên đáp ứng để gửi một trả lời cho bên yêu cầu (trả lời có thể là: Điều kiện, Thực hiện lại, Không hoàn tất, Cung cấp địa điểm, Sẽ cung cấp, Đặt giữ và Đánh giá). 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 gi a o dịch ILL TR Ả L Ờ I HỦY được sử dụng bởi người đáp ứng để đáp lại yêu cầu hủy. ĐÃ NHẬN được sử dụng bởi bên yêu cầu để cho biết đã nhận được một tài liệu Đ Ò I được sử dụng bởi các bên đáp ứng để yêu cầu trả lại ngay một tài liệu ĐÃ 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 được sử dụng bởi bên đáp ứng để đáp lại một yêu cầu 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 được sử dụng bởi một trong hai bên bên yêu cầu hoặc bên đáp ứng để thông báo về hiện trạng và bất kỳ thông tin liên quan nào sẵn có, hoặc đ ể báo cáo một điều kiện lỗi của giao dịch ILL 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 sa u cho mỗi giao dịch ILL: - Nhận dạng giao dịch; - Trạng thái giao thức; - Các biến giao thức; - Bộ đếm thời gian hết hạn; - Thông tin yêu cầu; - Thông tin lịch sử. 7.1 Nhận dạng giao dịch APDU ILL hoặc dịch vụ ban đầu được kết hợp với một giao dịch ILL bằng một id giao dịch. Id giao dịch đáp ứng các yêu cầu sau đây: a) t í nh duy nhất trong trường hợp tổ chức theo chuỗi và phân khu; b) cho phép các giao dịch con liên kết với giao dịch ILL ch í nh; c) cho phép nhiều giao dịch ILL liên kết với nhau thành một nhóm logic, ví dụ khi bên yêu cầu chuyển một yêu cầu ILL đến nhiều bên đáp ứng lần lượt; hoặc việc L ặp lại được liên kết đến yêu cầu ILL gốc. Giao dịch bao gồm các thành phần sau: Nhận dạng (ID) bên yêu cầu ban đầu (tùy chọn) xác định người khởi xướng giao dịch ILL; Dấu hạn định nhóm giao dịch (bắt buộc) 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 gi a n 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 i d giao dịch Giao dịch đơn giản Id bên yêu cầu ban đầu Dấu hạn định nhóm giao dịch Dấu hạn định giao dịch Dấu hạn định giao dịch con Tùy chọn Khai báo bởi bên yêu cầu Bắt buộc Khai báo bởi bên yêu cầu Bắt buộc Khai b á o bởi bên yêu cầu Không sử dụng Bảng 3- Giao dịch theo chuỗi hoặc phân khu Giao dịch theo chuỗi hoặc phân khu Id bên yêu cầu ban đầu Dấu hạn định nhóm giao dịch Dấu hạn định giao dịch Dấu hạn định giao dịch con Bắt buộc Khai báo bởi người trung gian Bắt buộc Khai báo bởi bên yêu cầu Bắt buộc 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. i d bên yêu cầu ban đầu có thể lấy bất kỳ biểu tượng đại diện n ào như được xác định trong 7.5.1 để sử dụng làm id hệ thống, nhưng nếu sử dụng biểu tượng đại diện cho cá nhân hoặc tập thể, thì khi đó giao dịch ILL sẽ bị hạn chế và chỉ có thể thực hiện trong vùng có thể nhận diện rõ biểu tượng đại diện, ví dụ: trong một quốc gia. Nếu người trung gian gán giá trị cho thành phần này thì giá trị đó phải trùng với "id bên yêu cầu" trong YÊU CẦU ILL ban đầu. CHÚ THÍCH: Các thành phần bên trong của id bên yêu cầu có thể cần phải được xác định rõ h ơ n trong một định nghĩa diện ứng dụng. Đối với một giao dịch ILL hai bên đơn giản, thành phần id bên yêu cầu ban đầu không cần phải được đưa vào như một phần của id giao dịch vì thông tin này đã có sẵn trong loại id bên yêu cầu của APDU YÊU CẦU-ILL đó. Tuy nhiên, nếu id bên yêu cầu ban đầu hiện diện trong một APDU YÊU C Ầ U-ILL, thì nó phải đưa ra cùng một giá trị trong tất cả các thông báo khác có liên quan với giao dịch ILL. Ngoài ra, dấu hạn định giao dịch con là không cần thiết. Dấu hạn định nhóm giao dịch là một thành phần bắt buộc của id giao dịch. Dấu này là duy nhất trong phạm vi của bên yêu cầu ban đầu. Bên yêu cầu ban đầu, có trách nhiệm gán các tr ị cho dấu hạn định này để đáp ứng quy tắc này. Chỉ được tái sử dụng dấu hạn định nhóm giao dịch khi tất cả các giao dịch ILL trong nhóm đã ngừng hoạt động và ít khả năng có giao dịch mới được khởi xướng liên quan đến các giao dịch của nhóm. Dấu hạn định có thể được sử dụng để liên kết nhiều giao dịch ILL, ví dụ trong trường hợp tham chiếu hay muốn phân biệt các lần thử lại giao dịch với các giao dịch ILL gốc. Dấu hạn định giao dịch xác định duy nhất một giao dịch ILL trong một nhóm giao dịch. Dấu hạn định giao dịch là thành phần bắt buộc của một id giao dịch. Đối với một giao dịch con, tất cả các thành phần đều cần thiết. Id bên yêu cầu ban đầu cùng với dấu hạn định nhóm giao dịch và dấu hạn định giao dịch đảm bảo rằng giao dịch ILL là duy nhất trong miền đơn tr ị của id bên yêu cầu ban đầu. Dấu hạn định giao dịch con cùng với thông tin id bên yêu cầu được chuyển vào một APDU YÊU CẦU-ILL của giao dịch con đảm bảo tính duy nhất của giao dịch con. Trong trường hợp các giao dịch ILL theo chuỗi, có thể có một chuỗi các giao dịch con được liên kết trong một chuỗi. Trong trường hợp này, mỗi giao dịch con được coi là một giao dịch con của giao dịch ILL gốc, vì vậy mỗi người trung gian khởi tạo một giao dịch con mới thay thế dấu hạn định giao dịch con hiện tại bằng một dấu mới là duy nhất trong phạm vi của người trung gian này. Tất cả các giao dịch con của một giao dịch ILL cụ thể được phân biệt trên cơ sở sự kết hợp của id giao dịch và id bên yêu cầu. 7.2 Trạng thái giao thức Các trạng thái giao thức giống hệt như các trạng thái giao dịch ILL được xác định trong định nghĩa dịch vụ ILL. 7.2.1 Trạng thái bên yêu cầu Trạng thái bên yêu cầu là trạng thái xử lý của một giao dịch ILL ở bên yêu cầu. Nó có thể là một trong những trường hợp sau: NH À N R Ỗ I Giao dịch ILL chưa bắt đầu. ĐANG CHỜ Đã thực hiện một yêu cầu và đợi tài liệu từ bên đáp ứng; hoặc đã nhận một thông báo cho biết tài liệu sẽ được cung cấp hoặc đã được đặt giữ; hoặc cho biết yêu cầu đã được chuyển tiếp đến c ơ quan khác. KHÔNG CUNG C Ấ P Giao dịch ILL đã đạt đến một giai đoạn mà yêu cầu không thể được thực hiện bởi người đáp ứng. Đ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 Tài liệu đã được nhận từ bên đáp ứng 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 Tài liệu đã bị bên đáp ứng đòi lạ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Ý Bên đáp ứng đã nhận được và đang xử lý yêu cầu; tài liệu chưa được gửi đi. 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 Giao dịch ILL đã bị 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. GIA HẠN/ĐANG CHỜ Một yêu cầu đã được thực hiện để gia hạn tài liệu. GIA HẠN/QUÁ HẠN Một yêu cầu đã được thực hiện để gia hạn cho tài liệu qu á hạn. QUÁ HẠN Bên đáp ứng đã thông báo cho bên yêu cầu về tài liệu quá hạn. ĐÒI Tài liệu đã bị đòi lại bởi bên đáp ứng. 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 g i an chuyển phát. Đối với các tài liệu không được trả lại, khoảng thời gian này phải đủ để bên yêu cầu xác định được tài liệu yêu cầu và khởi tạo một dịch vụ truy vấn-trạng thái hoặc Mất. Các trạng thái thiết bị đầu cuối có thể cho bên yêu cầu là : - KHÔNG-CUNG C Ấ P; - ĐÃ HỦY; - ĐÃ NHẬN (nếu nhận được một tài liệu không phải trả lại); - Đ Ã TRẢ; - M Ấ T Các trạng thái thiết bị đầu cuối có thể cho bên đáp ứng là: - KHÔNG-CUNG CẤP; - ĐÃ HỦY; - CHUYỂN TIẾP; - ĐÃ CHUYỂN ĐI (nếu một tài liệu không trả phải được chuyển đi); - ĐÃ KIỂM NHẬN; - MẤT Trạng thái thiết bị đầu cuối cho một giao dịch ILL cụ thể sẽ phụ thuộc vào các trường hợp giao dịch của nó. V í dụ, khi một bản sao được cung cấp, ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho bên đáp ứng, trong khi NHẬN là trạng thái thiết bị đầu cuối cho bên yêu cầu. Các trạng thái thiết bị đầu cuối có thể cho người trung gian là: - KHÔNG-CUNG CẤP; - CHUYỂN TIẾP; - ĐÃ HỦY ĐÃ CHUYỂN ĐI 7.2.4 Trạng thái ngườ i trung gian Người trung gian tham gia vào một giao dịch ILL theo chuỗi hoặc phân khu đ ó ng c ả hai vai trò vừa là bên đáp ứng (trong các tương tác với bên yêu cầu) và vừa là bên yêu cầu (trong các tương tác với bên đáp ứng). Người trung gian duy trì thông tin trạng thái riêng biệt cho mỗi một bộ các tương tác này. Đối với các giao dịch con không thành công, các trạng thái thiết bị đầu cuối cho bên yêu cầu trung gian là KHÔNG-CUNG CẤP và HỦY; cho bên đáp ứng trung gian là KHÔNG-CUNG CẤP, HỦY; CHUYỂN TIẾP. Đối với một giao dịch ILL thành công, trạng thái thiết bị đầu cuối cho một người trung gian trong cả hai vai trò của bên yêu cầu và bên đáp ứng là trạng thái ĐÃ CHUYỂN. 7.3 Các biến giao thức Các biến giao thức sau đây ảnh hưởng đến trạng thái giao thức ILL . Các biến này được d u y trì bởi các ILLPM và được đặt theo các thông số của các dịch vụ ban đầu hoặc nhận các APDU. Người trung gian duy trì các biến giao thức riêng thích hợp phân ra cho từng vai trò của bên yêu cầu và bên đáp ứng. TRẢ (RETURN) sử dụng để chỉ ra một tài liệu đã vận chuyển phải được trả lại cho bên đáp ứng. Nó nhận các giá trị TRUE (ĐÚNG) hoặc FALSE (SAI) CHUYỂN TIẾP (FWD) sử dụng đ ể thông báo bên đáp ứng có thể chuyển tiếp một yêu cầu hay không. Thông báo nhận TRUE (ĐÚNG) hoặc FALSE (SAI) PHÂN KHU (PART) được sử dụng bởi một người trung gian để chỉ ra một giao dịch ILL có thể được hoặc đã được phân khu. Biến này nhận các giá trị TRUE (Đ Ú NG) hoặc FALSE (SAI ) CHU Ỗ I (CHAIN) được sử dụng bởi một người trung gian để cho biết một giao dịch ILL có thể được hoặc đã được thực hiện theo chuỗi. Chuỗi nhận các giá trị TRUE (ĐÚNG) hoặc FALSE (SAI) DẤ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 Bộ đếm thời gian sau đây phải được duy trì bởi bên đáp ứng nếu nó hỗ trợ dịch vụ HẾT HẠN: H ế t HẠN xác định ngày hết hạn giao dịch ILL. Thông tin này được cung cấp bởi bên yêu cầu trong Yêu cầu ILL. 7.5 Thông tin yêu cầu Toàn bộ nội dung của Y Ê U C Ầ U- ILL ban đầu phải được lưu giữ để hỗ trợ chuyển tiếp, phân khu và tổ chức xâu chuỗi giao dịch ILL . Tuy nhiên người trung gian có thể thay đổi nội dung của một Yêu cầu ILL khi yêu cầu được chuyển tiếp hoặc một giao dịch con được khởi xướng. Ví dụ, có thể sửa thông tin thư mục được cung cấp, hoặc có thể thay đổi C ho phép tổ chức chuỗi thành SAI trong một giao dịch con khi giá trị của YÊU CẦU ILL ban đầu là ĐÚNG. Người trung gian phải luôn thay đổi giá trị id bên yêu cầu thành id riêng của m ì nh khi một giao dịch con được khởi xướng. Lưu ý rằng danh tính của bên yêu cầu ban đầu được lưu giữ trong id giao dịch. 7.5.1 ID hệ thống Thông tin Yêu cầu ILL bao gồm việc nhận dạng bên yêu cầu và bên đáp ứng, cả hai đều là loại id hệ thống, trong đó bao gồm một hoặc nhiều các thành phần sau: Biểu tượng cá nhân hoặc tổ chức một hoặc nhiều số, chữ cái hoặc mã dùng để xác định một cách rõ ràng bên đáp ứng, trong một định dạng viết tắt một cá nhân hoặc tổ chức tham gia vào một yêu cầu ILL. Tên cá nhân hoặc tổ chức 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ày tháng của dịch vụ gần đây nhất; - Người khởi tạo dịch vụ gần đây nhất - Loại dịch vụ vận chuyển; - Kết quả giao dịch; - Chú thích dịch vụ gần đây nhất. "Dịch vụ gần đây nhất" chỉ dịch vụ gốc ILL nào đã được gọi lần cuối cùng hay APDU (dấu hiệu) cuối cùng nhận được bởi người sử dụng dịch vụ ILL này. Các dấu hiệu dịch vụ không hợp lệ/ ngoài luồng phải được xem là dấu hiệu dịch vụ hợp lệ cho mục đích của thành phần "dịch vụ gần đây nhất" của báo cáo lịch sử. Một ngoại lệ là khi một B Á O CÁO T Ì NH TRẠNG hoặc L Ỗ I được gửi để đáp ứng một Yêu cầu trạng thái, trong trường hợp này "dịch vụ gần đây nhất " là một dịch vụ trước YÊU CẦU TRẠNG THÁI. "Ngày tháng của Dịch vụ gần đây nhất" cho biết ngày tháng của "dịch vụ gần đây nhất" "Người khởi xướng dịch vụ gần đây nhất" xác định bên yêu cầu hoặc bên đáp ứng khởi xướng dịch vụ gần đây nhất. " Loại dịch vụ chuyển đi " phải phản ánh các thông tin mới nhất trong tham số " loại dịch vụ chuyển đi " từ dịch vụ ĐÃ CHUYỂN hoặc ĐÃ NHẬN hoặc từ APDU ĐÃ CHUYỂN hoặc Đ Ã NHẬN, ví dụ nếu bên yêu cầu đã nhận được một APDU ĐÃ CHUYỂN và sau đó thực hiện một yêu cầu ĐÃ NHẬN, thì lúc này, cần sử dụng giá trị trong yêu cầu ĐÃ NHẬN. Thông tin này có thể không có sẵn cho tất cả các giao dịch ILL. "Các kết quả giao dịch " cần phản ánh giá trị của tham số " kết quả giao dịch " chứa trong Trả lời ILL. Thông tin này có thể không có sẵn cho tất cả các giao dịch ILL. " Chú thích dịch vụ gần đây nhất " cung cấp nội dung của các tham số Chú thích từ dịch vụ gốc gần đây nhất. Nếu thông tin trạng thái được yêu cầu cho một giao dịch ILL đã kết thúc, thông tin lịch sử không thể được cung cấp. 8 Các yếu tố của thủ tục 8.1 Sự kiện và hành động Khoản này mô tả các sự kiện và hành động cho một giao dịch ILL đơn lẻ. Bên yêu cầu, bên đáp ứng và người trung gian phải phản ứng với các sự kiện khác nhau bằng việc thực hiện nh ữ ng hành động cụ thể. Một sự kiện được định nghĩa là việc nhận một APDU từ một ASE ILL hoặc nhận một dịch vụ gốc từ người sử dụng dịch vụ ILL cục bộ. Một hành động có thể dưới hình thức đưa ra một dịch vụ gốc cho người sử dụng dịch vụ ILL cục bộ, hoặc truyền tải một hoặc nhiều APDU cho một ASE ILL ở xa. Các mục sau đây xác định các sự kiện và hành động được phép đối với bên yêu cầu, bên đáp ứng và người trung gian và những gì có thể được hiểu ngầm là không được phép. 8.1.1 Sự kiệ n của bên yêu cầu Khoản này mô tả các sự kiện được phép đối với một bên yêu cầu. Các sự kiện liên quan đến yêu cầu dịch vụ gốc từ người sử dụng dịch vụ ILL sau đây: - YÊU C Ầ U-ILL . yêu cầu - TRẢ LỜI-CÓ ĐIỀU KIỆN: yêu cầu Trả lời = CÓ - TRẢ LỜI-CÓ ĐIỀU KIỆN: yêu cầu Trả lời = KHÔNG - HỦY-YÊU CẦU - ĐÃ NHẬN . yêu cầu - ĐÃ TRẢ. yêu cầu - GIA HẠN. yêu cầu - HỦY. yêu cầu - HƯ HẠI. yêu cầu - THÔNG BÁO. yêu cầu - YÊU CẦU TRẠNG THÁI . yêu cầu - BÁO CÁO TRẠNG THÁI HOẶC LỖI. yêu cầu Các sự kiện liên quan đến các APDU ILL nhận được ASE ILL từ xa sau đây: - THÔNG BÁO CHUYỂN TIẾP - ĐÃ CHUYỂN ĐI - CÂU TRẢ LỜI- ILL Kết quả yêu cầu = ĐIỀU KIỆN - CÂU TRẢ LỜI- ILL: Kết quả yêu cầu = LÀM LẠI - CÂU TRẢ LỜI- ILL: Kết quả yêu cầu = KHÔNG THỰC HIỆN - CÂU TRẢ LỜI- ILL: Kết quả yêu cầu = Đ Ị A ĐIỂM - CUNG CẤP - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = SẼ CUNG CẤP - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = ĐẶT - GIỮ - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = D Ự TÍNH - TRẢ LỜI -HỦY - ĐÒI - KIỂM NHẬN - QUÁ HẠN - TRẢ LỜI GIA HẠN: Câu trả lời = CÓ - TRẢ LỜI GIA HẠN: Câu trả lời = KHÔNG - MẤT - H Ư HẠI - THÔNG BÁO - HỎI TRẠNG THÁI - BÁO C Á O TRẠNG THÁI HOẶC LỖI - HẾT HẠN. 8.1.2 Hành động của bên yêu cầu Các dịch vụ ban đầu sau đây có thể được cấp cho người sử dụng dịch vụ ILL: - THÔNG BÁO CHUYỂN TIẾP . chỉ thị - V Ậ N CHUYỂN . chỉ thị - CÂU TRẢ LỜI ILL . chỉ thị Kết quả yêu cầu = CÓ ĐIỀU KIỆN - C Â U TRẢ LỜI ILL. chỉ thị Kết quả yêu cầu = LÀM LẠI - CÂU TRẢ LỜI ILL. chỉ thị Kết quả yêu cầu = ĐỊA ĐIỂM ĐƯ Ợ C CUNG CẤP - CÂU TRẢ LỜI ILL .Chỉ thị Kết quả yêu cầu = SẼ CUNG CẤP - CÂU TRẢ LỜI ILL. chỉ thị Kết quả yêu cầu = ĐẶT GIỮ - CÂU TRẢ LỜI ILL. chỉ thị Kết quả yêu cầu = DỰ TÍNH - CÂU TRẢ LỜI HỦY. chỉ thị - ĐÒI. chỉ thị - KIỂM NHẬN. chỉ thị - CÂU TRẢ LỜI GIA HẠN - QUÁ HẠN. chỉ thị - Câu trả lời Gia hạn. chỉ thị Câu trả lời = CÓ - CÂU TRẢ LỜI GIA HẠN. chỉ thị Câu trả lời = KHÔNG - MẤT. chỉ thị - H Ư HẠI. chỉ thị - THÔNG B Á O. chỉ thị - YÊU CẦU TRẠNG THÁI. chỉ thị - BÁO CÁO TRẠNG THÁI HOẶC LỖI. chỉ thị - HẾT HẠN. chỉ thị Các APDU ILL sau đây có thể được gửi đến ASE ILL ở xa: - Yêu cầu ILL - TRẢ LỜI CÓ ĐI Ề U KIỆN Câu trả lời=Có - TRẢ LỜI CÓ ĐI Ề U KIỆN Câu trả lờ i= Không - Hủy - Đ Ã NHẬN- Đây là hành động tùy chọn - ĐÃ TRẢ- Đây là hành động tùy chọn - GIA HẠN - MẤT - HƯ HẠI - THÔNG BÁO - YÊU CẦU TRẠNG THÁI - BÁO CÁO- TRẠNG THÁI HOẶC- LỖI 8.1.3 Sự kiện của bên đáp ứng Điều này mô tả các sự kiện cho phép đối với một người đáp ứng. Các sự kiện liên quan đến yêu cầu dịch vụ ban đầu từ người sử dụng dịch vụ ILL như sau: - CHUYỂN TIẾP. yêu cầu - CHUYỂN ĐI. yêu cầu - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = CÓ ĐIỀU KIỆN - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = LÀM LẠI - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = KHÔNG THỰC HIỆN - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = CUNG CẤP ĐỊA ĐIỂM - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = SẼ CUNG CẤP - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = ĐẶT GIỮ - CÂU TRẢ LỜI ILL.yêu cầu: Kết quả Yêu cầu = D Ự T Í NH - TRẢ LỜI HỦY.yêu cầu - ĐÒI.yêu cầu - KIỂM NHẬN.yêu cầu - QUÁ HẠN.yêu cầu - CÂU TRẢ LỜI GIA HẠN.yêu cầu: Câu trả lời = CÓ - CÂU TRẢ LỜI GIA HẠN.yêu cầu: Câu trả lời = KHÔNG - M Ấ T.yêu cầu - HƯ HẠI.yêu cầu - TH Ô NG BÁO.yêu cầu - CÂU HỎI TRẠNG THÁI.yêu cầu - BÁO CÁO TRẠNG THÁI HOẶC LỖI.yêu cầu Các sự kiện liên quan đến các APDU ILL nhận được từ ASE ILL ở xa như sau: - YÊU CẦU ILL - TRẢ LỜI ĐIỀU KIỆN: Câu trả lời = CÓ - TRẢ LỜ I Đ IỀ U KIỆN: Câu trả lời = KHÔNG - HỦY - ĐÃ NHẬN - ĐÃ TRẢ - GIA HẠN - MẤT - HƯ HẠI - THÔNG BÁO - HỎI TRẠNG THÁI - BÁO CÁO TRẠNG TH Á I HOẶC LỖI. - Những sự kiện cục bộ sau đây có thể xảy ra trong nội bộ nhà cung cấp dịch vụ ILL - H Ế T THỜI HẠN 8.1.4 Hành động của bên đáp ứng Các dịch vụ ban đầu ILL sau đây có thể được đưa ra cho người sử dụng dịch vụ ILL: - YÊU C Ầ U ILL . chỉ thị - Đ Á P ỨNG CÓ ĐIỀU KIỆN.chỉ thị: Câu trả lời = CÓ - ĐÁP ỨNG CÓ ĐIỀU KIỆN.chỉ thị: Câu trả lời = KHÔNG - HỦY.chỉ thị - ĐÃ NHẬN.chỉ thị - ĐÃ TRẢ.chỉ thị -GIA HẠN.chỉ thị - MẤT.chỉ thị - HƯ HẠI.chỉ thị - THÔNG BÁO.chỉ thị - HỎI TRẠNG THÁI.chỉ thị - BÁO C Á O TRẠNG THÁI HOẶC L ỖI .chỉ thị - HẾT HẠN.chỉ thị Các APDU ILL sau đây có thể được gửi đến ASE ILL ở xa: - YÊU CẦU ILL - ĐÃ CHUYỂN ĐI-APDU này là tùy chọn - THÔNG BÁO CHUY Ể N TIẾP - CÂY TRẢ LỜI ILL: Kết quả yêu cầu = ĐIỀU KIỆN - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = LÀM LẠI - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = KHÔNG THỰC HIỆN ĐƯỢC - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = CUNG CẤP ĐỊA ĐIỂM - CÂU TRẢ LỜI ILL: Kết qu ả yêu cầu = SẼ CUNG CẤP - CÂU TRẢ LỜI ILL: Kết quả yêu cầu = ĐẶT GIỮ - CÂU TRẢ LỜI ILL: Kết qu ả yêu cầu = DỰ TÍNH - TRẢ LỜI HỦY - ĐÒI - KIỂM NHẬN - Hoạt động này là tùy chọn - QUÁ HẠN - CÂU TRẢ LỜI GIA HẠN: Câu trả lời = CÓ - CÂU TRẢ LỜI GIA HẠN: Câu trả lời = KHÔNG - M Ấ T - HƯ HẠI - THÔNG BÁO - CÂU HỎI TRẠNG THÁI - BÁO CÁO TRẠNG THÁI HOẶC LỖI - HẾT HẠN 8.1.5 Sự kiện và hành động của người trung gian Điều này mô tả các sự kiện cho phép đối với một người trung gian. Người trung gian tham gia vào một giao dịch ILL theo chuỗi hoặc phân khu đóng cả hai vai trò của bên yêu cầu và bên đáp ứng . Trong vai trò của bên yêu cầu, các sự kiện và hoạt động của người trung gian cũng giống như đối với bên yêu cầu, mặc dù các trạng thái có thể khác nhau. Trong vai trò của bên đáp ứng, các sự kiện và hoạt động của người trung gian cũng giống như đối với bên đáp ứng, mặc dù các trạng thái có thể khác nhau. Khác biệt là bắt buộc phải có APDU ĐÃ CHUYỂN. 8.2 Quy định thủ tục cho tất cả các bên 8.2.1 Gửi và nhận APDU Trừ ngoại lệ với dịch vụ CHUYỂN TIẾP, mỗi dịch vụ ban đầu yêu cầu tạo ra việc chuẩn bị và truyền tải các APDU có tên tương ứng. Trong trường hợp Yêu cầu Chuyển tiếp, hai APDU được chuẩn bị: một APDU YÊU CẦU- ILL được gửi tới bên đáp ứng mới, trong khi một APDU THÔNG BÁO-CHUYỂN TIẾP được gửi cho bên yêu cầu. Việc nhận một APDU hợp lệ dẫn đến một dịch vụ ban đầu chỉ th ị tương ứng. Các APDU được chuẩn bị và chỉ gửi theo yêu cầu rõ ràng của người sử dụng dịch vụ ILL, với ngoại lệ của APDU HẾT HẠN được gửi bởi hệ thống của bên đáp ứng trong trường hợp hết hạn bộ đếm thời gian. 8.2.2 Các giai đoạn giao dịch Một giao dịch ILL có thể có hai giai đoạn: xử lý và theo dõi. Giai đoạn xử lý là bắt buộc đối với tất cả các giao dịch ILL trong khi giai đoạn theo dõi chỉ áp dụng cho giao dịch ILL khi một tài liệu có trả lại, ví dụ một chuyên khảo, được cung cấp. Giai đoạn xử lý cho bên yêu cầu bao gồm tất cả các sự kiện và hành động đến khi và bao gồm cả việc tiếp nhận các tài liệu yêu cầu. Giai đoạn này thường kết thúc ở trạng thái NHẬN Giai đoạn xử lý cho bên đáp ứng bao gồm tất cả các sự kiện và hành động đến và bao gồm cả việc c huyển đi tài liệu yêu cầu. Giai đoạn này thường kết thúc ở trạng thái ĐÃ CHUYỂN ĐI. Đối với bên yêu cầu trung gian, giai đoạn xử lý bao gồm tất cả các sự kiện và hành động cho đến khi nhận chỉ thị ĐÃ CHUYỂN ĐI, bao gồm cả việc chuyển đi; với bên đáp ứng trung gian giai đoạn xử lý bao gồm tất cả các sự kiện đến khi yêu cầu ĐÃ CHUYỂN, bao gồm cả việc đã chuyển đi. Đối với cả bên yêu cầu và bên đáp ứng trung gian, các giai đoạn xử lý thường chấm dứt ở trạng thái ĐÃ CHUYỂN ĐI. Giai đoạn theo dõi bao gồm tất cả các sự kiện và hành động sau khi đã chuyển và nhận một tài liệu phải trả lại, kể cả gia hạn, quá hạn và trả tài liệu. Sự tồn tại của giai đoạn theo dõi với một giao dịch ILL được chỉ định bởi biến giao thức TRẢ LẠI. Giá trị ĐÚNG chỉ ra rằng giai đoạn theo dõi được áp dụng và phải có các thủ tục liên quan kèm theo. Giá trị SAI chỉ ra rằng giai đoạn theo dõi không cần thiết và các sự kiện tương ứng không được phép. Không có giai đoạn theo dõi cho các giao dịch ILL liên quan đến các tài liệu không trả lại, ví dụ bản sao chụp. Bên đáp ứng đặt biến TRẢ LẠI khi sự kiện phát sinh là ĐÃ NHẬN yêu cầu. Nếu phần tử dữ liệu Loại - dịch vụ - chuyển là MƯỢN, th ì đặt ĐÚNG cho biến TRẢ LẠI; nếu phần tử dữ liệu Loại -dịch vụ - chuyển đi là SAO CHỤP/KHÔNG TR Ả LẠI thì đặt SAI cho biến TRẢ LẠI. Bên yêu cầu đặt biến Trả khi k í ch hoạt sự kiện là ĐÃ NHẬN yêu cầu. Nếu các phần t ử dữ liệu Loại - dịch vụ - vận chuyển là MƯỢN, khi đó TRẢ được đặt là ĐÚNG, nếu các phần t ử dữ liệu Loại dịch vụ chuyển đi là SAO CHỤP/KHÔNG TRẢ LẠI, khi đó TRẢ LẠI được đặt là SAI. 8.2.3 Thông báo tùy chọn 8.2.3.1 Giao dịch đơn giản Đối với một giao dịch ILL đơn giản, bốn trong số những hành động Giao thức ILL là không bắt buộc: - Gửi APDU ĐÃ CHUYỂN; - Gửi APDU ĐÃ NHẬN; - Gửi APDU ĐÃ TRẢ; - Gửi APDU ĐÃ KIỂM NHẬN . Một yêu cầu thực thể ứng dụng có thể gửi các APDU tùy chọn bất cứ khi nào nó muốn, ngoài ra có nhiệm vụ gửi chúng trong những t ì nh huống nhất định. Người khởi xướng một giao dịch ILL có thể thông báo cho bên đáp ứng có thể cung cấp những gì và yêu cầu là g ì thông qua các thông báo tùy chọn bên trong yêu cầu ILL. Yêu cầu ILL có thể xác định như sau: a) bên yêu cầu có khả năng gửi ĐÃ NHẬN hay không; b) bên yêu cầu có khả năng gửi ĐÃ TRẢ hay không; c) bên yêu cầu có yêu cầu ĐÃ CHUYỂN hay không; d) bên yêu cầu có yêu cầu KIỂM NHẬN hay không e) bên yêu cầu có muốn ĐÃ CHUYỂN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn c) ở trên là KHÔNG f) bên yêu cầu có muốn ĐÃ KIỂM NHẬN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn d) ở trên là KHÔNG Tương ứng, TRẢ LỜI ILL và ĐÃ CHUYỂN có thể được xác định như sau: a) bên đáp ứng có khả năng gửi ĐÃ CHUYỂN hay không; b) bên đáp ứng có khả năng gửi KIỂM NHẬN hay không; c) bên đáp ứng có yêu cầu ĐÃ NH Ậ N hay không; d) bên đáp ứng c ó yêu cầu ĐÃ TRẢ hay không e) bên đáp ứng có muốn ĐÃ NHẬN hay không; lựa chọn này chỉ có ý nghĩa nếu chọn c) ở trên là KHÔNG ; f) bên đáp ứng có muốn TRẢ hay không; lựa chọn này chỉ có ý nghĩa nếu chọn d) ở trên là KHÔNG . Khi bên đáp ứng nhận YÊU CẦU ILL chỉ ra rằng a) bên yêu cầu đ ó không thể gửi thông báo theo yêu cầu của bên đáp ứng, hoặc b) bên yêu cầu đó cần thông báo rằng bên đáp ứng không thể gửi, Khi đó bên đáp ứng có thể gửi một thông báo KHÔNG-HOÀN-THÀNH-CÂU-TRẢ-LỜI-ILL . Nếu bên đáp ứng vẫn chọn cung cấp tài liệu yêu cầu, tức là bên đáp ứng đã hiểu rằng các thông báo ĐÃ NHẬN và ĐÃ TRẢ sẽ không được gửi đi. Trong tất cả các trường hợp không cần thiết thông báo, có thể gửi hoặc không gửi thông báo dù có mong muốn thông báo hay không. Nhận một APDU tùy chọn không được yêu cầu không phải một lỗi giao thức thức và không gây ra một thay đổi trạng thái, trừ APDU ĐÃ CHUYỂN. 8.2.3.2 Giao dịch theo chuỗi và phân khu Đối với các giao dịch ILL xâu chuỗi và phân khu, APDU ĐÃ CHUYỂN là bắt buộc, cả giữa bên đáp ứng và người trung gian và giữa người trung gian và bên yêu cầu. Các APDU NHẬN, TRẢ và KIỂM NHẬN là tùy chọn. Tuy nhiên, người trung gian, khi hành động như một bên yêu cầu, phải có khả năng tạo ra NHẬN và/hoặc TRẢ nếu có yêu cầu của bên đáp ứng, và khi hoạt động như bên đáp ứng, phải có khả năng tạo ra KIỂM NHẬN nếu có yêu cầu của bên yêu cầu. 8.2 Danh sách gửi đến "Danh sách gửi đến" xác định điểm đến tiềm năng cho chuyển tiếp, theo chuỗi và phân khu. Mỗi mục trong danh sách quy định một id bên đáp ứng cụ thể, một số tài khoản tùy chọn và một địa chỉ hệ thống. Người kh ởi xướng giao dịch ILL luôn có thể cung cấp cho các mục trong danh sách này, có thể không bao giờ điền vào nó, hoặc có thể dựa vào người trung gian để bổ sung các mục. Giao thức này không giới hạn số lượng các mục trong Danh sách gửi đến, cũng không cấm các mục lặp lại, với điều kiện là các mục lặp lại như vậy không thể được sử dụng khi chuyển tiếp (xem 8.2.5). Người trung gian có thể thay đổi danh sách này giá trị "Cho phép thay đổi danh sách gửi đến" là ĐÚNG. Những hình thức thay đổi danh sách này có thể là bổ sung hoặc xóa. Việc giải thích danh sách này được điều c h ỉ nh bởi loại "Ưu tiên". Giá trị "Trình tự" cho biết thứ tự ưu tiên cho việc chuyển tiếp, v . v, được quy định trong "danh sách gửi đến". Những thay đổi với danh sách, khi được phép, chỉ có thể bằng hình thức thêm vào cuối danh sách. Giá trị "Không có trình tự" cho biết rằng bất kỳ thành viên nào của danh sách có thể được lựa chọn mà không ưu tiên. Những thay đổi với danh sách, khi được phép, có thể ở mọi hình thức. 8.2.5 Danh sách đã thử Danh sách này xác định các tổ chức đã được gửi yêu cầu ILL. Các địa điểm này phải được loại trừ khỏi bất kỳ chuyển tiếp tiếp theo, tức là không cho phép cho một bên đáp ứng đã chuyển tiếp một yêu cầu ILL nhận một yêu cầu ILL tiếp theo với cùng một id giao dịch. Danh sách này không áp đặt các ràng buộc khác về xử lý giao dịch ILL. Danh sách này được cập nhật với id hệ thống của bên đáp ứng bất cứ khi nào một yêu cầu ILL được chuyển tiếp, hoặc một giao dịch con cho một ILL giao dịch theo chuỗi hoặc hoặc phân khu được khởi tạo. Trong YÊU CẦU ILL ban đầu dữ liệu có thể được chứa trong Danh sách đã thử. Bất kỳ sự bổ sung vào danh sách phải được đặt ở cuối danh sách. 8.2.6 Kiểm soát gia hạn Các APDU CHUYỂN ĐI, QUÁ HẠN VÀ CÂU TRẢ LỜI GIA HẠN với cùng một id giao dịch sẽ cho biết một tài liệu mượn có thể được gia hạn hay không. Thông tin này được cung cấp cho bên yêu cầu, người được dự kiến sẽ không khởi xướng một Yêu cầu gia hạn trừ khi tài liệu này có thể được gia hạn. Không phải là lỗi nếu một yêu cầu GIA HẠN được thực hiện khi tài liệu không thể gia hạn. 8.2.7 Xác nhận trình tự APDU Ngoại trừ các APDU THÔNG BÁO, HỎI TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và HƯ HẠI người nhận xác nhận tất cả các APDU nhận được với cùng id giao dịch và từ cùng một người khởi tạo với trình tự chính xác, dựa trên giá trị của loại "Ngày và thời gian của dịch vụ" trong mỗi APDU. Giá trị của tham số "Ngày và thời gian dịch vụ" phải phân biệt cho từng yêu cầu dịch vụ được thực hiện bởi cùng một bên (bên yêu cầu, bên đáp ứng hoặc người trung gian) cho một giao dịch cụ thể. Giá trị này được so sánh với giá trị của các biến giao thức DẤU THỜI GIAN TUẦN TỰ. Nếu DẤU THỜI GIAN TUẦN TỰ có giá trị bằng hoặc lớn hơn giá trị trong APDU nhận được, APDU nhận được không gây ra thay đổi trạng thái, DẤU THỜI GIAN TUẦN TỰ không được cập nhật, và chỉ thị dịch vụ ban đầu được đưa ra cho người sử dụng. Không thực hiện kiểm tra đối với APDU lặp lại (xem 8.2.8). Nếu DẤU THỜI GIAN TUẦN TỰ có giá trị thấp hơn giá trị của loại "Ngày và thời gian của dịch vụ" trong APDU nhận, APDU được chấp nhận, sự thay đổi trạng thái được thực hiện nếu thích hợp và DẤU THỜI GIAN TUẦN TỰ được cập nhật. Việc xác nhận trình tự được thực hiện sau khi xác nhận hệ thống và trước các xử lý khác bởi người nhận ILLPM. Việc xác nhận trình tự được thực hiện chỉ cho các APDU từ cùng một người khởi tạo. Đối với bên yêu cầu, và bên yêu cầu trung gian, điều này được xác định bằng cách so sánh các biến giao thức ID ĐỐI TÁC HIỆN TẠI với một trường trong một số hoặc tất cả các APDU được nhận. Trong một giao dịch đơn giản, so sánh được thực hiện với trường id bên đáp ứng trong đó mỗi APDU nhận được, ngoại trừ trường hợp của APDU THÔNG BÁO CHUYỂN TIẾP nơi so sánh thực hiện với trường id người trung gian. Trong một giao dịch theo chuỗi hoặc phân khu, việc so sánh thực hiện với trường "id người trung gian" bất kỳ THÔNG BÁO CHUYỂN TIẾP hoặc ĐÃ CHUYỂN nào nhận được. Biến giao thức ID ĐỐI TÁC HIỆN TẠI được lấy giá trị ban đầu như mô tả trong 7.3. Khi một APDU đến từ một bên đáp ứng khác, ví dụ như chỉ thị ĐÃ CHUYỂN đi từ một tổ chức đã được chuyển tiếp một yêu cầu ILL, khi đó không thực hiện kiểm tra trình tự và biến giao thức ID ĐỐI TÁC TRƯỚC ĐÓ được kiểm tra để xác định xem có các APDU đến từ một bên đã tham gia vào giao dịch ILL không. Nếu APD U nhận được là từ một bên đáp ứng mới, khi đó a) APDU nhận được được xử lý như một thông báo trong trình tự và được xử lý phù hợp, b) biến giao thức DẤU THỜI GIAN TUẦN TỰ được đặt để khai báo dấu thời gian của APDU nhận được, và c) giá trị ID ĐỐI TÁC HIỆN TẠI được thêm vào các ID ĐỐI TÁC TRƯỚC ĐÓ và được cập nhật để phản ánh giá trị của id bên đáp ứng trong APDU nhận được. Nếu bên đáp ứng là một người trước đó, th ì APDU nhận được xử lý theo cùng một cách như một chuỗi không tuần tự và DẤU THỜI GIAN TUẦN TỰ, ID ĐỐI TÁC HIỆN TẠI và các ID ĐỐI TÁC TRƯỚC Đ Ó không được cập nhật. Nếu bên yêu cầu là một người trước đó, thì APDU nhận được xử lý theo cùng một cách như một chuỗi không tuần tự và DẤU THỜI GIAN TUẦN T Ự , ID ĐỐI TÁC HIỆN TẠI và các ID ĐỐI TÁC TRƯỚC ĐÓ không được cập nhật. Lưu ý rằng, với ngoại lệ trình tự (Yêu cầu ILL, Hủy), giao thức ILL linh hoạt với tất cả các kết hợp không tuần tự, theo nghĩa là APDU không tuần tự thứ hai trong chuỗi sẽ được chấp nhận bởi giao thức ngay cả khi nó được nhận đầu tiên. Điều này cần tránh đối với các quy tắc đặc biệt cho từng tình huống có thể, miễn là APDU thứ hai nhận được không bao giờ gây ra một thay đổi trạng thái. 8.2.8 APDU được lặp Có thể lặp lại một yêu cầu dịch vụ cụ thể một hoặc nhiều lần mà không gây ra lỗi giao thức. Ví dụ về các tình huống mà một yêu cầu dịch vụ có thể cần lặp bao gồm: - Yêu cầu QUÁ HẠN khi nhiều thông báo quá hạn được gửi trước khi hành động được thực hiện ; - YÊU CẦU- ILL, HỦY, GIA HẠN, hoặc ĐIỀU KIỆN khi không nhận được câu trả lời cho yêu cầu trước đ ó : - YÊU CẦU- ILL hoặc bất kỳ yêu cầu khác, khi một vấn đề được phát hiện với các dịch vụ truyền thông tin cơ bản mà có thể c ả n trở việc cung cấp APDU tương ứng. Chỉ có yêu cầu dịch vụ gần đây nhất gây ra một thay đổi trạng thái trong hệ thống xuất phát có thể được lặp. Các yêu cầu dịch vụ mà không bao giờ g â y ra một thay đổi trạng thái, nghĩa là THÔNG BÁO, H Ỏ I TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và HƯ HẠI không được lặp; mỗi yêu cầu dịch vụ là một yêu cầu mới. Nếu một CÂU TRẢ LỜI- ILL (CÓ ĐIỀU KIỆN) được theo sau TRẢ LỜI- ĐIỀU KIỆN (CÓ) , bên đáp ứng có thể gửi một TRẢ LỜI- ILL (CÓ ĐIỀU KIỆN) khác, với điều kiện bổ sung. Điều này không được coi là một yêu cầu dịch vụ lặp. Một yêu cầu dịch vụ lặp được xác định bằng cách cung cấp một giá trị cho kiểu "Ngày và thời gian của dịch vụ ban đầu" khi yêu cầu lặp được thực hiện. Ngày và thời gian này là của yêu cầu ban đầu đang được lặp. Khi yêu cầu dịch vụ được lặp, chỉ có các tham biến "ngày và thời gian dịch vụ" và "chú thích" có thể có các giá trị khác nhau. Không có thay đổi trạng thái được thực hiện trong hệ thống mà việc lặp lại yêu cầu được khởi xướng. Người nhận APDU lặp gi ả i quyết nó khác nhau tùy theo APDU lặp ban đầu hoặc trước đó đã được nhận hay chưa. Nếu chưa nhận APDU trước đó, nghĩa là các giá trị "Ngày-giờ-của-dịch-vụ-ban-đầu" khác với DẤU-THỜI-GIAN-LẶP-LẠI, thì APDU được xử lý như là yêu cầu ban đầu với chỉ thị dịch vụ và th a y đổi trạng thái tương ứng. Ngoài ra, các DẤU-THỜI-G I AN-L Ặ P-LẠI, được cập nhật để bằng "Ngày và thời gian của dịch vụ ban đầu". Nếu nhận được một APDU trước đó, như được tính bằng "Ngày và thời gian của dịch vụ ban đầu" và "DẤU THỜI GIAN LẶP", khi đó không có thay đổi trạng thái được thực hiện. Tuy nhiên, một chỉ thị dịch vụ gốc được cấp cho người sử dụng dịch vụ bởi v ì khả năng là trường"Chú thích" có thể có thông tin mới . Người nhận một chỉ thị dịch vụ lặp s ẽ lặp lại phân ứng trước đó của mình, nếu có một dịch vụ đã được thực hiện. Cơ chế, theo đó quyết định được thực hiện để lặp lại một yêu cầu dịch vụ nằm ngoài phạm vi của tiêu chuẩn này. Lưu ý rằng Dịch vụ hết hạn không thể lặp bởi vì nó là một dịch vụ nhà cung cấp khởi xướng. 8.2.9 Thực hiện lại Khi một giao dịch ILL hoặc giao dịch con trước đó kết thúc với kết quả giao dịch là THỬ LẠI, KHÔNG HOÀN THÀNH, ĐỊA ĐIỂM CUNG CẤP HOẶC DỰ TÍNH, có thể bắt đầu một giao dịch mới như là việc thử lại rõ ràng vào một ngày sau đó. Khi giao dịch ILL là thử lại của giao dịch lần trước, "Cờ Thử lại " của APDU YÊU CẦU- ILL được đặt là ĐÚNG. Đối với bên yêu cầu khởi tạo, thực hiện lại là một giao dịch mới, và do đó, dấu hạn định giao dịch ILL phải khác với dấu được sử dụng trong yêu cầu ban đầu, nhưng dấu hạn định nhóm giao dịch ILL và dấu hạn định giao dịch ILL phải giống nhau (để cho phép bên đáp ứng hoặc người trung gian liên kết cuộc thực hiện lại này với giao dịch ILL trước đó). Đối với người trung gian, thực hiện lại là một giao dịch con mới, v ì vậy dấu hạn định giao dịch con phải khác với dấu được sử dụng trong yêu cầu ban đầu, nhưng cả dấu hạn định nhóm giao dịch ILL và dấu hạn định giao dịch ILL phải giống nhau (để cho phép bên đáp ứng hoặc người trung gian tiếp theo liên kết cuộc thực hiện này với giao dịch con trước đó). 8.2.10 Hết hạn giao dịch Bên yêu cầu, tại thời điểm YÊU CẦU- ILL, có thể chọn để đặt một giới hạn thời gian về vòng đời của giao dịch ILL. Thời hạn này được chỉ định theo một trong hai cách: a) bằng cách đưa ra một giá trị cho loại "Cần trước ngày" và đặt "C ờ hết hạn" cho biến "C Ầ N TRƯỚC NGÀY" ; hoặc là b) bằng cách cung cấp một giá trị cho loại "Ngày hết hạn" và khai báo "Cờ hết hạn" với "NGÀY THÁNG KHÁC". Nếu một trong hai điều kiện này được đáp ứng, khi đó bộ đếm thời gian "H Ế T HẠN" được đặt với thời hạn sử dụng theo quy định ở bên đáp ứng khi APDU YÊU CẦU- ILL nhận được. Nếu không có thời gian giới hạn được đặt cho Hết hạn giao dịch ILL khi đó "cờ hết hạn" được gán giá trị "KHÔNG- HẾT HẠN". Nếu không có phản hồi nào được đưa ra (dưới hình thức của một câu trả lời ILL hoặc dịch vụ đã chuyển) trước khi giá trị bộ đếm thời gian "HẾT HẠN" bằng thời gian theo lịch hiện tại, bên đáp ứng s ẽ gửi một APDU HẾT HẠN đến bên yêu cầu. Một dịch vụ ban đầu chỉ thị Hết hạn được đưa ra ở cả hai bên bên yêu cầu và bên đáp ứng và giao dịch ILL đi vào trạng thái KHÔNG-CUNG CẤP. CHÚ THÍCH 1 Có hai khả năng để đặt ngày hết hạn cho một giao dịch ILL sẽ cho phép bên yêu cầu linh hoạt trong việc gán hay không gán nghĩa hết hạn cho "cần-trước-ngày". Một ví dụ về việc sử dụng Ngày hết hạn khác với "C ầ n trước ngày" sẽ cho phép một thời gian trả lời ngắn hơn do đó những bên đáp ứng tiềm năng khác có thể được liên hệ trước "Cần trước ngày'. CHÚ THÍCH 2: Trong các trường hợp "Cờ hết hạn" được đặt là "NGÀY KHÁC", nó vẫn còn có thể cung cấp một giá trị cho "Cần trước ngày" nhưng nó không có ý nghĩa hết hạn. CHÚ THÍCH 3: Đây là một cân nhắc thực hiện để chống lạ i khả năng mất một APDU HẾT HẠN, bên yêu cầu cũng có thể duy trì một bộ đếm thời gian hết hạn. Nếu bộ đếm thời gian này phải hết hạn, điều này có thể kích hoạt người sử dụng gửi một Yêu cầu trạng thái đến bên đáp ứng. Hạn sử dụng bộ đếm thời gian của bên yêu cầu không được gây ra hết thời hạn tự động của giao dịch ILL, v ì là bên đáp ứng có thể không thực sự hết thời gian (ví dụ thông báo ĐÃ CHUYỂN có thể đang chuyển đến hoặc có thể đã bị mất). Nếu một yêu cầu CÂU TRẢ LỜI- ILL với kết quả CÓ ĐIỀU KIỆN được đưa ra bởi bên đáp ứng, khi đó bộ đếm thời gian HẾT HẠN được đặt lại giá trị kiểu "Ngày đáp ứng". Nếu bộ đếm thời gian này hết hạn, khi đó các hành động tương tự mô tả ở trên xảy ra. Nếu không có giá trị cho loại này, thời gian HẾT HẠN không có tác động, tức là tắt nếu bị vô hiệu hóa trước đó hoặc giữ nguyên giá trị nếu được đặt trước đó. CHÚ THÍCH "ngày đáp ứng" trong CÂU TRẢ LỜI ILL (CÓ ĐIỀU KIỆN) có thể sớm hơn ngày bên yêu cầu khai báo ban đầu cho Hết hạn. Nếu bên đáp ứng nhận TRẢ LỜI CÓ ĐIỀU KIỆN với câu trả lời CÓ, khi đó bộ đếm thời gian HẾT HẠN được đặt lại giá trị ban đầu của nó. Các sự kiện sau đây ở bên đáp ứng sẽ vô hiệu hóa bộ đếm thời gian HẾT HẠN: - CÂU TRẢ LỜI ILL.yêu cầu có kết quả khác với ĐIỀU KIỆN - ĐÃ CHUYỂN.yêu cầu - CHUYỂN TIẾP.yêu cầu - Nhận APDU HỦY CHÚ THÍCH Nếu CÂU TRẢ LỜI- ILL nhận được c ó kết quả là S Ẽ -CUNG CẤP hoặc ĐẶT- G IỮ. có ngày muộn hơn trong "Cần trước ngày" hoặc "Hết hạn" trên YÊU CẦU ILL ban đầu, thì tùy thuộc b ê n yêu cầu quyết định xem phải chờ đợi hoặc hủy bỏ yêu cầu. 8.2.11 Hủy giao dịch Bên yêu cầu có thể bắt đầu hủy một giao dịch ILL bất cứ lúc nào trong khi ở trạng thái CHỜ Khi bên đáp ứng nhận được chỉ thị HỦY, cần phải trả lời bằng TRẢ LỜI HỦY. yêu cầu, với ngoại lệ sau. Nếu bên đáp ứng đã đưa ra ĐÃ CHUYỂN.yêu cầu, CHUYỂN TIẾP.yêu cầu hoặc TRẢ LỜI- ILL. yêu cầu với kết quả là THỬ LẠI, KHÔNG HOÀN THÀNH, ĐỊA ĐIỂM-CUNG CẤP hoặc DỰ TÍNH hoặc đã nhận được chỉ thị HẾT HẠN, thì chỉ thị HỦY được bỏ qua và không có yêu cầu TRẢ LỜI HỦY được đưa ra. Khi bên đáp ứng đưa ra TRẢ LỜI HỦY.yêu cầu với câu trả lời = CÓ, th ì APDU TRẢ LỜI HỦY được gửi và bên đáp ứng nhập vào đầu cuối trạng thái ĐÃ HỦY. Khi APDU TRẢ L Ờ I - HỦY được nhận, bên yêu cầu đưa ra TRẢ LỜI HỦY. chỉ thị và nhập vào trạng thái thiết bị đầu cuối HỦY. Khi bên đáp ứng đưa ra TRẢ L Ờ I HỦY. yêu cầu với câu trả lời = KHÔNG, thì APDU TRẢ LỜI HỦY được gửi và bên đáp ứng đáp ứng nhập trạng thái ĐANG XỬ LÝ. Khi APDU TRẢ LỜI HỦY được nhận bên yêu cầu đưa ra TRẢ LỜI HỦY. chỉ thị và nhập vào trạng thái ĐANG CHỜ. 8.2.12 Tuổi thọ của thông tin Giao dịch ILL Khoảng thời gian thông tin giao dịch ILL được duy trì bởi hệ thống một khi một giao dịch ILL đạt đến một trạng thái thiết bị đầu cuối là vấn đề cục bộ nằm ngoài phạm vi của tiêu chuẩn này. Quá trình theo đó thông tin này không có sẵn được gọi là đóng giao dịch hoặc loại bỏ giao dịch. Một hệ thống phải đáp ứng tất cả các yêu cầu HỎI TRẠNG THÁI. Nếu giao dịch ILL liên quan không có sẵn, thì BÁO CÁO TRẠNG THÁI HOẶC LỖI sẽ chỉ ra một trong hai lý do sau đây: - " Thông tin không có sẵn - tạm thời" - " Thông tin không có sẵn - vĩnh viễn" Điều kiện đầu tiên được sử dụng để thông báo sự không có sẵn thông tin tạm thời, ví dụ như do một lỗi của hệ thống lưu trữ. Điều kiện thứ hai được sử dụng khi một giao dịch ILL đã bị đóng. 8.2.13 Lỗi giao thức Bất kỳ sự kiện nào không được liệt kê trong các bảng giao thức của Phụ lục A là không hợp lệ và được coi là lỗi giao thức. Với ngoại lệ quy định tại khoản 8.2.14., các APDU định dạng sai hoặc APDU với dữ liệu không hợp lệ cũng được coi là lỗi giao thức. Khi một lỗi giao thức được phát hiện, không có thay đổi trạng thái xảy ra và một APDU BÁO C Á O TRẠNG THÁI HOẶC LỖI mô tả bản chất của lỗi được gửi b ở i ILLPM. Nếu phát hiện một lỗi giao thức xảy ra khi hồi đáp một APDU yêu cầu ILL ban đầu, bên yêu cầu có thể để giao dịch ở trạng thái thiết bị đầu cuối là ĐÃ HỦY hoặc KHÔNG-CUNG CẤP. Ngoài ra bên yêu cầu có thể đưa lại APDU này trong một phiên bản khác. 8.2.14 Quy tắc để mở rộng Tất cả các lỗi cú pháp trong các APDU nhận được coi là lỗi giao thức ngoại trừ một giá trị chưa biết của một tham biến đã biết (khác với phiên bản giao thức), mà không gây ra một lỗi giao thức. Một giá trị chưa biết của giao thức phiên bản không tạo thành lỗi giao thức. 8.2.15 Thông tin riêng của bên đáp ứng Giao thức ILL cho phép truyền thông tín riêng của bên đáp ứng để mô tả một dịch vụ yêu cầu hoặc kết qu ả của một yêu cầu ILL. Thông tin riêng của bên đáp ứng có thể được cung cấp để bổ sung các giá trị chuẩn h ó a cho loại dịch vụ ILL và giải thích kết quả được định nghĩa trong tiêu chuẩn này. Trong trường hợp như vậy, bất kỳ giá trị chuẩn hóa khác với " riêng của bên đáp ứng " được sử dụng cho loại dịch vụ ILL hoặc lý do kết quả và các thông tin riêng của bên đáp ứng bổ sung được cung cấp trong loại dịch vụ riêng của bên đáp ứng hoặc kết quả riêng của bên đáp ứng, tương ứng. Ngoài ra, thông tin riêng của bên đáp ứng có thể được cung cấp để thay thế các giá trị chuẩn hóa cho loại dịch vụ ILL và giải thích kết quả được định nghĩa trong tiêu chuẩn này. Trong trường hợp này, giá trị chuẩn hóa "riêng cho bên đáp ứng" được sử dụng cho loại dịch vụ ILL hoặc lý do kết quả và Thông tin riêng cho bên đáp ứng phải được cung cấp trong loại Dịch vụ riêng cho bên đáp ứng hoặc Kết quả riêng cho bên đáp ứng, tương ứng. Việc sử dụng các kiểu BÊN NGOÀI của ASN.1 đ ể xác định Thông tin riêng cho bên đáp ứng được mô tả trong Phụ lục D. 8.2.16 Thông tin số tài khoản Khi một yêu cầu được chuyển tiếp, theo chuỗi hoặc phân khu, các số tài khoản trong Kiểu- thông tin - Chi ph í được thay bằng số tài khoản của tổ chức yêu cầu với tổ chức tiếp theo tới đó yêu cầu được gửi như chứa trong mục tương ứng ở Loại -Danh sách -Gửi đến (loại danh sách địa chỉ gửi). Nếu không có sẵn đề mục như vậy, trường này được để trống. 8.2.17 Mô tả tài liệu bổ sung Ngoài thông tin định danh tài liệu được xác định trong tiêu chuẩn này, có thể cung cấp thông tin bổ sung khác về bản chất hoặc về định dạng. Ví dụ, thông tin có thể được cung cấp trong định dạng, hoặc ở định dạng mã vạch để nhận dạng tài liệu nhanh chóng theo ISO 2709. Mô tả tài liệu bổ sung có thể được cung cấp trong các yêu cầu YÊU CẦU- ILL, ĐÃ CHUYỂN, CÂU TRẢ LỜI ILL, ĐÃ NHẬN và ĐÃ TRẢ. Thông tin này có thể được cung cấp bởi bên yêu cầu ban đầu hoặc bổ sung sau bởi bên đáp ứng hoặc người trung gian (ví dụ là kết quả của việc kiểm tra thư mục). 8.2.18 Thông báo gửi Tham số này là một tham số dịch vụ trừu tượng không tạo ra một tham số giao thức tương ứng. 8.3 Quy định về thủ tục cho người trung gian Tất cả giao dịch ILL ban đầu là đơn gi ả n. Khi được sự cho phép của bên yêu cầu, bên đáp ứng có thể chọn chuyển tiếp, theo chuỗi hay phân khu một giao dịch ILL, hoặc có thể đặt các giao dịch ILL riêng biệt. Những người trung gian là đối tượng của các quy tắc quy định tại khoản này, ngoài các quy tắc tại các khoản trên đây. 8.3.1 Chuyển tiếp giao dịch Giao thức ILL hỗ trợ chuyển tiếp không giới hạn một yêu cầu ILL, với ràng buộc duy nhất là một yêu cầu không thể được chuyển tiếp hai lần đến cùng một bên đáp ứng trong cùng một nhóm giao dịch ILL . Bên đáp ứng có thể cung cấp hai kiểu ghi chú khác nhau khi chuyển tiếp một YÊU CẦU- ILL: ghi chú chuyển tiếp trong YÊU CẦU- ILL được chuyển tiếp và ghi chú thông báo trong THÔNG BÁO - CHUYỂN TIẾP. Khi chuyển tiếp xảy ra, bên đáp ứng không còn tham gia vào giao dịch ILL nữa. Từ thời điểm đó, người chuy ể n tiếp chỉ có thể thực hiện các dịch vụ CHUYỂN TIẾP, YÊU CẦU TRẠNG THÁI, BÁO CÁO TRẠNG THÁI hoặc LỖI và THÔNG BÁO có thể được gọi bởi bên đáp ứng. Nếu trong trạng thái ĐANG CHỜ, bên yêu cầu gửi một YÊU CẦU- ILL lặp, một APDU HỦY, THÔNG BÁO hoặc H Ỏ I TRẠNG THÁI đến bên đáp ứng, bên đáp ứng khi đã chuyển tiếp yêu cầu đến bên đáp ứng mới, người trung gian (bên đáp ứng đầu tiên) sẽ gửi một BÁO CÁO TRẠNG THÁI HOẶC LỖI với một giá trị báo cáo lỗi của "Đã chuyển tiếp" với thông tin trong trường Chú thích là nơi yêu cầu được chuyển tiếp. Biến giao thức Bool Chuyển tiếp được sử dụng bởi bên đáp ứng cho biết một yêu cầu có thể được chuyển tiếp hay không. Biến giao thức này được đặt sau khi nhận được APDU YÊU CẦU- ILL với giá trị được chuyển bằng kiểu "Cho phép chuyển tiếp". Nếu Chuyển tiếp có giá trị là ĐÚNG, thì được phép chuyển tiếp. Nếu Chuyển tiếp có giá trị là SAI, th ì không được phép chuyển tiếp. Kiểu "Cho phép chuyển tiếp" cũng có thể được đặt là SAI tại thời điểm một yêu cầu được chuyển tiếp khi muốn hạn chế việc chuyển tiếp sau đó. Chuyển tiếp có thể được kết hợp giữa xâu chuỗi hoặc phân khu giao dịch ILL. CHÚ THÍCH Chuyển tiếp kh ô ng nhằm để sử dụng khi một tài liệu được yêu cầu dự kiến s ẽ có sẵn trong tương lai; trong những trường hợp như vậy, một CÂU TRẢ LỜI I LL có giá trị THỬ LẠI và ngày THỬ LẠI được quy định là đáp ứng thích hợp. 8.3.2 Xâu chuỗi giao dịch Giao thức ILL hỗ trợ xâu chuỗi không giới hạn của một ILL giao dịch. Giao dịch ILL theo chuỗi được xác định bởi giá trị của "Kiểu giao dịch" trong APDU Yêu cầu ILL. Khi việc thực hiện chuỗi giao dịch ILL x ả y ra, bên đáp ứng khi đó tr ở thành người trung gian và khởi tạo một giao dịch con với một bên đáp ứng mới. Khi giao dịch con được khởi tạo, biến theo CHUỖI vẫn là ĐÚNG trong khi biến PHÂN KHU được đặt là Sai. Người trung gian đảm nhận vai trò của bên yêu cầu cho các giao dịch con và giữ vai trò của bên đáp ứng cho giao dịch ILL ch í nh. Giao dịch con được phân biệt với giao dịch ILL chính vì vậy giao dịch trước đây có thể không thành công không ả nh hư ở ng đến giao dịch sau này. Người sử dụng dịch vụ ILL tr ung gian có trách nhiệm phối hợp các sự kiện trên các giao dịch chính và phụ. Về mặt khái niệm, sự kết hợp này là các dịch vụ gốc : chỉ thị dịch vụ gốc trên một giao dịch ILL được ánh xạ vào yêu cầu dịch vụ gốc tương ứng trên các chỉ thị khác, ví dụ việc nhận chỉ thị chuyển đi được ánh xạ vào một yêu cầu chuyển đi được gửi cho bên yêu cầu. Người trung gian có thể thay đổi các giá trị của tham số dịch vụ như thực hiện ánh xạ giữa giao dịch chính và giao dịch con, trừ trường hợp đặc biệt không được phép. Nếu nó làm thay đổi giá trị của bộ đếm thời gian hết hạn, thời hạn sử dụng đối với giao dịch con phải bằng hoặc ít hơn thời hạn sử dụng cho yêu cầu ban đầu. Điểm kết nối giữa giao dịch chính và phụ là những gì sự kiện giao dịch chính ILL luôn được ánh xạ vào các sự kiện giao dịch con tương ứng. Tương tự như vậy, tất cả các sự kiện giao dịch con, ngoại trừ chỉ thị CÂU TRẢ LỜI- ILL có giá trị THỬ LẠI, KHÔNG HOÀN THÀNH, hoặc ĐỊA ĐIỂM CUNG CẤP, chỉ thị HẾT HẠN và chỉ thị THÔNG BÁO CHUYỂN TIẾP, được ánh xạ lên các sự kiện giao dịch ILL chính tương ứng. Trong các trường hợp chỉ thị CÂU TRẢ LỜI ILL với một trong các giá trị quy định ở trên, nó có thể được ánh xạ lên một yêu cầu CÂU TRẢ LỜI -ILL của giao dịch ILL chính, hoặc nó có thể không theo sự lựa chọn của người trung gian. Một ví dụ về trường hợp sau là tình huống người trung gian, khi nhận được phản hồi từ chối từ một bên đáp ứng, chọn khởi tạo một giao dịch con mới với bên đáp ứng khác chứ không phải báo cáo ngay lập tức một câu trả lời từ chối cho bên yêu cầu giao dịch ILL chính. Chỉ thị CÂU TRẢ LỜI -ILL với một giá trị CÓ ĐIỀU KIỆN phải được ánh xạ vào yêu cầu Câu trả lời ILL của giao dịch ILL chính. Trả lời Điều kiện tiếp theo với giá trị Không được ánh xạ vào giao dịch con. Lưu ý rằng trong trường hợp này người trung gian có thể không bắt đầu một giao dịch con mới với bên đáp ứng khác. Trong trường hợp của chỉ thị Thông báo chuyển tiếp và chỉ thị Hết hạn, không có ánh xạ bất kỳ sự kiện giao dịch ILL chính được thực hiện. Những dịch vụ ban đầu này có ý nghĩa chỉ với các giao dịch con. Nếu bên yêu cầu trung gian trong trạng thái Chờ hủy nhận chỉ thị Thông báo chuyển tiếp t ừ bên đáp ứng và kết quả là trở lại trạng thái Chờ, cần đưa ra yêu cầu Hủy đến bên đáp ứng mới. Người trung gian tham gia vào cả giao dịch chính và con trong suốt vòng đời của chúng, nhưng không thực hiện chuyển đổi trạng thái trong giai đoạn theo dõi các giao dịch ILL như vậy, tức là các hành vi người trung gian trong chế độ xuyên suốt. Trong phạm vi người trung gian, trạng thái ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho cả giao dịch ILL chính thành công và một giao dịch con thành công. Sự chuyển trạng thái tiếp theo chỉ xảy ra đối với bên yêu cầu và bên đáp ứng. Các quy tắc chuyển đổi trạng thái cho người trung gian khác với các quy tắc của bên yêu cầu và bên đáp ứng ở một số trạng thái. Những quy tắc c ụ thể cho người trung gian được nêu trong các bảng tại Phụ lục A. Biến giao thức Bool theo CHUỖI được sử dụng để cho biết có hay không một giao dịch ILL theo chuỗi. Biến giao thức này được đặt sau khi nhận được một APDU YÊU CẦU- ILL với giá trị chuyển bằng kiểu "Cho phép theo chuỗi". Nếu thực hiện theo CHUỖI là ĐÚNG, th ì việc theo chuỗi có thể được phép. Người trung gian có thể chọn thay đổi giá trị của kiểu "Cho phép theo chuỗi" khi bắt đầu một giao dịch con. Khi người trung gian khởi tạo một giao dịch con, nó luôn luôn chỉ ra một yêu cầu về thông báo Đã chuyển trong tham số "Thông báo tùy chọn của bên yêu cầu" của dịch vụ YÊU CẦU- ILL. Tất cả các thành phần khác của tham số này có cùng giá trị như được cung cấp trong YÊU CẦU ILL ban đầu. Khi người trung gian đáp ứng bên yêu cầu với APDU ĐÃ CHUYỂN, tham số "Thông báo tùy chọn của bên đáp ứng" ph ả i l ấ y giá trị được cung cấp trong một APDU ĐÃ CHUYỂN nhận được từ bên đáp ứng 8.3.3 Phân khu giao dịch Giao thức ILL hỗ trợ phân khu không giới hạn một giao dịch ILL. Các giao dịch ILL phân khu được xác định bởi giá trị của "Kiểu giao dịch" trong APDU Yêu cầu ILL. Khi việc phân khu giao dịch ILL xảy ra, bên đáp ứng lúc này tr ở thành người trung gian và khởi tạo một giao dịch con với một bên đáp ứng mới. Khi giao dịch con được khởi tạo, biến PHÂN KHU vẫn Đ Ú NG trong khi biến Xâu chuỗi được đặt là SAI. Người trung gian tham gia vào giao dịch ILL chính chỉ trong giai đoạn xử lý, nghĩa là cho đến khi một APDU ĐÃ CHUYỂN được nhận được từ bên đáp ứng và chuyển cho bên yêu cầu . Các giao dịch con chỉ có một giai đoạn xử lý. Trong phạm vi của người trung gian, trạng thái ĐÃ CHUYỂN là trạng thái thiết bị đầu cuối cho cả giao dịch ILL chính thành công và giao dịch con thành công. Giai đoạn theo dõi thường liên quan đến sự tương tác trực tiếp giữa bên yêu cầu và bên đáp ứng và bỏ qua người trung gian. Tuy nhiên, nếu người trung gian nhận một APDU THÔNG BÁO, HỎI TRẠNG THÁI, BÁO CÁO TRẠNG THÁI HOẶC LỖI th ì ở trong trạng thái thiết bị đầu cuối, người trung gian không trả lời mà chuyển tiếp APDU này. Các định danh của giao dịch chính và phụ chỉ khác nhau ở sự có mặt của dấu hạn định giao dịch con. Sau khi hoàn thành giai đoạn xử lý, bên đáp ứng bỏ dấu hạn định giao dịch con khỏi Dấu hạn định giao dịch ILL (xem 7.1) và sử dụng phần còn lại khi tương tác với bên yêu cầu. Trong giai đoạn xử lý, các giao dịch chính và con được kết hợp theo cách tương tự như các giao dịch ILL theo chuỗi. Biến giao thức Bool CHUỖI được sử dụng để cho biết giao dịch ILL có thể được phân khu hay không. Biến giao thức được đặt sau khi nhận được một APDU YÊU CẦU- ILL với giá trị chuyển bằng kiểu "Cho phép phân khu". Nếu Phân khu có giá trị ĐÚNG, thì phân khu là được phép. Khi người trung gian khởi tạo một giao dịch con, luôn chỉ ra yêu cầu cho các thông báo Vận chuyển trong tham số " Thông báo tùy chọn của bên yêu cầu" của dịch vụ YÊU CẦU- ILL. T ấ t cả các thành phần khác của tham số này có cùng giá trị như được cung cấp trong YÊU CẦU-ILL ban đầu. Khi người trung gian đáp ứng cho bên yêu cầu với APDU ĐÃ CHUYỂN, tham số "Thông báo tùy chọn của bên đáp ứng" phải nhận giá trị được cung cấp trong APDU ĐÃ CHUYỂN nhận được từ bên đáp ứng. Bên yêu cầu gửi bất kỳ APDU được yêu cầu này trực tiếp đến bên đáp ứng, không phải tới người trung gian. 8.3.4 Chuyển tiếp, xâu chuỗi và phân khu hỗn hợp Chuyển tiếp, theo chuỗi và phân khu có thể được kết hợp theo bất kỳ cách thức nào trong một giao dịch ILL. Các quy tắc áp dụng khác nhau tùy theo sự kết hợp cụ thể được sử dụng. Các trường hợp sau đây được phân biệt: a) Chuỗi theo sau là chuyển tiếp: người nhận YÊU C Ầ U- ILL chuyển tiếp tương tác trong suốt giao dịch ILL với người trung gian, được xác định bởi tham số "id bên yêu cầu" trong Yêu cầu ILL nhận được. b) Chuyển tiếp theo chuỗi tiếp theo: người khởi xư ớ ng giao dịch con theo chuỗi tương tác trực tiếp với bên yêu cầu ban đầu sau khi đã nhận được YÊU CẦU -ILL chuyển tiếp. Người nhận YÊU CẦU -ILL theo chuỗi tương tác với người trung gian thực hiện theo chuỗi, như với một giao dịch ILL theo chuỗi bình thường. c) Phân khu có Chuyển tiếp tiếp theo: người nhận YÊU CẦU ILL chuyển tiếp tương tác trong suốt quá trình xử lý với người trung gian được xác định bởi tham số "id bên yêu cầu" của YÊU CẦU ILL nhận được. Trong giai đoạn theo dõi, nó tương tác trực tiếp với bên yêu cầu ban đầu. d) Chuyển tiếp có Phân khu tiếp theo: người khởi xướng giao dịch con phân khu tương tác trực tiếp với bên yêu cầu ban đầu trong giai đoạn xử lý, sau khi nó đã nhận được YÊU CẦU ILL chuyển tiếp. Người nhận YÊU CẦU ILL ph â n khu tương tác với người trung gian phân khu trong giai đoạn xử lý, và với bên yêu cầu ban đầu trong giai đoạn theo dõi, như với một giao dịch ILL bình thường. e) Thực hiện theo chuỗi có Phân khu tiếp theo: khi phân khu theo chuỗi, các quy tắc cho phân khu chi phối các quy tắc cho thực hiện theo chuỗi. Người nhận YÊU CẦU ILL phân khu tương tác trong giai đoạn xử lý với người trung gian được xác định bởi tham số "id bên yêu cầu" của YÊU CẦU ILL nhận được. Nếu giai đoạn này hoàn thành với việc gửi một APDU ĐÃ CHUYỂN, thì tham số "kiểu giao dịch" phải được trả lại cho người yêu cầu ban đầu với giá trị "phân khu" mà không phải là "theo chuỗi". Giá trị của tham số "id bên đáp ứng" là Ký hiệu nhận dạng bên đáp ứng với nó yêu cầu được phân khu. Trong giai đoạn theo dõi, bên yêu cầu ban đầu tương tác trực tiếp với bên đáp ứng đó. f) Phân khu theo chuỗi tiếp theo: Không giống như các trường hợp trên, người nhận mà YÊU CẦU ILL được thực hiện theo chuỗi không nhận thức được sự phân khu và do đó không thể sửa đổi hành vi của m ì nh cho phù hợp. Do đó, không bao giờ tương tác trực tiếp với bên yêu cầu ban đầu. Giai đoạn xử lý tiến hành bình thường, ngoại trừ việc xử lý APDU ĐÃ CHUYỂN. Nếu người trung gian trong chuỗi, tức là người được phân khu YÊU CẦU ILL, nhận được chỉ thị ĐÃ CHUYỂN từ bên đáp ứng cuối cùng thì trước khi chuyển thông báo đi, người trung gian phải khai b á o tham số "id nhà cung cấp" vào giá trị "id bên đáp ứng" và khai báo "id bên đáp ứng " vào nhận dạng của người trung gian. Tham số "kiểu giao dịch" được đặt với giá trị "phân khu". Bằng cách này, chỉ thị ĐÃ CHUYỂN gửi tới bên yêu cầu ban đầu sẽ chỉ ra rằng sự tương tác tiếp theo trong giai đoạn theo dõi sẽ thực hiện trực tiếp với người trung gian theo chuỗi. Tuy nhiên, "id nhà cung cấp" sẽ xác định nhà cung cấp thực tế tài liệu này. Người trung gian thực hiện theo chuỗi vẫn chịu trách nhiệm tiếp tục với việc theo chuỗi tất cả các tương tác với bên yêu cầu ban đầu cho tới bên đáp ứng cuối cùng, và ngược lại. Những thay đổi với các tham số "kiểu giao dịch ", "id nhà cung cấp" và "id bên đáp ứng" được thực hiện chỉ khi tham số "kiểu giao dịch" không có giá trị "phân khu". Quy tắc này đảm bảo rằng người trung gian cuối cùng trong một chuỗi phân khu luôn được xác định với bên yêu cầu đầu. g) Chuyển tiếp, theo chuỗi và phân khu: Không có quy định bổ sung được áp dụng. Hành vi của bất kỳ sự kết hợp quy định nào được xác định bởi áp dụng lặp lại các quy tắc này cho các kết hợp theo cặp đã nêu ở trên. 8.3.4.1 Các giao dịch ILL riêng biệt Nếu hệ thống đặt các giao dịch đặc biệt hoạt động thay thế cho người trung gian, tiêu chuẩn này không đặt quy định thủ tục cụ thể cho việc liên kết các giao dịch ILL riêng biệt. Tuy nhiên, lưu ý rằng một hệ thống vai trò kép phải sử dụng một cơ chế nào đó để theo dõi tiến trình của hai giao dịch này để đảm bảo rằng chúng tiếp cận trạng thái thiết bị đầu cuối; điều này có thể đạt được bằng nhiều cách khác nhau, ví dụ: a) Đối với tất cả các tài liệu, hoặc là một APDU ĐÃ CHUYỂN phải được cung cấp bởi người đáp ứng hoặc tài liệu này phải được chuyển qua người trung gian. b) Đối với các tài liệu được trả lại, hoặc là một APDU KIỂM NHẬN phải được cung cấp bởi người trả lời hoặc các tài liệu này phải được trả lại thông qua người trung gian. Cách hoạt động này, vì nó liên quan đến việc phân biệt các giao dịch ILL đơn giản, không có ý nghĩa giao thức và không được mô tả cụ thể hơn trong tiêu chuẩn này. 9 Cú pháp trừu tượng 9.1 ASN.1 đ ặc tả các APDU ILL Điều này mô tả cú pháp trừu tượng của các APDU ILL trong Giao thức ILL đã được liệt kê tại điều 6. Các APDU ILL được định nghĩa bằng cách sử dụng ký hiệu ASN.1 định nghĩa trong Phụ lục 2 của ISO 8824. Mỗi APDU được định nghĩa như là một kiểu có cấu trúc trong đó kiểu là một tập các giá trị có tên. Kiểu có cấu trúc được xác định bằng cách tham chiếu tới một hoặc nhiều kiểu khác mà có thể là kiểu có cấu trúc hoặc kiểu đơn giản. Kiểu đơn giản được định nghĩa bằng cách trực tiếp xác định các giá trị của nó. Khi định nghĩa các kiểu có cấu trúc, ASN.1 xác định loại thành phần nào tạo nên kiểu có cấu trúc là tùy chọn, các loại thành phần nào là bắt buộc, và các giá trị cho phép của các loại này. Các thông tin khác, ví dụ như một chuỗi là cố định hoặc biến đổi về kích thước, và các giá trị mặc định cũng được cung cấp. Các chú giải bao gồm trong đặc tả ASN.1 là một phần của tiêu chuẩn này. Một số kiểu tùy chọn được cung cấp các giá trị mặc định. Nếu giá trị của kiểu không tồn tại trong APDU đã mã hóa, giá trị mặc định sẽ được sử dụng. Nếu một kiểu không có giá trị mặc định, và giá trị cho kiểu đó không tồn tại trong APDU đã mã hóa, thì không có giá trị được kết hợp với kiểu đó. Nếu một kiểu có cấu trúc là bắt buộc, nhưng được tạo duy nhất từ các kiểu thành phần tùy chọn thì ít nhất một trong các kiểu tùy chọn phải có, ví dụ id hệ thống. Nếu một kiểu có cấu trúc là tùy chọn, nhưng được xây dựng t ừ một kiểu bắt buộc, th ì kiểu thành phần là bắt buộc chỉ nếu kiểu có cấu trúc có mặt, ví dụ kiểu -vật mang tin-thông tin-cung cấp. Các APDU ILL được định nghĩa trong 9.1.1 là các kiểu có c ấ u trúc. 9.1.2 liệt kê các kiểu mà từ đó các kiểu có c ấ u trúc được xây dựng và chưa được quy định trong 9.1.1. FILE ĐƯỢC ĐÍNH KÈM THEO VĂN BẢN 10 Sự phù hợp 10.1 Sự phù hợp tĩnh Việc thực hiện tuyên bố phù hợp này phải có khả năng: a) tuân thủ các quy định đối với một trong các vai trò sau: • vai trò bên yêu cầu, • vai tr ò bên đáp ứng, • 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 H O ẶC LỖI cho tất cả các loại dịch vụ; và dịch vụ có điều kiện ĐÃ TRẢ LẠI với loại dịch vụ "cho mượn" (xem Chú thích 1); e) hỗ trợ gọi các dịch vụ sau cho vai bên đáp ứng: các dịch vụ bắt buộc đã chuyển, Trả lời ILL, Trả lờ i hủy, Mất, Báo cáo trạng thái hoặc lỗi khi hỗ tr ợ bất kỳ loại hình dịch vụ nào; và các dịch vụ có điều kiện Đòi, Kiểm nhận quá hạn, Gia hạn, Trả lời gia hạn, Trả khi hỗ trợ loại hình dịch vụ "cho mượn" (xem Chú thích 1); f) hỗ trợ gọi các dịch vụ sau đây cho vai trò người trung gian: các dịch vụ bắt buộc Yêu cầu ILL, Trả lời điều kiện, Báo cáo trạng thái, Báo cáo trạng thái hoặc lỗi, Đã chuyển, Đã Nhận, Trả lời ILL, Hủy, Trả lời Hủy, Mất; Hư hại và Thông báo khi hỗ trợ bất kỳ loại hình dịch vụ nào; và các dịch vụ có điều kiện Đòi, Quá hạn, đã Kiểm nhận, Gia hạn. Trả lời gia hạn, Đã Trả khi hỗ trợ loại hình dịch vụ "cho mượn" (xem Chú thích 1); g) nhận các APDU với dữ liệu được định nghĩa cho tất cả các kiểu như quy định tại khoản 9; h) hỗ trợ tất cả các loại bắt buộc đối với APDU được truyền như quy định tại khoản 9 (xem Chú thích 2); i) xác định dữ liệu với nhiều tùy chọn được hỗ trợ bởi việc thực hiện (xem Chú thích 3). CHÚ THÍCH 1: Dịch vụ tùy chọn cho các vai trò bên yêu cầu và bên đáp ứng bao gồm các dịch vụ đã bị hư hại Thông báo, Yêu cầu trạng thái. Khi các dịch vụ tùy chọn này kh ô ng được hỗ trợ, thì dù việc thực hiện không có khả năng truy ề n các APDU được kết hợp với dịch vụ này nhưng vẫn có khả năng tiếp nhận các APDU liên quan. Khi các dịch vụ có điều kiện không được hỗ trợ, việc thực hiện không cần phải có khả năng truyền hoặc nhận các APDU được kết hợp với các dịch vụ. CHÚ THÍCH 2: Kh i hỗ trợ một kiểu bắt buộc, việc thực hiện phải luôn luôn xác định dữ liệu cho loại đó. Nếu kiểu có cấu trúc là bắt buộc, nhưng chỉ được cấu tạo từ các kiểu tùy chọn này không, khi đó ít nhất một trong các kiểu tùy chọn sẽ c ó mặt . Nếu kiểu có cấu trúc l à tùy chọn, nhưng được xây dựng từ một kiểu bắt buộc, khi đó kiểu này là bắt buộc chỉ nếu kiểu có cấu trúc l à hiện thời. CHÚ THÍCH 3: Hỗ trợ một kiểu tùy chọn là chỉ khả năng việc thực hiện để xác định dữ liệu cho kiểu được hỗ trợ khi truyền các APDU. Dữ liệu cho các tùy chọn không cần phải luôn luôn có mặt. Các điều kiện cho sự hiện diện của dữ liệu trong các kiểu tùy chọn là một vấn đề thực hiện cục bộ. Không hỗ trợ một kiểu tùy chọn nghĩa là việc thực hiện không có khả năng cung cấp các dữ liệu được xác định cho kiểu này. Lưu ý rằng việc thực hiện vẫn có thể nhận được các kiểu tùy chọn không được hỗ trợ. 10.2 Sự phù hợp động Để phù hợp với tiêu chuẩn này, việc thực hiện phải thể hiện chế độ/tính năng bên ngoài nhất quán với: a) khi thực hiện một ASE ILL theo quy định của điều 8 của tiêu chuẩn này; b) khả năng đề ra và các yêu cầu liên quan về thông báo tùy chọn, như được chỉ ra trong các APDU Yêu cầu ILL, Trả lời ILL và Đã chuyển; c) đã thực hiện khả năng luôn gửi và nhận các APDU Đ ã chuyển, Đã Nhận, Đã Trả và Đã Kiểm nhận khi đóng vai trò người trung gian; d) mã hóa các APDU như quy định tại điều 9 của tiêu chuẩn này. Có thể áp dụng nhiều lược đồ mã hóa cho gi á tr ị của các kiểu dữ liệu được xác định bằng cách sử dụng ASN.1. Lược đồ mã hóa bắt buộc là các Quy tắc mã hóa cơ bản cho xác định cú pháp trừu tượng 1 trong ISO/IEC 8825. Một khả năng khác là lược đồ mã hóa được xác định bởi tiêu chuẩn EDIFACT, ISO 9735, và Phụ lục B. 10.3 Yêu cầu trình bày tuân thủ thực hiện giao thức Mỗi khi thực hiện phải cung cấp một trình bày tuân thủ thực hiện giao thức (PICS). Các PICS phải nêu: a) các vai trò nào được hỗ trợ; b) các loại dịch vụ nào được hỗ trợ; c) các loại giao dịch nào được hỗ trợ; d) các dịch vụ nào được hỗ trợ; e) các APDU nào được hỗ trợ; f) các kiểu dữ liệu APDU nào được hỗ trợ; g) các yêu cầu đối với các hệ thống khác liên quan đến APDU tùy chọn cho phép liên kết mạng, tức là một hệ thống có thể yêu cầu các hệ thống khác phải hỗ trợ tất cả các APDU tùy chọn khi liên kết mạng với hệ thống đó; h) các quy tắc mã hóa nào được hỗ trợ; i) một hoặc các phiên bản giao thức nào được hỗ trợ. Phụ lục A (Quy định) Bảng trạng thái ILL A.1 Tổng quan Giao thức ILL định nghĩa một tập các trạng thái thông qua đó một giao dịch ILL tiến hành. Trong Phụ lục này các bảng trạng thái được trình bày cho mỗi bên yêu cầu, bên đáp ứng và người trung gian. Các bảng này cho thấy mối tương quan giữa trạng thái của một máy giao thức ILL (ILLPM), những sự kiện đến xảy ra trong giao thức, các hành động thực hiện, và cuối cùng, trạng thái kết quả của ILLPM. Phụ lục này chứa các bảng dưới đây: a) Bảng A.1 quy định tên viết tắt và mô tả của mỗi sự kiện đến. b) Bảng A.2 quy định tên viết tắt và mô tả của mỗi sự kiện đi. c) Bảng A.3 quy định các vị từ d) Bảng A.4 quy định bảng trạng thái cho bên yêu cầu cho giai đoạn xử lý một giao dịch ILL. Bảng này mô t ả đầy đủ tất cả các trạng thái với một giao dịch ILL liên quan đến một tài liệu không trả lại ví dụ như một bản sao chụp. e) Bảng A.5 và A.6 quy định b ả ng trạng thái cho bên yêu cầu cho giai đoạn theo dõi một giao dịch ILL. Các bảng này chỉ áp dụng cho các giao dịch ILL liên quan đến một tài liệu trả lại ví dụ như một chuyên khảo. f) Bảng A.7 quy định bảng trạng thái cho bên đáp ứng cho giai đoạn xử lý. B ả ng này áp dụng cho tất cả các loại dịch vụ ILL, bao gồm các yêu cầu đối với các tài liệu được trả lại và không trả lại. g) Bảng A.8 quy định bảng trạng thái cho bên đáp ứng cho giai đoạn theo dõi. Bảng này áp dụng cho tất cả các loại dịch vụ ILL, bao gồm các yêu cầu đối với các tài liệu được trả lại và không trả lại. h) Bảng A.9 quy định bảng trạng thái cho người trung gian đóng vai trò của bên yêu cầu. i) Bảng A.10 và A. 11 quy định bảng trạng thái cho người trung gian đóng vai trò của bên đáp ứng A.2 Quy ước Giao của một sự kiện đến (hàng) và một trạng thái (cột) tạo thành một ô. Trong bảng trạng thái, một ô trống là sự kết hợp của một sự kiện đến và một trạng thái không được định nghĩa cho giao thức ILL. Một ô không trống thể hiện một sự kiện đến và trạng thái được xác định cho Giao thức ILL. Một ô như thế chứa một danh sách hành động. Một danh sách hành động có thể là bắt buộc hoặc có điều kiện. Một danh sách hành động bắt buộc bao gồm: a) một sự kiện đi; b) tùy chọn thay đổi với một biến giao thức cục bộ hoặc bộ hẹn giờ; và c) trạng thái kết quả. Một danh sách hành động có điều kiện bao gồm: a) một biểu thức v ị t ừ bao gồm các vị từ và các toán t ử Bool ( ^ đại diện cho toán tử Bool Không); và b) danh sách hành động bắt buộc. Danh sách này chỉ được sử dụng nếu biểu thị vị ngữ có giá trị đúng Các hàng riêng biệt được cung cấp cho các sự kiện ban đầu và lặp để phân biệt giữa các danh sách hành động có thể khác nhau. Lưu ý rằng các hàng riêng biệt không được cung cấp cho các sự kiện lặp lại liên quan đến các dịch vụ và các APDU Thông báo , Yêu cầu trạng thái, Báo cáo trạng thái hoặc lỗi, Hư h ỏ ng vì chúng không phải là lặp; mỗi lần xuất hiện như vậy được coi là một sự kiện ban đầu. Các sự kiện yêu cầu dịch vụ ban đầu và lặp được phân biệt trên cơ sở các tiêu ch í sau: a) Đối với một bên yêu cầu hoặc bên đáp ứng, yêu cầu dịch vụ ban đầu không có giá trị cho tr ường "Ngày và thời gian của dịch vụ ban đầu". Sự kiện lặp có một giá trị xác định cho trường này; yêu cầu dịch vụ lặp chỉ có thể được gọi trong khi không có sự thay đổi trạng thái trong lệnh gọi thực thể ứng dụng ban đầu từ sự kiện y êu cầu dịch vụ ban đầu. b) Đối với một người trung gian, yêu cầu dịch vụ ban đầu có thể có giá trị "Ngày và thời gian dịch vụ ban đầu" miễn là không có ngay trước yêu cầu dịch vụ cùng loại. Yêu cầu dịch vụ lặp có một giá trị xác định cho "Ngày và thời gian của dịch vụ ban đầu" và đứng ngay trước là một yêu cầu dịch vụ cùng loại với cùng giá trị ngày và thời gian trong các trường "Ngày và thời gian dịch vụ ban đầu" hoặc ";"Ngày và thời gian của dịch vụ" này. Một yêu cầu dịch vụ lặp có thể được gọi trong một trạng thái khác với yêu cầu ban đầu, do khả năng của các sự kiện đến. CHÚ THÍCH: Yêu cầu dịch vụ tiếp theo có một hoặc nhiều Thông báo, Yêu cầu trạng thái, Báo cáo trạng thái hoặc lỗi và Hư hại, sau đó tiếp theo là một yêu cầu dịch vụ cùng loại như dịch vụ đầu tiên được xem xét ngay lập tức trước giá trị lặp thứ hai của cùng một dịch vụ. Các sự kiện APDU ban đầu và lặp được phân biệt trên cơ sở là một APDU lặp đáp ứng các tiêu chuẩn sau đây: a) một giá trị được cung cấp cho kiểu "Ngày và thời gian của dịch vụ ban đầu" và kiểu cấu trúc "Ngày thời gian dịch vụ". b) giá trị này giống như biến giao th ứ c Con dấu thời gian lặp. A.3 Hành động phải được thực hiện theo Giao thức ILL A.3.1 Tổng quan Các bảng trạng thái Giao thức ILL xác định các hành động được thực hiện bởi máy Giao thức ILL về một sự kiện đi, những thay đổi với các biến giao thức cục bộ hoặc bộ tính giờ và trạng thái kết quả của ILLPM. A.3.2 Nút giao không hợp lệ Các ô trống chỉ một nút giao không hợp lệ của một sự kiện đến và trạng thái. Nếu một nút giao như vậy xảy ra, nó được coi là một lỗi giao thức. ILLPM bỏ qua sự kiện đến, sẽ gửi một APDU Báo cáo trạng thái hoặc lỗi để thông báo cho người gửi lỗi giao thức này, và không thay đổi trạng thái. Các hành động cục bộ bổ sung, chẳng hạn như thông báo của người sử dụng dịch vụ, cũng có thể được thực hiện, nhưng không được quy định trong tiêu chuẩn này. A.3.3 Nút giao hợp lệ Nếu nút giao của các sự kiện và trạng thái đến là hợp lệ, một trong những hành động sau đây được thực hiện: a) nếu một ô chứa một danh sách hành động bắt buộc, các ILLPM có các hành động cụ thể; b) nếu một ô chứa một danh sách hành động có điều kiện và nếu biểu thức vị từ là đúng, ILPM thực hiện các hành động theo quy định. Nếu biểu thức vị từ là sai, khi đó thay đổi hành động và trạng thái quy định cho ô này không được thực hiện. CHÚ THÍCH: Đối với một số kết hợp của trạng thái và sự kiện đầu vào, các hành động khác nhau và thay đổi trạng thái là có thể, tùy theo giá trị của vị từ. Trong trường hợp này, cả hai khả năng được phản ánh trong bảng trạng thái trên các hàng riêng biệt . A.4 Mối quan hệ với dịch vụ hỗ trợ Các bảng trạng thái quy định trong phụ lục này không tính đến các tương tác với dịch vụ hỗ trợ, vì chúng phụ thuộc vào các ánh xạ được định nghĩa ngoài phạm v i tiêu chuẩn này. Đối với mỗi ánh xạ được định nghĩa, các trạng thái bổ sung và dịch chuyển trạng thái có thể được yêu cầu. Bảng A.1 - Danh sách sự kiện đến Tên viết tắt Mô tả ILLreq FWDreq ANSreq-CO ANSreq-RY ANSreq-UN ANSreq-LP ANSreq-WS ANSreq-HP ANSreq-ES C-REPreq + C-REPreq - CANreq CARreq + CARreq - SHIreq RCVreq RCLreq DUEreq RETreq RENreq REAreq + REAreq - CHKreq LSTreq DAMreq MSGreq STQreq STRreq ILL ILL-REQ U EST.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 = yes 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.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 FWD ANS-CO ANS-RY ANS-UN ANS-LP ANS-WS ANS-HP ANS-ES C-REP+ C-REP- CAN CAR + CAR - SHI RCV RCL DUE RET REN REA + REA - CHK LST DAM MSG STQ STR EXP EXPIRY timeout receive FORWARD-NOTIFICATION APDU receive ILL-ANSWER APDU: result = CONDITIONAL 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 = yes 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 CHECKED-IN APDU receive LOST APDU receive DAMAGED APDU receive MESSAGE APDU receive STATUS-QUERY APDU receive STATUS-OR-ERROR-REPORT APDU receive EXPIRED APDU Transaction Timer Exp ir y Bảng A. 2 - Danh sách sự kiện đi Tên viết tắt Mô tả ILLind FWDind ANSind-CO ANSind-RY ANSind-UN ANSind-LP ANSind-WS ANSind-HP ANSind-ES C-REPind + C-REPind - CANind CARind + CARind - SHIind RCVind RCLind DUEind RETind RENind REAind + REAind - CHKind LSTind DAMind MSGind STQind STRind EXPind ILL FWD ANS-CO ANS-RY ANS-UN ANS-LP ANS-WS ANS-HP ANS-ES C-REP + C-REP - ILL-REQ U EST.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 COND I TIONAL-REPLY.indication: answer = yes COND I TIONAL-REPLY.indication: answer = no CANCEL.indication CANCEL-REPLY.indication: answer = yes C A NCEL-REPLY.indication: answer = no SHIPPED . indication RECEIVED.indication RECALL.indication OVERDUE.indication RETURNED.indication RENEW.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 ILL-REQUEST APDU 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 send CONDITIONAL-REPLY APDU: answer = no CAN CAR + CAR - SHI RCV RCL DUE RET REN REA + REA - CHK LST DAM MSG STQ STR EXP send CANCELAPDU send CANCEL-REPLY APDU: answer = yes 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 CHECKED-IN APDU 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 p1 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 i s 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 p 5 returns TRUE if the RETURN protocol variable is TRUE p 6 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 g i á 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 C-REP + + repeat PENDING C-REPreq C-REP- - NOT-SUP-PLIED ILUeq p 1 ILL PENDING C-REPreq - C-REP- repeat NOT-SUP-PLIED CANreq CAN CANCEL- PENDING CANreq CAN repeat CANCEL- PENDING RCVreq RCV (opt) RCV (opt) RCV(opt) set RETURN var 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 STQ CONDITONAL STQ STQ CANCELLED STQ SHIPPED PENDING NOT-SUP- PLIED CANCEL- PENDING STRreq STR STR STR CONDITIONAL STR CANCEL- PENDING STR CANCELLED STR PENDING NOT-SUP-PLIED SHIPPED FWD FWDind FWDind PENDING PENDING FWD FWDind repeat PENDING ANS-CO p7 ANSind-CO ANSind-CO CONDITIONAL p7 ANSind-CO ANSind-CO CONDITIONAL NOT-SUP-PLIED ANSind-CO CANCEL- CANCELLED PENDING ANS-CO ^ p7 ANSind-CO ANSind-CO CONDITIONAL ^ p7 ANSind-CO CANCELLED ANSind-CO ANSind-CO NOT-SUP- CANCEL- ANS-CO ANSind-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 ILLreq p 1 ILL PENDING ANS-RY repeat ANSind-RY NOT-SUP- PLIED ANS-UN ANSind-UN ANSind-UN ANSind-UN NOT-SUP - P LI ED NOT-SUP - P LI ED NOT-SUP - P LI ED ANS-UN ANSind-UN repeat NOT-SUP-PLIED ANS-LP ANSind-LP ANSind-LP ANSind-LP NOT-SUP-PLIED NOT-SUP-PLIED NOT-SUP-PLIED ANS-LP ANSind-LP repeat NOT-SUP-PLIED ANS-WS ANSind-WS ANSind-WS ANSind-WS CONDITIONAL ANSind-WS ANSind-WS PENDING NOT-SUP-PLIED CANCEL- PENDING SHIPPED ANS-WS ANSind-WS ANSind-WS ANSind-WS CONDITIONAL ANSind-WS ANSind-WS repeat PENDING NOT-SUP-PLIED CANCEL- PENDING SHIPPED ANS-HP ANSind-HP ANSind-HP ANSind-HP ANSind-HP ANSind-HP PENDING NOT-SUP-PLIED CONDITIONAL CANCEL- SHIPPED PENDING ANS-HP ANSind-HP ANSind-HP ANS i nd-HP ANS i nd-HP ANSind-HP PENDING SHIPPED repeat CONDITIONAL ANS-ES ANSi n d-ES ANSind-ES ANSind-ES NOT-SUP-PLIED NOT-SUP-PLIED NOT-SUP-PLIED ANS-ES ANSind-ES repeat NOT-SUP-PLIED CAR + CARind + CARind + CANCELLED CANCELLED CAR + CARind + repeat CANCELLED CAR - CAR i nd - CAR i nd - CARind - PENDING PENDING SHIPPED CAR - CARind - CARind - repeat PENDING SHIPPED SHI SHIind SHIind SHIind SHIPPED SHIPPED SHIPPED IL L eq p 1 ILL PENDING SHI SHIind repeat SHIPPED DUE DUEind DUEind DUEind set RETURN set RETURN set RETURN var = TRUE var = TRUE var = TRUE RCL RCLind RCLind RCLind set RETURN set RETURN set RETURN CHK CHKind CHKind CHKind set RETURN set RETURN set RETURN MSG MSGind MSGind M SGind MSGind MSGind MSGind PENDING CONDITIONAL SHIPPED STQ STQind STQind STQind CONDITIONAL STQind STQind STQind PENDING CANCELLED STR STRind STRind STRind CONDITIONAL STRind STRind STRind PENDING NOT-SUP-P LI ED CANCEL- PENDING 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 NOT-RCVD/OVERDUE RCVreq RCV(opt) OVERDUE RCVreq repeat RCV(opt) RECEIVED RET req p5 RET (opt) RETURNED RET (opt) RETURNED RET (opt) RETURNED RETr e q repeat . RCVreq RCV (opt) RENreq p5 REN RENEW/PENDING REN RENreq Repeat REN REN LSTreq p5 LST LOST LST LOST LST LOST LST LOST LSTreq repeat DAMreq DAM DAM DAM MSGreq MSG MSG MSG MSG STQreq STQ STQ STQ STQ STRreq STR SIR STR STR ANS-WS ANSind-WS RECEIVED ANSind-WS RENEW/PENDING ANSind-WS RENEW/OVERDUE ANSind-WS NOT-RCVD/ OVERDUE ANS-WS repeat ANS i nd-WS RECEIVED ANSind-WS RENEW/PENDING ANSind-WS RENEW/OVERDUE ANSind-WS NOT-RCVD/OVERDUE ANS-HP ANSind-HP RECEIVED ANSind-HP RENEW/PENDING ANSind-HP RENEW/OVERDUE ANSind-HP NOT-RCVD/OVERDUE ANS-HP repeat ANSind-HP RECEIVED ANSind-HP RENEW/PENDING ANSind-HP RENEW/OVERDUE ANSind HP NOT-RCVD/OVERDUE CAR - CARind - RECEIVED CARind- RENEW/PENDING CARind - RENEW/OVERDUE CARind - NOT-RCVD/OVERDUE CAR - repeat CARind - RECEIVED CARind - RENEW/PENDING CARind - RENEW/OVERDUE CARind - NOT-RCVD/OVERDUE SHI SHIind RECEIVED SHIind RENEW/PENDING SHIind RENEW/OVERDUE SHIind NOT-RCVD/OVERDUE SHI repeat SHIind RECEIVED SHIind RENEW/PENDING SHIind RENEW/OVERDUE SHIind NOT-RCVD/OVERDUE RCL p5 RCLind RECALL RCLind RECALL RC Li nd RECALL RCLind RECALL RCL repeat RCVreq DUE p5 DUEind DUEind p7 and p8 DUEind OVERDUE OVERDUE DUE p5 DUEind DUEind ^ p7 OVERDUE DUE repeat DUEind DUEind LST LSTind LST repeat DAM MSG MSGind MSGind MSGind MSGind RECEIVED RENEW/PENDING RENEW/OVERDUE NOT-RCVD/ OVERDUE STQ STQind STQind STQind STQind RECEIVED RENEW/PENDING RENEW/OVERDUE NOT-RCVD/ OVERDUE STR STR i nd STRind STRind STRind RECEIVED RENEW/PENDING RENEW/OVERDUE NOT-RCVD/OVERDUE REA + P5 REAind + RECEIVED REAind + RECEIVED REAind + RECEIVED REA + repeat REAind + RECEIVED REA- p5 REAind - RECEIVED REAind- OVERDUE REAind - RECEIVED REA- repeat REAind - RECEIVED CHK p 5 CHKind 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 RETURNED LOST RECALL RCVreq RCV(opt) RECALL RCVreq repeat RCVreq RCV (opt) RETreq RET (opt) RETURNED p9 RET (opt) RETURNED RET (opt) RETURNED RETreq RET (opt) RENreq REN RENEW/OVERDUE RENreq LSTreq L ST L ST LST L ST LOST LOST LOST LOST LSTreq L ST repeat LOST DAMreq DAM DAM DAM OVERDUE RETURNED RECALL MSGreq MSG MSG MSG MSG OVERDUE RETURNED LOST RECALL STQreq STQ STQ STQ STQ OVERDUE RETURNED LOST RECALL STRreq STR STR STR STR OVERDUE RETURNED LOST RECALL ANS-WS ANSind-WS ANSind-WS ANSind-WS ANSind-WS OVERDUE RETURNED LOST RECALL ANS-WS repeat ANSind-WS ANSind-WS ANSind-WS ANSind-WS OVERDUE . RETURNED LOST RECALL ANS-HP ANSind-HP ANSind-HP ANSind-HP ANSind-HP OVERDUE RETURNED LOST RECALL ANS-HP repeat ANSind-HP ANSind-HP ANSind-HP ANSind-HP OVERDUE RETURNED LOST RECALL CAR - CARind - CARind - CARind - CARind - OVERDUE RETURNED LOST RECALL CAR - repeat CARind- CARind - CARind - CARind - OVERDUE RETURNED LOST RECALL SHI SHIind SHI i nd SHIind SHIind OVERDUE RETURNED LOST RECALL SHI repeat SHIind SHIind SHIind SHIind OVERDUE RETURNED LOST RECALL RCL RCLind RCLind RCLind RCLind RCL RCLind RCLind RCL i nd RETURNED LOST RECALL RCVreq RCV (opt) RECALL DUE DUEind DUEind DUEind DUEind OVERDUE RETURNED LOST RECALL DUE DUEind DUEind DUEind DUE i nd RETURNED LOST RECALL LST LSTind LSTind LSTind LOST LOST LOST LST LSTind LOST DAM DAMind RETURNED MSG MSGind MSGind MSGind MSGind OVERDUE RETURNED LOST RECALL STQ STQind STQind STQind STQind OVERDUE RETURNED LOST RECALL STR STR i nd STRind STRind STRind OVERDUE RETURNED LOST RECALL REA + REAind + REAind + REAind + RETURNED LOST RECALL REA + REAind + REAind + REAind + RETURNED LOST RECALL REA - REAind - REAind - REAind - REAind - OVERDUE RETURNED LOST RECALL REA - REAind - REAind - REAind - REAind - OVERDUE RETURNED LOST RECALL CHK CH Kind CHKind CHKind RETURNED 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 FWDvar set CHAIN var set PART var set EXPIRY timer IN-PROCESS ILLind IN-PROCESS ILLind NOT-SUP-PLIED ILLind CONDITIONAL ILLind FORWARD ILL repeat ILL i nd IN-PROCESS ILLind NOT-SUP-PLIED ILLind CONDITIONAL IL Li nd FORWARD FWDreq p4 ILL FW D disable EXPIRY timer FORWARD ANSreq-CO ANS- CO reset EXPIRY timer CONDI - TIONAL FWDreq repeat ILL FWD FORWARD ANS-COreq ANS- CO reset EXPIRY timer CONDI - TIONAL ANS-COreq repeat ANS-CO CONDITIONAL ANS-RYreq ANS-RY disable EXPIRY timer NOT-SUPPLIED ANS-RYreq repeat ANS-RY NOT-SUP-PLIED ANS-UNreq ANS-UN disable EXPIRY timer NOT-SUPPLIED ANS- 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- E S NOT-SUP- PLIED CARreq + CAR + CANCELLED CARreq + repeat CAR + CANCELLED CARreq- CAR- enable EXPIRY timer IN-PROCESS CARreq- repeat CAR - IN-PROCESS SHIreq SHI (opt) set RETURN var disable EXPIRY timer SHIPPED SHIreq repeat MSGreq MSG IN-PROCESS MSG NOT-SUP-PLIED MSG CONDITIONAL MSG CANCEL-PENDING MSG CANCELLED MSG FORWARD STQreq STQ IN-PROCESS STQ NOT-SUP-PLIED STQ CONDITIONAL STQ CANCEL-PENDING STQ CANCELLED STQ FORWARD STRreq STR IN-PROCESS STR NOT-SUP-PLIED STR CONDITIONAL STR CANCEL-PENDING STR CANCELLED STR FORWARD 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-REP- repeat C-REPind- NOT-SUP-PLIED CAN p7 CANind CANCEL-PEND - ING CANind NOT-SUP-PLIED CANind CANCEL-PEND - ING CANind CANCEL-PENDING CANind CANCELLED CANind FORWARD CAN ^ p7 CANind IN-PROCESS CANind NOT-SUP-PLIED CANind CANCEL-PEND - ING CANind CANCEL-PENDING CANind CANCELLED CANind FORWARD CAN repeat CANind IN-PROCESS CANind NOT-SUP-PLIED CANind CANCEL-PEND - ING CANind CANCEL-PENDING CANind CANCELLED CANind FORWARD MSG MSGind IN-PROCESS MSGind NOT-SUP-PLIED MSGind CONDITIONAL MSGind CANCEL-PENDING MSGind CANCELLED MSGind FORWARD STQ STQ i nd IN-PROCESS STQind NOT-SUP-PLIED STQind CONDITIONAL STQind CANCEL-PENDING STQind CANCELLED STQind FORWARD STR STRind IN-PROCESS STRind NOT-SUP-PLIED STRind CONDITIONAL STRind CANCEL-PENDING STRind CANCELLED STRind FORWARD EXPIRY Timeout EXPind EXP 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 p 5 RCL RCL RCL RCL RECALL RECALL RECALL RECALL RCLreq RCL repeat RECALL DUEreq p5 DUE DUE p8 OVERDUE RENEW OVERDUE DUE OVERDUE DUEreq DUE DUE repeat RENEW OVERDUE OVERDUE LSTreq LST LST LST LST LST LST LOST LOST LOST LOST LOST LOST LSTreq LST repeat LOST DAMreq DAM CHECKED-IN MSGreq MSG MSG MSG MSG MSG MSG MSG SHIPPED RENEW/ PENDING RENEW OVERDUE OVERDUE RECALL CHECKED-IN LOST STQreq STQ STQ STQ STQ STQ STQ STQ SHIPPED RENEW PENDING RENEW OVERDUE OVERDUE RECALL CHECKED-IN LOST STRreq STR STR STR STR STR STR STR SHIPPED RENEW PENDING RENEW OVERDUE OVERDUE RECALL CHECKED-IN LOST REAreq + REA + REA + SHIPPED SHIPPED REAreq + REA+ repeat SHIPPED REAreq - REA - REA - SHIPPED OVERDUE REAreq - REA - REA - repeat SHIPPED OVERDUE ILL ILLind ILLind ILLind ILLind ILLind SHIPPED OVERDUE RECALL CHECKED- I N LOST ILL ILLind ILLind ILLind ILLind ILL i nd repeat SHIPPED OVERDUE RECALL CHECKED-IN LOST CAN CAN i nd CANind CANind CANind CANind CANind CANind SHIPPED RENEW PENDING RENEW OVERDUE OVERDUE RECALL CHECKED- I N LOST CAN repeat CANind SHIPPED CAN ind RENEW PENDING CANind RENEW OVERDUE CANind OVERDUE CANind RECALL CANind CHECKED-IN CANind LOST RCV RCVind SHIPPED RCVind RENEW PENDING RCVind RENEW OVERDUE RCVind OVERDUE RCVind RECALL RCVind CHECKED-IN RCVind LOST RCV repeat RCVind SHIPPED RCVind RENEW PENDING RCVind RENEW OVERDUE RCVind OVERDUE RCVind RECALL RCVind CHECKED-IN RCVind LOST RET RETind SHIPPED RETind RENEW PENDING RETind RENEW OVERDUE RETind OVERDUE RETind RECALL RETind CHECKE D -IN RETind LOST RET repeat RETind SHIPPED RETind RENEW PENDING RETind RENEW OVERDUE RETind OVERDUE RETind RECALL RETind CHECKED-IN RETind LOST REN p7 RENind RENEWPENDING RENind RENEW PENDING RENind RENEW OVERDUE RENind RENEW OVERDUE REN i nd RECALL RENind CHECKED-IN RENind LOST REN ^ p7 RENind SHIPPED RENind RENEW PENDING RENind RENEW OVERDUE RENind RENEW OVERDUE RENind RECALL RENind CHECKED-IN RENind LOST REN repeat REN i nd SHIPPED RENind RENEW PENDING RENind RENEW OVERDUE RENind OVERDUE RENind RECALL RENind CHECKED-IN RENind LOST LST LSTind LOST LSTind LOST LSTind LOST LSTind LOST LSTind LOST LSTind CHECKED-IN LSTind LOST LST repeat LSTind CHECKED-IN LSTind LOST DAM DAMind SHIPPED DAMind RENEW PENDING DAMind RENEW OVERDUE DAMind OVERDUE DAMind RECALL DAMind CHECKED-IN DAMind LOST MSG MSGind SHIPPED MSGind RENEW PENDING MSGind RENEW OVERDUE MSGind OVERDUE MSGind RECALL MSGind CHECKED-IN MSGind LOST STQ STQind SHIPPED STQ i nd RENEW PENDING STQind RENEW OVERDUE STQ i nd OVERDUE STQind RECALL STQind CHECKED-IN STQind LOST STR STRind SHIPPED STRind RENEW PENDING STRind RENEW OVERDUE STRind OVERDUE STRind RECALL STRind 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 CANCEL-PENDING CANCELLED SHIPPED ILLreq p2 or p3 ILL update CHAIN var update PART var PENDING ILLreq repeat ILL PENDING ILL NOT-SUP-PLIED ILL CONDITIONAL ILL SHIPPED C-REPreq + C-REP + NOT-SUP-PLIED C-REP + PENDING ILlreq p2 or p3 ILL update CHAIN var update PART var PENDING C-REPreq+ 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) set RETURN var SHIPPED RCV (opt) set RETURN var SHIPPED p6 RCV (opt) set RETURN var SHIPPED RCVreq repeat RCV (opt) SHIPPED RETreq RET (opt) SHIPPED p6 RET SHIPPED RETreq repeat RET SHIPPED RENreq REN SHIPPED p6 REN SHIPPED RENreq repeat REN SHIPPED LSTreq LST SHIPPED p6 LST SHIPPED LSTreq repeat LST SHIPPED ILLreq p2 or p3 ILL update CHAIN var update PART var PENDING DAMreq DAM SHIPPED DAM SHIPPED p6 DAM SHIPPED MSGreq MSG PENDING MSG NOT-SUP-PLIED MSG CONDITIONAL MSG CANCEL-PENDING MSG CANCELLED MSG SHIPPED STQreq STQ PENDING STQ NOT-SUP-PLIED STQ CONDITIONAL STQ CANCEL-PENDING STQ CANCELLED STQ SHIPPED STRreq STR PENDING STR NOT-SUP-PLIED STR CONDITIONAL STR CANCEL-PENDING STR CANCELLED STR SHIPPED FWD FWDind PENDING FWDind PENDING FWD repeat FWDind PENDING ANS-CO p7 ANS i ndCO CONDITIONAL ANSind-CO NOT-SUP-PLIED ANSind-CO CONDITIONAL ANSind-CO CANCEL-PENDING ANSind-CO CANCELLED ANS-CO ^ p7 ANSind-CO PENDING ANSind-CO NOT-SUP-PLIED ANSind-CO CONDITIONAL ANSind-CO CANCEL-PENDING ANSind-CO CANCELLED ANS-CO repeat ANSind-CO PENDING ANSind-CO NOT-SUP-PLIED ANSind-CO CONDITIONAL ANS i nd-CO CANCEL-PENDING ANSind-CO CANCELLED ANS-RY ANS i nd-RY NOT-SUPPLIED ANSind-RY NOT-SUP-PLIED ANSind-RY NOT-SUPPLI E D 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 ILLreq 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 CONDITIONAL ANSind-WS CANCEL-PENDING ANSind CANCELLED WSAN-Sind-WS SHIPPED ANS-WS repeat ANSind-WS PENDING ANSind-WS NOT-SUP-PLIED ANSind-WS CONDITIONAL ANSind-WS CANCEL- PENDING ANSind-WS CANCELLED ANSind-WS SHIPPED ANS-HP ANSind-HP PENDING ANS i nd-HP NOT-SUP-PLIED ANSind-HP CONDITIONAL ANSind-HP CANCEL-PENDING ANS i nd-HP CANCELLED ANSind- HP SHIPPED ANS-HP repeat ANSind-HP PENDING ANS i nd-HP NOT-SUP-PLIED ANSind-HP CONDITIONAL ANS i nd-HP CANCEL-PENDING ANSind-HP CANCELLED ANS i nd-HP SHIPPED ANS-ES ANS i nd-ES NOT- SUPPLIED ANS i nd-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 CAR i nd - PENDING CAR i nd - SHIPPED CAR - repeat CAR i nd - PENDING CARind - SHIPPED SHI SHI i nd SHIPPED SHI i nd SHIPPED SHIind SHIPPED SHI repeat SHI i nd SHIPPED DUE DUEind SHIPPED p6 DUEind SHIPPED DUE repeat DUE i nd SHIPPED ILLreq p2 or p3 ILL update CHAIN var update PART 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 LST i nd SHIPPED DAM p6 DAM i nd SHIPPED RCL RCLind SHIPPED p6 RCL i nd RCL repeat RCLind SHIPPED MSG MSG i nd PENDING MSGind NOT-SUP-PLIED MSG i nd CONDITIONAL MSGind CANCEL-PENDING MSGind CANCELLED MSGind SHIPPED STQ STQind PENDING STQind NOT-SUP-PLIED STQind CONDITIONAL STQind CANCEL-PENDING STQind CANCELLED STQind SHIPPED STR STRind PENDING STRind NOT-SUP- PLIED STR i nd CONDITIONAL STRind CANCEL-PENDING STRind CANCELLED STRind SHIPPED EXP EXPind NOT-SUPPLIED EXPind NOT-SUP-PLIED EXPind NOT-SUPPLIED EXP i nd NOT-SUPPLIED ILLreq p2 or p3 ILL update CHAIN var update PART var PENDING CHK CHKind SHIPPED CHKind SHIPPED p6 CHKind SHIPPE CHK repeat CHKind SHIPPED Bảng A.10 - Bảng trạng thái người trung gian: Va i trò bên đáp ứng IDLE IN-PROCESS NOT-SUP-PLIED CONDITIONAL CANCEL-PENDING CANCELLED FORWARD SHIPPED ILL ILLind set FWDvar set CHAIN var set PART var set EXPIRY timer IN-PROCESS ILL i nd IN-PROCESS ILL i nd NOT-SUP-PLIED ILL i nd CONDITIONAL ILLind FORWARD ILLind SHIPPED ILL repeat ILLind IN-PROCESS ILLind NOT-SUP-PLIED ILLind CONDITIONAL ILLind FORWARD ILLind SHIPPED FWDreq p4 ILL FWD disable EXPIRY timer FORWARD FWDreq repeat ILL FWD FORWARD ANSreq-CO ANS-CO reset EXPIRY timer CONDITIONAL ANS-CO CANCEL-PENDING ANS-CO CANCELLED ANS- COreq repeat ANS-CO disable EXPIRY timer IN-PROCESS 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 ILLind NOT-SUP-PLIED ILLind CONDITIONAL ILLind FORWARD ILLind SHIPPED ANS-RYreq 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 ANS-LP 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 CONDITIONAL 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 CANCELLED ANS-WS SHIPPED ANS-HPreq ANS-HP disable EXPIRY timer IN-PROCESS ANS-HP NOT-SUP-PLIED ANS-HP CONDITIONAL ANS-HP CANCEL-PENDING ANS-HP CANCELLED ANS-HP SHIPPED ILL ILLind set FWDvar set CHAIN var set PART var set EXPIRY timer IN-PROCESS ILLind IN-PROCESS ILLind NOT-SUP-PLIED ILLind CONDITIONAL ILLind FORWARD ILLind SHIPPED ANS-HPreq repeat ANS-HP IN-PROCESS ANS-HP NOT-SUP-PLIED ANS-HP CONDITIONAL ANS-HP CANCEL-PENDING ANS-HP 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- SHIPPED CARreq- repeat CAR- IN-PROCESS CAR- SHIPPED Bảng A.11 - Bảng trạng thái người trung gian: va i trò bên đáp ứng SHIreq SHI set RETURN var disable EXPIRY timer SHIPPED SHI set RETURN variable disable EXPIRY timer SHIPPED SHI SHIPPED SHIreq repeat SHI SHIPPED MSGreq MSG IN-PROCESS MSG NOT-SUP-PLIED MSG CONDITIONAL MSG CANCEL-PENDING MSG CANCELLED MSG FORWARD MSG SHIPPED STQreq STQ IN-PROCESS STQ NOT-SUP-PLIED STQ CONDITIONAL STQ CANCEL-PENDING STQ CANCELLED STQ FORWARD STQ SHIPPED STRreq STR IN-PROCESS STR NOT-SUP-PLIED STR CONDITIONAL STR CANCEL-PENDING STR CANCELLED STR FORWARD STR SHIPPED CHKreq CHK (opt) SHIPPED CHK(opt) SHIPPED p 6 CHK (opt) SHIPPED CHKreq repeat CHK (opt) SHIPPED DUEreq DUE SHIPPED p6 DUE SHIPPED DUEre q re p eat DUE SHIPPED REAreq + p6 REA + SHIPPED REAreq + repeat REA+ SHIPPED REAreq - p6 REA- SHIPPED REAreq -repeat REA- SHIPPED RCLreq RCL SHIPPED p6 RCL SHIPPED RCLreq repeat RCL SHIPPED LSTreq LST SHIPPED LST SHIPPED p6 LST SHIPPED LSTreq repeat LST SHIPPED DAMreq p6 DAM SHIPPED C-REP + C-REPind + IN- C-REPind + C-REPind + PROCESS NOT-SUP-PLIED reset EXPIRY timer IN-PROCESS 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- repeat - NOT-SUP-PLIED CAN P7 CANind CANind CANind CANind CANind CANind CANind CANCEL-PENDING NOT-SUP-PLIED CANCEL-PENDING CANCEL-PENDING CANCELLED FORWARD SHIPPED CAN ^ P7 CANind CANind CANind CANind CANind CANind CANind IN-PROCESS NOT-SUP-PLIED CANCEL-PENDING CANCEL-PENDING CANCELLED FORWARD SHIPPED CAN CANind CANind CANind CANind CANind CANind CANind repeat IN-PROCESS NOT-SUP-PLIED CANCEL-PENDING CANCEL-PENDING CANCELLED FORWARD SHIPPED MSG MSGind MSGind MSGind MSGind MSGind MSGind MSGind IN-PROCESS NOT-SUP-PLIED CONDITIONAL CANCEL-PENDING CANCELLED FORWARD SHIPPED STQ STQind IN-PROCESS STQind NOT-SUP-PLIED STQind CONDITIONAL STQind CANCEL-PENDING STQind CANCELLED STQind FORWARD STQind SHIPPED STR STRind IN-PROCESS STRind NOT-SUP-PLIED STRind CONDITIONAL STRind CANCEL-PENDING STRind CANCELLED STRind FORWARD STRind SHIPPED RCV RCVind SHIPPED RCVind SHIPPED p6 RCVind SHIPPED RCV repeat RCVind SHIPPED RET RETind SHIPPED p6 RETind SHIPPED RET repeat RETind 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 Timeout 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. Tất cả các dữ liệu được truyền giữa hai địa điểm trong một lần được định nghĩa là một trao đổi. Nói cách khác, một trao đổi tạo thành từ một hoặc nhiều thông báo. Mỗi APDU ILL truyền được mã hóa dưới dạng thông báo EDIFACT đơn; mỗi thông báo EDIFACT ch ứ a chính xác một APDU ILL. 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. Một trao đổi được tạo thành từ một số đoạn. Mỗi đoạn bắt đầu với một mã đoạn ba ký tự, theo thứ tự là dấu phân cách mã đoạn, nội dung đoạn, và kết thúc dấu phân cách đoạn. Kết thúc dấu phân cách đoạn được định nghĩa là k ý tự "". Dấu phân cách mã đoạn được định nghĩa là ký tự "+". 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+... Ký tự "?" là một ký tự thoát . Nếu phần tử dữ liệu hoặc phần tử con ch ứ a một trong những ký tự đặc biệt "+ ':?" thì ký tự đặc biệt đó phải được đi trước bởi một dấu "?". Sau đây là định nghĩa của một tr ao đổ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 _l ist segment:: = segment_code "+" segment_content segment_code:: = alpha alpha alpha segment_content:: = data_element I data_element"+" segm e nt_cont e nt 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 special_character:: = "??" I "?+" I "?": I "?" 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 tạo nên một trao đổi được phân loại là đoạn kiểm soát hoặc là đoạn dữ liệu. 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. G i á 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ả Tư v ấ n chuỗi dịch vụ 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 Cho biết bắt đầu một trao đổi. Phải là đoạn thứ hai của trao đổi 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 Mô tả 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 Mô tả 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ả Các phần tử dữ liệu 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ả Xác định các quy tắc cú pháp. Bao gồm 2 phần tử dữ liệu con: 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 Mô tả 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 Phần tử dữ liệu 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ả 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 c hỉ 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 Mô tả 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 Phần tử dữ liệu 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ểu diễn 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) ILLREQ Forward-Notification (Thông báo chuyển tiếp) FORNOT Shipped (Đã chuyển) SH I PED ILL-Answer (Câu trả lời ILL) ILLANS Conditional-Reply (Trả lời có điều CONREP Cancel (Hủy) CANCEL Cancel-Reply (Trả lời Hủy) CNLREP Received (Đã Nhận) RCEIVD Recall (Đòi) RECALL Returned (Đã Trả) RETRND Checked-ln (Kiểm nhận) CHKDIN 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) DAMAGE 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 Điều này cung cấp một ánh xạ từ các kiểu ASN.I vào các đoạn EDIFACT, các phần tử dữ liệu và các phần tử con. Phép ánh xạ này tận dụng các đoạn lồng ẩn và lặp tiềm ẩn. 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, c huỗ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. Các klểu ASN.I được định nghĩa là Bên ngoài (EXTERNAL) được ánh xạ vào các phần tử dữ liệu EDIFACT với phần tử con đầu tiên được định nghĩa là một ký hiệu nhận dạng đối tượng. Các phần tử con còn lại được định nghĩa bên ngoài, nhưng phải phù hợp với các kiểu đơn giản ASN.1 được hỗ trợ trong đặc tả này. 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 ATL 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 địa chỉ thanh toá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 CID 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 - 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: đ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 điều kiện 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 COI 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 loại thông tin chi phí Mã đoạn C IT 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ệ } thỏa thuận đối ứng 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 ngày Kiểm nhậ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 trường ngày đến hạn 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 Mã đoạ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ả Tên đoạn đị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] - lưu ý đoạn này đã được đổi tên từ cung cấp vật lý. Để duy trì khả năng tương thích với các hệ thống hiện có, Mã đoạn vẫn là DLS. Trường hợp APDU đòi hỏi một sự lựa chọn Cung cấp vật lý hoặc Dịch vụ cung cấp điện tử, một DLS hoặc các đoạn EDY (lặp) sẽ được sử dụng. 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 EDY 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 đị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 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 - 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 hoặc mã 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 nguồn báo cáo 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 thông tin vị trí - đ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 Mã đoạn 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". - Không có phần mở rộng được xác định cho các phiên bản 1 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 Mã đoạn 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 Tên đoạn 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 Phần tử dữ liệu 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 hoặc tổ chức { 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 chỉ một trong những phần tử con này có thể có mặt } 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 loại vật mang tin đặt giữ 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 - đoạn phụ thuộc cuối c ù ng có thể được lặp 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 Mã đoạn 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 Mã đoạn 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 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 có thể có mặt } Tên đoạn Id tài liệu Mã đoạn HD Phần tử dữ liệu 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 số tùng thư- nhan đề 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 hệ thống- số 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 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 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 } địa chỉ vị trí { 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 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: 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 Tên đoạn 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 Phần tử dữ liệu 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 Mã đoạn 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 Tên đoạn 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 POH 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 cá nhân 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 mã bưu điện 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 ưu tiên 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 cấm chuyển trạng thái { 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 Mã đ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ó Mã đoạn 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 Tên đoạ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 Phần tử dữ liệu nguồn báo cáo Tên đoạn I d 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 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 chú thích bên yêu cầu 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 Nhận 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 địa chỉ 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 - 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 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 Mã đoạn 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 có thể gửi đã Kiểm nhận 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 Tên đoạn 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 RYD 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 kết quả thực hiện lại 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 trả lại qua 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 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ỉ cung cấp bưu chính mở rộng đường phố và số nhà hộp thư thành phố vùng 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 ngày hết hạn 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, số tài khoản đị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 { ngà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 Mã đoạn 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: báo cáo l ị ch sử 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 Tên đoạn 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 Tên đoạn 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 ngày chuyển đi - 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ử - ba phần tử tiếp theo cùng nhau tạo thành - 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 hoặc tổ chức { 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 - chỉ có một trong các phần tử con này có thể có mặt } 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ệ } không có đơn vị cho mỗi loại vật mang tin { 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 SMI 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 Phần tử dữ liệu 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 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 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 phân khu 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 - hai phần tử dữ liệu đầu tiên cùng nhau tạo thành - 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 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 } 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 TRE 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 kết quả không thực hiệ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 báo cáo lỗi của người dùng 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 - 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 } địa chỉ bên đáp ứng { ký hiệu nhận dạng dịch vụ viễn thô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 Tên đoạn 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 thông tin vị trí - đ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/07 + 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 b i t 03/00, và Đúng tương ứng với chuỗi b i t 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 (Quy định) 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) CHÚ THÍCH: Không có ký hiệu nhận dạng đối tượng được gán cho các cú pháp truyền cho các APDU ILL tạo thành từ việc áp dụng các ASN.I Quy tắc mã hóa cơ bản (ISO/IEC 8825). Với các mục đích thỏa thuận ngữ cảnh trình bày, cú pháp này được xác định bởi một cặp ký hiệu nhận dạng đối tượng: một cho cú pháp trừu tượng và một cho các quy tắc mã hóa cơ bản: - {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 (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 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. D.2 Phạm vi và lĩnh vực ứng dụng của định nghĩa kiểu dữ liệu Bên ngoài ILL Đị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à d) định nghĩa cú pháp trừu tượng ASN.I chính thức cho kiểu dữ liệu Bên ngoài, phù hợp với tiêu chuẩn ISO/IEC 8824-1:2008, Điều 37. 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 [Để nghiên cứu tiếp] D.7.2 Phương pháp g i ả 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) 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 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 { single-ASNI-type [0] ANY DEFINED BY NLC-Responder-Specific-Services } } NLC-Responder-Spedfic-Services:: = ENUMERATED { Urgent Action (1), Delivery by Facsimile (2), Abstract Acceptable (3) } Phụ lục F (tham khảo) 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 F2 Ánh xạ lưu trữ và chuyển tiếp 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 d a nh 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 959. Giao thức truyền tệp (FTP): FTP có thể mang các tài liệu điện tử được mã hóa trong định dạng ASCII hoặc nhị phân. - 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 th a m khảo [1] ISO 2709 , Information and documentation - Format for information exchange (Thông tin và Tư liệu - Định dạng trao đổ i thông tin). [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 - F ile 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 - Se rvice definition for the Association Con tr ol Service Element (Hệ thống xử l ý thông tin - Liên kết các hệ t hố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 - L iê 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). [12] ISO/IEC 9545:1994, Information technology - Open Systems Interconnection - Application Layer structure (Công nghệ thông tin - Liê n kết các hệ thống mở - C ấ u trúc tầng ứng dụng). [13] ISO/IEC 10021-4:1990, Information technology - Text Communication - Message - Oriented Text Interchange Systems (MOTI SJ - 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 Tổng quan về giao thức 5.1 Cung cấp dịch vụ 5.2 Dịch vụ hỗ trợ g i ả đị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.5 Thông tin yêu cầu 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.2 Sự phù hợp động 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