Tiêu chuẩn Quốc gia TCVN 11523-1:2016 ISO/IEC 24752-1:2014 Công nghệ thông tin-Giao diện người sử dụng-Bộ điều khiển từ xa phổ dụng-Phần 1: Khung tổng quát chung

TIÊU CHUẨN QUỐC GIA

TCVN 11523-1:2016

ISO/IEC 24752-1:2014

CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ DỤNG - PHẦN 1: KHUNG TỔNG QUÁT CHUNG

Information technology - User interfaces - Universal remote console - Part 1: General framework

Lời nói đầu

TCVN 11523-1:2016 hoàn toàn tương đương với ISO/IEC 24752-1:2014

TCVN 11523-1:2016 do Tiểu Ban kỹ thuật tiêu chuẩn quốc gia TCVN/JTC 1/SC 35 Giao diện người sử dụng biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Bộ tiêu chuẩn TCVN 11523 Công nghệ thông tin - Giao diện người sử dụng - Bộ điều kiển từ xa phổ dụng gồm sáu phần:

- TCVN 11523-1:2016 (ISO/IEC 24752-1:2014), Phần 1: Khung tổng quát chung

- TCVN 11523-2:2016 (ISO/IEC 24752-2:2014), Phần 2: Mô tả socket giao diện người sử dụng

- TCVN 11523-3:2016, Phần 3: Khuôn mẫu trình bày

- TCVN 11523-4:2016 (ISO/IEC 24752-4:2014), Phần 4: Mô tả đích

- TCVN 11523-5:2016 (ISO/IEC 24752-5:2014), Phần 5: Mô tả tài nguyên

- TCVN 11523-6:2016 (ISO/IEC 24752-6:2014), Phần 6: Tích hợp dịch vụ web

CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ DỤNG - PHẦN 1: KHUNG TỔNG QUÁT CHUNG

Information technology - User interfaces - Universal remote console - Part 1: General framework

1  Phạm vi áp dụng

Bộ tiêu chuẩn này hỗ trợ việc vận hành các sản phẩm thông tin và điện tử thông qua các giao diện từ xa, thay thế và các tác nhân thông minh.

Tiêu chuẩn này xác định khung tổng quát của các thành phần kết hợp với nhau để kích hoạt các giao diện người sử dụng từ xa và điều khiển các thiết bị, dịch vụ điện tử có thể truy cập mạng từ xa thông qua bộ điều khiển từ xa phổ dụng (URC). Tiêu chuẩn này cung cấp cái nhìn tổng quan về khung tổng quát URC và các thành phần của nó.

2  Sự phù hợp

2.1  URC

Một URC thích hợp phải tuân theo các yêu cầu về URC được quy định trong Điều 4 và Điều 8. Bảng 1 tóm tắt các yêu cầu về các URC.

Bảng 1 - Tóm tắt các yêu cầu về URC

2.2  Đích

Một đích thích hợp phải đáp ứng các yêu cầu quy định trong Điều 5 và Điều 8. Bảng 2 tóm tắt các yêu cầu của đích.

Bảng 2 - Tóm tắt các yêu cầu của đích

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

Tiêu chuẩn này áp dụng các thuật ngữ, định nghĩa sau đây.

3.1

Tài nguyên khóa truy cập (access key resource)

Tài nguyên nguyên tử quy định ký tự đơn có thể được sử dụng kết hợp với cơ chế dành cho URC để di chuyển trọng tâm đến thẻ của giao diện

CHÚ THÍCH  Khi một khóa truy cập được gắn kết với một lệnh thì việc đưa vào khóa truy cập sẽ kích hoạt lệnh.

3.2

Tài nguyên nguyên tử (atomic resource)

Tài nguyên được sử dụng như thực thể nguyên tử trong việc xây dựng giao diện người sử dụng cụ thể

VÍ DỤ Tài nguyên nguyên tử bao gồm tài nguyên nhãn, nguồn trợ giúp, tài nguyên khóa truy cập, tài nguyên từ khóa và các mô tả vị trí.

CHÚ THÍCH  Tài nguyên nguyên tử có thể là bất cứ dạng nào bao gồm văn bản, hình ảnh, âm thanh, ảnh động và các video. Xem TCVN 11523-5 (ISO/IEC 24752-5).

3.3

Mô tả tài nguyên nguyên tử (atomic resource description)

Mô tả tài nguyên của tài nguyên nguyên tử

CHÚ THÍCH 1 TCVN 11523-5 (ISO/IEC 24752-5) quy định định dạng cho các mô tả tài nguyên nguyên tử.

3.4

Lệnh (command)

Lệnh socket (socket command)

Thẻ socket biểu diễn chức năng chính trong đó người sử dụng có thể yêu cầu thực hiện đích không thể đạt được thông qua việc thao tác giá trị của biến đơn

VÍ DỤ Hoạt động 'thiết lập lại' hoặc ‘đệ trình’

CHÚ THÍCH Xem TCVN 11523-2 (ISO/IEC 24752-2)

3.5

Thông số lệnh (command parameter)

Thông số lệnh socket (socket command parameter)

Giá trị của biến được sử dụng cho việc thực hiện lệnh

CHÚ THÍCH  Xem TCVN 11523-2 (ISO/IEC 24752-2)

3.6

Kết nối (connection)

Sự kết hợp thiết lập giữa các đơn vị chức năng cho việc truyền dữ liệu

[NGUỒN: Từ điển tiêu chuẩn quốc gia Mỹ về công nghệ thông tin (ANSDIT)]

3.7

Ngữ cảnh sử dụng (context of use, use context)

Người sử dụng, nhiệm vụ, trang thiết bị (phần cứng, phần mềm và các tài liệu), môi trường vật lý và môi trường xã hội mà sản phẩm được sử dụng

[NGUỒN: ISO 9241-11:1998, điều 3.5]

3.8

Pha điều khiển (control phase)

Khoảng thời gian một URC và một đích bắt đầu và kết thúc phiên điều khiển giữa URC và socket đích cụ thể

3.9

Phần phụ thuộc (dependency)

Biểu thức xác định mối quan hệ giữa đặc tính của biến, lệnh socket hoặc thẻ thông báo và các giá trị của các thẻ socket khác

3.10

Thiết bị (device)

Thiết bị vật lý với giao diện người sử dụng có sẵn có thể được điều khiển bằng điện

VÍ DỤ các công tắc đèn, bộ ổn nhiệt, các thiết bị trong nhà, trang thiết bị nghe-nhìn, máy bán hàng tự động và các thiết bị điểm bán.

3.11

Thẻ socket thứ nguyên (dimensional socket element)

Thẻ thứ nguyên (dimensional element)

Tập các giá trị đồng nhất liên quan đến thẻ socket

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.12

Tập socket thứ nguyên (dimensional socket set)

Tập socket lặp (repeating socket set)

Tập hợp các tập đồng nhất với các chỉ số khác nhau

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.13

Khám phá (discovery)

Quá trình mà một URC định vị và kết nối đến các đích trong môi trường của nó

3.14

Pha khám phá (discovery phase)

Khoảng thời gian URC duyệt qua môi trường cho các đích có sẵn và định danh các socket của chúng

3.15

Tài nguyên nguyên tử động (dynamic atomic resource)

Tài nguyên nguyên tử được cung cấp bởi đích tại thời gian chạy

3.16

Thẻ (element)

Đơn vị logic cơ bản của tài liệu XML

3.17

Thông số toàn cục (global parameter)

Thông số lệnh toàn cục (global command parameter)

Tham chiếu từ lệnh đến biến dùng là thông số đầu ra hoặc đầu vào cho lệnh

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.18

Tài nguyên tạo nhóm (grouping resource)

Tạo nhóm (grouping)

Cấu trúc phân cấp của các thẻ socket giao diện người sử dụng hoặc các thẻ mô tả cài đặt giao diện người sử dụng theo kiểu trên xuống được cung cấp từ bên ngoài cho mô tả socket

CHÚ THÍCH: Cú pháp và ngữ nghĩa của các tài nguyên tạo nhóm được xác định trong TCVN 11523-5 (ISO/IEC 24752-5).

3.19

Tệp tạo nhóm (grouping sheet)

Tệp chứa các tài nguyên tạo nhóm

CHÚ THÍCH: Cú pháp và ngữ nghĩa của các tệp tạo nhóm được xác định trong TCVN 11523-5 (ISO/IEC 24752-5).

3.20

Tài nguyên trợ giúp (help resource)

Tài nguyên nguyên tử được sử dụng để cung cấp sự trợ giúp cho người sử dụng đích

3.21

Thông số đầu vào (input parameter)

Giá trị của biến được đích đọc ra trước khi thực hiện lệnh, nhằm tác động đến việc thực hiện và kết quả của nó

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.22

Thông số đầu vào - đầu ra (input-output parameter)

Biến được sử dụng như thông số đầu vào và đầu ra cho cùng một lệnh

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.23

Bộ tạo giao diện (interface generator)

Phần mềm tạo giao diện người sử dụng cho một đích mà đích đó thích hợp với ngữ cảnh sử dụng đã biết

CHÚ THÍCH: Trong bộ tiêu chuẩn TCVN 11523 (ISO/IEC 24752), việc tạo giao diện được dựa trên mô tả socket, các tệp tài nguyên và các tệp tạo nhóm.

3.24

Tài nguyên từ khóa (keyword resource)

Tài nguyên nguyên tử quy định từ khóa liên quan đến thẻ tham chiếu

3.25

Tài nguyên nhãn (label resource)

Tài nguyên nguyên tử sử dụng để ghi nhãn, định danh hoặc biểu diễn một thẻ trong giao diện người sử dụng

VÍ DỤ  Nhãn “Sân bay quốc tế John F Kennedy” có thể được sử dụng để biểu diễn giá trị “JFK” hoặc nhãn “Nơi đến” có thể được sử dụng để định danh trường đầu vào ở đó người sử dụng phải nhập nơi đến.

3.26

Thông số cục bộ (local parameter)

Thông số đầu vào hoặc đầu ra được gắn với một lệnh

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.27

Chức năng định vị (locator function)

Bộ định vị (locator)

Chức năng của đích có thể được gọi ra bởi người sử dụng và giúp người sử dụng định vị đích

VÍ DỤ  Các chức năng nghe như là tiếng bíp hoặc chuông, các chức năng nhìn như là đèn flash và các chức năng chỉ hướng như là chức năng “ping hồng ngoại".

3.28

Thông báo (notification)

Trạng thái đặc biệt của đích mà hoạt động thông thường bị tạm ngưng

VÍ DỤ  Trạng thái loại bỏ

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/1EC 24752-2).

3.29

Thẻ khai báo (notify element)

Thẻ khai báo socket (socket notify element)

Thẻ socket biểu diễn một thông báo

3.30

Thông số đầu ra (output parameter)

Kết quả lệnh (command result)

Giá trị của biến được cập nhật bởi đích sau khi thực hiện lệnh, nhằm tác động đến kết quả của việc thực hiện

CHÚ THÍCH: Xem TCVN 11523-2(ISO/IEC 24752-2).

3.31

Tài nguyên (resource)

Đối tượng được sử dụng như một thực thể hoặc để hỗ trợ cho việc đưa ra quyết định trong quá trình xây dựng giao diện người sử dụng cụ thể

VÍ DỤ  Tài nguyên bao gồm mô tả cài đặt giao diện người sử dụng, tệp tài nguyên và mọi loại tài nguyên nguyên tử như là tài nguyên nhãn, tài nguyên trợ giúp, tài nguyên khóa truy cập và tài nguyên từ khóa.

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.32

Mô tả tài nguyên (resource description)

Mô tả tài nguyên dưới dạng các đặc tính của nó

CHÚ THÍCH: Định danh của mô tả tài nguyên được quy định trong TCVN 11523-5 (ISO/IEC 24752-5).

3.33

Dịch vụ tài nguyên (resource service)

Dịch vụ cung cấp các tài nguyên từ các nhà sản xuất đích và bất kỳ bên thứ ba nào, như là nhà sản xuất URC, ngoại trừ các tài nguyên đích

CHÚ THÍCH: Xem TCVN 11523-5 (ISO/IEC 24752-5).

3.34

Mô tả dịch vụ tài nguyên (resource service description)

Mô tả mọi tham chiếu đến dịch vụ tài nguyên

CHÚ THÍCH: Định dạng mô tả dịch vụ tài nguyên được quy định trong TCVN 11523-5 (ISO/IEC 24752-5).

3.35

Tệp tài nguyên (resource sheet)

Tệp chứa các mô tả tài nguyên nguyên tử

CHÚ THÍCH: Định dạng tệp tài nguyên được quy định trong TCVN 11523-5 (ISO/IEC 24752-5).

3.36

Mạng URC-tài nguyên (resource-URC network)

RUN

Mạng kết nối URC với các nguồn tài nguyên bổ sung và các mô tả cài đặt giao diện người sử dụng (UIIDs)

CHÚ THÍCH: Có thể sử dụng mọi công nghệ kết nối và công nghệ nối mạng.

3.37

Liên kết mạng URC-tài nguyên (resource-URC network link)

RUNL

Liên kết từ URC đến mạng URC-tài nguyên

3.38

Dịch vụ (service)

Chức năng tạo sẵn cho người sử dụng

VÍ DỤ  Dịch vụ giữ chỗ hàng không, dịch vụ đổi tiền, dự báo thời tiết, giới thiệu nhà hàng, v.v...

3.39

Phiên (session)

Phiên điều khiển

Giai đoạn kết nối giữa socket của đích và URC nhằm mục đích điều hành socket qua URC

3.40

Đích-yêu cầu phiên (session-full target)

Đích yêu cầu mở một phiên với URC cho một phần hoặc tất cả các chức năng của đích đó

3.41

Đích-không yêu cầu phiên (session - less target)

Đích cung cấp tất cả các chức năng của nó cho mọi URC mà không yêu cầu phiên

3.42

Phiên chia sẻ (shared sessions)

Các phiên của một socket mà các giá trị thẻ socket là chung hoặc chia sẻ (các phiên chéo) cho các thẻ socket với cùng định danh

3.43

socket (socket)

socket giao diện người sử dụng (user interface socket)

Điểm truy cập và điều khiển cho máy để vận hành một đích.

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.44

Mô tả socket (socket description)

Mô tả socket giao diện người sử dụng (user interface socket description)

Mô tả chức năng và đặc tính của socket

CHÚ THÍCH: Mô tả socket được trình bày trong XML với ngôn ngữ đánh dấu quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

3.45

Thẻ socket (socket element)

Biến, lệnh hoặc thẻ khai báo

CHÚ THÍCH: Xem TCVN (ISO/IEC 24752-2).

3.46

Thành phần thẻ socket (socket element component)

Một giá trị không thuộc tập các giá trị cho thẻ socket thứ nguyên

CHÚ THÍCH: Xem TCVN 11523-2(ISO/IEC 24752-2).

3.47

Tập socket (socket set)

Tập (set)

Tập bao gồm các thẻ socket và các tập khác

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/1EC 24752-2).

3.48

Tài nguyên nguyên tử tĩnh (static atomic resource)

Tài nguyên nguyên tử được cung cấp trước thời gian chạy, ví dụ: thông qua tệp tài nguyên

3.49

Tài nguyên nguyên tử bổ sung (supplemental atomic resource)

Tài nguyên bổ sung được sử dụng như một thực thể nguyên tử trong việc xây dựng giao diện người sử dụng cụ thể

3.50

Tài nguyên tạo nhóm bổ sung (supplemental grouping resource)

Tạo nhóm bổ sung (supplemental grouping)

Tài nguyên tạo nhóm được cung cấp bên ngoài bởi các dịch vụ tài nguyên cho đích

3.51

Nhãn bổ sung (supplemental label)

Tài nguyên nhãn tạo sẵn bên ngoài cho đích

3.52

Tài nguyên bổ sung (supplemental resource)

Tài nguyên tạo sẵn bên ngoài cho đích

3.53

Đích (target)

Thiết bị hoặc dịch vụ mà người dùng muốn sử dụng

VÍ DỤ  Đầu thu cát-sét video (VCR), danh mục điện thoại trực tuyến.

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

3.54

Tài nguyên nguyên tử đích (target atomic resource)

Tài nguyên đích được sử dụng như một thực thể nguyên tử trong việc xây dựng giao diện người sử dụng cụ thể

3.55

Mô tả đích (target description)

TD

Tài liệu chứa thông tin về một đích cần thiết cho việc khám phá và truy cập đích và các socket của nó

CHÚ THÍCH: Có một mô tả cho mỗi đích.

3.56

Định danh đối tượng đích (target instance identifier)

Định danh cho một đối tượng đích là duy nhất trong số tất cả các đích với cùng một tên

3.57

Tài nguyên đích (target resource)

Tài nguyên được cung cấp bởi một đích trong môi trường mạng cục bộ

3.58

Mạng URC- đích (target-URC network)

TUN

Mạng kết nối đích và URC có thể sử dụng mọi công nghệ nối mạng và công nghệ kết nối

CHÚ THÍCH: Các ví dụ về công nghệ kết nối bao gồm Ethernet, bluetooth và 802.11. Các ví dụ về công nghệ nối mạng bao gồm UpnP và Java/Jini.

3.59

Liên kết mạng URC- đích (target-URC network link)

TUNL

Liên kết giữa đích hoặc URC và mạng URC đích

CHÚ THÍCH: Mỗi TUNL đặc trưng cho các công nghệ nối mạng và các công nghệ kết nối được sử dụng.

VÍ DỤ  "UPnP trên TUNL bluetooth”, "Jini trên TUNI 802.11 b” hoặc "Jini trên TUNL bluetooth”.

3.60

Bộ điều khiển từ xa phổ dụng (universal remote console)

URC

Thiết bị hoặc phần mềm mà người sử dụng truy cập một đích

