TIÊu chuẩn việt nam tcvn 11777-9: 2017 with amendment 5: 2014


D.2.24 Căn chỉnh (JPIP-align)



tải về 8.86 Mb.
trang23/40
Chuyển đổi dữ liệu01.12.2017
Kích8.86 Mb.
#34910
1   ...   19   20   21   22   23   24   25   26   ...   40

D.2.24 Căn chỉnh (JPIP-align)

Tiêu đề đáp ứng này nên được cung cấp nếu đảm bảo sự liên kết máy chủ khác với yêu cầu của máy khách. (Xem C.7.1.)



D.2.25 Địa chỉ phụ (JPIP-subtarget)

Tiêu đề đáp ứng này nên được cung cấp nếu địa chỉ phụ được xác định bởi các máy chủ khác với yêu cầu của máy khách. (Xem C.2.3.)



D.2.26 Yêu cầu xử lý (handled)

Các máy chủ bao gồm tiêu đề đáp ứng này trong đáp ứng của nó với một yêu cầu có chứa các trường yêu cầu xử lý. Tiêu đề đáp ứng xử lý JPIP này xác định các yêu cầu mà máy chủ có thể xử lý một cách chính xác, phù hợp với tiêu chuẩn này. Mỗi trường yêu cầu có thể là bất kỳ một trường yêu cầu được đề cập trong Điều C.1.2, nhưng cũng có thể bao gồm các thẻ mà một số máy khách có thể không nhận ra; máy khách sẽ bỏ qua bất kỳ trường yêu cầu mà chúng không hiểu.

Một partially-handled-req có thể được sử dụng để hỗ trợ một phần cho trường yêu cầu. Nếu trường yêu cầu có liên quan có một tập hữu hạn các chuỗi tham số hoàn chỉnh theo sau ký tự "=" (ví dụ, "yes" hoặc "no"), các handled-req-option có thể là một trong những giá trị đó. Bảng D.3 mô tả các giá trị bổ sung cho các handled-req-option được xác định bởi tiêu chuẩn này để sử dụng với các trường theo yêu cầu cụ thể. Các máy chủ có thể bao gồm các thẻ cho handled-req-option mà một số máy khách có thể không nhận ra. Máy khách phải bỏ qua partially-handled-req bất kỳ có trường yêu cầu hoặc handled-req-option mà chúng không hiểu.

Bảng D.3 - Các giá trị handled-req-option bổ sung cho trường yêu cầu đặc biệt

request-field

handled-req-option

Ý nghĩa

Cnew

transport-name

Máy chủ xử lý một cách chính xác các trường yêu cầu kênh mới (new-channel) có chứa các loại truyền tải xác định.

Context

"jplx", "mj2t", "jpmp", "jpxf"

Máy chủ xử lý một cách chính xác trường yêu cầu Ngữ cảnh Dòng mã cho các giá trị context-range bắt đầu với thẻ handled-req-option.

D.3 Dữ liệu đáp ứng

Đối với bất kỳ loại nào khác kiểu trả về ảnh dòng JPP hoặc dòng JPT, bao gồm dòng mã thô, dữ liệu đáp ứng nên bao gồm các thực thể yêu cầu đầy đủ. Đối với kiểu trả về ảnh dòng JPP hoặc JPT, dữ liệu đáp ứng bao gồm một chuỗi các bản tin được quy định tại Phụ lục A, kết thúc bằng bản tin EOR (End Of Response) đơn. Bản tin EOR không được quy định tại Phụ lục A và không phải là một phần chính thức của kiểu phương tiện truyền thông dòng JPP hoặc dòng JPT.

Bản tin EOR bao gồm tiêu đề và phần thân. Tiêu đề bản tin EOR bao gồm định byte đơn, 0x00, theo sau là một mã lý do byte đơn, R, và tiếp theo là một số đếm VBAS byte đơn, chỉ ra số lượng các byte trong phần thân của bản tin EOR. Tiêu chuẩn này không quy định giải thích nội dung của phần thân bản tin EOR.

Phần thân và tiêu đề của bản tin EOR chỉ đơn thuần là bản tin không góp phần vào việc hạn chế số lượng byte gán cho trường yêu cầu Độ dài Đáp ứng Tối đa được định nghĩa trong C.6.1.

Chú thích: Bản tin EOR nghĩa là máy chủ đã cung cấp tất cả các nội dung thích hợp của ngăn dữ liệu có liên quan cho một yêu cầu máy khách. Đây không nhất thiết là toàn bộ nội dung của các ngăn dữ liệu này. Đáp ứng kết thúc khi đạt đến một ngưỡng giới hạn cụ thể. Nếu không xác định giới hạn, thì bản tin EOR có nghĩa là tất cả các nội dung của ngăn dữ liệu liên quan sẽ được phục vụ.

