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

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

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)

...

...

...

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

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

ĐÃ CHUYỂN (SHIPPED)

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

TRẢ LỜI ILL (ILL-ANSWER)

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

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

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

HỦY (CANCEL)

...

...

...

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

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

ĐÃ NHẬN (RECEIVED)

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

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

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

ĐÃ TRẢ LẠI (RETURNED)

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

KIỂM NHẬN (CHECKED-IN)

...

...

...

QUÁ HẠN (OVERDUE)

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

GIA HẠN (RENEW)

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

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

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

ĐÃ MẤT (LOST)

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

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

...

...

...

THÔNG BÁO (MESSEAGE)

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

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

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

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

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

HẾT HẠN (EXPIRY)

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

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

...

...

...

5.3  Mô hình

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

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

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

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

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

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

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

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

...

...

...

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

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

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

YÊU CẦU ILL

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

VẬN CHUYỂN

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

TRẢ LỜI ILL

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

...

...

...

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

HỦY

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

TRẢ LỜI HỦY

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

ĐÃ NHẬN

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

ĐÒI

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

...

...

...

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

KIỂM NHẬN

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

QUÁ HẠN

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

GIA HẠN

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

TRẢ LỜI GIA HẠN

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

...

...

...

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

HƯ HẠI

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

THÔNG BÁO

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

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

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

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

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

...

...

...

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

7  Thông tin giao dịch

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

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

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

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

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

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

- Thông tin lịch sử.

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

Giao dịch đơn giản

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

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

...

...

...

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

Tùy chọn

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

Bắt buộc

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

Bắt buộc

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

Không sử dụng

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

...

...

...

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

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

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

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

Bắt buộc

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

Bắt buộc

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

Bắt buộc

...

...

...

Bắt buộc

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

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

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

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

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

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

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

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

...

...

...

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

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

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

NHÀN RỖI

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

ĐANG CHỜ

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

KHÔNG CUNG CẤP

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

...

...

...

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

ĐANG CHỜ HỦY

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

ĐÃ HỦY

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

ĐÃ CHUYỂN

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

ĐÃ NHẬN

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

...

...

...

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

GIA HẠN/QUÁ HẠN

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

QUÁ HẠN

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

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

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

ĐÒI

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

...

...

...

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

MẤT

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

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

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

NHÀN RỖI (IDLE)

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

ĐANG XỬ LÝ

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

...

...

...

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

KHÔNG CUNG CẤP

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

ĐIỀU KIỆN

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

ĐANG CHỜ HỦY

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

ĐÃ HỦY

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

...

...

...

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

GIA HẠN/ĐANG CHỜ

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

GIA HẠN/QUÁ HẠN

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

QUÁ HẠN

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

ĐÒI

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

...

...

...

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

MẤT

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

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

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

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

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

- KHÔNG-CUNG CẤP;

- ĐÃ HỦY;

...

...

...

- ĐÃ TRẢ;

- MẤT

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

- KHÔNG-CUNG CẤP;

- ĐÃ HỦY;

- CHUYỂN TIẾP;

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

- ĐÃ KIỂM NHẬN;

- MẤT

...

...

...

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

- KHÔNG-CUNG CẤP;

- CHUYỂN TIẾP;

- ĐÃ HỦY

ĐÃ CHUYỂN ĐI

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

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

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

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

...

...

...

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

TRẢ (RETURN)

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

CHUYỂN TIẾP (FWD)

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

PHÂN KHU (PART)

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

CHUỖI (CHAIN)

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

7.5  Thông tin yêu cầu

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

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

7.5.1  ID hệ thống

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

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

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

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

...

...

...

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

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

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

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

7.6  Thông tin lịch sử

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

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

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

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

...

...

...

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

- Kết quả giao dịch;

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

Trả lời = KHÔNG

- HỦY-YÊU CẦU

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

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

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

- HỦY. yêu cầu

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

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

...

...

...

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

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

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

- ĐÃ CHUYỂN ĐI

- CÂU TRẢ LỜI- ILL

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

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

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

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

...

...

...

- CÂU TRẢ LỜI ILL:

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

- CÂU TRẢ LỜI ILL:

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

- CÂU TRẢ LỜI ILL:

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

- TRẢ LỜI -HỦY

- ĐÒI

- KIỂM NHẬN

...

...

...

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

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

- MẤT

- HƯ HẠI

- THÔNG BÁO

- HỎI TRẠNG THÁI

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

- HẾT HẠN.

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

- ĐÒI. chỉ thị

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

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

- QUÁ HẠN. chỉ thị

...

...

...

Câu trả lời = CÓ

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

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

- MẤT. chỉ thị

- HƯ HẠI. chỉ thị

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

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

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

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

...

...

...

- Yêu cầu ILL

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

Câu trả lời=Có

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

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

- Hủy

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

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

- GIA HẠN

...

...

...

- HƯ HẠI

- THÔNG BÁO

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

- ĐÒI.yêu cầu

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

...

...

...

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

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

- MẤT.yêu cầu

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

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

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

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

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

- YÊU CẦU ILL

...

...

...

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

- HỦY

- ĐÃ NHẬN

- ĐÃ TRẢ

- GIA HẠN

- MẤT

- HƯ HẠI

- THÔNG BÁO

- HỎI TRẠNG THÁI

...

...

...

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

- HẾT THỜI HẠN

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

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

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

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

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

- HỦY.chỉ thị

- ĐÃ NHẬN.chỉ thị

...

...

...

-GIA HẠN.chỉ thị

- MẤT.chỉ thị

- HƯ HẠI.chỉ thị

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

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

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

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

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

- YÊU CẦU ILL

...

...

...

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

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

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

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

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

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

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

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

- TRẢ LỜI HỦY

...

...

...

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

- QUÁ HẠN

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

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

- MẤT

- HƯ HẠI

- THÔNG BÁO

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

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

...

...

...

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

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

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

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

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

8.2.1  Gửi và nhận APDU

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

8.2.3.1  Giao dịch đơn giản

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

- Gửi APDU ĐÃ CHUYỂN;

- Gửi APDU ĐÃ NHẬN;

- Gửi APDU ĐÃ TRẢ;

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

8.2  Danh sách gửi đến

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

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

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

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

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

8.2.5  Danh sách đã thử

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

8.2.8 APDU được lặp

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

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

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

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

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

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

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

...

...

...

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

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

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

8.2.9  Thực hiện lại

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

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

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

8.2.10  Hết hạn giao dịch

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