CHÚ THÍCH: URC có khả năng trả lại giao diện người sử dụng cho mọi đích. Từ "phổ dụng” có nghĩa là có thể được sử dụng đề điều khiển mọi đích. Giả sử rằng người sử dụng chọn một URC có khả năng đáp ứng các yêu cầu tương tác cá nhân.

3.61

Giao diện người sử dụng (user interface)

UI

Phương tiện mà người sử dụng tương tác với một đích

CHÚ THÍCH: Giao diện bao gồm thông tin đưa ra cho người sử dụng, các giá trị người sử dụng có thể nhập hoặc thao tác bằng tay và tất cả các hoạt động người sử dụng có thể hướng dẫn cho đích thực hiện.

3.62

Mô tả cài đặt giao diện người sử dụng (user interface implementation description)

UIID

Mô tả việc cài đặt giao diện người sử dụng cho đích dựa trên socket của đích

CHÚ THÍCH: Có thể dùng dạng mô tả giao diện người sử dụng hoặc bao gồm mã khả thi tác động lên lớp URC riêng.

3.63

Biến (variable)

Biến socket (socket variable)

Thẻ socket biểu diễn giá trị liên quan đến giao diện người sử dụng của đích trong đó có thể được thay đổi bởi đích hoặc người sử dụng

CHÚ THÍCH: Xem TCVN 11523-2 (ISO/IEC 24752-2).

4  Các yêu cầu về bộ điều khiển từ xa phổ dụng (URC)

4.1  Khái quát

Bộ điều khiển từ xa phổ dụng (URC) là thiết bị hoặc phần mềm mà người sử dụng truy cập đích. URC là "phổ dụng” có nghĩa là nó có thể được sử dụng để điều khiển mọi đích tuân theo mệnh lệnh. URC đưa ra các giao diện cho các đích tuân theo mệnh lệnh đến người sử dụng và chuyển tiếp các hoạt động của người sử dụng cho các đích này. URC có thể cung cấp thông tin cho người sử dụng theo bất kỳ dạng nào (nghe, nhìn, v.v...) phục vụ cho người sử dụng, URC và môi trường (ví dụ: lái xe, môi trường yên tĩnh, v.v...). Tiêu chuẩn này không áp đặt bất kỳ yêu cầu nào với dạng mà người dùng sử dụng.

Điều này đưa ra các yêu cầu chung, các yêu cầu này phải được đáp ứng bởi bộ điều khiển từ xa phổ dụng cho các đích được tìm ra và được lựa chọn bởi người sử dụng URC và cho phiên điều khiển giữa URC và đích được thiết lập, duy trì và kết thúc. Tài liệu này không cung cấp các hướng dẫn cài đặt trên các nền tảng mạng cụ thể.

4.2  Quản lý khám phá

4.2.1  Khái quát

Quản lý khám phá bao gồm các chức năng trong đó đảm nhận việc khám phá các đích có sẵn, các socket của chúng và đưa ra thông tin cho người sử dụng. URC dựa trên các cơ chế khám phá hiện có được cung cấp bởi các liên kết mạng URC - đích đã cài đặt (xem điều 4.5).

4.2.2  Hỗ trợ cho khám phá đích

Trong pha khám phá, URC tìm ra các đích và lấy thông tin về chúng thông qua các cơ chế TUN và giải thích việc mô tả đích (xem điều 4.2.4). Tiêu chuẩn này không quy định các cách cụ thể về việc URC đưa ra thông tin cho người sử dụng.

4.2.3  Lấy các tài liệu từ đích

4.2.3.1  Khái quát

URC phải có khả năng lấy các tài liệu từ một đích thông qua các cơ chế tìm nạp cụ thể cho TUN (điều 5.1.2). URC cần giải thích các URI để lấy các tài liệu mà URI tham chiếu. Điều này bao gồm giải pháp URI cục bộ dựa trên ngữ cảnh của chúng.

URC phải công nhận các kiểu MINE mô tả đích (xem TCVN 11523-4(ISO/IEC 24752-4)), mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)), tệp tạo nhóm và tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)), nếu thích hợp.

4.2.3.2  Bộ nhớ đệm

Nhằm mục đích lưu trữ dữ liệu trong bộ nhớ truy cập nhanh, URC có thể giả thiết rằng một tài liệu được cung cấp bởi đích là ổn định theo thời gian nếu nó không thay đổi định danh (URI) và ngày tháng sửa đổi.

Việc khôi phục tài liệu có thể diễn ra trong cả pha khám phá và điều khiển.

4.2.4  Giải thích mô tả đích

Thông tin đa nền trên một đích được truyền tải theo dạng mô tả đích (được xác định trong TCVN 11523-4(ISO/IEC 24752-4)) hoặc mô tả đích ngầm định (được xác định trong TCVN 11523-6 (ISO/IEC 24752-6)).

CHÚ THÍCH Mô tả đích là độc lập từ mọi ngôn ngữ tự nhiên.

URC không được yêu cầu giải thích toàn bộ thông tin chứa trong mô tả đích. Tuy nhiên, URC phải có khả năng định danh một đích và mở phiên điều khiển với một trong các socket của nó.

4.2.5  Gọi chức năng định vị của đích

Các chức năng định vị của đích có thể được tạo sẵn cho người sử dụng nếu có sẵn trên đích. Chức năng định vị được mô tả trong mô tả đích và được gọi ra bởi URC theo cách đặc trưng cho TUNL (xem điều 4.5), bao gồm định danh của thẻ định vị trong mô tả đích.

4.3  Quản lý phiên

4.3.1  Khái quát

Quản lý phiên bao gồm các chức năng mở, duy trì và đóng các phiên điều khiển giữa URC và socket của đích.

CHÚ THÍCH  Quản lý phiên cần cho các đích yêu cầu phiên (trái với các đích không yêu cầu phiên). Các URC phải hỗ trợ các chức năng quản lý phiên sao cho có thể xử lý các đích yêu cầu phiên.

4.3.2  Yêu cầu phiên mở URC

4.3.2.1  Khái quát

URC phải hỗ trợ yêu cầu phiên mở cho đích yêu cầu phiên, định danh socket bởi URI như đã quy định trong mô tả đích. Yêu cầu phiên mở cũng có thể chứa mã được phép trong đó URC lấy từ đích ví dụ thông qua yêu cầu chuyển tiếp phiên (xem điều 5.5.7).

Đích có thể chấp nhận hoặc từ chối yêu cầu phiên mở hoặc chuyển tiếp URC tới socket khác (cùng một đích hoặc đích khác nhau).

Yêu cầu phiên mở và đáp ứng của đích đặc trưng cho nền tảng TUN riêng (xem điều 7.2).

4.3.2.2  Các quyền ưu tiên của URC

URC cho biết tập các quyền ưu tiên với yêu cầu phiên mở. Định dạng của các quyền ưu tiên không thuộc phạm vi của tiêu chuẩn này.

CHÚ THÍCH Nhằm mục đích hướng đến phạm vi các quyền ưu tiên (và các bảng từ vựng liên quan) trong các phiên bản tương lai của tiêu chuẩn này.

4.3.2.3  Đích chấp nhận yêu cầu

Nếu đích chấp nhận yêu cầu thì URC sẽ thiết lập phiên điều khiển với socket. Đích cung cấp định danh phiên, được sử dụng cho các sự kiện mới trên phiên (xem các điều sau đây).

4.3.2.4  Đích từ chối yêu cầu

Nếu đích từ chối yêu cầu, URC sẽ thông báo cho người sử dụng theo cách phù hợp. Điều này bao gồm việc giải thích lý do từ chối, nếu thích hợp.

4.3.2.5  Đích chuyển tiếp yêu cầu

Nếu đích yêu cầu phiên chuyển tiếp URC đến socket khác và socket này thuộc đích yêu cầu phiên thì URC sẽ gửi yêu cầu phiên mở đến đích và socket đã định.

Nhìn chung, một socket mà URC được chuyển tiếp tới được quy định bởi tên của socket (URI), như đã đề cập trong mô tả đích của socket. Bên cạnh đó, các nền tảng TUN có thể sử dụng các cơ chế chuyển tiếp cụ thể để thực hiện quá trình chuyển tiếp.

4.3.3  Yêu cầu phiên treo URC

4.3.3.1  Khái quát

URC có thể yêu cầu rằng một phiên hoạt động với socket của đích bị tạm ngưng. Phiên treo có thể được bắt đầu lại sau đó qua yêu cầu phiên tiếp (xem điều 4.3.4) nếu phiên đó không đề cập đến thời gian.

4.3.3.2  Thời gian chờ được đề xuất

URC có thể cung cấp thời gian chờ được đề xuất cùng với yêu cầu phiên treo.

4.3.3.3  Trả lời đích

Đích trả lời yêu cầu phiên treo bằng cách từ chối hoặc chấp thuận yêu cầu. Đối với việc chấp thuận yêu cầu, đích sẽ cung cấp giá trị thời gian chờ tạm đối với phiên treo cho URC. Tuy nhiên, đích có thể quyết định ngưng phiên bất cứ lúc nào thậm chí trước khi thời gian chờ tạm xuất hiện.

4.3.4  Yêu cầu phiên tiếp URC

4.3.4.1  Khái quát

URC có thể yêu cầu một phiên treo được bắt đầu lại. URC phải truyền định danh phiên cùng với yêu cầu. Phiên tiếp có thể bị tạm ngưng ở cùng một URC hoặc một URC khác. (Do đó, một phiên có thể được chuyển từ một URC tới URC khác.)

4.3.4.2  Trả lời đích

Đích trả lời yêu cầu phiên tiếp bằng cách từ chối hoặc chấp thuận yêu cầu. Đối với việc chấp thuận yêu cầu, URC sẽ tái thiết lập phiên điều khiển với socket của phiên.

4.3.5  Sự kiện phiên đóng URC

URC phải hỗ trợ sự kiện phiên đóng mà được gửi tới socket của đích nhằm mục đích kết thúc giai đoạn điều khiển.

CHÚ THÍCH  Sự kiện phiên đóng URC không phải là cách chính quy trong việc kích thích một ứng dụng. Đối với các nhiệm vụ phức tạp giao diện người sử dụng tạo sẵn sẽ chứa các tín hiệu ‘thoát ra’ hoặc ‘khởi động lại’ (xem điều 5.5.4.2).

4.3.6  Hỗ trợ sự kiện phiên hủy

URC phải hỗ trợ sự kiện phiên bị hủy từ đích. Đối với việc nhận sự kiện này, URC phải thông báo với người sử dụng phiên bị hủy theo cách phù hợp.

4.3.7  Kết nối đã thiết lập

Trong suốt giai đoạn điều khiển. URC phải theo dõi thông tin trạng thái kết nối từ mạng trực thuộc (TUN), sao cho có thể xác định liệu URC có kết nối với đích và phản ứng trở lại một cách thích đáng hay không.

4.3.8  Hỗ trợ chuyển tiếp phiên

Đích yêu cầu phiên có thể yêu cầu URC mở một phiên với socket khác của phiên điều khiển tại mọi thời điểm. Có hai kiểu chuyển tiếp phiên: một là đóng phiên cũ (chuyển tiếp phiên hủy) và một là giữ lại phiên cũ (chuyển tiếp phiên giữ).

Đối với việc chuyển tiếp phiên, đích gửi sự kiện chuyển tiếp phiên đến URC, định danh kiểu chuyển tiếp và chứa URI của đích mới và định danh của socket đích cụ thể mà URC được gửi tới. Sự kiện chuyển tiếp phiên cũng có thể chứa mã được phép để URC mở phiên mới.

Khi nhận sự kiện chuyển tiếp phiên, URC có thể gửi một yêu cầu phiên mở (xem điều 4.3.2) cho socket mà được quy định trong sự kiện chuyển tiếp phiên, bao gồm thẻ định danh của socket mới và mã được phép nếu có trong sự kiện. Tuy nhiên, URC có thể lựa chọn không làm như vậy vì một số lý do sau đây: socket đã quy định có thể không có sẵn trên mạng URC đích sử dụng để giao tiếp với socket gốc, trong trường hợp đó người sử dụng phải được thông báo. Hoặc URC có thể kết luận rằng socket mới là không đáng tin cậy với sự giúp đỡ của người sử dụng và phần mềm thương lượng an toàn trên URC.

Đối với việc chuyển tiếp phiên có hủy, URC có thể bỏ qua sự kiện phiên đóng (xem điều 4.3.3) nếu nhận được sự kiện phiên hủy (xem điều 5.5.5) từ đích.

4.4  Quản lý socket

4.4.1  Khái quát

Sau khi yêu cầu phiên mở thành công bởi URC, một phiên được tạo và duy trì giữa socket của đích yêu cầu phiên và URC. Đối với đích không yêu cầu phiên, URC có thể giao tiếp với các socket mà không có quản lý phiên, tức là không có yêu cầu phiên mở ưu tiên.

CHÚ THÍCH URC có thể có nhiều phiên tại cùng thời điểm nếu được kết nối với nhiều socket (cùng đích yêu cầu phiên hoặc nhiều đích yêu cầu phiên).

Đối với cả đích đầy đủ phiên và đích không yêu cầu phiên, quản lý socket trên URC bao gồm các chức năng cho việc đồng bộ hóa các thẻ socket qua TUN. Điều này bao gồm cập nhật socket đáp lại sự thay đổi giá trị kích khởi cho người sử dụng. Cơ chế đồng bộ hóa này được cài đặt qua TUNL (xem điều 4.5), dựa vào các cơ chế đặc trưng cho nền tảng nối mạng để hoàn thành việc đồng bộ hóa.

Tiêu chuẩn này dựa trên việc cài đặt đối tượng phân tán cung cấp bởi tầng nối mạng trực thuộc (TUN). Người thực thi tiêu chuẩn này có thể sử dụng giải pháp hiện có cho mô hình đối tượng phân tán hoặc cài đặt theo phiên bản của chính họ.

Việc cài đặt cơ chế đồng bộ hóa đối với các thẻ socket đặc trưng cho nền tảng TUN (điều 7.2) và vượt quá phạm vi của tiêu chuẩn này. Giả thiết có cơ chế cập nhật theo sự kiện mặc dù có thể sử dụng việc kiểm soát vòng. Trong các điều nhỏ sau đây, thuật ngữ ‘propagation (phổ biến rộng rãi)’ được sử dụng để bao gồm các cơ chế đồng bộ hóa có thể xảy ra.

4.4.2  Đồng bộ hóa các biến

4.4.2.1  Khái quát

CHÚ THÍCH 1 Các biến socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

Các giá trị của các biến socket (ngoại trừ các kiểu dòng) và các thành phần của chúng, nếu có, phải được đồng bộ hóa với phiên tương ứng trên URC.

CHÚ THÍCH 2 Đối với các biến với các kiểu dòng, dòng có thể hoặc không thể được quản lý bởi socket.

CHÚ THÍCH 3 Các biến socket của các đích không yêu cầu phiên luôn được chia sẻ qua tất cả các URC kết nối. Các đích yêu cầu phiên có thể chia sẻ biến qua nhiều phiên (với nhiều URC). Nhìn chung, URC không thể xác định liệu biến có được chia sẻ với các phiên khác hay không. Tuy nhiên, thuộc tính ‘sharedSessions’ của thẻ <socket> trong mô tả đích có thể cung cấp các lời gợi ý (xem TCVN 11523-4 (ISO/IEC 24752-4)).

4.4.2.2  Chấp nhận/từ chối

Nếu giá trị được thay đổi trên URC (ví dụ trả lời hoạt động của người sử dụng), thay đổi này phải được phổ biến đến socket trên đích. Socket có thể chấp nhận hoặc từ chối thay đổi. Nếu thay đổi được chấp nhận thì nó sẽ được phổ biến trở lại đến URC (và tất cả các URC kết nối khác). Nếu thay đổi bị từ chối thì socket sẽ thông báo cho URC về việc từ chối. URC phải cập nhật giá trị biến theo các hướng dẫn của socket.

4.4.2.3  Các giá trị mới duy nhất

URC không phổ biến các thay đổi đến đích ở đó giá trị cũ bằng với giá trị mới của biến.

CHÚ THÍCH Socket cần từ chối thay đổi biến từ URC. Do sự không ổn định của mạng (chậm trễ) và các lý do an toàn. Các trường hợp sử dụng thích hợp bao gồm biến không thể được ghi tại thời điểm thay đổi khi URC chưa nhận thay đổi trạng thái từ socket tạo ra phần phụ thuộc write của biến là false. Hoặc URC đang thay đổi một biến tại cùng thời điểm nếu vậy tùy vào socket để quyết định xem chấp nhận giá trị nào.

4.4.2.4  Các giá trị không xác định

URC phải hỗ trợ thông tin về các giá trị biến không xác định mà được quy định là một phần của thông tin đồng bộ hóa từ đích.

CHÚ THÍCH 1 Các giá trị của biến có thể không được xác định với các lý do khác nhau. Ví dụ, chúng có thể không khởi tạo đúng. Hoặc chúng có thể phản ánh các tính năng không có sẵn ở các đối tượng đích riêng (xem điều 4.4.2.5).

CHÚ THÍCH 2  Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra liệu giá trị của biến được xác định với hàm uis : isAvailable (đường dẫn) hay không, xem TCVN 11523-2(ISO/IEC 24752-2).

4.4.2.5  Tính sẵn có của các biến

URC phải cung cấp thông tin về tính sẵn có của các biến mà được quy định là một phần của thông tin đồng bộ hóa từ đích.

URC không phải yêu cầu thiết lập giá trị của biến nếu biến không sẵn có tại thời gian chạy.

URC không đưa ra bất kỳ đối tượng giao diện người sử dụng nào cho người sử dụng mà được ánh xạ đến biến không sẵn có.

CHÚ THÍCH Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra tính sẵn có của biến bằng cách sử dụng hàm uis:isAvailable (đường dẫn), xem TCVN 11523-2 (ISO/IEC 24752-2).