The EOR message, header and body, is the only message which does not contribute to the byte count restriction associated with the Maximum Response Length request field as defined in C.6.1.

Các mã lý do hiện tại được xác định (xem Bảng D.2).
Phụ lục E

(Quy định)

Tải ảnh lên máy chủ

E.1 Tổng quan

Dự đoán rằng các ảnh sẽ được đặt trên một máy chủ bằng nhiều cách khác nhau nằm ngoài phạm vi của tiêu chuẩn này. Mục đích của phụ lục này là mô tả một cơ chế cho phép các phần của một ảnh được tải lên máy chủ.



E.2 Yêu cầu tải lên

E.2.1 Cấu trúc yêu cầu

Một yêu cầu tải lên bao gồm một hoặc nhiều trường yêu cầu quy định tại Phụ lục C, và phần thân của yêu cầu.



E.2.2 Trường yêu cầu tải lên

Các trường yêu cầu khi tải lên phải chứa trường yêu cầu Tải lên. Các trường yêu cầu Địa chỉ, Địa chỉ phụ và ID Địa chỉ (xem C.2.2, C.2.3 và C.2.4) cũng có thể được sử dụng. Đối với việc tải lên kiểu phương tiện truyền thông ảnh hoàn chỉnh, các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng (xem C.4.2, C.4.3, và C.4.4) được sử dụng để chỉ ra vị trí của phần tải lên trong toàn bộ ảnh. Đối với việc tải lên dòng JPT và dòng JPP, số lượng ngăn dữ liệu (số lượng khối ảnh và phân khu ảnh) cùng với các tiêu đề chính chỉ ra vị trí của dữ liệu được mã hóa và không cần thiết trường yêu cầu Cửa sổ hiển thị



E.2.3 Phần thân của yêu cầu Tải lên

E.2.3.1 Tổng quát

Phần thân của yêu cầu tải lên bao gồm một trong các loại ảnh được hỗ trợ: dòng JPP, dòng JPT, hoặc kiểu phương tiện truyền thông ảnh hoàn chỉnh. Phần thân chứa dữ liệu máy khách được yêu cầu để xử lý tại máy chủ. Tiêu chuẩn này không hỗ trợ tải lên dữ liệu ảnh thô.



E.2.3.2 ng JPT

Phần thân của yêu cầu chứa tất cả các ngăn dữ liệu máy khách muốn máy chủ thay thế (ngăn dữ liệu tiêu đề, ngăn dữ liệu đặc tả và ngăn dữ liệu khối ảnh). Nếu máy khách không tải lên ngăn dữ liệu tiêu đề chính, thì ngăn dữ liệu khối ảnh sẽ được mã hóa một cách tương thích với các tiêu đề chính hiện tại.



E.2.3.3 Dòng JPP

Phần thân của yêu cầu chứa tất cả ngăn dữ liệu máy khách muốn máy chủ thay thế (ngăn dữ liệu tiêu đề, ngăn dữ liệu tiêu đề khối ảnh, ngăn dữ liệu đặc tả và ngăn dữ liệu phân khu ảnh). Nếu máy khách không tải lên ngăn dữ liệu tiêu đề chính hoặc ngăn dữ liệu tiêu đề khối ảnh, thì phân khu sẽ được mã hóa một cách cách tương thích với các tiêu đề chính và tiêu đề khối ảnh hiện tại



E.2.3.4 Tải lên ảnh hoàn chỉnh

Phần thân của yêu cầu chứa kiểu phương tiện truyền thông ảnh hoàn chỉnh đại diện cho những mẫu máy khách muốn thay đổi.

Trong trường hợp tải lên ảnh hoàn chỉnh, yêu cầu có thể bao gồm các trường yêu cầu Kích cỡ Khung hình, Kích thước Vùng và Độ lệch. Trường yêu cầu Kích cỡ Khung hình sẽ là kích thước lưới tọa độ tham chiếu của ảnh. Trong trường hợp tải lên ảnh hoàn chỉnh, nén không cần thực hiện một cách tương thích với địa chỉ logic trên máy chủ. Nếu kích thước của ảnh tải lên vượt quá phạm vi trong trường yêu cầu Kích thước Vùng, máy chủ nên thay đổi hạn chế phạm vi theo quy định trong trường yêu cầu Kích thước Vùng

E.3 Đáp ứng máy chủ

E.3.1 Tổng quát