- Nhận APDU HỦY

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

8.2.11  Hủy giao dịch

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

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

...

...

...

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

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

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

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

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

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

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

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

8.2.13  Lỗi giao thức

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

8.2.18 Thông báo gửi

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

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

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

8.3.1  Chuyển tiếp giao dịch

...

...

...

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

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

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

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

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

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

8.3.2  Xâu chuỗi giao dịch

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

8.3.3  Phân khu giao dịch

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

10  Sự phù hợp

10.1  Sự phù hợp tĩnh

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

10.2  Sự phù hợp động

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

Phụ lục A

(Quy định)

Bảng trạng thái ILL

A.1  Tổng quan

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

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

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

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

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

...

...

...

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

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

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

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

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

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

A.2  Quy ước

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

A.3.1  Tổng quan

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

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

...

...

...

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

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

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

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

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

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

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

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

Tên viết tắt

...

...

...

ILLreq

FWDreq

ANSreq-CO

ANSreq-RY

ANSreq-UN

ANSreq-LP

ANSreq-WS

ANSreq-HP

ANSreq-ES

...

...

...

C-REPreq -

CANreq

CARreq +

CARreq -

SHIreq

RCVreq

RCLreq

DUEreq

RETreq

...

...

...

REAreq +

REAreq -

CHKreq

LSTreq

DAMreq

MSGreq

STQreq

STRreq

ILL

...

...

...

FORWARD.request

ILL-ANSWER.request: result = CONDITIONAL

ILL-ANSWER.request: result = RETRY

ILL-ANSWER.request: result = UNFILLED

ILL-ANSWER.request: result = LOCATION-PROVIDED

ILL-ANSWER.request: result = WILL-SUPPLY

ILL-ANSWER.request: result = HOLD PLACED

ILL-ANSWER.request: result = ESTIMATE

CONDITIONAL-REPLY.request: answer = yes

...

...

...

CANCEL.request

CANCEL-REPLY.request: answer = yes

CANCEL-REPLY.request: answer = no

SHIPPED.request

RECEIVED.request

RECALL.request

OVERDUE.request

RETURNED.request

RENEW.request

...

...

...

RENEW-ANSWER.request: answer = no

CHECKED-IN.request

LOST.request

DAMAGED.request

MESSAGE.request

STATUS-QUERY.request

STATUS-OR-ERROR-RE PORT, request

receive ILL-REQUEST APDU

FWD

...

...

...

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP+

C-REP-

CAN

...

...

...

CAR -

SHI

RCV

RCL

DUE

RET

REN

REA +

REA -

...

...

...

LST

DAM

MSG

STQ

STR

EXP

EXPIRY timeout

receive FORWARD-NOTIFICATION APDU

receive ILL-ANSWER APDU: result = CONDITIONAL

...

...

...

receive ILL-ANSWER APDU: result = UNFILLED

receive ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

receive ILL-ANSWER APDU: result - WILL-SUPPLY

receive ILL-ANSWER APDU: result = HOLD PLACED

receive ILL-ANSWER APDU: result = ESTIMATE

receive CONDITIONAL-REPLY APDU: answer = yes

receive CONDITIONAL-REPLY APDU: answer = no

receive CANCEL APDU

receive CANCEL-REPLY APDU: answer = yes

...

...

...

receive SHIPPED APDU

receive RECEIVED APDU

receive RECALL APDU

receive OVERDUE APDU

receive RETURNED APDU

receive RENEW APDU

receive RENEW-ANSWER APDU: answer = yes

receive RENEW-ANSWER APDU: answer = no

receive CHECKED-IN APDU

...

...

...

receive DAMAGED APDU

receive MESSAGE APDU

receive STATUS-QUERY APDU

receive STATUS-OR-ERROR-REPORT APDU

receive EXPIRED APDU

Transaction Timer Expiry

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

Tên viết tắt

Mô tả

...

...

...

FWDind

ANSind-CO

ANSind-RY

ANSind-UN

ANSind-LP

ANSind-WS

ANSind-HP

ANSind-ES

C-REPind +

...

...

...

CANind

CARind +

CARind -

SHIind

RCVind

RCLind

DUEind

RETind

RENind

...

...

...

REAind -

CHKind

LSTind

DAMind

MSGind

STQind

STRind

EXPind

ILL

...

...

...

ANS-CO

ANS-RY

ANS-UN

ANS-LP

ANS-WS

ANS-HP

ANS-ES

C-REP +

C-REP -

...

...

...

FORWARD.indication

ILL-ANSWER.indication: result = CONDITIONAL

ILL-ANSWER.indication: result = RETRY

ILL-ANSWER.indication: result = UNFILLED

ILL-ANSWER.indication: result = LOCATIONS-PROVIDED

ILL-ANSWER.indication: result = WILL-SUPPLY

ILL-ANSWER.indication: result = HOLD PLACED

ILL-ANSWER.indication: result = ESTIMATE

CONDITIONAL-REPLY.indication: answer = yes

...

...

...

CANCEL.indication

CANCEL-REPLY.indication: answer = yes

CANCEL-REPLY.indication: answer = no

SHIPPED.indication

RECEIVED.indication

RECALL.indication

OVERDUE.indication

RETURNED.indication

RENEW.indication

...

...

...

RENEW-ANSWER.indication: answer = no

CHECKED-IN.indication

LGST.indication

DAMAGED.indication

MESSAGE.indication

STATUS-QUERY.indication

STATUS-OR-ERROR-REPORT.indication

EXPIRY,indication

send ILL-REQUEST APDU

...

...

...

send ILL-ANSWER APDU: result = CONDITIONAL

send ILL-ANSWER APDU: result = RETRY

send ILL-ANSWER APDU: result = UNFILLED

send ILL-ANSWER APDU: result = LOCATIONS-PROVIDED

send ILL-ANSWER APDU: result = WILL-SUPPLY

send ILL-ANSWER APDU: result = HOLD PLACED

send ILL-ANSWER APDU: result = ESTIMATE

send CONDITIONAL-REPLY APDU: answer = yes

send CONDITIONAL-REPLY APDU: answer = no

...

...

...

CAR +

CAR -

SHI

RCV

RCL

DUE

RET

REN

REA +

...

...

...

CHK

LST

DAM

MSG

STQ

STR

EXP

send CANCELAPDU

send CANCEL-REPLY APDU: answer = yes

...

...

...

send SHIPPED APDU

send RECEIVED APDU

send RECALL APDU