4.4.3  Lệnh và đồng bộ hóa trạng thái lệnh

4.4.3.1  Khái quát

CHÚ THÍCH 1  Các lệnh socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

URC phải hỗ trợ yêu cầu gọi trên lệnh socket thông qua các cơ chế đặc trưng cho nền tảng TUN, bằng cách cung cấp thẻ định danh của thẻ lệnh trong mô tả socket.

CHÚ THÍCH 2  Không có gì ở trên hàm ý là 'đồng bộ’ hoặc các cuộc gọi phương pháp từ xa được sử dụng để gọi ra các lệnh trên đích hoặc để đồng bộ hóa các trạng thái của lệnh socket giữa URC và đích. Việc đồng bộ hóa nhiều lệnh socket có thể bắt đầu đồng thời và không đồng bộ, chỉ tùy thuộc vào đích liên quan đến các ràng buộc trong mô tả socket và các giá trị trạng thái liên quan và URC liên quan đến các giá trị trạng thái được trả lại từ đích.

4.4.3.2  Chấp nhận/từ chối

Yêu cầu thực hiện có thể bị từ chối bởi socket, nếu vậy socket sẽ thông báo cho URC về việc từ chối.

4.4.3.3  Các thông số đầu vào cục bộ

Khi có yêu cầu thực hiện lệnh với các thông số đầu vào cục bộ, URC phải gửi đến đích các giá trị của tất cả các thông số đầu vào cục bộ mà lệnh chứa. Điều này xảy ra trong cơ chế đặc trưng cho nền tảng TUN.

Không có sự đồng bộ hóa các thông số đầu vào cục bộ của lệnh nào khác đến đích hoặc từ đích diễn ra.

CHÚ THÍCH  Các thông số đầu vào toàn cục (các tham chiếu từ lệnh đến các biến dùng như thông số đầu vào cho lệnh) không được chuyển đến đích theo cách này. Thay vào đó, chúng được đồng bộ hóa trên các thay đổi giá trị như đã quy định cho các biến (xem điều 4.4.2).

4.4.3.4  Các thông số đầu ra cục bộ

4.4.3.4.1  Khái quát

Khi trả lời lệnh với các thông số đầu ra cục bộ, URC phải nhận từ đích các giá trị của toàn bộ thông số đầu ra cục bộ mà lệnh chứa. Điều này xảy ra trong cơ chế đặc trưng cho nền tảng TUN.

Không có sự đồng bộ hóa các thông số đầu ra cục bộ của lệnh nào khác đến đích hoặc từ đích diễn ra.

CHÚ THÍCH Các thông số đầu ra toàn cục (các tham chiếu từ lệnh đến các biến dùng như thông số đầu ra cho lệnh) không được chuyển đến đích theo cách này. Thay vào đó, chúng được đồng bộ hóa trên các thay đổi giá trị như đã quy định cho các biến (xem điều 4.4.2).

4.4.3.4.2  Giới hạn đồng thời

Lệnh kiểu uis:basicCommand hoặc uis:timeCommand không được gọi ra nhiều lần trừ khi việc thực hiện trước đó quay lại và các kết quả trước đó (các giá trị của các thông số đầu ra) được nhận.

CHÚ THÍCH Giới hạn này không áp dụng cho các lệnh kiểu uis:voidCommand mà không thể có các thông số đầu vào -đầu ra (xem TCVN 11523-2 (ISO/IEC 24752-2)).

4.4.3.5  Trạng thái lệnh

Lệnh kiểu uis:basicCommand hoặc uis:timeCommand có trạng thái chỉ được đồng bộ hóa một chiều giữa socket và URC kết nối. URC phải hỗ trợ các cập nhật từ đích liên quan đến trạng thái của lệnh- chỉ có đích mới có thể thay đổi trạng thái của lệnh và URC không được thay đổi trạng thái của lệnh.

URC nên đề cao ý nghĩa của các trạng thái lệnh, như đã đề cập trong TCVN 11523-2 (ISO/IEC 24752-2) và cho biết trạng thái của lệnh và timeToComplete (khi có liên quan) đến người sử dụng.

4.4.3.6  timeToComplete

Lệnh kiểu uis:timeCommand có trường timeToComplete chỉ hợp lệ nếu trạng thái lệnh là inProgress. Trường timeToComplete được đồng bộ hóa một chiều giữa socket và URC kết nối. URC phải hỗ trợ việc đồng bộ hóa này. Giá trị của trường timeToComplete là một lời gợi ý từ đích đến URC để tính xem thời gian ước tính hoàn thành là bao lâu - đích không cung cấp bất cứ sự đảm bảo nào. URC không được thay đổi timeToComplete - chỉ có đích mới có thể thay đổi nó.

4.4.3.7  Các trạng thái lệnh không xác định

URC phải hỗ trợ thông tin về các trạng thái lệnh không xác định được quy định là một phần của thông tin đồng bộ hóa từ đích. Điều này chỉ áp dụng cho các kiểu lệnh chiếu cố đến thông tin trạng thái lệnh (uis:basicCommand, uis:timeCommand).

CHÚ THÍCH 1  Trạng thái của lệnh có thể không xác định vì các lý do khác nhau. Ví dụ, lệnh có thể không khởi tạo đúng. Hoặc không sẵn có tại thời gian chạy ở đối tượng đích riêng (xem điều 4.4.3.8).

CHÚ THÍCH 2  Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra liệu trạng thái của lệnh có được xác định với hàm uis:hasDefinedValue (đường dẫn) hay không, xem TCVN 11523-2 (ISO/IEC 24752-2).

4.4.3.8  Tính sẵn có của các lệnh

URC phải hỗ trợ thông tin về tính sẵn có của các lệnh được quy định là một phần của thông tin đồng bộ hóa từ đích.

URC không được yêu cầu thực hiện một lệnh không sẵn có tại thời gian chạy.

URC không đưa ra bất kỳ đối tượng giao diện người sử dụng nào cho người sử dụng mà được ánh xạ đến lệnh không sẵn có.

CHÚ THÍCH  Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra tính sẵn có của lệnh bằng cách sử dụng hàm uis:isAvailable (đường dẫn), xem TCVN 11523-2 (ISO/IEC 24752-2).

4.4.4  Nhận thông báo và báo nhận

4.4.4.1  Khái quát

CHÚ THÍCH 1 Các thông báo socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

URC phải cung cấp sự hỗ trợ cho việc nhận và báo nhận các thông báo.

Nếu thông báo socket hoạt động (khởi động bởi socket của đích), URC biểu diễn điều này cho người sử dụng theo cách phù hợp, dựa trên kiểu thông báo.

CHÚ THÍCH 2 Đích có thể chia sẻ thông báo qua nhiều phiên (với nhiều URC). Nhìn chung, URC không thể xác định liệu thông báo có được chia sẻ với các phiên khác hay không.

4.4.4.2  Báo nhận rõ ràng của người sử dụng

Đối với tất cả các thông báo ngoại trừ kiểu 'show', URC nên yêu cầu người sử dụng báo nhận thông báo. Với việc báo nhận của người sử dụng, URC phải gửi sự kiện báo nhận thông báo cho đích. Tuy nhiên, URC không được thay đổi trạng thái của thông báo, nhưng sẽ đợi đến khi đích chối bỏ thông báo (bằng cách thiết lập trạng thái của nó trở về ‘không hoạt động’).

VÍ DỤ  URC yêu cầu người sử dụng báo nhận rõ ràng một thông báo bằng cách cung cấp hộp thoại với nút ‘OK’. Việc ấn nút này là sự báo nhận rõ ràng.

CHÚ THÍCH  Các thông báo kiểu ‘show’ không yêu cầu rằng chúng được báo nhận rõ ràng bởi người sử dụng.

4.4.4.3  Các thông báo xếp chồng

Đích có thể kích hoạt thông báo trong khi thông báo khác đang hoạt động. Trong trường hợp này, thông báo thứ hai chiếm ưu thế hơn thông báo thứ nhất. URC phải giữ số lượng lớn các thông báo trong tầm kiểm soát. Tất cả các thông báo không nằm trong tầm kiểm soát được xem là trong trạng thái ‘bị xếp chồng’ (ở bên trong URC và không được chia sẻ với đích). URC phải đề cao thứ tự mà các thông báo hoạt động, sao cho các thông báo kích hoạt mới nhất luôn được đưa ra cho người sử dụng. Nếu đích không kích hoạt thông báo trên cùng thì thông báo tiếp theo trên ngăn xếp của URC sẽ hoạt động lần nữa và được đưa ra cho người sử dụng. Tùy vào URC để đảm bảo rằng người sử dụng không ngẫu nhiên chối bỏ thông báo mới nếu nó được đưa ra khi người sử dụng đang trả lời thông báo trước.

CHÚ THÍCH Để ngăn ngừa việc lạm dụng như là phủ nhận các tấn công dịch vụ, URC có thể xóa phiên điều khiển với mục tiêu tại mọi thời điểm, nếu đích làm quá tải URC bằng các thông báo hoặc các sự kiện khác. Trong trường hợp này, URC nên gửi sự kiện phiên đóng URC (xem điều 4.3.5) trước khi hủy phiên.

4.4.4.4  Các trạng thái thông báo không xác định

URC phải hỗ trợ thông tin về các trạng thái thông báo không xác định được quy định là một phần của thông tin đồng bộ hóa từ đích.

CHÚ THÍCH 1  Trạng thái của thông báo có thể không xác định vì các lý do khác nhau. Ví dụ, thông báo có thể không khởi tạo đúng. Hoặc nó không sẵn có tại thời gian chạy ở đối tượng đích riêng (xem điều 4.4.4.5).

CHÚ THÍCH 2  Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra liệu trạng thái của thông báo có được xác định với hàm uis:hasDefinedValue (đường dẫn) hay không, xem TCVN 11523-2 (ISO/IEC 24752-2).

4.4.4.5  Tính sẵn có của các thông báo

URC phải hỗ trợ thông tin về tính sẵn có của các thông báo được quy định là một phần của thông tin đồng bộ hóa từ đích.

URC không được báo nhận thông báo mà không có sẵn tại thời gian chạy.

URC không được đưa ra bất kỳ đối tượng giao diện người sử dụng nào cho người sử dụng mà được ánh xạ đến thông báo không sẵn có.

CHÚ THÍCH Trong các biểu thức phụ thuộc, tác giả có thể kiểm tra tính sẵn có của thông báo bằng cách sử dụng hàm uis:isAvailable (đường dẫn), xem TCVN 11523-2 (ISO/IEC 24752-2).

4.4.5  Các chỉ số thực tế về các tập/thẻ socket thứ nguyên

Các tập kết hợp giá trị chỉ số thực tế cho mỗi tập socket và thẻ socket thứ nguyên, nếu có, phải được đồng bộ hóa giữa socket và các URC mà tham gia vào phiên chung với socket.

URC có thể yêu cầu bổ sung hoặc bỏ đi chỉ số thực tế về tập socket và thẻ socket thứ nguyên. Vì các chỉ số được xử lý theo kiểu phân cấp (‘đường dẫn chỉ số’) nên yêu cầu này phải bao gồm tất cả các chỉ số của đường dẫn chỉ số mà đi trước tập/thẻ ở đó chỉ số mới được yêu cầu bổ sung (hoặc chỉ số thực tế được yêu cầu bỏ đi theo thứ tự). Yêu cầu có thể bao gồm các giá trị ban đầu đã đề xuất cho các thành phần thẻ socket mới cuối cùng nếu chỉ số mới được yêu cầu bổ sung.

Socket sẽ chấp nhận hoặc từ chối việc sửa đổi. Nếu chấp nhận việc sửa đổi thì điều này được truyền trở lại URC (và tất cả các URC kết nối khác). Nếu từ yêu cầu thì socket sẽ thông báo với URC về việc từ chối.

URC phải cập nhật phiên tương ứng khi nhận được một sửa đổi của các giá trị chỉ số thực tế đối với tập hoặc thẻ socket thứ nguyên. Trong trường hợp chỉ số mới đang được bổ sung thì socket sẽ cung cấp giá trị ban đầu cho các thành phần thẻ mới cuối cùng và tất cả các URC kết nối phải khởi tạo các giá trị của thành phần mới theo các hướng dẫn của socket.

4.4.6  Hỗ trợ cho các phần phụ thuộc của thẻ socket

URC có thể cung cấp sự hỗ trợ cho việc giữ vững các phần phụ thuộc của các lệnh. URC nên cung cấp sự hỗ trợ cho tất cả các phần phụ thuộc khác của các biến, các lệnh và các thông báo. Các phần phụ thuộc của thẻ socket được quy định trong TCVN 11523-2 (ISO/IEC 24742-2).

Điều này bao gồm việc giải thích các giá trị phụ thuộc (các biểu thức XPath) trong khi URC được kết nối với socket. URC cho người sử dụng biết liệu thẻ socket có thể đọc được hoặc ghi được hay không và liệu tập các chỉ số thực tế cho thẻ socket thứ nguyên có thể sửa đổi theo các giá trị phụ thuộc hiện có hay không.

4.4.7  Thời gian chờ trả lời người sử dụng

4.4.7.1  Khái quát

URC phải hỗ trợ thuộc tính 'timeout' trên các thông báo (xem TCVN 11523-2(ISO/IEC 24752-2)).

Các yêu cầu sau đây áp dụng cho thời gian chờ tạo bởi đích do tính không hoạt động của người sử dụng hoặc việc thực hiện chậm. Những điều này được tham chiếu đến ‘thời gian chờ trả lời người sử dụng’.

4.4.7.2  Đưa ra thời gian chờ cho người sử dụng

URC có thể đưa ra giá trị của thuộc tính ‘timeout’ cho người sử dụng.

4.4.7.3  Yêu cầu kéo dài thời gian chờ

URC có thể yêu cầu kéo dài thời gian chờ từ đích, theo mô hình người sử dụng bên trong hoặc dựa trên giá trị được thiết lập bởi người sử dụng.

CHÚ THÍCH Cơ chế cho các yêu cầu kéo dài thời gian chờ giữa URC và đích không thuộc phạm vi của tiêu chuẩn này.

4.5  Liên kết mạng URC đích trên URC

4.5.1  Khái quát

Liên kết mạng URC đích (TUNL) trên URC là liên kết từ URC đến mạng URC đích. URC có thể hỗ trợ nhiều TUNL cho phép nó thực hiện chức năng với các công nghệ và nền tảng mạng khác nhau. Mỗi URC phải cung cấp ít nhất một TUNL. Mỗi TUNL đặc trưng cho các công nghệ kết nối và nối mạng riêng được sử dụng. Các ví dụ là "UpnP trên TUNL bluetooth”, ‘”Jini trên TUNL 802.11b”v.v... Xem điều 7.2 để biết thêm chi tiết về các mạng URC đích.

Đặc tả các kỹ thuật và cơ chế đặc trưng cho nền tảng TUN nhằm thực thi tiêu chuẩn này trên nền tảng riêng không thuộc phạm vi của tiêu chuẩn này.

4.5.2  Hỗ trợ tài nguyên nguyên tử động

URC phải hỗ trợ việc nhận và cập nhật tài nguyên nguyên tử động. Các tài nguyên nguyên tử này có thể thay đổi tại thời gian chạy.

4.6  Liên kết mạng URC tài nguyên (RUNL) trên URC

4.6.1  Khái quát

Liên kết mạng URC tài nguyên (RUNL) là liên kết từ URC đến mạng URC tài nguyên. URC có thể tiếp xúc một hoặc nhiều dịch tài nguyên thông qua RUNL để tìm kiếm tài nguyên bổ sung có thể được sử dụng bất cứ đâu khi cần.

CHÚ THÍCH 1  Tài nguyên bổ sung có thể sử dụng bất cứ đâu khi cần, như là: đối với việc xây dựng giao diện người theo yêu cầu cho các phiên với socket; đối với việc biên dịch thông tin về đích hoặc socket sang một ngôn ngữ khác; đối với việc biểu diễn hình ảnh cho các đích và socket khám phá thay vì các nhãn của chúng; v.v...

RUNL đặc trưng cho các công nghệ nối mạng và kết nối riêng được sử dụng trên mạng URC tài nguyên.

Tiêu chuẩn này không quy định bất kỳ RUNL riêng nào và cũng không quy định cách URC yêu cầu các tài nguyên từ dịch vụ tài nguyên.

VÍ DỤ  Dịch vụ web làm cơ sở cho các công nghệ như là "SOAP qua HTTP qua TCP/TP”.

4.6.2  Định vị các dịch vụ tài nguyên

Các dịch vụ tài nguyên cung cấp các tài nguyên bổ sung (ngoài các tài nguyên đích) cho các mô tả đích, các mô tả socket và các mô tả cài đặt giao diện người sử dụng (UIIDs). URC có thể sử dụng mọi dịch vụ tài nguyên mà sẵn có trên mọi liên kết mạng (RUNL) của URC.

URC có thể sử dụng một trong các cách sau đây để định vị dịch vụ tài nguyên:

a) mô tả đích bao gồm tham chiếu đến dịch vụ tài nguyên, qua thẻ <resSvc> trong mô tả đích như đã quy định trong TCVN 11523-4(ISO/IEC 24752-4);

b) liên kết đến dịch vụ tài nguyên được mã hóa cứng vào trong URC hoặc URC lấy nó từ tệp cấu hình hoặc địa chỉ máy chủ đã biết. Điển hình là dịch vụ tài nguyên được duy trì bởi nhà sản xuất URC;

c) có các dịch vụ thư mục công cộng đã biết về các dịch vụ tài nguyên, ví dụ dựa trên UDDI.

4.7  Tạo giao diện người sử dụng

4.7.1  Khái quát

Sau cùng, URC phải cung cấp giao diện người sử dụng cụ thể cho phiên điều khiển với socket của đích, dựa trên mô tả socket và tài nguyên đích, bao gồm các tài nguyên bên trong đích (các tài nguyên bổ sung).