Các máy chủ đáp ứng yêu cầu tải lên với mã trạng thái và mệnh đề lý do từ Phụ lục D. Các mã và mệnh đề lý do trả về hữu ích đối với việc tải lên hình ảnh được thể hiện trong các Điều dưới đây.



E.3.2 201 (Đã tạo)

Các máy chủ nên sử dụng mã trạng thái này, nếu sau khi nhận được yêu cầu tải lên, một nguồn tài nguyên mới được xác định trên máy chủ. Các máy chủ có trách nhiệm hoàn thành việc tạo ra trước khi trả về yêu cầu này. Nếu xảy ra trễ, máy chủ sẽ trả về 202 (Đã chấp nhận) thay vì 201 (Đã tạo).

Các máy chủ bao gồm một tiêu đề đáp ứng với một trường ID Địa chỉ mới cho các nguồn tài nguyên được cập nhật.

Không cần trả về phần thân.



E.3.3 202 (Đã chấp nhận)

Các máy chủ nên sử dụng mã trạng thái này nếu việc tải lên tạo ra một nguồn tài nguyên mới nhưng máy chủ vẫn chưa sẵn sàng để phục vụ. Các máy chủ cũng có thể sử dụng mã trạng thái này cho một bản cập nhật của tài nguyên hiện hành.



E.3.4 400 (Yêu cầu bị lỗi)

Máy chủ phát hành mã trạng thái này nếu yêu cầu có định dạng không chính xác, hoặc nếu truy vấn chứa các trường yêu cầu không tương thích với quá trình tải lên hoặc có chứa một trường không được công nhận trong chuỗi truy vấn.



E.3 5 404 (Không tìm thy)

Mã trạng thái này cần được phát hành nếu máy chủ không thể dung hòa các tài nguyên yêu cầu với một ID Địa chỉ được phát hành.



E.3.6 415 (Loại phương tiện không được hỗ tr)

Mã trạng thái này có thể được phát hành để chỉ ra rằng hỗ trợ việc tải lên, nhưng chỉ tải lên các loại đặc biệt (ví dụ, ảnh hoàn chỉnh, dòng JPT, hoặc dòng JPP) đi kèm với yêu cầu không được hỗ trợ.



E.3.7 501 (Không được triển khai)

Trạng thái này có thể được sử dụng nếu máy chủ không hỗ trợ tải lên hoặc không hỗ trợ lựa chọn đặc biệt cho tải lên.



E.4 Gộp dữ liệu trên máy chủ

E.4.1 Cập nhật ảnh

Sau khi nhận được các dữ liệu tải lên, các máy chủ có thể tạo ra một phiên bản mới cho địa chỉ logic và cung cấp các phiên bản mới cho các máy khách truy cập vào URL mới hoặc URL cũ. Tuy nhiên, các máy chủ không được sử dụng các trường yêu cầu ID Địa chỉ cũ để cung cấp quyền truy cập vào bất kỳ dữ liệu bị gộp hoặc cập nhật.

Nếu máy khách chứa trường yêu cầu ID Địa chỉ trong yêu cầu tải lên và địa chỉ ID không phù hợp với địa chỉ ID hiện tại của máy chủ đối với các nguồn tài nguyên, máy chủ không nên cập nhật các hình ảnh. Việc không phù hợp này có thể cho thấy máy khách đã chỉnh sửa một phiên bản trước của hình ảnh được sửa đổi. Máy chủ có thể từ chối hoặc chấp nhận việc tải lên không chứa trường yêu cầu ID Địa chỉ. Đây là một cách để chặn nhiều sửa đổi đồng thời trên cùng một địa chỉ của các máy khách khác nhau. Các máy chủ cung cấp khả năng chỉnh sửa để khắc phục các vấn đề như khóa địa chỉ bằng một số phương tiện khác.

Máy khách JPIP có thể tải lên một phần của ảnh mới bằng cách xác định địa chỉ ID là 0, hoặc sử dụng một URL mới, hoặc địa mà máy chủ không có. Các máy chủ nên phát hành một địa chỉ ID cho việc tải lên. Một máy khách có thể tiếp tục tải lên một phần bổ sung của ảnh mới bằng cách sử dụng địa chỉ ID trả về từ máy chủ trong phiên tải lên trước đó.



E.4.2 Dòng JPT