send OVERDUEAPDU

send RETURNED APDU

send RENEW APDU

send RENEW-ANSWER APDU: answer = yes

send RENEW-ANSWER APDU: answer = no

send CHECKED-IN APDU

...

...

...

send DAMAGED APDU

send MESSAGE APDU

send STATUS-QUERY APDU

send STATUS-OR-ERROR-REPORT APDU

send EXPIRED APDU

Bảng A.3 - Vị từ

Mã

Ỹ nghĩa

p1

...

...

...

p2

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

p3

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

p4

returns TRUE if the FWD protocol variable is TRUE

p5

returns TRUE if the RETURN protocol variable is TRUE

p6

...

...

...

p7

returns TRUE if a received APDU is in sequence

p8

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

p9

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

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

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

...

...

...

PENDING

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

SHIPPED

ILLreq

p1 ILL PENDING

...

...

...

ILLreq

ILL

...

...

...

repeat

PENDING

...

...

...

C-REPreq

C-REP +

+

...

...

...

PENDING

C-REPreq

C-REP +

...

...

...

+ repeat

PENDING

...

...

...

C-REPreq

C-REP-

...

...

...

-

NOT-SUP-PLIED

ILUeq

...

...

...

PENDING

...

...

...

C-REPreq -

C-REP-

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

CANreq

CAN

...

...

...

CANCEL-

PENDING

...

...

...

CANreq

...

...

...

repeat

CANCEL-

...

...

...

PENDING

RCVreq

...

...

...

RCV (opt)

RCV (opt)

RCV(opt)

set RETURN
var

...

...

...

set RETURN
var

set RETURN
var

LSTreq

LST

...

...

...

LST

LOST

LOST

...

...

...

MSGreq

MSG
PENDING

MSG

MSG

MSG

MSG

MSG
SHIPPED

...

...

...

CONDITIONAL

STQreq

STQ

...

...

...

STQ
CONDITONAL

STQ

STQ
CANCELLED

STQ

SHIPPED

PENDING

NOT-SUP-

...

...

...

CANCEL-

PENDING

STRreq

STR

...

...

...

STR
CONDITIONAL

STR

CANCEL-

PENDING

STR
CANCELLED

STR

PENDING

NOT-SUP-PLIED

...

...

...

FWD

FWDind

FWDind

...

...

...

PENDING

PENDING

FWD

FWDind

...

...

...

repeat

PENDING

...

...

...

ANS-CO

p7

ANSind-CO

ANSind-CO
CONDITIONAL

p7

ANSind-CO

...

...

...

ANSind-CO CONDITIONAL

NOT-SUP-PLIED

ANSind-CO CANCEL-

CANCELLED

...

...

...

PENDING

ANS-CO

^p7

ANSind-CO

...

...

...

^p7

ANSind-CO
CANCELLED

ANSind-CO

...

...

...

ANSind-CO

NOT-SUP-

CANCEL-

ANS-CO

ANSind-CO

ANSind-CO

...

...

...

ANSind-CO

ANSind-CO
CANCELLED

repeat

ANS-RY

...

...

...

ANSind-RY

ANSind-RY

NOT-SUP-
PLIED

NOT-SUP-
PLIED

NOT-SUP-
PLIED

ILLreq

...

...

...

PENDING

...

...

...

ANS-RY
repeat

ANSind-RY

...

...

...

NOT-SUP-
PLIED

...

...

...

ANSind-UN

ANSind-UN

ANSind-UN

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-UN

ANSind-UN

...

...

...

repeat

NOT-SUP-PLIED

...

...

...

ANS-LP

ANSind-LP

ANSind-LP

ANSind-LP

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

ANS-LP

...

...

...

ANSind-LP

repeat

NOT-SUP-PLIED

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

ANSind-WS

...

...

...

ANSind-WS

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

...

...

...

ANS-WS

ANSind-WS

ANSind-WS

ANSind-WS
CONDITIONAL

ANSind-WS

ANSind-WS

repeat

...

...

...

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

SHIPPED

ANS-HP

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

PENDING

NOT-SUP-PLIED

...

...

...

CANCEL-

SHIPPED

PENDING

...

...

...

ANS-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

ANSind-HP

...

...

...

PENDING

SHIPPED

repeat

...

...

...

CONDITIONAL

ANS-ES

ANSind-ES

ANSind-ES

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

...

...

...

ANS-ES

ANSind-ES

repeat

...

...

...

NOT-SUP-PLIED

CAR +

...

...

...

CARind +

CARind +

...

...

...

CANCELLED

CAR +

CARind +

...

...

...

repeat

CANCELLED

CAR -

...

...

...

CARind -

CARind -

CARind -

PENDING

...

...

...

PENDING

SHIPPED

CAR -

CARind -

...

...

...

CARind -

repeat

PENDING

...

...

...

SHI

SHIind

SHIind

SHIind

...

...

...

SHIPPED

SHIPPED

SHIPPED

ILLeq

p1 ILL

...

...

...

PENDING

...

...

...

SHI

...

...

...

repeat

SHIPPED

DUE

...

...

...

DUEind

DUEind

DUEind

set RETURN

...

...

...

set RETURN

set RETURN

var = TRUE

...

...

...

var = TRUE

RCL

RCLind

RCLind

...

...

...

set RETURN

set RETURN

set RETURN

CHK

...

...

...

CHKind

CHKind

CHKind

set RETURN

...

...

...

set RETURN

set RETURN

MSG

MSGind

MSGind

MSGind

...

...

...

MSGind

MSGind

PENDING

CONDITIONAL

...

...

...

STQ

STQind

STQind

STQind
CONDITIONAL

STQind

STQind

STQind

...

...

...

PENDING

CANCELLED

STR

STRind

STRind

...

...

...

STRind

STRind

STRind

PENDING

NOT-SUP-PLIED

CANCEL-

PENDING

...

...

...

SHIPPED

EXP

EXPind

EXPind

EXPind
NOT-SUP-PLIED

EXPind

...

...

...

NOT-SUP-PLIED

NOT-SUP-PLIED

NOT-SUP-PLIED

LST

...

...

...

LSTind

LSTind

LOST

...

...

...

LOST

LOST

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

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/OVERDUE

...

...

...

RCV(opt)

OVERDUE

RCVreq

repeat

RCV(opt)

RECEIVED

...

...

...

RET

req

p5

RET (opt)

RETURNED

RET (opt)

RETURNED

...

...

...

RETURNED

RETreq repeat