4.7.2  Sử dụng tài nguyên đích và tài nguyên bổ sung

URC có thể sử dụng tài nguyên đích hoặc sử dụng tài nguyên bổ sung lấy từ các dịch vụ tài nguyên (hoặc bất kỳ sự kết nào của chúng). URC có thể sử dụng tài nguyên tạo nhóm hoặc mô tả cài đặt giao diện người sử dụng (UIID) lấy từ đích hoặc thông qua mạng URC tài nguyên hoặc nguồn khác (ví dụ UIID có sẵn trên URC). Không có giới hạn nào liên quan đến khả năng hòa trộn và làm cho phù hợp chừng nào socket của đích được sử dụng như là phương tiện để điều khiển đích.

4.7.3  Sử dụng tài nguyên nguyên tử

Nhãn và tài nguyên nguyên tử khác có thể được xác định cho thẻ socket và thẻ UIID mà liên kết với thẻ socket. Khi giao diện người sử dụng dựa trên UIID, URC nên đưa quyền ưu tiên cho tài nguyên nguyên tử xác định cho thẻ UIID nếu được quy định. Nếu không có tài nguyên nguyên tử nào được đưa ra cho thẻ UIID thì URC nên sử dụng tài nguyên nguyên tử thích hợp với phân tử socket mà thẻ UIID liên kết đến.

4.7.4  Quyền ưu tiên cho tài nguyên từ nhà cung cấp đích

Vì là nguyên tắc chung nên URC xây dựng giao diện người sử dụng được thiết kế và công bố bởi nhà cung cấp đích gần như các giới hạn thực tế được đưa ra của thiết bị URC, các yêu cầu và quyền ưu tiên của người sử dụng.

Kết quả là, khi URC có nhiều tài nguyên sẵn có để hoàn thành vai trò đơn trong việc xây dựng giao diện người sử dụng, như là nhiều nhãn trong đó tất cả thích hợp với cùng thẻ socket, mặt khác, khi vắng mặt quyền ưu tiên của người sử dụng chỉ thị các tài nguyên cung cấp bởi đích và nhà cung cấp đích nên được sử dụng ưu tiên được đề nghị bởi các bên thứ ba. Cụ thể, tài nguyên nguyên tử động nên được ưu tiên cho tài nguyên nguyên tử tĩnh tại thời gian chạy.

4.7.5  Quyền ưu tiên của người sử dụng

URC vẫn có thể quyết định sử dụng bất kỳ tài nguyên ứng dụng nào. Không có chuẩn nào được thiết lập trong đặc tả này cho việc hình thành các quyền ưu tiên của người sử dụng. Đây có thể là đầu vào tương tác từ người sử dụng trong suốt phiên, việc thiết lập tạo bởi người sử dụng trong suốt các phiên khác được thực hiện với cùng một URC này, hoặc một kết luận hợp lý từ lớp sản phẩm của chính URC. Khách hàng người mà quyết định mua một URC đầu ra bằng giọng nói có thể được giải thiết ưu tiên biểu diễn các nhãn âm thanh.

4.7.6  Thứ tự các thẻ

URC không cần xây dựng giao diện người sử dụng mà bảo toàn thứ tự các thẻ trong mô tả socket hoặc tài liệu UIID, nhưng nó được khuyến cáo rằng thứ tự của nhà cung cấp đích được bảo toàn theo các giới hạn thực tế được đưa ra của thiết bị URC, các yêu cầu và các quyền ưu tiên của người sử dụng.

URC nên đưa ra các đối tượng của tập socket thứ nguyên hoặc thẻ socket thứ nguyên cho người sử dụng sao cho phản ảnh thứ tự của các giá trị chỉ số như đã xác định bởi khía cạnh cơ bản 'có thứ tự’ của xác định kiểu chỉ số (xem Lược đồ XML Phần 2: Kiểu dữ liệu). Đối với các kiểu chỉ số được xác định bởi sự giới hạn (các kiểu liệt kê), thứ tự nên phản ánh thứ tự mà các giá trị được liệt kê trong định nghĩa. Nếu các kiểu liệt kê được kết hợp bởi toán tử kết hợp thì thứ tự nên theo sau thứ tự mà các kiểu cơ sở xuất hiện trong mệnh đề kết hợp.

4.8  An toàn và các yêu cầu về quyền riêng tư

Xem điều 8.2.

5  Thành phần đích và các yêu cầu

5.1  Quản lý khám phá

5.1.1  Khái quát

Quản lý khám phá bao gồm các chức năng chịu trách nhiệm truyền bá các socket sẵn có đến mạng và phổ biến các đặc tính của chúng đến các URC. Đích dựa trên các cơ chế khám phá hiện có được cung cấp bởi các liên kết mạng URC đích đã cài đặt. Trong pha khám phá, các đích tự truyền bá đến các URC thông qua các cơ chế đặc trưng cho nền tảng và sự phân phối mô tả đích.

5.1.2  Định danh đối tượng đích

Đích phải có định danh đối tượng được tạo sẵn cho các URC thông qua tất cả các liên kết mạng URC đích của đích. Định danh đối tượng phải là duy nhất trong số tất cả các đích với cùng một tên (xem TCVN 11523-4 (ISO/IEC 24752-4)).

CHÚ THÍCH  Định danh đối tượng đích được tạo sẵn cho URC thông qua các cách đặc trưng cho TUN (xem điều 7.2.2) và có thể được tham chiếu trong các mô tả tài nguyên nguyên tử (xem TCVN 11523-5 (ISO/IEC 24752-5)). Tuy nhiên, mô tả đích và mô tả socket được cho là chung cho tất cả các đối tượng của sản phẩm và do đó không tạo ra các tham chiếu đến các đối tượng đích.

5.1.3  Hỗ trợ cho việc triển khai tài liệu

Đích phải cung cấp cơ chế tìm nạp đặc trưng cho TUN mà cho phép URC lấy lại mô tả đích, các mô tả socket và các tệp tài nguyên đích bởi URI. Cơ chế tìm nạp này có thể bao gồm các cơ chế xác thực đối với URC và/hoặc đích.

Đích phải hỗ trợ các kiểu MINE đã quy định của mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752- 4)), mô tả socket (xem TCVN 11523-2(ISO/IEC 24752-2)), tệp tài nguyên và tệp tạo nhóm ((xem TCVN 11523-5 (ISO/IEC 24752-5)), nếu thích hợp.

Để thuận lợi hóa cho việc nâng cấp hiệu suất thông qua bộ nhớ đệm cạnh-URC, đích có thể hỗ trợ các cơ chế cụ thể như là các yêu cầu tài liệu có điều kiện dựa trên việc sửa đổi ngày tháng của tài liệu.

Việc triển khai tài liệu phải có sẵn trong pha khám phá và pha điều khiển.

5.1.4  Mô tả đích

Đích phải cung cấp chính xác một mô tả đích, độc lập với số socket mà đích cung cấp. Điều này phải là mô tả đích như đã quy định trong TCVN 11523-4 (ISO/IEC 24752-4) hoặc mô tả đích ngầm định như đã quy định trong TCVN 11523-6 (ISO/IEC 24752-6).

Mô tả đích phải chứa các con trỏ đến các mô tả socket cho tất cả các socket của nó (bao gồm các socket mà URC có thể được chuyển tiếp đến). Mô tả đích cũng phải tham chiếu tất cả các tệp tài nguyên chứa các tài nguyên nguyên tử đích được yêu cầu và tệp tạo nhóm chứa nhóm được yêu cầu (xem điều 5.4.5).

CHÚ THÍCH 1 Mô tả đích là tài liệu cung cấp tất cả thông tin và tham chiếu được yêu cầu bởi URC trong pha khám phá, cho phép URC khám phá, định danh và nắm bắt đích và (các) socket của nó. Việc định vị mô tả đích được cung cấp cho URC bởi đích theo cách đặc trưng cho nền tảng TUN.

CHÚ THÍCH 2 Mô tả đích được ghi theo cách độc lập với nền tảng TUN (ngoại trừ thông tin ánh xạ đặc trưng cho nền tảng có thể được bao gồm). Phụ lục B trình bày ví dụ về mô tả đích.

CHÚ THÍCH 3 Mô tả đích độc lập với với các ngôn ngữ tự nhiên. Các tài nguyên nguyên tử đích (xem điều 5.4.2) và/hoặc các tài nguyên nguyên tử bổ sung cần được sử dụng để các phần liên quan đến nội dung của nó có thể được trả lại cho người sử dụng.

5.1.5  Hỗ trợ cho các chức năng định vị

Đích phải cung cấp cho việc hỗ trợ các chức năng định vị mà được quy định trong mô tả đích, sao cho URC có thể gọi chúng trong suốt các pha khám phá và pha điều khiển theo cách đặc trưng cho TUN. Định danh thẻ <locator> được sử dụng dụng để định danh chức năng định vị cụ thể.

5.2  Socket giao diện người sử dụng

5.2.1  Khái quát

Socket giao diện người sử dụng cung cấp truy cập thực tế đến và điều khiển đơn vị chức năng của đích. Socket được sử dụng để điều hành đích từ Bộ điều khiển thiết bị phổ dụng (URC) khi mà phiên điều khiển được khởi tạo. Socket biểu diễn chức năng và trạng thái của đích theo cách máy có thể hiểu được sao cho URC có thể truy cập và điều hành nó, theo đó cung cấp cách truy cập và điều khiển cho người sử dụng URC.

CHÚ THÍCH  Socket UI độc lập với nền tảng TUN. Tại thời gian chạy, socket UI được kết nối với một hoặc nhiều nền tảng TUN thông qua các liên kết mạng URC đích.

5.2.2  Các socket của đích

Đích phải cung cấp một hoặc nhiều socket giao diện người sử dụng (hoặc các socket ngắn). Socket được định vị trên đích.

CHÚ THÍCH Trong một cài đặt hướng đối tượng của URC, socket có thể được biểu diễn theo phía máy khách như một đối tượng proxy. Chúng tôi khuyến cáo gọi đối tượng này là ‘đối tượng phản chiếu socket’ để tạo sự phân biệt với socket chủ phía đích.

Nếu một đích có nhiều socket thì mỗi socket phải biểu diễn đơn vị chức năng của chức năng của đích. Để điều tiết nhiều URC, thông tin giao diện người sử dụng được cung cấp theo kiểu trừu tượng hơn là theo định dạng cụ thể cho giao diện (ví dụ giao diện nhìn, giao diện lời nói, giao diện tối ưu hóa cho điện thoại thông minh, v.v...).

Nói chung, các socket của đích phải cung cấp truy cập cho tất cả các chức năng cung cấp bởi giao diện người sử dụng của đích dựng sẵn.

5.2.3  Các thẻ socket

5.2.3.1  Khái quát

Socket chứa các biến, các lệnh và các thông báo.

a) Các biến biểu diễn dữ liệu động liên quan đến trạng thái của tương tác đích người sử dụng. Chúng phải bao gồm tất cả các dữ liệu động trên trạng thái của socket đích mà người sử dụng có thể nhận biết và/hoặc vận dụng, và cũng có thể bao gồm dữ liệu hỗ trợ động bổ sung mà không đưa ra cho người sử dụng. Ví dụ, các biến bao gồm âm lượng của tivi, hoặc tầng hiện tại của thang máy. Tất cả các biến đều có giá trị. Đích có thể thay đổi giá trị của biến tại mọi thời điểm. URC cố gắng thay đổi giá trị của biến tại mọi thời điểm nhưng đích có thể chấp nhận hoặc từ chối thay đổi. Các thay đổi của biến trên một giới hạn (đích hoặc URC) được truyền đến giới hạn khác ngay lập tức (đồng bộ hóa hai chiều).

b) Lệnh là chức năng chính mà người sử dụng có thể yêu cầu một đích (thông qua socket của nó) để thực hiện và không thể được biểu diễn bởi biến. Các lệnh phải bao gồm tất cả các chức năng đích mà có thể được gọi rõ ràng hoặc ngầm định bởi người sử dụng. Các ví dụ bao gồm lệnh 'search (tìm kiếm)’ của hệ thống giữ chỗ hàng không hoặc lệnh ‘seek (tìm)’ của máy nghe nhạc.

c) Các thông báo là các trạng thái đặc biệt ở đó thao tác thông thường bị tạm ngưng, như là trạng thái loại bỏ. Các thông báo được khởi động bởi đích. Chúng phải bao trùm tất cả các loại bỏ mà đích cần thông báo cho người sử dụng. Các ví dụ bao gồm thông báo tạo bởi hệ thống địa chỉ trong sân bay, báo thức hoặc trả lời đầu vào không hợp lệ cho trường của một biểu mẫu. Thông báo có một trạng thái mà phải được tạo sẵn để URC kiểm tra. Chỉ có đích (thông qua các socket của nó) mới có thể cập nhật trạng thái của thông báo; các cập nhật được truyền đến URC.

Socket chịu trách nhiệm duy trì giá trị chính xác và thông tin trạng thái cho các biến, các lệnh và các thông báo.

5.2.3.2  URC đa kết nối

Socket có thể chia sẻ các giá trị biến, lệnh và các trạng thái thông báo trong số các URC đa kết nối hoặc duy trì các tập riêng rẽ (các phiên) cho mỗi URC. Đối với các thẻ chia sẻ, socket phải phổ biến các thay đổi cho tất cả các URC kết nối.

5.2.3.3  Các đích nhiều người sử dụng và một người sử dụng

Đích nhiều người sử dụng như là tivi có thể duy trì một socket chia sẻ tất cả các biến cho tất cả URC kết nối. Đích một người sử dụng như là dịch vụ đổi tiền có thể duy trì một socket mà có nhiều bản sao tập biến, mỗi bản sao cho mỗi URC kết nối. Các đích khác có thể chấp nhận phương pháp hỗn hợp. Ví dụ, thang máy với các URC đa kết nối có thể có một số biến chia sẻ (ví dụ: vị trí của mỗi thang máy) và một số biến đặc trưng cho URC (ví dụ: tầng yêu cầu của người sử dụng).

5.2.3.4  Đồng bộ hóa

Tiêu chuẩn này dựa trên mức cao nhất của nền tảng mạng hiện có hơn là thay thế chúng. Tiêu chuẩn này dựa vào các cách đồng bộ hóa trạng thái socket đặc trưng cho nền tảng TUN giữa socket của đích và các URC kết nối.

5.3  Mô tả socket giao diện người sử dụng

5.3.1  Khái quát

Nhà sản xuất đích phải cung cấp mô tả socket giao diện người sử dụng cho mỗi socket của đích. Mô tả socket phải phù hợp với TCVN 11523-2 (ISO/IEC 24752-2) quy định ngôn ngữ dựa trên XML cho các tài liệu mô tả socket dành riêng (xem Bảng 2) hoặc phù hợp với TCVN 11523- 6(ISO/IEC 24752-6) quy định ‘mô tả socket ngầm định' gắn trong tài liệu WSDL.

Mô tả socket phải mô tả tất cả thông tin và tính năng điều khiển biểu diễn trong socket. Mô tả socket cũng phải quy định tất cả các thông tin tĩnh về socket mà sẵn có cho người sử dụng của giao diện người sử dụng dựng sẵn như là số máy.

CHÚ THÍCH 1 Mô tả socket giao diện người sử dụng là đặc tả mà mô tả các thẻ của socket theo cách độc lập với nền tầng TUN. Nó được thiết kế để hỗ trợ mỗi lớp URC, bao gồm các giao diện người sử dụng và các khái niệm giao diện người sử dụng khác như là các đại lý phần mềm thông minh.

CHÚ THÍCH 2  Đối với các sản phẩm kế thừa có TUN mặc định (ví dụ: UpnP hoặc Java/Jini), nhà sản xuất đích có thể cung cấp bên ngoài một tập các mô tả socket bị thiếu.

5.4  Tài nguyên đích

5.4.1  Tài nguyên tạo nhóm đích

Tài nguyên tạo nhóm có thể được cung cấp như một phần của các tệp tạo nhóm như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5).

Ngoại trừ tài nguyên tạo nhóm phải được cung cấp phù hợp (xem điều 5.4.5), số tài nguyên tạo nhóm có thể được cung cấp bởi nhà sản xuất đích.

CHÚ THÍCH  Tài nguyên tạo nhóm quy định cấu trúc của các thẻ socket giao diện người sử dụng hoặc các thẻ UIID theo kiểu trên xuống và được cung cấp bên ngoài cho mô tả socket. Trong các phân nhóm riêng lẻ của tài nguyên tạo nhóm và các thẻ giao diện người sử dụng có thể xuất hiện nhiều lần (trong các nhóm cha khác nhau)

5.4.2  Tài nguyên nguyên tử đích

5.4.2.1  Khái quát

Đích có thể cung cấp tài nguyên nguyên tử đích.

Tài nguyên nguyên tử đích là tài nguyên nguyên tử mà được cung cấp bởi đích thông qua hỗ trợ của nó để triển khai tài liệu (xem điều 5.1.2). Với các tài nguyên khác, các tài nguyên nguyên tử đích có thể hoặc không thể được sử dụng bởi URC và có thể được bổ sung hoặc thay thế bởi các tài nguyên bổ sung thích hợp từ các nguồn bên ngoài.

Tài nguyên nguyên tử đích được phân loại thành các lớp sau đây: các nhãn, các từ khóa, trợ giúp, các khóa truy cập và vị trí. Để biết thêm thông tin về các tài nguyên nguyên tử, tham khảo TCVN 11523-5(ISO/IEC 24752-5).

5.4.2.2  Nhãn

Tài nguyên nhãn là mọi đối tượng được sử dụng như thực thể nhãn trong giao diện người sử dụng cụ thể. Nhìn chung, tài nguyên nhãn có thể là văn bản, đồ họa, âm thanh hoặc sử dụng phương thức khác bao gồm nhiều phương thức.

Ngoại trừ các nhãn phải được cung cấp phù hợp (xem điều 5.4.5), mọi nhãn có thể được cung cấp bởi nhà sản xuất đích.

5.4.2.3  Từ khóa

Mọi từ tài nguyên từ khóa có thể được cung cấp bởi nhà sản xuất đích.

5.4.2.4  Trợ giúp

Mọi tài nguyên trợ giúp có thể được cung cấp bởi nhà sản xuất đích.

5.4.2.5  Khóa truy cập

Mọi tài nguyên khóa truy cập có thể được cung cấp bởi nhà sản xuất đích.

5.4.2.6  Vị trí

Mọi tài nguyên vị trí có thể được cung cấp bởi nhà sản xuất đích.

CHÚ THÍCH Tài nguyên định vị có thể được sử dụng để mô tả vị trí của đích. Trong trường hợp này tài nguyên vị trí phải chỉ tới thẻ <target> của mô tả đích.

Đối với các đích có vị trí vật lý, nội dung của tài nguyên vị trí đích nên được cập nhật khi di chuyển đích.

VÍ DỤ  Khi thiết bị được mua và được cài đặt trong nhà/văn phòng/khách sạn thì tài nguyên vị trí nên được cập nhật.

5.4.2.7  Thực thể gắn với tài nguyên nguyên tử đích

Các nhà sản xuất có thể cung cấp tài nguyên nguyên tử (bằng một hoặc nhiều ngôn ngữ tự nhiên) đối với các thực thể sau đây:

- trong mô tả đích: cho các thẻ <target>, <locator> và <socket>;

- trong mô tả socket: cho thẻ gốc <uiSocket>; cho thẻ <set>; cho các thẻ <variable>, <command> và <notification> và cho các xác định kiểu bên trong qua <simpieType> và <complex Type>;

- trong tệp tài nguyên: cho các thẻ <group>;

- trong tệp định nghĩa XML bên ngoài (XSD): cho các thẻ <simpleType> và <complexType>;

- cho mọi thẻ UIID có định danh.

5.4.3  Tệp tài nguyên đích

Các tài nguyên nguyên tử đích được quy định trong các tệp tài nguyên, như đã quy định trong TCVN 11523-5 (ISO/IEC 24752-5), xem Phụ lục B để xem ví dụ về tệp tài nguyên.

Tệp tài nguyên đích nên giữ ổn định nhất có thể. Tệp tài nguyên đích chỉ có thể thay đổi nếu định danh hoặc ngày tháng sửa đổi của của tệp bị thay đổi.

5.4.4  Tệp tạo nhóm đích

Tài nguyên tạo nhóm đích được quy định trong các tệp tạo nhóm, như đã quy định trong TCVN 11523-5 (ISO/IEC 24752-5), xem Phụ lục B để xem ví dụ về tệp tạo nhóm.

Tệp tạo nhóm đích nên giữ ổn định hết mức có thể. Tệp tạo nhóm đích chỉ có thể thay đổi nếu định danh của nó hoặc ngày tháng sửa đổi của nó bị thay đổi.

5.4.5  Tài nguyên đích yêu cầu

5.4.5.1  Khái quát

Các tài nguyên nhãn sau đây (xem điều 5.4.3) phải được cung cấp bởi nhà sản xuất đích:

a) tài nguyên tạo nhóm cho mỗi socket của đích tham chiếu tất cả các thẻ socket UI nhưng không có thẻ nào từ socket hay UIID khác;

b) nhãn văn bản cho thẻ <target> trong mô tả đích (như tài nguyên nguyên tử tĩnh);

CHÚ THÍCH 1 Nhãn văn bản có giá trị vai trò của http://myurc.org/ns/res#label, với giá trị dc :type "Text” và giá trị dc :format "text/xml” hoặc "application/xml” và nội dung của nó là chuỗi ký tự không định dạng (xem TCVN 11523-5 (ISO/IEC 24752-5))

CHÚ THÍCH 2  Các nhãn văn bản có thể là tĩnh hoặc động. Các nhãn tính là các phần của tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)). Các nhãn động được xem là một phần của các tài nguyên đích yêu cầu và cần được cung cấp phù hợp tại thời gian chạy

c) nhãn văn bản cho mỗi thẻ <socket> trong mô tả đích (như tài nguyên nguyên tử tĩnh);

CHÚ THÍCH 3  Đây cũng là nhãn văn bản cho thẻ <uiSocket> của mô tả socket.

d) nhãn văn bản cho mỗi thẻ <locator> trong mô tả đích (như tài nguyên nguyên tử tĩnh):

e) nhãn văn bản cho mỗi thẻ <variable>, <command> và <notify> trong mô tả socket cho mỗi socket (như tài nguyên nguyên từ tĩnh hoặc động);

f) nhãn văn bản cho mỗi kiểu trong mô tả socket cho mỗi socket nếu người dùng không hiểu được tên kiểu (như tài nguyên nguyên tử tĩnh hoặc động):

g) nhãn văn bản cho mỗi giá trị liệt kê trong mô tả đích cho mỗi socket nếu người dùng không hiểu giá trị liệt kê (như tài nguyên nguyên tử tĩnh hoặc động):

h) nhãn văn bản cho mỗi thẻ <Group> trong các tài nguyên tạo nhóm yêu cầu, xem mục (a) ở trên (như tài nguyên nguyên tử tĩnh).

CHÚ THÍCH 4  Tất cả các tệp tài nguyên chưa tài nguyên đích yêu cầu phải được tham chiếu từ mô tả đích (xem điều 5.1.4).

CHÚ THÍCH 5  Đối với các sản phẩm kế thừa mà có TUNL mặc định (ví dụ UpnP hoặc Java/Jini), nhà sản xuất đích có thể cung cấp tập các tài nguyên đích yêu cầu, nghĩa là các tệp tài nguyên (bổ sung) bên ngoài.

5.4.5.2  Tính độc lập về văn bản và phương thức

Để cho phép nhiều giao diện URC được xây dựng (phù hợp với môi trường, các ràng buộc người sử dụng và các đặc điểm thiết bị của URC, cũng như hỗ trợ các tác nhân thông minh) thì thông tin trong các tài nguyên đích yêu cầu phải có tính độc lập về văn bản và phương thức. Giả sử được đưa ra dưới dạng nghe hoặc nhìn và không có các giả thiết về kích cỡ của màn hình, sự hiện diện của bàn phím, v.v...

5.4.6  Sự phù hợp trong ngôn ngữ tự nhiên

Đích phải phù hợp trong ít nhất một ngôn ngữ tự nhiên.

Để dễ dàng chuyển dịch, đích nên phù hợp với ít nhất một ngôn ngữ thông dụng.

Đích phù hợp với ngôn ngữ tự nhiên nếu nó cung cấp ít nhất một đối tượng cho mỗi tài nguyên đích yêu cầu (một tập hoàn thiện như đã xác định trong điều 5.4.5) thích hợp với ngôn ngữ tự nhiên, với các nhãn bao trùm mô tả đích và mỗi socket của đích. Nếu một trong các socket của đích chứa các thẻ socket mà các tài nguyên nguyên tử được cung cấp tại thời gian chạy (‘các tài nguyên nguyên tử động’) thì các nhãn này được coi là một phần của các tài nguyên nguyên tử yêu cầu và cần được cấp phù hợp trong ngôn ngữ tự nhiên.

Có một loại bỏ đối với các socket đặc trưng về văn hóa: nếu có tập con các socket sao cho mỗi socket trong tập con này cung cấp truy cập đến cùng thông tin và chức năng của đích, nói một cách đầy đủ, các tài nguyên đích yêu cầu trong ngôn ngữ tự nhiên đó được cung cấp cho một trong các socket trong tập con.

5.4.7  Mô tả cài đặt giao diện người sử dụng đích (UIIDs)

UIIDs là các mô tả cụ thể cho việc cài đặt một giao diện đến socket. Chúng được mô tả đầy đủ hơn trong điều 6.10. UIID có thể được cung cấp ở bất cứ dạng nào. Điều này cho phép hỗ trợ cho các công nghệ độc quyền trên các thiết bị URC cụ thể.

Đích có thể cung cấp nhiều mô tả cài đặt giao diện người sử dụng (UlIDs), gọi là UIIDs đích, một số trong chúng liên quan đến cùng một socket.

Với tất cả các UIIDs, UIID đích luôn dựa trên một hoặc nhiều socket, nghĩa là mọi tương tác giữa một socket và UIID thông qua socket.

CHÚ THÍCH  Khác với mô tả socket, UIID có thể hoặc không thể được sử dụng bởi URC. URC có thể quyết định sử dụng mọi UIID cung cấp bên ngoài cho đích, hoặc tạo một giao diện người sử dụng trực tiếp từ mô tả socket.

UIID đích có thể sử dụng các tài nguyên đích hoặc sử dụng thông tin tương đương gắn vào UIID đích hoặc lấy từ các tài nguyên bổ sung (xem Điều 6).

5.5  Quản lý phiên

5.5.1  Hỗ trợ cho yêu cầu phiên mở URC

5.5.1.1  Khái quát

Đích yêu cầu phiên phải hỗ trợ yêu cầu phiên mở từ URC. Đích không yêu cầu phiên không cung cấp phương pháp mở một phiên.

Yêu cầu phiên mở từ URC chứa định danh (URI) của socket đã yêu cầu. Đích được yêu cầu trả lời yêu cầu phiên mở URC theo một trong các cách: chấp nhận, từ chối hoặc chuyển tiếp đến socket khác (xem điều 5.5.7). Yêu cầu phiên mở và phản hồi của đích đặc trưng cho nền tảng mạng riêng.

5.5.1.2  Chấp nhận

Nếu đích chấp nhận yêu cầu thì nó phải cung cấp thông tin đầy đủ về URC để mở một phiên với socket. Điều này phải bao gồm việc cung cấp định danh phiên. Mỗi socket phải được kết nối với TUNL mà hỗ trợ cùng nền tảng TUN khi đích sử dụng để quảng bá socket của nó (khám phá). Nếu đích quảng bá qua nhiều nền tảng TUN thì phải được hỗ trợ bởi mỗi socket.

5.5.1.3  Từ chối

Trong trường hợp từ chối, đích phải trả lời yêu cầu phiên mở với một trong các mã sau đây:

- ‘Bad request’: tên đích/socket không hợp lệ;

- ‘Unauthorized’: yêu cầu phiên mở không chưa mã cho phép dù đã yêu cầu;

- ‘Authorization Failed’: mã cho phép không hợp lệ;

- ‘Too many Session’: đích có nhiều phiên mở;

- ‘Inappropriate’: đích/socket không thích hợp cho người sử dụng và/hoặc ngữ cảnh sử dụng;

- ‘Gone’: đích/socket hiện tại không hoạt động;

- ‘Internal Server Error’: Lỗi bên trong xảy ra trong đích;

- ‘Other’: không có mã cung cấp cho lý do từ chối;

- ‘Unknown’: đích không muốn cung cấp lý do từ chối.

5.5.1.4  Chuyển tiếp

Nếu đích chuyển tiếp URC đến socket khác (của cùng đích hoặc đích khác) thì nó phải cung cấp đầy đủ thông tin cho URC để yêu cầu một phiên với socket khác. Điều này bao gồm các tên (URIs) của đích và socket mà URC chuyển tiếp đến như đã đề cập trong mô tả đích của mục tiêu đến. Ngoài ra, các nền tảng TUN có thể sử dụng các cơ chế chuyển tiếp khác để tính hành quá trình chuyển tiếp.

CHÚ THÍCH  Cách một đích phản ứng với các yêu cầu phiên mở trong khi có một phiên mở rồi (với URC khác) xác định xem liệu có thể vận hành nhiều URC tại cùng một thời điểm hay không. Phiên song song trên socket có thể hoặc không thể chia sẻ trạng thái socket của phiên hiện có. Điển hình là, Tivi cho phép nhiều phiên chia sẻ các giá trị trạng thái socket. Sử dụng tính năng chuyển tiếp, máy ATM nên tính đến một phiên 'hoạt động' và nhiều phiên 'xếp hàng chờ'.

5.5.2  Hỗ trợ cho yêu cầu phiên treo URC

Đích yêu cầu phiên phải hỗ trợ yêu cầu phiên treo từ URC. Đích không yêu cầu phiên không cung cấp phương pháp tạm ngưng một phiên.

Đích yêu cầu phiên phải trả lời yêu cầu phiên treo URC (xem điều 4.3.3) bởi một trong các cách sau đây:

- từ chối;

- cấp yêu cầu và cung cấp giá trị thời gian chờ dự kiến cho phiên treo URC. Mục tiêu có thể lấy giá trị do URC gợi ý hoặc mọi giá trị thời gian chờ khác. Giá trị thời gian chờ dự kiến phải cho biết đích dự định giữ phiên có hiệu lực là bao lâu. Đó là giá trị không đảm bảo dù đích có thể ngừng phiên tại mọi thời điểm sau khi yêu cầu.

Trong trường hợp từ chối, đích phải trả lời yêu cầu phiên treo với một trong các mã sau đây:

- “Bad Request”: định danh phiên là không hợp lệ;

- “Inappropriate”: trạng thái phiên hiện tại là không phù hợp cho việc tạm ngừng phiên;

- “Not Implemented”: đích không cài đặt chức năng phiên treo/tiếp;

- “Internal Server Error”: lỗi bên trong xảy ra trong đích;

- “Other”: không có mã cung cấp cho lý do từ chối;

- "Unknown”: đích không muốn cung cấp lý do từ chối.

5.5.3  Hỗ trợ cho yêu cầu phiên tiếp URC

Đích yêu cầu phiên phải hỗ trợ yêu cầu phiên tiếp từ URC. Đích không yêu cầu phiên không cung cấp phương pháp bắt đầu lại một phiên.

Đích yêu cầu phiên phải trả lời yêu cầu phiên tiếp URC (xem điều 4.3.4) bởi một trong các cách sau đây:

- từ chối yêu cầu. Điều này có thể do phiên bị ngừng bởi đích hoặc vì các lý do khác;

cấp yêu cầu và thiết lập lại phiên treo với URC. Phiên mà được bắt đầu lại có thể bị tạm ngưng trên URC đang yêu cầu hoặc URC khác. (Do đó một phiên có thể được truyền từ một URC đến một URC khác.)

Trong trường hợp từ chối, đích phải trả lời yêu cầu phiên tiếp với một trong các mã sau đây:

- “Bad Request”: định danh phiên là không hợp lệ;

- “Too Many Sessions”: đích có quá nhiều phiên mở;

- “Inappropriate”: trạng thái phiên hiện thời không phù hợp cho việc bắt đầu lại phiên;

- “Not Implemented”: đích không cài đặt chức năng phiên treo/tiếp;

- “Internal Server Error”: lỗi bên trong xảy ra trong đích;

- “Other”: không có mã cung cấp cho lý do từ chối;

- “Unknown”: đích không muốn cung cấp lý do từ chối.

5.5.4  Hỗ trợ cho sự kiện phiên đóng URC

5.5.4.1  Khái quát

Đích yêu cầu phiên phải hỗ trợ sự kiện phiên đóng từ URC. Đích không yêu cầu phiên không cung cấp phương pháp đóng phiên.

Đích yêu cầu phiên phải trả lời sự kiện phiên đóng URC bằng cách đóng phiên tức thì.

- Đối với các socket đơn (ví dụ: ATM). Mọi giao dịch đã hoàn thành, xác nhận hoặc lưu thì sẽ không được làm lại.

- Đối với các socket nhiều người sử dụng (ví dụ: Ti vi): phụ thuộc vào cách socket phản ứng với việc không kết nối URC.

5.5.4.2  Thoát khỏi ứng dụng

Sự kiện phiên đóng URC không phải là cách thoát khỏi ứng dụng thông thường.

Đối với các nhiệm vụ phức tạp, giao diện người sử dụng dựng sẵn của đích sẽ chứa tín hiệu “exit" hoặc "reset". Trong trường hợp socket giao diện người sử dụng phải chứa các tín hiệu tương đương (sử dụng các lệnh socket, các biến socket hoặc các thông báo socket) để người sử dụng xóa ứng dụng theo cách đúng đắn.

5.5.5  Sự kiện phiên hủy

5.5.5.1  Khái quát

Các socket có thể hủy các phiên người sử dụng tại các thời điểm khác nhau với các lý do khác nhau, điều đó cho biết việc kết thúc một phiên mà không có yêu cầu hoặc xác nhận của người sử dụng. Trong trường hợp này, đích phải gửi một sự kiện phiên hủy đến URC.

Trong trường hợp hủy, đích phải cung cấp một trong các mã sau đây cho biết lý do hủy phiên:

- “Session Expired”: thời gian chờ xảy ra trên đích;

- “Suspended Session Timeout": thời gian chờ xảy ra trên đích sau khi phiên bị tạm ngưng

- “Session Forwarded”: phiên bị đóng bởi đích do yêu cầu chuyển tiếp;

- “Too Many Sessions”: đích có quá nhiều phiên mở;

- “Gone”: đích/socket không hoạt động thời điểm hiện tại;

- “Internal Server Error”: lỗi bên trong xảy ra trong đích;

- “Other”: không có mã cung cấp cho lý do từ chối;

- “Unknown”: đích không muốn cung cấp lý do từ chối.

5.5.5.2  Các điều kiện

Các điều kiện hủy phiên có thể khác nhau. Tuy nhiên, các nhà thiết kế socket nên bảo đảm rằng các điều kiện hủy phiên không áp đặt gánh nặng hay rào cản cho người dùng không có khả năng hoặc người dùng trong các môi trường ràng buộc, xem mục (c) dưới đây

Các điều kiện hủy phiên có thể bao gồm:

a) mất kết nối. Trong trường hợp này, URC không thể nhận sự kiện phiên hủy bởi kết nối bị mất;

b) thời gian chờ trả lời người sử dụng. Xem điều 4.4.7 và 5.6.10;

c) tần số lỗi người sử dụng. Người sử dụng không có khả năng hoặc trong các môi trường ràng buộc (ví dụ: ồn ào, gập gềnh) có thể tạo ra tần số cao hơn nhà thiết kế socket mong đợi. Các phiên không bị hủy bởi tần số lỗi người sử dụng cao, ngoại trừ các lý do về an toàn như là các lỗi mật khẩu lặp lại trong thủ tục đăng nhập của người sử dụng

5.5.6  Kết nối đã thiết lập

5.5.6.1  Khái quát

Trong pha điều khiển, đích phải tìm ra thông tin trạng thái kết nối từ mạng TUN trực thuộc, sao cho có thể xác định xem liệu nó vẫn được kết nối với URC hay không.

5.5.6.2  Mất kết nối

Trong trường hợp mất kết nối trong pha điều khiển, nó tùy thuộc vào cách socket phản ứng, ví dụ: thực hiện hoạt động thiết lập lại tức thì hoặc chỉ sau thời gian chờ nhất định. Khi thích hợp, socket nên nhắc nhở người sử dụng liệu họ có muốn bắt đầu lại cuộc hội thoại hay không, nếu kết nối được thiết lập lại với số thời gian nhất định.

5.5.7  Chuyển tiếp phiên

5.5.7.1  Khái quát

Đích yêu cầu phiên có thể yêu cầu URC mở phiên với socket khác (của cùng một đích hoặc đích khác nhau) tại mọi thời điểm của phiên điều khiển. Có hai kiểu chuyển tiếp phiên: một là đóng phiên cũ (“chuyển tiếp có hủy”) và một là giữ phiên cũ (“chuyển tiếp phiên nhân’’ hoặc “yêu cầu phiên con”). Trong trường hợp thứ hai, các phiên cũ và mới sẽ kết thúc độc lập với nhau.

5.5.7.2  Chỉ báo chuyển tiếp phiên trong mô tả socket

Nếu việc thực hiện lệnh socket có thể kích khởi việc chuyển tiếp phiên thì đích nên chỉ báo như vậy trong mô tả socket bằng cách bao hầm chức năng “subSession” trong điều kiện sau của thẻ lệnh (xem TCVN 11523-2 (ISO/IEC 24752-2)).

5.5.7.3  Sự kiện chuyển tiếp phiên

Đối với chuyển tiếp phiên, socket phải gửi sự kiện chuyển tiếp phiên cho URC, định danh kiểu chuyển tiếp và chứa URI của đích mới và định danh của socket đích cụ thể mà URC chuyển tiếp đến. Sự kiện chuyển tiếp phiên cũng có thể chứa mã cho phép cho URC để mở phiên mới.

Socket mới không được yêu cầu có sẵn trên TUN sử dụng bởi đích xuất phát.

5.5.7.4  Sau sự kiện chuyển tiếp phiên

Sau sự kiện chuyển tiếp phiên có thể được trợ giúp bởi người sử dụng, tùy thuộc vào URC xác định xem liệu có làm theo yêu cầu chuyển tiếp phiên từ đích hay không. Nếu sự kiện chuyển tiếp phiên được làm theo thì URC sẽ gửi yêu cầu phiên mở (xem điều 4.3.2) cho đích mà nó đang được chuyển tiếp đến, nếu đích là đầy đủ phiên. Trong trường hợp này, đích nên chấp nhận yêu cầu phiên mở được kích khởi bởi sự kiện chuyển tiếp phiên nếu xảy ra trong khung thời gian hợp lý.

Socket không thể tự chuyển URC đến một phiên mới. Tuy nhiên, trong trường hợp chuyển tiếp có hủy, đích yêu cầu phiên có thể hủy phiên cũ bằng cách gửi sự kiện phiên hủy đến URC (xem điều 5.5.5).

5.5.7.5  Chuyển tiếp trong cùng một đích

Đối với việc chuyển tiếp phiên trong cùng một đích yêu cầu phiên hoặc giữa các đích mà cài đặt cùng một liên kết mạng URC đích, sự kiện chuyển tiếp đến URC có thể chứa các thông số đặc trưng cho nền tảng nối mạng để tối ưu hóa sự chuyển tiếp giữa các socket.

VÍ DỤ Sự cung cấp định danh đích - socket đặc trưng cho việc nối mạng có thể xóa bỏ quá trình khám phá tốn nhiều thời gian cho một socket mới.

5.6  Quản lý socket

5.6.1  Khái quát

Sau yêu cầu phiên mở thành công bởi URC, một phiên phải được tạo và duy trì giữ socket và URC.

5.6.2  Các phiên của socket

Socket của đích yêu cầu phiên có thể có nhiều phiên mở tại cùng một thời điểm nếu nhiều URC đang tham gia trong một phiên điều khiển chung với socket. Phụ thuộc vào đích và socket của nó để xác định xem liệu các giá trị của các thẻ socket có được chia sẻ giữa các phiên hay không. Thực tế, điều này có thể khác với các thẻ socket khác và thẻ chia sẻ có thể chi được chia sẻ giữa tập con của các URC kết nối.

Đối với các đích không yêu cầu phiên, không có các phiên mà chỉ có các kết nối socket với URC. Trong trường hợp nhiều URC đang được kết nối với cùng một socket, các thẻ socket được chia sẻ giữa các URC.

Đối với các đích không yêu cầu phiên, không có các phiên mà chỉ có các kết nối socket với URC. Trong trường hợp nhiều URC đang được kết nối với cùng một socket thì các thẻ socket được chia sẻ giữa các URC.

5.6.3  Chỉ báo tính sẵn có của các thẻ socket tại thời gian chạy

Đích phải chỉ báo đến URC thông qua phương tiện chuyên về TUN trong số các thẻ socket tùy chọn sẵn có cho một phiên riêng (điều 7.2.5.2).

CHÚ THÍCH  “thẻ socket tùy chọn" là các thẻ socket mà có thuộc tính 'optional' với giá trị “true” (xem TCVN 11523-2 (ISO/IEC 24752-2)).

5.6.4  Cơ chế đồng bộ hóa

Quản lý socket bao gồm các chức năng đồng bộ hóa các thẻ socket với các URC kết nối. Điều này bao gồm cập nhật socket đáp ứng việc thay đổi giá trị khởi tạo của người sử dụng và phổ biến các thay đổi đến URC kết nối. Cơ chế thay đổi này được cài đặt qua TUNL, dựa trên các cơ chế đặc trưng cho nền tảng TUN để đạt được việc đồng bộ hóa.

CHÚ THÍCH 1 Đặc tả socket dựa trên việc cài đặt đối tượng phân tán được cung cấp bởi tầng TUN trực thuộc. Người cài đặt các socket có thể sử dụng giải pháp hiện có (trung gian) cho mô hình đối tượng phân tán, hoặc cài đặt phiên bản của chính họ.

CHÚ THÍCH 2 Việc cài đặt cơ chế đồng bộ hóa về các thẻ socket đặc trưng cho nền tảng TUN vượt quá phạm vi của tiêu chuẩn này. Điển hình là, cơ chế cập nhật dựa trên sự kiện được giả thiết qua phiếu bầu cũng có thể được sử dụng. Trong các điều nhỏ sau đây, thuật ngữ “phổ biến" được sử dụng để bao gồm tất cả các cơ chế đồng bộ hóa có thể xảy ra.

5.6.5  Biến và đồng bộ hóa các giá trị biến

5.6.5.1  Khái quát

Các biến socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

Các giá trị (ngoại trừ các kiểu dòng) của các biến socket và các thành phần của chúng nếu có phải được đồng bộ hóa giữa socket và các URC mà tham gia vào phiên chung với socket.

CHÚ THÍCH  Đối với các biến với các kiểu dòng, dòng có thể hoặc không thể được quản lý bởi socket.

5.6.5.2  Các giá trị không xác định

Đích có thẻ đặt giá trị của biến là không xác định tại mọi thời điểm. Thông tin về các giá trị không xác định phải được bao gồm trong thông tin đồng bộ hóa từ đích đến URC.

CHÚ THÍCH Các giá trị của biến có thể là không xác định với các lý do khác nhau. Ví dụ, chúng có thể không khởi tạo đúng. Hoặc chúng có thể phản ánh các tính năng mà không sẵn có trên đối tượng đích riêng (xem điều 7.6.3).

5.6.5.3  Các biến không sẵn có

Giá trị của biến không sẵn có phải là không xác định. Thông tin về tính sẵn có của các biến phải được bao gồm trong thông tin đồng bộ hóa từ đích đến URC.

Đích không được thay đổi trạng thái sẵn có của mọi biến trong suốt thời gian chạy.

CHÚ THÍCH  Điều này cho phép URC kiểm tra tính sẵn có của biến chỉ lúc bắt đầu một phiên. Mục tiêu phải bỏ qua yêu cầu của URC đặt giá trị của biến không sẵn có.

5.6.5.4  Thay đổi giá trị khởi tạo URC

URC mà có kết nối với socket có thể yêu cầu thay đổi giá trị của biến socket. Đích có thể chấp nhận hoặc từ chối các thay đổi được đưa ra bởi các URC kết nối. Nếu thay đổi của URC được chấp nhận thì đích phải phản hồi bằng cách truyền giá trị mới đến tất cả các URC kết nối trong đó chia sẻ biến liên quan. Nếu thay đổi bị từ chối thì đích phải thông báo với URC từ người thay đổi yêu cầu.

CHÚ THÍCH  Socket cần từ chối thay đổi biến từ URC. Do sự không ổn định của mạng (chậm trễ) và các lý do an toàn. Các trường hợp sử dụng thích hợp bao gồm biến không thể được ghi tại thời điểm thay đổi khi URC chưa nhận thay đổi trạng thái từ socket tạo phần phụ thuộc write của biến là false. Hoặc URC đang thay đổi một biến tại cùng thời điểm nếu vậy, tùy vào socket để quyết định xem chấp nhận giá trị nào.

5.6.5.5  Cập nhật giá trị khởi tạo đích

Đích phải cập nhật các giá trị của các biến socket và truyền chúng đến các URC kết nối.

CHÚ THÍCH Không có gì ở trên được phân tích hàm ý là ‘đồng bộ’ hoặc chặc các cuộc gọi từ xa được sử dụng để đồng bộ hóa các giá trị của các biến socket giữa URC và đích. Việc đồng bộ hóa nhiều biến socket có thể tiến hành đồng thời và không đồng bộ hóa, chỉ phụ thuộc vào đích liên quan đến các ràng buộc trong mô tả socket và URC liên quan đến các giá trị hoàn trả từ đích.

5.6.5.6  Đa phiên điều khiển

Đối với các đích yêu cầu phiên, socket phải duy trì các tập giá trị biến socket riêng cho mỗi phiên điều khiển, ngoại trừ các giá trị mà được chia sẻ qua các phiên (ví dụ: nhiệt độ hiện thời của lò).

5.6.5.7  Đồng bộ hóa các giá trị phụ thuộc

Đích có thể cung cấp cơ chế cung cấp các cập nhật về các giá trị phụ thuộc đến các URC kết nối.

5.6.6  Lệnh và đồng bộ hóa trạng thái lệnh

5.6.6.1  Khái quát

Đích phải hỗ trợ các yêu cầu dẫn ra lệnh từ URC và đồng bộ hóa các trạng thái lệnh.

Các lệnh socket được quy định trong TCVN11523-2 (ISO/IEC 24752-2).

5.6.6.2  Các thông số đầu vào cục bộ

Khi nhận yêu cầu của URC về việc dẫn ra lệnh với các thông số đầu vào cục bộ, đích phải nhận từ URC các giá trị của thông số đầu vào cục bộ mà lệnh bao hàm. Điều này xảy ra trong cơ chế đặc trưng cho nền tảng TUN.

Không có sự động bộ hóa các thông số đầu vào cục bộ nào khác đến URC hoặc từ URC xảy ra.

CHÚ THÍCH Các thông số đầu vào toàn cục (các tham chiếu từ lệnh đến các biến mà dùng là các thông số cho lệnh) không được truyền tải đến đích theo cách này. Thay vào đó, chúng được đồng bộ hóa theo các thay đổi giá trị như đã quy định cho các biến (xem điều 5.6.5).

5.6.6.3  Các thông số đầu ra cục bộ

5.6.6.3.1  Khái quát

Để kết luận một lệnh với các thông số đầu ra cục bộ, đích phải gửi đến URC các giá trị của tất cả các thông số đầu ra cục bộ mà lệnh bao hàm. Điều này xảy ra trong cơ chế đặc trưng cho nền tảng TUN. Không có sự động bộ hóa các thông số đầu ra cục bộ nào khác đến URC hoặc từ URC xảy ra.

CHÚ THÍCH  Các thông số đầu ra toàn cục (các tham chiếu từ lệnh đến các biến mà dùng là các thông số cho lệnh) không được nhận từ đích theo cách này. Thay vào đó, chúng được đồng bộ hóa theo các thay đổi giá trị như đã quy định cho các biến (xem điều 5.6.5).

5.6.6.4  Trạng thái lệnh

Lệnh kiểu uis:basicCommand hoặc uis:timedCommand có trạng thái trong đó đích phải đồng bộ hóa chỉ một chiều từ socket đến các URC kết nối và chỉ tại thời điểm khởi tạo giao diện người sử dụng và hoàn thành việc thực hiện lệnh.

Chỉ có đích mới có thể thay đổi trạng thái của lệnh, và bỏ qua mọi thay đổi trạng thái đã truyền từ URC.

Đích phải chú ý đến các ý nghĩa của giá trị trạng thái lệnh (như đã quy định trong TCVN 11523-2 (ISO/IEC 24752-2)) để phản ánh kết quả của việc thực hiện được gọi trước đó. Trạng thái lệnh ban đầu (trước khi việc thực hiện xảy ra) phải là “không xác định”.

Vào lúc hoàn thành việc thực hiện, đích phải đảm bảo rằng tất cả sửa đổi của các thông số đầu ra cục bộ và toàn cục của lệnh được truyền đến URC trước hoặc cùng với sự phổ biến việc thực hiện của lệnh và trạng thái mới của nó.

5.6.6.5  Các trạng thái lệnh không xác định

Đích có thể đặt trạng thái của lệnh là không xác định tại mọi thời điểm. Thông tin về các trạng thái lệnh không xác định phải được bao gồm trong thông tin đồng bộ hóa từ đích đến URC. Điều này chỉ gắn cho các kiểu lệnh đề cập đến thông tin trạng thái lệnh (uis:basicCommand, uis:timedCommand).

CHÚ THÍCH  Các trạng thái lệnh phải là không xác định với các lý do khác nhau. Ví dụ, chúng không khởi tạo đúng. Hoặc chúng có thể phản ánh các tính năng không sẵn có về đối tượng đích riêng (xem điều 5.6.6.6).

5.6.6.6  Các lệnh không sẵn có

Trạng thái của lệnh không sẵn có phải là không xác định. Thông tin về tính sẵn có của các lệnh phải được bao gồm trong thông tin đồng bộ hóa từ mục tiến đến URC.

Đích không thay đổi trạng thái tính sẵn có của mọi lệnh trong suốt thời gian chạy.

CHÚ THÍCH  Điều này cho phép URC kiểm tra tính sẵn có của lệnh tại chỉ lúc bắt đầu của phiên.

Đích phải bỏ qua yêu cầu của URC nhằm thực hiện lệnh không sẵn có.

5.6.6.7  Đa phiên điều khiển

Sockets phải duy trì các tập trạng thái lệnh socket đối với mỗi phiên điều khiển (cho các đích yêu cầu phiên) hoặc URC kết nối (cho các đích không yêu cầu phiên).

CHÚ THÍCH  Lý do không chia sẻ trạng thái lệnh là nó phản ánh kết quả của việc thực hiện lệnh cuối cùng khi được yêu cầu từ URC riêng.

5.6.6.8  Giới hạn đồng thời

Trong khi lệnh của kiểu uis:basicCommand, uis:timedCommand đang được xử lý trên đích thì đích không được phép gọi thêm cùng một lệnh. Đích phải chỉ báo điều này bằng cách giữ trạng thái lệnh là inProgress khi đang thực hiện nó.

CHÚ THÍCH  Không nên giả thiết rằng các cuộc gọi phương thức từ xa đồng bộ hoặc bị chặn được sử dụng để gọi ra các lệnh trên đích hoặc để đồng bộ hóa các trạng thái của các lệnh socket giữa URC và đích. Việc đồng bộ hóa nhiều lệnh socket có thể bắt đầu đồng thời và không đồng bộ, chỉ phụ thuộc vào đích liên quan đến các ràng buộc trong mô tả socket và URC liên quan đến các giá trị trạng thái hoàn trả từ đích.

5.6.6.9  timeToComplete

Lệnh của kiểu uis:timedCommand có trường timeToComplete chỉ hợp lệ khi lệnh ở trạng thái inProgress. Nếu trong trạng thái inProgress thì đích phải “đếm ngược” theo chu kỳ giá trị của timeToComplete cho đến khi lệnh chuyển đến trạng thái khác. Giá trị của timeToComplete là một gợi ý từ đích đến URC để biết được thời gian ước tính để hoàn thành là bao nhiêu- không có bất kỳ sự đảm bảo nào được cung cấp bởi đích.

5.6.6.10  Yêu cầu thực hiện lệnh bởi URC

Đích có thể hoặc không thể thực hiện lệnh (của mọi kiểu) khi được yêu cầu bởi URC. URC yêu cầu thực hiện lệnh thông qua các cơ chế đặc trưng cho nền tảng TUN, tham chiếu lệnh bởi định danh của nó.

Nếu đích từ chối yêu cầu thực hiện lệnh thì đích phải cập nhật trạng thái của lệnh (nếu có) là “failed” trong phiên liên quan. Trong lúc hoàn thành việc thực hiện lệnh yêu cầu, đích phải cập nhật trạng thái của lệnh phản ánh kết quả của việc gọi lệnh trong phiên liên quan.