Máy chủ chấp nhận dữ liệu ngăn dữ liệu khối ảnh đầu tiên phải loại bỏ tất cả các dữ liệu cũ cho các khối ảnh tải lên, và bao gồm các dữ liệu mới thêm vào dòng mã. Cập nhật không thể tạo ra kết quả bằng việc thay đổi về số lượng hoặc kích thước hoặc vị trí của khối ảnh: cấu trúc của ảnh không thể thay đổi khi tải lên. Đặc biệt, một máy chủ không nên chấp nhận tải lên ngăn dữ liệu khối ảnh của dòng mã chứa đoạn nhãn PPM trong tiêu đề chính, trừ khi máy khách cung cấp một tiêu đề chính mới khi tải lên. Bất kỳ đoạn nhãn PLM hoặc TLM sẽ bị xóa hoặc cập nhật. Ngăn dữ liệu tiêu đề chính dòng JPT sẽ tải lên các ảnh mới.

Cách hình thành các dòng mã phần khối ảnh từ ngăn dữ liệu khối ảnh không được xác định. Các máy khách không cần thiết phải cung cấp tất cả các phần khối ảnh, và cũng không cần phần khối ảnh cuối để hoàn thành. Các máy chủ có trách nhiệm cập nhật tiêu đề chính và các phần bất kỳ của định dạng tập tin bị ảnh hưởng (ví dụ như chiều dài của khung Dòng mã).

Khi gộp dữ liệu, số lượng hoặc kích thước của khối ảnh không bị thay đổi và dữ liệu không bị thay thế bởi quá trình tải lên có nghĩa tương tự như ban đầu lúc trước khi tải lên.



E.4.3 Dòng JPP

Máy chủ chấp nhận bản tin ngăn dữ liệu phân khu ảnh đầu tiên sẽ loại bỏ các ngăn dữ liệu phân khu ảnh cũ tương ứng đối với các phân khu ảnh được tải lên, và bao gồm các dữ liệu ngăn dữ liệu phân khu ảnh mới. Thay đổi không thể được thực hiện đối với tiêu đề mà kết quả của thay đổi về số lượng phân khu ảnh, hoặc ý nghĩa của định danh phân khu ảnh, hoặc vị trí hoặc kích thước của mỗi phân khu ảnh trong Độ phân giải thành phần khối ảnh. Các ngăn dữ liệu tiêu đề khối ảnh dòng JPP và ngăn dữ liệu tiêu đề chính sẽ tải lên các ảnh mới.

Các hình thành gói phân khu ảnh từ ngăn dữ liệu phân khu ảnh không được xác định. Các máy khách không cần cung cấp tất cả các gói của phân khu ảnh, hoặc thậm chí gói hoàn chỉnh được cung cấp cuối cùng.

Khi gộp dữ liệu, số lượng hoặc kích thước của phân khu ảnh không bị thay đổi và dữ liệu không bị thay thế bởi quá trình tải lên sẽ có nghĩa tương tự như ban đầu lúc trước khi tải lên.



E.4.4 Ngăn dữ liệu đặc tả dòng JPP và dòng JPT

Ngăn dữ liệu đặc tả có thể được tải lên, thay thế nội dung trong ngăn dữ liệu đặc tả đang tồn tại. Do máy chủ kiểm soát việc phân bổ dữ liệu đặc tả vào ngăn dữ liệu đặc tả, nên máy khách cũng thực hiện theo cấu trúc ngăn dữ liệu đặc tả của máy chủ. Máy khách sẽ không thay đổi các khung Chờ trong ngăn dữ liệu đặc tả, ngoại trừ việc hoàn toàn loại bỏ khung Chờ. Khi tải lên toàn bộ ngăn dữ liệu đặc tả, máy khách có thể thêm dữ liệu đặc tả mới bằng cách thêm vào phần cuối của ngăn dữ liệu đặc tả cũ, hoặc bằng cách chèn dữ liệu đặc tả mới giữa các khung trong ngăn dữ liệu đặc tả cũ. Máy chủ quản lý khung Chờ và cấu trúc ngăn dữ liệu đặc tả. Điều này bao gồm cập nhật tất cả khung chờ chỉ đến tới khung dữ liệu đặc tả bị hỏng bất kỳ đã được thay đổi hoặc bị ảnh hưởng bởi sự thay đổi. Các máy chủ sẽ xóa khung dữ liệu đặc tả bất kỳ được trỏ đến bởi một khung Chờ mà máy khách đã loại bỏ. Các máy chủ có thể tái cấu trúc dữ liệu đặc tả sau khi tải lên được chấp nhận, nhưng phải trước khi các nguồn tài nguyên mới được tạo ra. Nếu không sử dụng được phần còn lại trong tập tin sau khi tải lên, các khung Free được sử dụng để điền vào những phần đó.



E.4.5 Tải lên ảnh hoàn chỉnh