.

RCVreq

...

...

...

RCV (opt)

RENreq

p5 REN

RENEW/PENDING

REN

RENreq Repeat

...

...

...

REN

REN

LSTreq

p5 LST

LOST

LST LOST

LST LOST

LST LOST

...

...

...

DAMreq

DAM

DAM

DAM

...

...

...

MSGreq

MSG

MSG

MSG

MSG

STQreq

STQ

STQ

...

...

...

STQ

STRreq

STR

SIR

STR

STR

ANS-WS

...

...

...

RECEIVED

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/ OVERDUE

ANS-WS repeat

ANSind-WS

...

...

...

ANSind-WS

RENEW/PENDING

ANSind-WS

RENEW/OVERDUE

ANSind-WS

NOT-RCVD/OVERDUE

ANS-HP

ANSind-HP

RECEIVED

...

...

...

RENEW/PENDING

ANSind-HP

RENEW/OVERDUE

ANSind-HP

NOT-RCVD/OVERDUE

ANS-HP repeat

ANSind-HP

RECEIVED

ANSind-HP

...

...

...

ANSind-HP

RENEW/OVERDUE

ANSind HP

NOT-RCVD/OVERDUE

CAR -

CARind -

RECEIVED

CARind-

RENEW/PENDING

...

...

...

RENEW/OVERDUE

CARind -

NOT-RCVD/OVERDUE

CAR - repeat

CARind -

RECEIVED

CARind -

RENEW/PENDING

CARind -

...

...

...

CARind -

NOT-RCVD/OVERDUE

SHI

SHIind

RECEIVED

SHIind

RENEW/PENDING

SHIind

RENEW/OVERDUE

...

...

...

NOT-RCVD/OVERDUE

SHI
repeat

SHIind

RECEIVED

SHIind

RENEW/PENDING

SHIind

RENEW/OVERDUE

SHIind

...

...

...

RCL

p5 RCLind

RECALL

RCLind RECALL

RCLind RECALL

RCLind RECALL

RCL
repeat

...

...

...

RCVreq

DUE

p5 DUEind

DUEind

...

...

...

OVERDUE

OVERDUE

DUE

p5 DUEind

DUEind

...

...

...

OVERDUE

DUE
repeat

...

...

...

DUEind

LST

LSTind

LST
repeat

...

...

...

DAM

MSG

MSGind

...

...

...

MSGind

MSGind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/ OVERDUE

STQ

STQind

...

...

...

STQind

STQind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/ OVERDUE

STR

STRind

...

...

...

STRind

STRind

RECEIVED

RENEW/PENDING

RENEW/OVERDUE

NOT-RCVD/OVERDUE

REA +

P5

...

...

...

REAind + RECEIVED

REAind + RECEIVED

REA +
repeat

REAind +

...

...

...

RECEIVED

REA-

p5

REAind - RECEIVED

...

...

...

REAind - RECEIVED

REA-
repeat

REAind -

...

...

...

RECEIVED

CHK

p5

CHKind

CHKind

...

...

...

CHKind

RETURNED

RETURNED

RETURNED

RETURNED

...

...

...

CHK
repeat

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

OVERDUE

RETURNED

...

...

...

RECALL

RCVreq

RCV(opt)

...

...

...

RECALL

RCVreq

repeat

...

...

...

RCVreq

RCV (opt)

RETreq

RET (opt) RETURNED

...

...

...

RET (opt) RETURNED

RET (opt) RETURNED

RETreq

...

...

...

RENreq

REN

...

...

...

RENreq

...

...

...

LST

LST

LST

LST

LOST

LOST

LOST

LOST

...

...

...

LST

repeat

LOST

...

...

...

DAM

DAM

DAM

OVERDUE

RETURNED

RECALL

...

...

...

MSG

MSG

MSG

MSG

OVERDUE

RETURNED

LOST

RECALL

...

...

...

STQ

STQ

STQ

STQ

OVERDUE

RETURNED

LOST

RECALL

...

...

...

STR

STR

STR

STR

OVERDUE

RETURNED

LOST

RECALL

...

...

...

ANSind-WS

ANSind-WS

ANSind-WS

ANSind-WS

OVERDUE

RETURNED

LOST

RECALL

...

...

...

ANSind-WS

ANSind-WS

ANSind-WS

ANSind-WS

OVERDUE

. RETURNED

LOST

RECALL

ANS-HP

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

OVERDUE

RETURNED

LOST

RECALL

ANS-HP
repeat

...

...

...

ANSind-HP

ANSind-HP

ANSind-HP

OVERDUE

RETURNED

LOST

RECALL

CAR -

CARind -

...

...

...

CARind -

CARind -

OVERDUE

RETURNED

LOST

RECALL

CAR -
repeat

CARind-

...

...

...

CARind -

CARind -

OVERDUE

RETURNED

LOST

RECALL

SHI

SHIind

SHIind

...

...

...

SHIind

OVERDUE

RETURNED

LOST

RECALL

SHI
repeat

SHIind

SHIind

...

...

...

SHIind

OVERDUE

RETURNED

LOST

RECALL

RCL

RCLind

RCLind

RCLind

...

...

...

RCL

RCLind

RCLind

RCLind

RETURNED

...

...

...

RECALL

RCVreq

RCV (opt)

...

...

...

RECALL

DUE

DUEind

DUEind

DUEind

DUEind

OVERDUE

RETURNED

...

...

...

RECALL

DUE

DUEind

DUEind

DUEind

DUEind

RETURNED

...

...

...

RECALL

LST

LSTind

LSTind

LSTind

LOST

...

...

...

LOST

LST

LSTind

...

...

...

DAM

DAMind

RETURNED

...

...

...

MSG

MSGind

MSGind

MSGind

MSGind

OVERDUE

RETURNED

...

...

...

RECALL

STQ

STQind

STQind

STQind

STQind

OVERDUE

RETURNED

...

...

...

RECALL

STR

STRind

STRind

STRind

STRind

OVERDUE

RETURNED

...

...

...

RECALL

REA +

REAind +

REAind +

REAind +

RETURNED

...

...

...

RECALL

REA +

REAind +

REAind +

REAind +

RETURNED

...

...

...

RECALL

REA -

REAind -

REAind -

REAind -

REAind -

OVERDUE

RETURNED

...

...

...

RECALL

REA -

REAind -

REAind -

REAind -

REAind -

OVERDUE

RETURNED

...

...

...

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ý

...

...

...

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

FORWARD

ILL

ILLind

set FWDvar

...

...

...

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

ILLind

NOT-SUP-PLIED

ILLind

CONDITIONAL

...

...

...

ILLind

FORWARD

ILL

repeat

ILLind

IN-PROCESS

ILLind

...

...

...

ILLind

CONDITIONAL

ILLind

FORWARD

FWDreq

p4

...

...

...

FW

D

disable EXPIRY timer

FORWARD

...

...

...

ANS-
CO

reset
EXPIRY
timer
CONDI-TIONAL

FWDreq

...

...

...

ILL

FWD

FORWARD

...

...

...

ANS-
CO

reset
EXPIRY
timer
CONDI-
TIONAL

ANS-COreq

...

...

...

ANS-CO

CONDITIONAL

ANS-RYreq

...

...

...

ANS-RY

disable EXPIRY timer

NOT-SUPPLIED

ANS-RYreq

...

...

...

ANS-RY

NOT-SUP-PLIED

ANS-UNreq

...

...

...

ANS-UN

disable EXPIRY timer

NOT-SUPPLIED

ANS-

...

...

...

repeat

ANS-UN

NOT-SUP-PLIED

...

...

...

ANS-LP

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

LPreq

repeat

ANS-LP

NOT-SUP-PLIED

...

...

...

ANS-WSreq

ANS-WS

disable EXPIRY timer

IN-PROCESS

...

...

...

ANS-WSreq

repeat

ANS-WS

IN-PROCESS

...

...

...

ANS-HPreq

ANS-HP

disable EXPIRY timer

IN-PROCESS

...

...

...

ANS-HPreq

repeat

ANS-HP

IN-PROCESS

...

...

...

ANS-ESreq

ANS-ES

disable EXPIRY timer

NOT-SUPPLIED

...

...

...

ANS-
ESreq
repeat

ANS-ES

NOT-SUP-
PLIED

...

...

...

CAR +

CANCELLED

CARreq

...

...

...

CAR + CANCELLED

CARreq-

...

...

...

CAR-

enable EXPIRY timer

IN-PROCESS

CARreq-

repeat

...

...

...

CAR -

IN-PROCESS

SHIreq

...

...

...

set RETURN var

disable EXPIRY timer

SHIPPED

SHIreq

...

...

...

MSGreq

...

...

...

IN-PROCESS

MSG

NOT-SUP-PLIED

MSG

CONDITIONAL

MSG

CANCEL-PENDING

MSG

CANCELLED

...

...

...

FORWARD

STQreq

STQ

IN-PROCESS

STQ

NOT-SUP-PLIED

STQ

CONDITIONAL

...

...

...

CANCEL-PENDING

STQ

CANCELLED

STQ

FORWARD

STRreq

STR

IN-PROCESS

...

...

...

NOT-SUP-PLIED

STR

CONDITIONAL

STR

CANCEL-PENDING

STR

CANCELLED

STR

FORWARD

...

...

...

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

NOT-SUP-PLIED

C-REPind - NOT-SUPPLIED

C-REP-
repeat

...

...

...

C-REPind-

NOT-SUP-PLIED

CAN

...

...

...

CANind

CANCEL-PEND-ING

CANind

NOT-SUP-PLIED

CANind

CANCEL-PEND-ING

CANind

CANCEL-PENDING

CANind

...

...

...

CANind

FORWARD

CAN

^p7

CANind

IN-PROCESS

CANind

NOT-SUP-PLIED

...

...

...

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

...

...

...

CANind

FORWARD

MSG

MSGind

IN-PROCESS

MSGind

NOT-SUP-PLIED

MSGind

...

...

...

MSGind

CANCEL-PENDING

MSGind

CANCELLED

MSGind

FORWARD

STQ

STQind

...

...

...

STQind

NOT-SUP-PLIED

STQind

CONDITIONAL

STQind

CANCEL-PENDING

STQind

CANCELLED

STQind

...

...

...

STR

STRind

IN-PROCESS

STRind

NOT-SUP-PLIED

STRind

CONDITIONAL

STRind

...

...

...

STRind

CANCELLED

STRind

FORWARD

EXPIRY

Timeout

EXPind

EXP

...

...

...

EXPind

EXP

NOT-SUPPLIED

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

...

...

...

RENEWPENDING

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

LOST

SHIreq

...

...

...

SHIreq

SHI (opt)

...

...

...

repeat

SHIPPED

...

...

...

CHKreq

p5

CHK (opt)

CHK (opt)

CHK (opt)

CHK (opt)

...

...

...

CHECKED-IN

CHECKED-IN

CHECKED-IN

CHECKED-IN

CHKreq

...

...

...

CHK (opt)

repeat

...

...

...

CHECKED-IN

RCLreq

p5 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

...

...

...

OVERDUE

LSTreq

LST

LST

LST

LST

...

...

...

LST

LOST

LOST

LOST

LOST

LOST

...

...

...

LSTreq

LST

repeat

...

...

...

LOST

DAMreq

...

...

...

DAM

...

...

...

CHECKED-IN

MSGreq

MSG

MSG

MSG

MSG

MSG

MSG

...

...

...

SHIPPED

RENEW/
PENDING

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

LOST

STQreq

...

...

...

STQ

STQ

STQ

STQ

STQ

STQ

SHIPPED

RENEW PENDING

...

...

...

OVERDUE

RECALL

CHECKED-IN

LOST

STRreq

STR

STR

STR

STR

...

...

...

STR

STR

SHIPPED

RENEW PENDING

RENEW OVERDUE

OVERDUE

RECALL

CHECKED-IN

...

...

...

REAreq +

REA +

REA +

...

...

...

SHIPPED

SHIPPED

REAreq +

REA+

...

...

...

repeat

SHIPPED

...

...

...

REAreq -

REA -

REA -

...

...

...

SHIPPED

OVERDUE

REAreq -

...

...

...

REA -

repeat

SHIPPED

...

...

...

OVERDUE

ILL

ILLind

ILLind

...

...

...

ILLind

ILLind

SHIPPED

OVERDUE

RECALL

CHECKED-IN

...

...

...

ILL

ILLind

ILLind

ILLind

ILLind

ILLind

repeat

...

...

...

OVERDUE

RECALL

CHECKED-IN

LOST

CAN

CANind

CANind

...

...

...

CANind

CANind

CANind

CANind

SHIPPED

RENEW PENDING

RENEW OVERDUE

OVERDUE

...

...

...

CHECKED-IN

LOST

CAN

repeat

CANind

SHIPPED

CANind

RENEW PENDING

CANind

...

...

...

CANind

OVERDUE

CANind

RECALL

CANind

CHECKED-IN

CANind

LOST

RCV

...

...

...

SHIPPED

RCVind

RENEW PENDING

RCVind

RENEW OVERDUE

RCVind

OVERDUE

RCVind

RECALL

...

...

...

CHECKED-IN

RCVind

LOST

RCV

repeat

RCVind

SHIPPED

RCVind

RENEW PENDING

...

...

...

RENEW OVERDUE

RCVind

OVERDUE

RCVind

RECALL

RCVind

CHECKED-IN

RCVind

LOST

...

...

...

RETind

SHIPPED

RETind

RENEW PENDING

RETind

RENEW OVERDUE

RETind

OVERDUE

RETind

...

...

...

RETind

CHECKED-IN

RETind

LOST

RET repeat

RETind

SHIPPED

RETind

RENEW PENDING

...

...

...

RENEW OVERDUE

RETind

OVERDUE

RETind

RECALL

RETind

CHECKED-IN

RETind

LOST

...

...

...

p7 RENind

RENEWPENDING

RENind

RENEW PENDING

RENind

RENEW OVERDUE

RENind

RENEW OVERDUE

RENind

...

...

...

RENind

CHECKED-IN

RENind

LOST

REN

^p7

RENind

SHIPPED

RENind

...

...

...

RENind

RENEW OVERDUE

RENind

RENEW OVERDUE

RENind

RECALL

RENind

CHECKED-IN

RENind

...

...

...

REN

repeat

RENind

SHIPPED

RENind

RENEW PENDING

RENind

RENEW OVERDUE

RENind

...

...

...

RENind

RECALL

RENind

CHECKED-IN

RENind

LOST

LST

LSTind

LOST

...

...

...

LOST

LSTind

LOST

LSTind

LOST

LSTind

LOST

LSTind

CHECKED-IN

...

...

...

LOST

LST

repeat

LSTind

...

...

...

LSTind

LOST

DAM

DAMind

SHIPPED

DAMind

RENEW PENDING

DAMind

RENEW OVERDUE

...

...

...

OVERDUE

DAMind

RECALL

DAMind

CHECKED-IN

DAMind

LOST

MSG

MSGind

...

...

...

MSGind

RENEW PENDING

MSGind

RENEW OVERDUE

MSGind

OVERDUE

MSGind

RECALL

MSGind

...

...

...

MSGind

LOST

STQ

STQind

SHIPPED

STQind

RENEW PENDING

STQind

RENEW OVERDUE

...

...

...

OVERDUE

STQind

RECALL

STQind

CHECKED-IN

STQind

LOST

STR

STRind

...

...

...

STRind

RENEW PENDING

STRind

RENEW OVERDUE

STRind

OVERDUE

STRind

RECALL

STRind

...

...

...

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

...

...

...

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

update PART var

PENDING

...

...

...

ILLreq

repeat

ILL

PENDING

ILL

...

...

...

ILL

CONDITIONAL

ILL

SHIPPED

C-REPreq

+

...

...

...

C-REP +

NOT-SUP-PLIED

C-REP + PENDING

ILlreq

p2 or p3

ILL

...

...

...

update PART var

PENDING

C-REPreq+

...

...

...

C-REP +

PENDING

C-REP +

NOT-SUP-PLIED

...

...

...

C-REP-

NOT-SUP-PLIED

C-REP-

NOT-SUPPLIED

...

...

...

repeat

C-REP-

NOT-SUP-PLIED

...

...

...

CAN

CANCEL-PEND-ING

CAN

NOT-SUP-PLIED

CAN

CANCEL-PEN-DING

...

...

...

SHIPPED

CANreq

repeat

CAN

PENDING

CAN

NOT-SUP-PLIED

...

...

...

CANCEL-PENDING

CAN

CANCELLED

CAN

SHIPPED

RCVreq

RCV (opt)

set RETURN var

...

...

...

RCV (opt)

set RETURN var

SHIPPED

p6

RCV (opt)

set RETURN var

...

...

...

RCVreq

repeat

RCV (opt) SHIPPED

...

...

...

RET (opt) SHIPPED

p6

RET

SHIPPED

...

...

...

repeat

RET

SHIPPED

...

...

...

REN

SHIPPED

p6

REN

...

...

...

RENreq

repeat

REN

...

...

...

LSTreq

LST

SHIPPED

p6

...

...

...

SHIPPED

LSTreq

repeat

...

...

...

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

update PART var PENDING

...

...

...

DAMreq

DAM

SHIPPED

DAM

...

...

...

p6

DAM

SHIPPED

MSGreq

MSG

PENDING

MSG

...

...

...

MSG

CONDITIONAL

MSG

CANCEL-PENDING

MSG

CANCELLED

MSG

SHIPPED

STQreq

...

...

...

STQ

PENDING

STQ

NOT-SUP-PLIED

STQ

CONDITIONAL

STQ

CANCEL-PENDING

STQ

...

...

...

STQ

SHIPPED

STRreq

STR

PENDING

STR

NOT-SUP-PLIED

STR

...

...

...

STR

CANCEL-PENDING

STR

CANCELLED

STR

SHIPPED

FWD

FWDind

...

...

...

FWDind

PENDING

FWD

repeat

...

...

...

PENDING

ANS-CO

p7

...

...

...

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

...

...

...

CANCEL-PENDING

ANSind-CO

CANCELLED

ANS-CO

repeat

ANSind-CO

PENDING

...

...

...

NOT-SUP-PLIED

ANSind-CO

CONDITIONAL

ANSind-CO

CANCEL-PENDING

ANSind-CO

CANCELLED

ANS-RY

...

...

...

ANSind-RY

NOT-SUPPLIED

ANSind-RY

NOT-SUP-PLIED

ANSind-RY

NOT-SUPPLIED

...

...

...

repeat

ANSind-RY

NOT-SUP-PLIED

...

...

...

ANSind-UN

NOT-SUPPLIED

ANSind-UN

NOT-SUP-PLIED

ANSind-UN NOT- SUPPLIED

...

...

...

repeat

ANSind-UN

NOT-SUP-PLIED

...

...

...

ANSind-LP NOT- SUPPLIED

ANSind-LP

NOT-SUP-PLIED

ANSind-LP NOT- SUPPLIED

ILLreq

...

...

...

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

...

...

...

CANCEL-PENDING

ANSind

CANCELLED

WSAN-Sind-WS

SHIPPED

ANS-WS

repeat

ANSind-WS

...

...

...

ANSind-WS

NOT-SUP-PLIED

ANSind-WS

CONDITIONAL

ANSind-WS

CANCEL- PENDING

ANSind-WS

CANCELLED

ANSind-WS

...

...

...

ANS-HP

ANSind-HP

PENDING

ANSind-HP

NOT-SUP-PLIED

ANSind-HP

CONDITIONAL

ANSind-HP

...

...

...

ANSind-HP

CANCELLED

ANSind- HP

SHIPPED

ANS-HP

repeat

ANSind-HP

PENDING

...

...

...

NOT-SUP-PLIED

ANSind-HP

CONDITIONAL

ANSind-HP

CANCEL-PENDING

ANSind-HP

CANCELLED

ANSind-HP

SHIPPED

...

...

...

ANSind-ES NOT- SUPPLIED

ANSind-ES

NOT-SUP-PLIED

ANSind-ES

NOT-SUPPLIED

...

...

...

repeat

ANSind-ES

NOT-SUP- PLIED

...

...

...

CARind + CANCELLED

CARind + CANCELLED

CAR + repeat

...

...

...

CARind + CANCELLED

CAR -

CARind - PENDING

...

...

...

CARind - PENDING

CARind - SHIPPED

CAR -

repeat

CARind - PENDING

...

...

...

CARind - SHIPPED

SHI

SHIind

SHIPPED

SHIind

...

...

...

SHIind

SHIPPED

SHI

repeat

...

...

...

SHIind

SHIPPED

DUE

DUEind

SHIPPED

...

...

...

p6

DUEind

SHIPPED

DUE

repeat

...

...

...

DUEind

SHIPPED

ILLreq

p2 or p3

ILL

update CHAIN var

update PART var

...

...

...

REA +

...

...

...

p6

REAind + SHIPPED

REA + repeat

...

...

...

REAind + SHIPPED

REA-

...

...

...

p6

REAind-

SHIPPED

REA-

repeat

...

...

...

REAind-

SHIPPED

LST

LSTind

SHIPPED

...

...

...

SHIPPED

p6

LSTind

SHIPPED

LST

repeat

...

...

...

LSTind

SHIPPED

DAM

...

...

...

p6

DAMind

SHIPPED

RCL

RCLind

SHIPPED

...

...

...

p6

RCLind

RCL

repeat

...

...

...

RCLind

SHIPPED

MSG

MSGind

PENDING

...

...

...

NOT-SUP-PLIED

MSGind

CONDITIONAL

MSGind

CANCEL-PENDING

MSGind

CANCELLED

MSGind

SHIPPED

...

...

...

STQind

PENDING

STQind

NOT-SUP-PLIED

STQind

CONDITIONAL

STQind

CANCEL-PENDING

...

...

...

CANCELLED

STQind

SHIPPED

STR

STRind

PENDING

STRind

NOT-SUP- PLIED

...

...

...

CONDITIONAL

STRind

CANCEL-PENDING

STRind

CANCELLED

STRind

SHIPPED

EXP

...

...

...

NOT-SUPPLIED

EXPind

NOT-SUP-PLIED

EXPind

NOT-SUPPLIED

EXPind

NOT-SUPPLIED

...

...

...

p2 or p3 ILL

update CHAIN var

update PART var PENDING

...

...

...

CHKind

SHIPPED

CHKind

SHIPPED

p6

...

...

...

SHIPPE

CHK

repeat

...

...

...

SHIPPED

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

IDLE

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

...

...

...

SHIPPED

ILL

ILLind

set FWDvar

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

...

...

...

ILLind

NOT-SUP-PLIED

ILLind

CONDITIONAL

ILLind

FORWARD

ILLind

...

...

...

ILL

repeat

ILLind

IN-PROCESS

ILLind

NOT-SUP-PLIED

ILLind

CONDITIONAL

...

...

...

ILLind

FORWARD

ILLind

SHIPPED

FWDreq

p4

ILL

...

...

...

disable EXPIRY timer

FORWARD

FWDreq

...

...

...

ILL

FWD

FORWARD

...

...

...

ANSreq-CO

ANS-CO

reset EXPIRY timer

CONDITIONAL

ANS-CO

CANCEL-PENDING

...

...

...

CANCELLED

ANS-
COreq

repeat

ANS-CO

disable EXPIRY timer

IN-PROCESS

...

...

...

NOT-SUP-PLIED

ANS-CO

CONDITIONAL

ANS-CO

CANCEL-PENDING

ANS-CO

CANCELLED

...

...

...

ILLind

set FWD var

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

ILLind

...

...

...

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

...

...

...

disable EXPIRY timer

NOT-SUP-PLIED

ANS-UNreq

repeat

...

...

...

NOT-SUP-PLIED

ANS-LPreq

ANS-LP

...

...

...

NOT-SUP-PLIED

ANS-LP

disable EXPIRY timer

NOT-SUP-PLIED

...

...

...

repeat

ANS-LP

NOT-SUP-PLIED

...

...

...

ANS-WSreq

ANS-WS

disable EXPIRY timer

IN-PROCESS

ANS-WS

NOT-SUP-PLIED

ANS-WS

CONDITIONAL

...

...

...

CANCEL-PENDING

ANS-WS

CANCELLED

ANS-WS

SHIPPED

ANS-WSreq

repeat

...

...

...

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

...

...

...

CONDITIONAL

ANS-HP

CANCEL-PENDING

ANS-HP

CANCELLED

ANS-HP

SHIPPED

ILL

...

...

...

set FWDvar

set CHAIN var

set PART var

set EXPIRY timer

IN-PROCESS

ILLind

IN-PROCESS

ILLind

NOT-SUP-PLIED

...

...

...

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

...

...

...

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

...

...

...

repeat

CAR-

IN-PROCESS

...

...

...

SHIPPED

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

SHIreq

SHI

set RETURN var

disable EXPIRY timer

SHIPPED

...

...

...

SHI

set RETURN variable

disable EXPIRY timer

SHIPPED

SHI

SHIPPED

SHIreq

...

...

...

SHI

SHIPPED

...

...

...

MSG

IN-PROCESS

MSG

NOT-SUP-PLIED

MSG

CONDITIONAL

MSG

CANCEL-PENDING

...

...

...

CANCELLED

MSG

FORWARD

MSG

SHIPPED

STQreq

STQ

IN-PROCESS

...

...

...

NOT-SUP-PLIED

STQ

CONDITIONAL

STQ

CANCEL-PENDING

STQ

CANCELLED

STQ

FORWARD

...

...

...

SHIPPED

STRreq

STR

IN-PROCESS

STR

NOT-SUP-PLIED

STR

CONDITIONAL

...

...

...

CANCEL-PENDING

STR

CANCELLED

STR

FORWARD

STR

SHIPPED

CHKreq

...

...

...

CHK(opt)

SHIPPED

p6

CHK (opt) SHIPPED

CHKreq

...

...

...

CHK (opt) SHIPPED

DUEreq

...

...

...

DUE

SHIPPED

p6

DUE

...

...

...

DUEreq repeat

DUE

...

...

...

REAreq +

p6

...

...

...

REAreq + repeat

REA+

...

...

...

REAreq -

p6

...

...

...

SHIPPED

REAreq

-repeat

...

...

...

REA-

SHIPPED

RCLreq

RCL

SHIPPED

...

...

...

p6

RCL

SHIPPED

RCLreq

repeat

...

...

...

RCL

SHIPPED

LSTreq

LST

SHIPPED

...

...

...

LST

SHIPPED

p6

LST

SHIPPED

LSTreq

...

...

...

LST

SHIPPED

...

...

...

p6

...

...

...

DAM

...

...

...

SHIPPED

C-REP +

C-REPind + IN-

...

...

...

C-REPind +

PROCESS

NOT-SUP-PLIED

...

...

...

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

repeat -

...

...

...

NOT-SUP-PLIED

CAN

...

...

...

CANind

CANind

CANind

CANind

CANind

CANind

CANind

...

...

...

NOT-SUP-PLIED

CANCEL-PENDING

CANCEL-PENDING

CANCELLED

FORWARD

SHIPPED

CAN

^P7

...

...

...

CANind

CANind

CANind

CANind

CANind

CANind

IN-PROCESS

...

...

...

CANCEL-PENDING

CANCEL-PENDING

CANCELLED

FORWARD

SHIPPED

CAN

CANind

CANind

...

...

...

CANind

CANind

CANind

CANind

repeat

IN-PROCESS

NOT-SUP-PLIED

CANCEL-PENDING

...

...

...

CANCELLED

FORWARD

SHIPPED

MSG

MSGind

MSGind

MSGind

MSGind

...

...

...

MSGind

MSGind

IN-PROCESS

NOT-SUP-PLIED

CONDITIONAL

CANCEL-PENDING

CANCELLED

...

...

...

SHIPPED

STQ

STQind

IN-PROCESS

STQind

NOT-SUP-PLIED

STQind

CONDITIONAL

...

...

...

CANCEL-PENDING

STQind

CANCELLED

STQind

FORWARD

STQind

SHIPPED

STR

...

...

...

IN-PROCESS

STRind

NOT-SUP-PLIED

STRind

CONDITIONAL

STRind

CANCEL-PENDING

STRind

CANCELLED

...

...

...

FORWARD

STRind

SHIPPED

RCV

RCVind

SHIPPED

...

...

...

SHIPPED

p6

RCVind

SHIPPED

RCV

repeat

...

...

...

RCVind

SHIPPED

RET

...

...

...

SHIPPED

p6

RETind

SHIPPED

...

...

...

repeat

RETind

...

...

...

REN

RENind

SHIPPED

...

...

...

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.

...

...

...

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ự "+".

...

...

...

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

...

...

...

interchange:: = segment_list

segmentjist:: = segment I segment segment_list

segment:: = segment_code "+" segment_content

segment_code:: = alpha alpha alpha

segment_content:: = data_element I data_element"+" segment_content

data_element:: = content_string I content_string data_element

content_string:: = string_part I string_part content_string

string_part:: = normal_string I special_character

special_character:: = "??" I "?+" I "?": I "?"

...

...

...

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

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

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

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

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

Tên đoạn

Mã đoạn

Mô tả

Tư vấn chuỗi dịch vụ

...

...

...

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

...

...

...

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ả

...

...

...

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ả

...

...

...

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

...

...

...

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:

...

...

...

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ả

...

...

...

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

...

...

...

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ả

...

...

...

Biểu diễn

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

Phần tử dữ liệu

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

Mô tả

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

Phần tử dữ liệu

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

Mô tả

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

FORNOT

Shipped (Đã chuyển)

SHIPED

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

ILLANS

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

CONREP

Cancel (Hủy)

CANCEL

...

...

...

CNLREP

Received (Đã Nhận)

RCEIVD

Recall (Đòi)

RECALL

Returned (Đã Trả)

RETRND

Checked-ln (Kiểm nhận)

CHKDIN

...

...

...

OVERDU

Renew (Gia hạn)

RENEWL

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

RENANS

Lost (Mất)

LOSTIT

Damaged (Hư hại)

DAMAGE

...

...

...

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.

...

...

...

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

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

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

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

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

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

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

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

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.

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

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:

...

...

...

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

...

...

...

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

...

...

...

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í

...

...

...

CIT

Phần tử dữ liệu

số tài khoản

chi phí tối đa

{

mã tiền tệ

giá trị tiền tệ

}

thỏa thuận đối ứng

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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ươ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ể

...

...

...

}

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ã

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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ữ

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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ố

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

ư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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

Tên đoạn

Id bên yêu cầu

Mã đoạn

RQI

Phần tử dữ liệu

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

{

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

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

...

...

...

}

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

{

tên cá nhân

tên tổ chức

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

}

Tên đoạn

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

- 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

...

...

...

}

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

...

...

...

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ử

...

...

...

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

...

...

...

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

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

...

...

...

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

...

...

...

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ệ

}

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

- 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

}

...

...

...

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

...

...

...

ư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

...

...

...

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

...

...

...

- 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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

}

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

...

...

...

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í

...

...

...

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

...

...

...

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

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

B.7.3.3  Mã hóa Bool

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

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

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

Phụ lục C

(Quy định)

...

...

...

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:

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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]

...

...

...

[Để 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

...

...

...

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)

...

...

...

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

...

...

...

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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.2  Dịch vụ hỗ trợ giả định

5.3  Mô hình

6  APDU ILL

7  Thông tin giao dịch

7.1  Nhận dạng giao dịch

7.2  Trạng thái giao thức

7.3  Các biến giao thức

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

7.5  Thông tin yêu cầu

...

...

...

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

...

...

...

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