5.6.7  Thông báo và báo nhận

5.6.7.1  Khái quát

Đích phải hỗ trợ việc truyền trạng thái thông báo đến các URC kết nối và chấp nhận các báo nhận thích hợp.

Các thông báo socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

5.6.7.2  Các trạng thái

Thông báo có thể có một trong các trạng thái sau đây: không hoạt động, hoạt động, không xác định.

5.6.7.3  Các trạng thái thông báo không xác định

Đích có thể đặt trạng thái của thông báo là không xác định. Thông tin về các trạng thái thông báo không xác định phải được bao gồm trong thông tin đồng bộ hóa từ đích đến URC.

CHÚ THÍCH  Trạng thái thông báo có thể là không xác định với nhiều lý do khác nhau. Ví dụ, chúng có thể không khởi tạo đúng. Hoặc chúng phản ánh các tính năng mà không sẵn ở đối tượng đích riêng (xem điều 5.6.7.4)

5.6.7.4  Các thông báo không sẵn có

Trạng thái của thông báo không sẵn có phải là không xác định. Thông tin về tính sẵn có của các thông báo phải được bao gồm trong thông tin đồng bộ hóa từ đích đến URC.

Đích không thay đổi tình trạng sẵn có của mọi thông báo trong suốt thời gian chạy.

CHÚ THÍCH  Điều này cho phép URC kiểm tra tính sẵn có của thông báo chỉ lúc bắt đầu của phiên.

Đích phải bỏ qua việc báo nhận của URC thông báo không sẵn có.

5.6.7.5  Đa phiên điều khiển

Socket phải duy trì các trạng thái thông báo tách riêng cho mỗi phiên điều khiển (cho các đích yêu cầu phiên) hoặc URC kết nối (cho các đích không yêu cầu phiên), ngoại trừ các sự kiện biểu thị thông báo liên quan đến tất cả các phiên/các URC (ví dụ: báo cháy) và không được báo nhận rõ ràng bởi người sử dụng.

5.6.7.6  Báo nhận của người sử dụng

Socket phải chấp nhận báo nhận từ URC sau khi các thông báo hoạt động. Socket có thể hoạt động trên báo nhận này bằng mọi cách (ví dụ: đặt trạng thái thông báo là “không hoạt động”), hoặc có thể bỏ qua nó. Socket có thể bắt đầu lại hoạt động (tức là đặc trạng thái thông báo là “không hoạt động”) mà không nhận báo nhận thậm chí ở nơi nó được mong chờ.

CHÚ THÍCH  Tất cả các thông báo yêu cầu báo nhận của người sử dụng ngoại trừ các thông báo của kiểu “show. Xem TCVN 11523-2(ISO/IEC 24752-2)”

5.6.7.7  Truyền trạng thái thông báo

Socket phải truyền thông tin trạng thái cho các thông báo socket đến các URC kết nối và phải bỏ qua mọi cập nhật trên trạng thái thông báo nhận từ URC.

5.6.7.8  Xếp chồng các thông báo

Socket có thể kích hoạt thông báo trong một phiên trong khi thông báo khác đang hoạt động trong cùng một phiên. Trong trường hợp này, thông báo thứ hai chiếm ưu thế hơn thông báo thứ nhất. Socket phải giải phóng các thông báo thứ tự kích hoạt đảo ngược.

5.6.8  Các chỉ số thực tế cho các tập/các thẻ socket thứ nguyên

Các tập kết hợp chỉ số thực tế cho mỗi tập socket và thẻ socket thứ nguyên, nếu có phải được đồng bộ hóa giữa socket và URC trong đó tham gia vào phiên chung với socket.

Đích nên truyền tải đến URC các đối tượng của tập hoặc thẻ socket thứ nguyên theo thứ tự phản ánh thứ tự của các giá trị chỉ số của nó như đã xác định bởi khía cạnh cơ sở ‘có thứ tự’ của xác định kiểu chỉ số (xem Lược đồ XML Phần 2: Kiểu dữ liệu). Đối với các kiểu chỉ số xác định bởi giới hạn (các kiểu liệt kê), thứ tự nên phản ánh thứ tự mà các giá trị được liệt kê trong định nghĩa. Nếu các kiểu liệt kê được kết hợp bởi toán tử kết hợp thì thứ tự nên theo sau thứ tự mà các kiểu cơ sở xuất hiện trong mệnh đề kết hợp.

CHÚ THÍCH Trong khi cũng có khuyến cáo về URC đưa ra các thẻ chỉ số trong thứ tự đã mô tả, khuyến cáo ở trên giúp cho URC khỏi việc phải sắp xếp một danh sách dài các kết hợp chỉ số ban đầu. Tuy nhiên, URC chịu trách nhiệm duy nhất cho việc xác định vị trí khuyến cáo của các giá trị chỉ số mà nó nhận khi cập nhật từ đích.

Socket có thể chấp nhận hoặc từ chối yêu cầu của URC để thêm vào hoặc bỏ một chỉ số thực tế trên tập hoặc thẻ socket thứ nguyên (xem điều 4.4.5). Nếu nó chấp nhận yêu cầu thì phải truyền sửa đổi đến URC (và tất cả các URC kết nối khác). Nếu nó từ chối yêu cầu thì phải thông báo với URC về việc từ chối.

Trong trường hợp socket chấp nhận chỉ số mới thì nó phải cung cấp các giá trị ban đầu cho các thành phần thẻ mới đến các URC kết nối. Do đó, đích có thể hoặc không thể chấp nhận các giá trị đã đề xuất của URC nếu được bao gồm trong yêu cầu.

5.6.9  Giải thích phía URC về tính phụ thuộc của thẻ socket

Socket không dựa trên việc URC thực hiện việc giải thích tính phụ thuộc của thẻ socket. Tính phụ thuộc của thẻ socket được quy định trong TCVN 11523-2 (ISO/IEC 24752-2).

URC không thể giải thích chính xác tính phụ thuộc giữa các thẻ socket hoặc trạng thái socket hiện thời không thể được phản ánh chính xác trên URC do mạng độ trễ mạng hoặc sự cố mạng.

5.6.10  Thời gian chờ trả lời người sử dụng

5.6.10.1  Khái quát

Các yêu cầu sau đây gắn với thời gian chờ được tạo bởi socket do tính không hoạt động hoặc thực hiện chậm của người sử dụng. Chúng được tham chiếu như ‘thời gian chờ trả lời người sử dụng’. Thời gian chờ được nhắc bởi các sự kiện thời gian thực không phụ thuộc vào các yêu cầu này, ví dụ như kết thúc một cuộc bán đấu giá.

5.6.10.2  Sử dụng thông báo như cảnh báo thời gian chờ

Nếu đích có điều kiện thời gian chờ khác với thông báo biên thời gian thì đích nên sử dụng một thông báo để báo trước cho người sử dụng khi điều kiện thời gian chờ xảy ra và cho phép người sử dụng yêu cầu nhiều thời gian hơn. Trong trường hợp như vậy, nếu người sử dụng yêu cầu nhiều thời gian hơn thông qua thông báo thì đích phải quay lại trạng thái của nhiệm vụ mà người sử dụng hoàn thành trước thời gian chờ.

VÍ DỤ  Nếu người sử dụng hết thời gian trong khi hoàn thành một mẫu thì sẽ nhận được thông báo thời gian chờ và yêu cầu thêm thời gian, sau đó các trường của mẫu mà chúng hoàn thành trong đó nên giữ lại các giá trị khi thông báo bị xóa và người sử dụng trở về với nhiệm vụ.

CHÚ THÍCH  Trong một số phạm vi quyền hạn và đối với một số thiết bị hoặc dịch vụ, điều khiển thời gian chờ hoặc khả năng kéo dài thời gian chờ có thể do luật pháp yêu cầu. Bản thân tiêu chuẩn này không tự yêu cầu điều đó nhưng giúp cho các đích đáp ứng điều này nếu chúng lựa chọn.

5.6.10.3  Thời gian chờ thông báo

Tất cả các thẻ thông báo mà có thời gian chờ trả lời người sử dụng phải biểu diễn các giá trị thời gian chờ mặc định bằng thuộc tính ‘timeout’, cho biết thời gian mặc định để người sử dụng trả lời thông báo trước khi đích xóa bỏ nó.

Giá trị phải ít nhất 10 giây.

5.6.10.4  Hỗ trợ yêu cầu kéo dài thời gian chờ trên thông báo

Khi thời gian chờ trả lời người sử dụng được thông báo thì đích phải cho phép URC kéo dài thời gian chờ lên đến 5 lần thời gian chờ mặc định, thậm chí trong khi thông báo hoạt động.

CHÚ THÍCH  Cơ chế về các yêu cầu kéo dài thời gian chờ giữa URC và đích không thuộc phạm vi của tiêu chuẩn này.

5.6.11  Cung cấp tài nguyên nguyên tử động

Đích có thể cung cấp tài nguyên nguyên tử động cho các thẻ socket hoặc các kiểu bên trong và bên ngoài socket. Các tài nguyên nguyên tử động có thể thay đổi tại thời gian chạy mà yêu cầu đồng bộ hóa với URC trong suốt phiên điều khiển.

5.7  Liên kết mạng URC đích (TUNL) trên đích

5.7.1  Khái quát

Liên kết mạng URC đích trên đích là liên kết từ đích đến mạng URC đích. Đích có thể hỗ trợ nhiều TUNL cho phép thực hiện chức năng với các công nghệ và nền tảng mạng khác nhau.

5.7.2  Yêu cầu

Mỗi đích phải cung cấp ít nhất một TUNL. Mỗi TUNL đặc trưng cho các công nghệ kết nối và nối mạng riêng được sử dụng.

VÍ DỤ “UPnP trên TUNL Bluetooth” hoặc “Jini trên 802.11bTUNL” v.v...

CHÚ THÍCH  Đặc tả các kỹ thuật và cơ chế đặc trưng cho nền tảng nối mạng để thực thi tiêu chuẩn này trên nền tảng TUN riêng không thuộc phạm vi của tiêu chuẩn này.

5.8  An toàn và các yêu cầu tính riêng tư

Xem điều 8.3

6  Tài nguyên bổ sung

6.1  Khái quát

Các tài nguyên bổ sung là mọi loại thông tin mà được cung cấp bên ngoài cho đích. Các tài nguyên bổ sung có thể bổ sung hoặc thay thế các tài nguyên đích và có thể được cung cấp bởi nhà sản xuất đích., nhà sản xuất URC hoặc các bên thứ ba. URC có thể tìm kiếm các tài nguyên bổ sung cho đích cụ thể từ mọi dịch vụ tài nguyên.

Các tài nguyên bổ sung có thể được sử dụng bởi các URC trong việc xây dựng giao diện người sử dụng. Chúng cũng có thể được sử dụng bởi người thiết kế các mô tả cài đặt giao diện người sử dụng trong việc xây dựng các UIID cho các sản phẩm URC riêng.

6.2  Các tài nguyên bổ sung từ bên thứ ba

Các tài nguyên bổ sung có thể được chuẩn bị hoặc phân phối bởi các bên thứ ba.

VÍ DỤ  Bất kỳ ai cũng có thể tạo tài nguyên thay thế cho sản phẩm đã cho và tạo sẵn trên internet. Do đó, người dùng có thể tạo giao diện thân thiện với người sử dụng (UIID) cho hệ thống stereo chạy trên điện thoại thông minh và tạo sẵn trên internet. Bất kỳ ai muốn tải UIID và sử dụng nó kết hợp với sản phẩm trong cũng một kiểu khi người dùng mua các điều khiển từ xa phổ dụng và sử dụng chúng để điều khiển các thiết bị ngày nay.

6.3  Các tài nguyên bổ sung là tùy chọn

Tính sẵn có của các tài nguyên bổ sung không được yêu cầu đối với việc sử dụng URC trong khung tổng quát URC. Các tài nguyên bổ sung là các tài nguyên tùy chọn, bổ sung, cần lưu ý rằng không có vị trí riêng nào mà các tài nguyên bổ sung được lưu trữ.

VÍ DỤ  Các tài nguyên bổ sung có thể được lưu trữ trên trang web của nhà sản xuất, trên trang chung hoặc các trang riêng. Chúng có thể được lưu trữ tại vị trí có thể truy cập mạng khác và được lấy ra bởi dịch vụ tài nguyên để sử dụng bởi URC. Các tài nguyên bổ sung có thể được cung cấp miễn phí hoặc chúng có thể là các sản phẩm bổ sung giá trị mà được thiết kế và được bán bởi các tài nguyên bổ sung khác.

6.4  Định dạng các tài nguyên bổ sung

Mặc dù các tài nguyên bổ sung có thể thuộc quyền sở hữu riêng hoặc công khai, TCVN 11523-5 (ISO/IEC 24752-5) cung cấp các định dạng chuẩn cho các tài nguyên bổ sung nhằm thuận lợi hóa việc sử dụng của các nhà xây dựng URC.

Các nhà sản xuất đích và URC có thể tự do xác định các dạng thêm vào của các tài nguyên bổ sung nếu chúng không xung đột với các hạng mục tài nguyên bổ sung như đã nêu trong TCVN 11523-5 (ISO/IEC 24752-5). Cụ thể, các nhà sản xuất đích và URC có thể sử dụng cả tài nguyên chuẩn và thuộc quyền sở hữu riêng trong các mô tả cài đặt giao diện người sử dụng đặc trưng cho URC chuyên dụng (UIIDs).

6.5  Các dạng dịch vụ tài nguyên

Nhìn chung, các dịch vụ tài nguyên cung cấp các tài nguyên bổ sung có thể có nhiều dạng. Chúng bao gồm

- các dịch vụ cung cấp mọi dạng UIID, nghĩa là mọi thành phần giao diện người sử dụng cắm vào trong socket của đích;

- các dịch vụ cung cấp các nhãn thay thế, bao gồm hình ảnh, ảnh động và âm thanh;

- các dịch vụ cung cấp các nhóm thay thế;

- các dịch vụ cung cấp thông tin cho các chức năng của đích;

- các dịch vụ chuyển dịch tập các nhãn bất kỳ từ ngôn ngữ này sang ngôn ngữ khác;

- các công cụ suy luận có thể giúp giải thích các lệnh không rõ ràng từ người sử dụng sang điều khiển phù hợp trên thiết bị;

- siêu cơ sở dữ liệu;

- từ điển chuyên đề;

- từ điển;

- các công cụ nhận diện giọng nói;

- các công cụ xử lý ngôn ngữ tự nhiên;

- các dịch vụ biên dịch;

- các thư viện hình tượng;

- các dịch vụ cung cấp tập điều khiển chung (ví dụ: các bộ điều khiển phát cho VCR hoặc CD), v.v...

- các dịch vụ sẵn có cục bộ hoặc từ xa qua kết nối mạng (thời gian thực hoặc có thể tải);

- v.v...

6.6  Tài nguyên nguyên tử bổ sung

Các tài nguyên nguyên tử bổ sung là các tài nguyên nguyên tử được cung cấp bên ngoài bởi các dịch vụ tài nguyên cho đích.

Các tài nguyên nguyên tử bổ sung sau đây có các dạng chuẩn hóa được xác định bởi TCVN 11523-5 (ISO/IEC 24752-5): nhãn, các từ khóa, trợ giúp, khóa truy cập và các tài nguyên vị trí.

6.7  Tệp tài nguyên bổ sung

Các tài nguyên nguyên tử bổ sung được quy định trong các tầng nguyên tử, như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5). Phụ lục B chỉ ra ví dụ về tệp tài nguyên cho nhiệt kế điện tử.

Tệp tài nguyên bổ sung càng ổn định càng tốt. Nó chỉ có thể thay đổi nếu định danh hoặc ngày tháng sửa đổi của nó bị thay đổi.

6.8  Tài nguyên tạo nhóm bổ sung

Các tài nguyên tạo nhóm bổ sung là các tài nguyên tạo nhóm mà được cung cấp bên ngoài bởi các dịch vụ tài nguyên cho đích. Các tài nguyên tạo nhóm và định dạng của chúng được quy định trong TCVN 11523-5 (ISO/IEC 24752-5).

6.9  Tệp tạo nhóm bổ sung

Các tài nguyên tạo nhóm bổ sung được quy định trong các tệp tạo nhóm, như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5). Phụ lục B cho biết ví dụ về tệp tạo nhóm.

Tệp tạo nhóm bổ sung càng ổn định càng tốt. Nó chỉ có thể thay đổi nếu định danh hoặc ngày tháng sửa đổi của nó bị thay đổi.

6.10  Mô tả cài đặt giao diện người sử dụng bổ sung (UIIDs)

UIIDs là các mô tả cụ thể về việc cài đặt giao diện người sử dụng cho đích, dựa trên socket của đích. UIID bổ sung là UIID cung cấp bên ngoài bởi các dịch vụ tài nguyên cho đích. UIIDs bổ sung có thể là các định dạng công khai hoặc thuộc sở hữu riêng.

VÍ DỤ  Nhà sản xuất hệ thống nghe-nhìn trong nhà có thể tạo UIIDs mà được tối ưu hóa để chạy trên các bộ điều khiển từ xa đặc trưng, trên PDA phổ biến (như là Palm hoặc Pocket PC) hoặc chạy trên laptop và máy tính cá nhân. Các UIID này có thể lấy mẫu giao diện người sử dụng mô tả trong kiểu chuẩn hoặc chứa mã thực thi để chạy trên thiết bị riêng (URC). Các công ty có thể quyết định tạo một số UIID chuẩn chung hoặc một số UIID biên dịch.

Với tất cả các UIID, UIID bổ sung luôn dựa trên một hoặc nhiều socket, nghĩa là mọi tương tác giữa đích và UIID thông qua socket.