Trong trường hợp chấp nhận tải lên của một ảnh hoàn chỉnh, các máy chủ cần giải nén (nếu cần) các ảnh phụ tải lên, giải nén một số phần của ảnh đầy đủ trên máy chủ, thay thế các điểm ảnh trong (không nén) miền không gian và nén lại tất cả các khối ảnh hoặc phân khu bị ảnh hưởng bởi các hoạt động cập nhật.

CHÚ THÍCH: Công nghệ này đòi hỏi phải tính toán nhiều hơn trên máy chủ. Tuy nhiên, nó loại bỏ khả năng r các máy khách sẽ sử dụng dữ liệu ảnh nén một cách không tương thích (ví dụ, sai số của mức biến đổi sóng con).
Phụ lục F

(Quy định)

Sử dụng JPIP trên HTTP

F.1 Tng quan

Phụ lục này quy định phương pháp để sử dụng JPIP với HTTP cho cả các yêu cầu và đáp ứng. Các tham số yêu cầu JPIP trong Phụ lục C được đóng gói trong các cấu trúc yêu cầu HTTP hợp lệ. Các đáp ứng máy chủ (bao gồm cả mã trạng thái, tiêu đề, bản tin và mã đáp ứng) trong Phụ lục D được đóng gói trong các đáp ứng HTTP hợp lệ. Mọi yêu cầu và đáp ứng được mã hóa theo quy định của tiêu chuẩn HTTP.

Lưu ý rằng các đoạn văn bản và các ví dụ trong phụ lục này mô tả việc sử dụng JPIP trên nền HTTP. Điều này cũng được sử dụng đối với HTTP bảo mật (hay HTTPS).

F.2 Các yêu cầu

F.2.1 Giới thiệu các yêu cầu

Phụ lục C xác định các trường yêu cầu. Khi truyền tải qua HTTP, yêu cầu JPIP có thể xuất hiện như là một chuỗi truy vấn trong yêu cầu HTTP "GET" hoặc là phần thân của yêu cầu HTTP "POST". Bởi vì một số hệ thống HTTP giới hạn độ dài của chuỗi truy vấn được cung cấp trong một yêu cầu, nên yêu cầu "GET", "POST' được ưu tiên cho các yêu cầu JPIP đầy đủ.



CHÚ THÍCH 1: Yêu cầu HTTP được định nghĩa trong phần 5 của RFC 2616 như sau:

CHÚ THÍCH 2: Các HTTP Request-Line và Request-URI được định nghĩa:



CHÚ THÍCH 3: RFC 2396 định nghĩa:





F.2.2 Yêu cầu GET

Yêu cầu JPIP có thể được cung cấp cho một máy chủ như là yêu cầu HTTP. Đối với yêu cầu "GET" giới hạn yêu cầu HTTP như đây:

- "Method" sẽ là "GET".

- "query" bằng không hoặc jpip-request-field được phân tách bởi "&"



Một ví dụ về yêu cầu JPIP đóng gói trong yêu cầu HTTP "GET":

Một ví dụ tương đương sử dụng một absoluteURI thay vì một abs_path:



CHÚ THÍCH: Tiêu chuẩn này áp đặt không hạn chế các thành phần lập lịch của absoluteURI.



Каталог: data -> 2017
2017 -> Tcvn 6147-3: 2003 iso 2507-3: 1995
2017 -> Các Cục Hải quan tỉnh, thành phố
2017 -> TIÊu chuẩn quốc gia tcvn 10256: 2013 iso 690: 2010
2017 -> Căn cứ Nghị định số 15/2017/NĐ-cp ngày 17/02/2017 của Chính phủ quy định chức năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ Nông nghiệp và Phát triển nông thôn
2017 -> TIÊu chuẩn quốc gia tcvn 8400-3: 2010
2017 -> TIÊu chuẩn nhà NƯỚc tcvn 3133 – 79
2017 -> Căn cứ Luật Tổ chức chính quyền địa phương ngày 19 tháng 6 năm 2015
2017 -> Căn cứ Nghị định số 15/2017/NĐ-cp ngày 17 tháng 02 năm 2017 của Chính phủ quy định chức năng, nhiệm vụ, quyền hạn và cơ cấu tổ chức của Bộ Nông nghiệp và Phát triển nông thôn
2017 -> Btvqh10 ngày 25 tháng 5 năm 2002 của Ủy ban Thường vụ Quốc hội về tự vệ trong nhập khẩu hàng hóa nước ngoài vào Việt Nam

tải về 8.86 Mb.

Chia sẻ với bạn bè của bạn:
1   ...   19   20   21   22   23   24   25   26   ...   40




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương