Hệ thống dò tìm đại diện tự động (Dynamic Delegation Discovery System - DDDS) là một thành phần cơ bản quan trọng của ENUM. Nó được đưa vào ENUM để giải quyết các vấn đề gặp phải khi thể hiện các tài nguyên gắn kết với số ENUM một cách tối ưu nhất, và hỗ trợ các giải pháp dữ liệu động tốt nhất
DDDS được sinh ra như kết quả của một hướng nghiên cứu mới của nhóm làm việc chuyên trách về "tên tài nguyên thống nhất" URN do khi nhóm nghiên cứu về vấn đề URN gặp phải vấn đề: làm thế nào để có thể tìm kiếm được thông tin về một URN nếu trong URN không chứa các thông tin định vị dịch vụ mạng (chẳng hạn không chứa tên hoặc địa chỉ máy chủ truy vấn). Một hệ thống được đưa ra có thể sử dụng một cơ sở dữ liệu luật dùng để áp đặt lên URN nhằm tìm ra thông tin trên từng đoạn của URN. Đầu tiên, hệ thống này được gọi là dịch vụ dò tìm thiết bị truy vấn RDS (Resolver Discovery Service), chỉ dùng được với các URN. Sau này, phương pháp tương tự được áp dụng trên các chuỗi không phải URN và trở thành DDDS.
DDDS được mô tả bởi một hệ thống các tài liệu chuẩn của IETF, gồm 5 phần với các RFC số 3401, 3402, 3403, 3404, 3405. DDDS được định nghĩa đơn giản là một thuật toán tổng quát nhằm áp dụng một luật chuyển đổi chuỗi thu nhận được một cách động lên một chuỗi đơn của ứng dụng. Nói cách khác, DDDS là phương pháp dùng để chuyển đổi chuỗi thành dữ liệu một cách động, sử dụng để hỗ trợ cấu hình động cho các hệ thống uỷ quyền (delegation).
Để làm được việc này, DDDS đơn giản là sử dụng các luật chuyển đổi chuỗi áp đặt tuần tự và lặp lại lên các chuỗi đầu vào cho tới khi điều kiện kết thúc đạt được, và ánh xạ kết quả vào các dữ liệu chứa trong cơ sở dữ liệu DDDS
1. Cách thực hiện DDDS
Hình 1. Thuật toán DDDS
Đầu tiên, chuỗi đơn đầu vào của ứng dụng được áp đặt một luật gọi là luật bắt đầu (First Well Known Rule). Luật này do ứng dụng định ra, chứ không phải lấy từ cơ sở dữ liệu. Luật này nhằm tìm ra khoá đầu tiên dùng để truy vấn cơ sở dữ liệu DDDS.
Với khoá tìm được, truy vấn cơ sở dữ liệu DDDS sẽ tìm được luật áp dụng tiếp theo. Luật này áp dụng lên chuỗi đầu vào sẽ cho khoá mới, hoặc cuối cùng là kết quả đầu ra mong muốn.
Để thấy được sự phức tạp của các biểu thức áp dụng trong DDDS, ta xem xét ví dụ sau:
Xem xét 1 URN có định dạng lấy từ MIME "Content-Ids" như sau:
urn:cid:199606121851.1@bar.example.com
Để truy vấn thông tin về URN này, ứng dụng thực hiện theo quy ước, ở đây việc đầu tiên là tìm thông tin về dạng dữ liệu MIME, bằng cách tìm chuỗi dữ liệu giữa 2 dấu ":" đầu tiên. Kết quả thu được là "cid"
Ứng dụng cũng được quy ước trước là với chuỗi thu được, nó phải thêm vào một đuôi "urn.arpa" để có được một khoá tìm kiếm đầy đủ. Khoá ở đây là "cid.urn.arpa"
Với truy vấn tên miền "cid.urn.arpa", ứng dụng thu được một bản ghi NAPTR như sau:
cid.urn.arpa.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
Do ở đây chỉ có 1 trường NAPTR trả về nên không có vấn đề sắp xếp thứ tự ưu tiên. Áp dụng luật thu được trên chuỗi URN ban đầu ta thu được chuỗi "example.com" (thành phần thứ 2 theo như biểu thức thay thế chỉ ra, giữa 2 dấu "!")
Truy vấn tiếp tên miền "example.com" ta thu được:
example.com.
;; order pref flags service regexp replacement
IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com.
IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
Chi tiết thêm về thuật toán DDDS tham khảo [RFC3402]
2. Phân bố các luật DDDS qua DNS
Để có thể phân bố các luật DDDS một cách hiệu quả và đơn giản, DDDS sử dụng cơ sở dữ liệu DNS như một cơ sở dữ liệu phân bố luật, định nghĩa theo [RFC3403]. Các khoá ở đây là các tên miền, và các luật được mã hoá bằng các trường NAPTR. Một truy vấn khoá sẽ có dạng một truy vấn tên miền thông thường, và kết quả trả về sẽ là một loạt các bản ghi NAPTR chứa các luật cần truy vấn. RFC3403 cũng đồng thời thay thế cho RFC2915, và được coi là định nghĩa chính thức của NAPTR. Các mô tả chính như sau:
Bộ mã được sử dụng trong các trường của NAPTR là UTF-8. Do đó nếu đầu vào/ đầu ra của các biểu thức có chứa các mã nằm ngoài bộ mã UTF-8 thì phải được biểu diễn bằng các tham chiếu theo kiểu một chuỗi byte để có thể thoả mãn được. Điều này là do các biểu thức thường được sử dụng là dạng mở rộng của biểu thức dùng trong hệ POSIX. Điều này cần được đặc biệt quan tâm khi áp dụng ở Việt Nam khi các trường NAPTR được sử dụng có chứa mã tiếng Việt. Tuy nhiên trong khuôn khổ tài liệu này sẽ không bàn đến vấn đề mã đa ngữ trong các bản ghi NAPTR.
Tất cả các bản ghi DNS đều được gán một thời gian sống (time-to-live) tính bằng giây. Sau khi bản ghi được lấy về thì nó chỉ có giá trị trong khoảng thời gian bằng time-to-live. Sau thời gian đó bản ghi coi như không còn giá trị, và phải được truy vấn lại. Điều này cũng ảnh hưởng tới việc lưu trữ các luật DDDS, vì ứng dụng phải đảm bảo là chỉ áp dụng các luật chưa bị quá hạn time-to-live. Nếu luật được áp dụng bị quá hạn, ứng dụng phải bắt đầu lại từ đầu việc áp dụng toàn bộ thuật toán.
Cấu trúc của khóa: Khóa phải là một tên miền được cấu tạo đúng cú pháp chuẩn
Để tìm kiếm 1 tập hợp luật, ứng dụng phải sử dụng một truy vấn DNS tiêu chuẩn để tìm bản ghi NAPTR ứng với tên miền đã cho
Định dạng gói tin NAPTR như sau:
Hình 2. Định dạng gói tin NAPTR
Ở đây chuỗi ký tự và tên miền được định nghĩa trong RFC1035
THỨ TỰ là một số 16 bit biểu thị thứ tự mà bản ghi cần được xử lý để có thể phản ánh đúng thứ tự các luật. Thứ tự được sắp xếp từ nhỏ đến lớn. Các bản ghi có cùng thứ tự được coi là cùng luật, và việc xử lý sẽ phụ thuộc vào các trường LỰA CHỌN và DỊCH VỤ
LỰA CHỌN cũng biểu thị thứ tự ưu tiên trong việc xử lý DDDS, nó chỉ ra thứ tự thực hiện trong trường hợp các trường THỨ TỰ là giống nhau. Ứng dụng có thể tìm các bản ghi có giá trị LỰA CHỌN cao hơn nếu nó muốn (ví dụ trường hợp nó không hỗ trợ tốt dịch vụ hay thủ tục nào đó)
Ứng dụng chỉ được xác định 1 THỨ TỰ để xử lý, trong khi nó có thể thay đổi các bản ghi để có LỰA CHỌN tốt hơn
CỜ là chuỗi dùng để xác định phương thức viết lại các trường trong bản ghi, do ứng dụng xác định.
DỊCH VỤ là chuỗi xác định các tham số dịch vụ phù hợp cho hướng chuyển giao này, cũng do ứng dụng xác định
BIỂU THỨC REGEXP chứa chuỗi thay thế được áp dụng cho chuỗi đầu vào để có được tên miền tiếp theo để truy vấn tiếp. Biểu thức chỉ được áp dụng cho chuỗi đầu vào, chứ không áp dụng cho các chuỗi trung gian trong quá trình xử lý bản ghi.
THAY THẾ là chuỗi sử dụng để thay thế chuỗi trong trường hợp thay thế đơn giản. Cùng với BIỂU THỨC để tạo nên một biểu thức thay thế đầy đủ sử dụng trong DDDS
Ở đây xuất hiện vấn đề xung đột trong các bản ghi NAPTR. Vì các bản ghi NAPTR trong cùng 1 khoá (một tên miền) có thể được sử dụng cho nhiều dạng ứng dụng khác nhau (ví dụ ENUM và URI có thể cùng truy vấn 1 tên miền nào đó), do đó luật trả về trong các NAPTR có thể sẽ chỉ thích hợp với 1 ứng dụng nào đó, và không thích hợp với các ứng dụng còn lại. Cơ chế xử lý là một trong các cách:
· Sử dụng các tên miền khác nhau cho các ứng dụng khác nhau
· Biểu thức phải được viết để có thể nhận dạng được ứng dụng truy vấn. Chẳng hạn biểu thức dùng cho ENUM có thể được viết để nhận biết được dấu + trước chuỗi số đầu vào
· Sử dụng các trường "cờ" khác nhau, hoặc các trường "dịch vụ" khác nhau.
Một vấn đề khác cần chú ý là các dữ liệu luật ghi trong các bản ghi DNS phải được thể hiện đúng dạng chuẩn DNS quy định trong [RFC1305], do đó với các biểu thức chứa các ký tự đặc biệt như "\" thì trong các file chứa dữ liệu DNS, nó phải được biến đổi thành "\\" v.v
3. Biểu thức (Regular Expression)
Biểu thức Regular Expression, gọi tắt là RE có thể coi là một ngôn ngữ lập trình chuyên biệt nhỏ gọn, chuyên sử dụng để xử lý các chuỗi ký tự thông qua việc định ra các "luật xử lý". Với RE, ta có thể chỉ ra các mẫu (pattern) mà ta muốn tìm kiếm, và các hành động áp dụng lên chuỗi trong trường hợp phát hiện đúng (match) các mẫu đó trong chuỗi, với các hành động như thay thế (replace), hay phân chia chuỗi (split).
RE được sử dụng từ lâu trong rất nhiều môi trường phát triển, như trong các thư viện lập trình C, các ứng dụng unix như sed, awk, grep... hay trong cả các hệ thống phát triển mới như Microsoft Visual C++, .NET...
Các mẫu sử dụng trong RE được biên dịch thành các mã bytecode thực thi nên tốc độ của nó thường rất nhanh, khả năng tùy biến cao, và hay được ứng dụng trong các ngôn ngữ lập trình cần tác động lên chuỗi ký tự.
RE tương đối nhỏ và giới hạn. Không phải tất cả các thao tác chuỗi dữ liệu đều có thể xử lý được với RE. Chỉ có một số giới hạn các thao tác được RE hỗ trợ, nhưng tập hợp lại thường các biểu thức RE lại trở nên hết sức phức tạp.
Để diễn giải cú pháp RE, trước hết ta xem xét các mẫu tìm kiếm
3.1. Ký tự "ứng hợp" (matching character)
Đa phần các ký tự được sử dụng để ứng với việc tìm kiếm chính bản thân chúng. Ví dụ các ký tự "test" dùng để tạo nên mẫu tìm kiếm cho chuỗi "test". Tuy nhiên, có một số ngoại lệ ở các ký tự đặc biệt. Các ký tự này có các ý nghĩa nhất định trong mẫu tìm kiếm.
^ chỉ ra vị trí đầu chuỗi. VD "^abc" hợp với các chuỗi bắt đầu bởi chuỗi con "abc"
$ chỉ ra vị trí cuối chuỗi. VD "abc$" hợp với các chuỗi kết thúc với chuỗi con "abc"
. ứng với mọi ký tự trừ ký tự xuống dòng. VD "acb.d" hợp với "abced", "abcfd", "abcgd"...
"[" và "]" : 2 ký tự này dùng để tạo ra một phân lớp ký tự, tức là tập hợp các ký tự mà ta muốn tìm kiếm. Các ký tự có thể được liệt kê lần lượt, hoặc liệt kê trong 1 dải ký tự bằng cách đưa ra ký tự bắt đầu và kết thúc phân cách bằng dấu "-". Ví dụ "[abc]" hay "[a-c]" dùng để tìm các ký tự a, b, hoặc c. Bên trong cặp [ ] các ký tự đặc biệt khác như $ bị mất ý nghĩa, và trở thành các ký tự thông thường. Tuy nhiên ký tự "^" sử dụng trong cặp [ ] có nghĩa là phủ định của tập ký tự. VD "[^5]" dùng để tìm các ký tự khác "5"
Ký tự "\" được coi là ký tự escape, các ký tự đi kèm với nó sẽ tạo ra các mã đặc biệt. Nó cũng được sử dụng để tạo ra các mã thông thường của các ký tự đặc biệt, ví dụ "\\" để chỉ mã ký tự "\", hay \[ để chỉ ra ký tự "["
\d ứng với các số thập phân, hay thuộc lớp [0-9]
\D ứng với các ký tự không phải số thập phân, hay [^0-9]
\s ứng với mọi loại khoảng cách trắng, tức là [ \t\n\r\f\v]
\S ứng với các ký tự không phải khoảng cách trắng, hay [^ \t\n\r\f\v]
\w ứng với mọi ký tự chữ và số, tương đương với [a-zA-Z0-9_]
\W ứng với mọi ký tự không phải chữ và số, hay [^a-zA-Z0-9_]
\< và \> ứng với bắt đầu và kết thúc một từ (word)
\( và \) sẽ đặt các biểu thức ở giữa vào một nhóm tham chiếu, đồng thời lưu tạm các ký tự tìm được trong phạm vi nhóm này vào bộ nhớ (có thể chứa 9 nhóm trong cùng 1 RE), và có thể được sử dụng với tham chiếu là \1 đến \9.
| ứng với mã "hoặc" (OR)
3.2. Mã lặp
* là mã đặc biệt chỉ ra tổ hợp lặp lại 0 hay nhiều hơn lần của ký tự đi cùng
+ chỉ ra tổ hợp lặp 1 hay nhiều hơn lần của ký tự đi cùng
? chỉ ra tổ hợp 1 hay 0 lần của ký tự đi cùng
{m,n} chỉ ra tổ hợp của ít nhất m lần, nhiều nhất n lần lặp của ký tự đi cùng
4. Ứng dụng RE trong các bản ghi RR của DNS
Các biểu thức RE thường được sử dụng trong các bản ghi cần độ tùy biến cao, và có tính chất bao quát. Chẳng hạn để có được 1 chuỗi ký tự duy nhất có thể áp dụng cho một tập hợp các bản ghi khác nhau, người ta có thể sử dụng RE với các toán tử tìm kiếm và thay thế. Ta sẽ phân tích kỹ trường hợp này.
Giả sử có một tập hợp chuỗi đầu vào có dạng 123456xxx, trong đó x là các số thập phân. Nếu ứng với mỗi chuỗi đầu vào ta cần đưa ra kết quả là xxx@test thì nếu làm thủ công với từng số, ta phải thao tác 1000 lần. Mặc dù điều này có thể thực hiện được với 1 chương trình máy tính đơn giản, cách làm như vậy không có tính tùy biến và mềm dẻo. Ta có thể áp dụng RE một cách đơn giản hơn. Biểu thức RE sau đây sẽ tổng hợp chuỗi kết quả nếu được áp dụng lên chuỗi đầu vào:
!^123456\(\d{3}\)$!\1@test!
Lưu ý chuỗi RE gồm có 2 phần, được phân cách bởi các ký tự "!", biểu thị mẫu "tìm kiếm" và mẫu "thay thế".
Mẫu tìm kiếm "^123456\(\d{3}\)$" tìm các chuỗi đầu vào có bắt đầu bằng "123456", tiếp theo là 3 (biểu diễn bởi "{3}") chữ số thập phân (biểu diễn bởi "\d"), và kết thúc. Ở đây sử dụng cặp mã \( và \) để tách nhóm 3 ký tự cuối và nhớ vào biến nhớ. Biến nhớ này có thể được tham chiếu về sau thông qua tham chiếu "\1"
Phần mẫu thay thế sử dụng lại tham chiếu \1 nói trên và thêm vào chuỗi "@test". Lưu ý là mẫu thay thế được áp dụng trên toàn bộ chuỗi ký tự đầu vào, ở đây là viết lại toàn bộ (nên còn được gọi là luật viết lại - rewrite rule)
5. Ứng dụng trong ENUM
Ứng dụng cách làm này trong các trường dữ liệu ENUM, người ta có các mẫu dữ liệu khá mềm dẻo. Ví dụ như để đưa dữ liệu email vào các trường ENUM cho toàn bộ văn phòng của 1 công sở, chuỗi sau sẽ được đưa vào bản ghi ENUM của mã điện thoại chung sử dụng cho công sở đó:
Công ty có số điện thoại +84-4-81234567
Các nhân viên có các mã mở rộng EXT từ 1 đến 999
bản ghi ENUM được chứa trong tên miền:
7.6.5.4.3.2.1.8.4.4.8.e164.arpa.
có chứa bản ghi
IN NAPTR 100 10 "u" "mailto+E2U" "!^84481234567(.*)$!mailto:\1@company.com!"
Với việc đưa biểu thức RE như trên vào bản ghi NAPTR, ứng dụng có thể lấy được mã trả về tùy theo đầu vào. VD nếu gọi số +84-4-81234567-123 thì áp dụng RE thu được từ bản ghi NAPTR nói trên ta sẽ thu được "mailto:123@company.com". Sở dĩ như vậy là vì biểu thức tìm kiếm đã ứng hợp với chuỗi đầu vào ("^84481234567") và đã nhóm chuỗi mở rộng "123" vào 1 nhóm được tham chiếu bởi "\1" ở biểu thức thay thế.
Trong thực tế, RE luôn được sử dụng để thể hiện các bản ghi ENUM, kể cả khi không có yêu cầu tổ hợp. Khi đó nó chỉ đóng vai trò như 1 khuôn dạng chung theo quy ước. Chẳng hạn các hệ thống cập nhật của nhà cung cấp có thể chỉ yêu cầu người sử dụng cập nhật nội dung đoạn mã kết quả, hệ thống sẽ tự định dạng theo dạng chuẩn chung và cập nhật hệ thống DNS tương ứng.
Định dạng hay sử dụng nhất là