UIID bổ sung có thể sử dụng các tài nguyên bổ sung hoặc sử dụng thay thế thông tin tương đương tạo thành UIID bổ sung.

7  Mạng

7.1  Khái quát

Để giúp cho URC giao tiếp với đích hoặc truy cập và tải các tài nguyên đích thì sẽ có một số kết nối mạng giữa chúng. Mạng giữa URC và đích có thể giống với mạng với các tài nguyên bổ sung và các dịch vụ tài nguyên. Nhưng vì mạng cho các tài nguyên bổ sung không được yêu cầu và có thể về bản chất không phải là thời gian thực (các tài nguyên bổ sung có thể được tải xuống URC để sử dụng sau này), mạng với đích (phải là thời gian thực) được xử lý riêng biệt.

7.2  Mạng URC đích (TUN)

7.2.1  Khái quát

Điều này mô tả các yêu cầu cho nền tảng mạng sử dụng cho giao tiếp URC đích có thể áp dụng để quản lý khám phá và quản lý phiên. Tiêu chuẩn này giả thiết các tầng nối mạng trực thuộc cung cấp việc khám phá (định vị tùy chọn) các đích, phân phối và đồng bộ hóa đối tượng, điều khiển chương trình và tính an toàn. Tiêu chuẩn giả thiết tính sẵn có của các dịch vụ này trong chức năng mạng hơn là yêu cầu mọi kiến trúc thiết bị riêng và nói rõ các yêu cầu được sử nền tảng TUN trực thuộc để thực thi tiêu chuẩn này.

Đích và thiết bị URC có thể được kết nối sử dụng bất cứ phương pháp nào. Chúng có thể nối mạng sử dụng mọi phương pháp hỗ trợ các yêu cầu cho TUN. Nơi đích và URC hỗ trợ các các công nghệ TUN khác nhau thì cổng có thể được sử dụng để tạo mạng URC đích liền mạch giữa chúng.

VÍ DỤ 1  Các công nghệ kết nối tiềm năng bao gồm các mạng hồng ngoại, RF, dây cáp, Ethernet, Bluetooth , IrDA và 802.11.

VÍ DỤ 2  Các công nghệ nối mạng tiềm năng bao gồm UPnP và Java/Jini.

7.2.2  Định danh đối tượng duy nhất

Mạng trực thuộc phải tạo sẵn các định danh đối tượng của đích (xem điều 5.1.2). Nếu đích hỗ trợ nhiều mạng thì định danh duy nhất của nó phải chung cho tất cả các mạng.

7.2.3  Hỗ trợ khám phá

7.2.3.1  Khái quát

Trong suốt pha khám phá, mạng trực thuộc phải cung cấp thông tin các đích sẵn có cho URC. Các đích sẵn có (các dịch vụ hoặc các thiết bị) tự truyền bá đến TUN trực thuộc.

7.2.3.2  Phạm vi khám phá

Sự khám phá thường được giới hạn cho môi trường cục bộ, nghĩa là TUN trực tiếp. Tuy nhiên, một số cơ chế về khám phá các đích có khoảng cách dài được yêu cầu cho các nền tảng nối mạng nhất định.

Tối thiểu, nếu đích có sẵn, địa chỉ của nó đã biết và địa chỉ đó có thể truy cập qua mạng URC đích và mọi yêu cầu xác nhận mạng được thỏa mãn thì nó sẽ khởi tạo phiên điều khiển với đích.

7.2.4  Hỗ trợ triển khai tài liệu

7.2.4.1  Cơ chế tìm nạp

TUN phải hỗ trợ cơ chế tìm nạp mà cho phép URC tìm kiếm mô tả đích, các mô tả socket và các tài nguyên đích bởi URI. Cơ chế tìm nạp này có thể bao gồm việc xác thực các cơ chế cho URC và/hoặc đích.

7.2.4.2  Phạm vi của triển khai tài liệu

Triển khai tài liệu phải sẵn có trong pha khám phá và trong pha điều khiển.

7.2.4.3  Mô tả đích

Mạng trực thuộc phải có sự hỗ trợ cho việc cung cấp thông tin về các đích, cụ thể, việc truyền phát mô tả đích. Sự khám phá có thể xảy ra trong một vài chu trình, tức là không phải tất cả các đặc tính đích cần sẵn có bởi một yêu cầu đơn.

7.2.4.4  Các chức năng định vị của đích

Mạng trực thuộc phải hỗ trợ việc gọi các chức năng định vị của đích từ URC trong pha khám phá hoặc pha điều khiển.

7.2.5  Hỗ trợ quản lý phiên

Tiêu chuẩn này dựa trên việc cài đặt đối tượng phân phối được cung cấp bởi tầng TUN trực thuộc. Các nhà cài đặt có thể sử dụng giải pháp hiện có (trung gian) cho mô hình đối tượng phân phối hoặc cài đặt phiên bản của họ.

7.2.5.1  Truyền phát các tài liệu

Trong pha khám phá hoặc tại thời điểm bắt đầu của phiên điều khiển, đích cung cấp thông tin cần thiết cho việc xây dựng giao diện người sử dụng từ xa qua các tài liệu (xem điều 5.2)

7.2.5.2  Hỗ trợ chỉ báo các thẻ socket sẵn có tại thời gian chạy

Mạng URC đích phải truyền tải chỉ báo các thẻ socket sẵn có của đích tại thời gian chạy cho một phiên riêng (xem điều 5.6.3).

7.2.5.3  Hỗ trợ đồng bộ hóa socket

Trạng thái của đích được mô tả trong socket của nó bởi tập các biến, các trạng thái lệnh và các trạng thái thông báo. Khi mở một phiên (đối với các đích yêu cầu phiên) hoặc kết nối một socket (với các đích không yêu cầu phiên) với các URC, đích chuyển các giá trị này đến URC. Khi đích thay đổi trạng thái thì việc thay đổi này phải được truyền tải đến URC. Tương tự, Khi trạng thái trên URC thay đổi hoặc lệnh đích được gọi từ URC thì thay đổi này phải được truyền tải đến đích.

CHÚ THÍCH  Các sự kiện, kiểm soát vòng hoặc mọi cơ chế đồng bộ hóa khác có thể được sử dụng để thuận lợi hóa việc phổ biến các thay đổi trạng thái từ các đích đến URC và ngược lại.

7.2.5.4  Hỗ trợ đồng bộ hóa các tài nguyên nguyên tử động

Mạng URC đích phải cung cấp phương tiện đồng bộ hóa các tài nguyên nguyên tử động. Các tài nguyên nguyên tử động có thể thay đổi tại thời gian chạy yêu cầu đồng bộ hóa với URC trong suốt phiên điều khiển.

7.2.5.5  Các yêu cầu sắp xếp thứ tự cho các thông điệp

Mạng URC đích phải chuyển giao tất cả các thông điệp tạo bởi URC cho đích theo thứ tự mà chúng được tạo. Tương tự, thứ tự của các thông điệp từ đích đến URC phải được bảo quản.

7.2.5.6  Bảo quản nội dung tài liệu

Mạng URC đích phải vận chuyển các tài liệu theo cách mà nội dung chính xác của mỗi đích được bảo quản.

7.2.5.7  Tình trạng của kết nối được thiết lập

Trong suốt pha điều khiển, mạng trực thuộc phải cung cấp thông tin tình trạng kết nối sao cho đích và URC có thể xác định liệu chúng vẫn được kết nối và tác động trở lại một cách phù hợp hay không.

7.2.5.8  Các kết nối với nhiều URC

TUN nên hỗ trợ các kết nối độc lập đồng thời từ đích đến nhiều URC.

7.2.6  An toàn và yêu cầu quyền riêng tư Xem điều 8.4.

7.3  Mạng URC tài nguyên (RUN)

Tiêu chuẩn này không quy định bất kỳ công nghệ hay liên kết mạng riêng nào được sử dụng như RUN. URC và các tài nguyên có thể được kết nối sử dụng mọi phương thức nối mạng. Có thể thấy rằng liên kết thường sẽ là một số kiểu công nghệ nối mạng TCP/IP mà kết nối thời gian thực hoặc ngẫu nhiên tới Internet.

Đối với các xem xét về an toàn và quyền riêng tư, xem điều 8.4.

8  Các xem xét về an toàn và quyền riêng tư

8.1  Khái quát

Các nhiệm vụ thực hiện thông qua hội thoại URC-đích có thể có các hậu quả tiềm tàng hoặc bao hàm dữ liệu nhạy cảm mà việc tiết lộ của nó cho các bên không liên quan có thể gây hại nghiêm trọng đến lợi ích của người sử dụng hoặc nhà cung cấp dịch vụ hay nhà cung cấp sản phẩm đích.

Việc xử lý các thiết bị tính toán và thông tin chia sẻ qua các mạng dữ liệu dễ thỏa hiệp với nhiều hoặc ít nỗ lực hơn phụ thuộc vào sự đề phòng phải có.

Đích có một tập hợp các đối tác hội thoại tương đối giống nhau: các cá nhân dùng các thiết bị URC. Đích có báo nhận các kết quả của các chức năng của nó và do đó có thể truy cập các yêu cầu về an toàn, yêu cầu về quyền riêng tư và cài đặt việc bảo vệ các yêu cầu này.

Mặc khác, URC còn đối mặt với nhiều tập hợp các đối tác hội thoại khác nhau hơn. Các yêu cầu an toàn thích hợp với các đích khác nhau sẽ khác nhau rất nhiều. Do đó, URC nên cài đặt các chức năng an toàn để kích hợp truy cập tới không chỉ các đích an toàn mức thấp mà còn tới các đích an toàn mức cao.

VÍ DỤ  Ví dụ được cung cấp trong Phụ lục A.

8.2  Các xem xét về URC

URC phải cài đặt các chức năng an toàn và quyền riêng tư sẵn có từ các TUN đã cài đặt để liên tác một cách thích hợp với các đích mà quyết định chọn cài đặt các chức năng này. Ngoài chức năng sẵn có từ các TUN đã cài đặt, thì trách nhiệm của đích là tạo truy cập sẵn có cho người sử dụng với sự giúp đỡ của hộp thoại người sử dụng.

CHÚ THÍCH  Các URC có thể cài đặt các chức năng quản lý chứng nhận người dùng khóa nhằm tiến hành việc xác thực tại mức ứng dụng. Tuy nhiên, các chức năng này không thuộc phạm vi của tiêu chuẩn này.

8.3  Các xem xét về đích

Các nhà xây dựng đích nên xem lại các nhiệm vụ mà có thể được thực hiện với sản phẩm hoặc dịch vụ của họ và cài đặt chiến lược về an toàn và quyền riêng tư thích hợp cho khả năng tiết lộ thông tin không thích hợp hoặc điều khiển thông qua hỗ trợ URC.

Phụ thuộc vào các yêu cầu về quyền riêng tư và các yêu cầu xác nhận thích hợp cho các nhiệm vụ này, đích nên cài đặt các chức năng về quyền riêng tư và các chức năng xác thực sẵn có từ các TUN đã cài đặt và và bổ sung chúng khi cần thiết với các chức năng về quyền riêng tư, xác thực và xác nhận ví dụ: đăng nhập cài đặt là một phần của chức năng đích. Chức năng đích này có thể hoạt động được thông qua socket và đáp ứng các yêu cầu tài liệu văn bản hóa và các yêu cầu hoạt động khác của tiêu chuẩn này.

8.4  Các xem xét về mạng

Mạng nên cung cấp các chức năng bảo vệ an toàn và quyền riêng tư thích hợp với việc để lộ tính hiệu của môi trường vật lý và ngữ cảnh sử dụng.

Phụ lục A

(Tham khảo)

Ví dụ về an toàn và quyền riêng tư

Các nhà xây dựng sản phẩm hoặc dịch vụ nên cân nhắc các vấn đề về an toàn và quyền riêng tư khi họ thiết kế tiêu chuẩn này thành các sản phẩm của họ. Tuy nhiên, các điều khoản về an toàn và quyền riêng tư mà họ cài đặt sẽ khác nhau phụ thuộc vào chức năng của các đích và các mạng được cài đặt bởi URC.

Tiêu chuẩn này cung cấp hoạt động của các đích từ xa thông qua việc thiết lập các dữ liệu chung của hộp thoại chuẩn giữa các đích và URC. Việc tăng truy cập thông tin và điều khiển thiết bị hoặc dịch vụ đích tăng cơ hội mà thông tin sẽ được truy cập bởi hoặc được điều khiển bởi các bên không thích hợp.

Ví dụ, mức ứng dụng khắc phục được tránh bao gồm:

- Một người tinh nghịch sử dụng URC để mở hệ thống âm thanh ở mức tối đa của nhà hàng xóm lúc nửa đêm.

- Tên trộm sử dụng URC để tắt hệ thống an toàn trong nhà.

- Tên cướp kiểm tra hộp thoại URC của người sử dụng với ATM và sử dụng thông tin để rút tiền.

- Tên khủng bố kiểm tra hộp thoại URC với thiết bị cuối công khai mà người sử dụng tự định danh và sử dụng định danh đó để nhập cảnh với mục đích xấu.

- Tên tội phạm đưa ra dịch vụ đích giả để đánh lừa người sử dụng phải tiết lộ thông tin nhạy cảm.

Các điểm yếu tồn tại trong các thiết bị tính toán và trong các công nghệ truyền thông dữ liệu. Tuy nhiên, các yêu cầu ở mỗi ứng dụng một khác và không có chuẩn đơn lẻ nào phù hợp với các ứng dụng giống như việc thành lập định danh góp phần vào việc sử dụng tiêu chuẩn này nếu được cài đặt cùng một thời điểm. Các miền ứng dụng cho các thực hành chung là rộng hơn rất nhiều việc mở rộng ‘dặm cuối cùng’ tương tác người sử dụng được dự tính ở đây.

Phụ lục B

(Tham khảo)

Ví dụ về mã XML

Phụ lục này cung cấp các tham chiếu đến các tài nguyên trực tuyến trên mã mẫu minh họa một số khái niệm và các kiểu tài liệu giới thiệu trong tiêu chuẩn này.

Tất cả các ví dụ liên quan đến bộ ổn nhiệt số như một đích. Đích cung cấp các tài liệu sau đây cho URC:

- Mô tả đích (http://www.openurc.orq/TPL/basic-thermostat-1/td)

- Mô tả socket (http://www.openurc.org/TPL/basic-thermostat-1/uis)

- Tệp tài nguyên cung cấp đích với các tài nguyên nhãn và tài nguyên trợ giúp (http://www.openurc.org/TPL/basic-thermostat-1/rsheet)

- Tệp tài nguyên cung cấp đích với các tài nguyên tạo nhóm (http://www.openurc.org/TPL/basicthermostat-1/qsheet)

Ngoài các tài nguyên đích, URC có thể có được các tệp tài nguyên bổ sung và các tệp tạo nhóm từ mọi dịch vụ tài nguyên bổ sung.

THƯ MỤC TÀI LIỆU THAM KHẢO

[1] ISO/IEC 10646, Information technology - Universal Coded Character Set (UCS)

[2] TCVN 11523-2:2016 (ISO/IEC 24752-2:2014), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 2: Mô tả socket giao diện người sử dụng

[3] TCVN 11523-4 (ISO/IEC 24752-4), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 4: Mô tả đích

[4] TCVN 11523-5 (ISO/IEC 24752-5), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 5: Mô tả tài nguyên

[5] TCVN 11523-5:2016 (ISO/IEC 24752-5:2014), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 6: Tích hợp dịch vụ web

[6] Overview of the universal remote console framework. OpenURC Alliance. http://openurc.org/urc-overview.

[7] American National Standard Dictionary of Information Technology (ANSDIT) http://www.agr.unideb.hu/~agocs/informatics/06_e_network/e_ansiinfodict/www.ncits.org/tc_hom/k5htm/c5.htm

[8] W3C Recommendation: Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126/

[9] W3C Recommendation: XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

MỤC LỤC

Lời nói đầu

Phạm vi áp dụng

2  Sự phù hợp

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

4  Các yêu cầu về bộ điều khiển từ xa phổ dụng (URC)

4.1  Khái quát

4.2  Quản lý khám phá

4.3  Quản lý phiên

4.4  Quản lý socket

4.5  Liên kết mạng URC đích trên URC

4.6  Liên kết mạng URC tài nguyên (RUNL) trên URC

4.7  Tạo giao diện người sử dụng

4.8  An toàn và các yêu cầu về quyền riêng tư

5  Thành phần đích và các yêu cầu

5.1  Quản lý khám phá

5.2  Socket giao diện người sử dụng

5.3  Mô tả socket giao diện người sử dụng

5.4  Tài nguyên đích

5.5  Quản lý phiên

5.6  Quản lý socket

5.7  Liên kết mạng URC đích (TUNL) trên đích

5.8  An toàn và các yêu cầu tính riêng tư

6  Tài nguyên bổ sung

6.1  Khái quát

6.2  Các tài nguyên bổ sung từ bên thứ ba

6.3  Các tài nguyên bổ sung là tùy chọn

6.4  Định dạng các tài nguyên bổ sung

6.5  Các dạng dịch vụ tài nguyên

6.6  Tài nguyên nguyên tử bổ sung

6.7  Tệp tài nguyên bổ sung

6.8  Tài nguyên tạo nhóm bổ sung

6.9  Tệp tạo nhóm bổ sung

6.10  Mô tả cài đặt giao diện người sử dụng bổ sung (UIIDs)

7  Mạng

7.1  Khái quát

7.2  Mạng URC đích (TUN)

7.3  Mạng URC tài nguyên (RUN)

8  Các xem xét về an toàn và quyền riêng tư

8.1  Khái quát

8.2  Các xem xét về URC

8.3  Các xem xét về đích

8.4  Các xem xét về mạng

Phụ lục A (Tham khảo) ví dụ về an toàn và quyền riêng tư

Phụ lục B (Tham khảo) ví dụ về mã XML