idnits 2.17.1 draft-ietf-appsawg-media-type-suffix-regs-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3023, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3023, updated by this document, for RFC5378 checks: 1999-09-24) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2012) is 4189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen 3 Internet-Draft AT&T Laboratories 4 Updates: 3023 (if approved) A. Melnikov 5 Intended status: Informational Isode Ltd 6 Expires: May 9, 2013 November 5, 2012 8 Additional Media Type Structured Syntax Suffixes 9 draft-ietf-appsawg-media-type-suffix-regs-08 11 Abstract 13 A content media type name sometimes includes partitioned meta- 14 information distinguish by a Structured Syntax, to permit noting an 15 attribute of the media as a suffix to the name. This document 16 defines several Structured Syntax Suffixes for use with media type 17 registrations. In particular, it defines and registers the "+json", 18 "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax 19 Suffixes, and provides a Message Type Structured Syntax Suffix 20 registration form for the "+xml" Structured Syntax Suffix. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 9, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. When to Use these Structured Syntax Suffixes . . . . . . . . . 3 58 3. Initial Structured Syntax Suffix Definitions . . . . . . . . . 4 59 3.1. The +json Structured Syntax Suffix . . . . . . . . . . . . 4 60 3.2. The +ber Structured Syntax Suffixes . . . . . . . . . . . 5 61 3.3. The +der Structured Syntax Suffixes . . . . . . . . . . . 6 62 3.4. The +fastinfoset Structured Syntax Suffix . . . . . . . . 8 63 3.5. The +wbxml Structured Syntax Suffix . . . . . . . . . . . 9 64 3.6. The +zip Structured Syntax Suffix . . . . . . . . . . . . 10 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 [RFC3023] created the +xml suffix convention that can be used when 76 defining names for media types whose representation uses XML 77 underneath. That is, they could have been successfully parsed as if 78 the media type had been application/xml in addition to their being 79 parsed as their media type that is using the +xml suffix. 80 [I-D.ietf-appsawg-media-type-regs] defines the Message Type 81 Structured Syntax Suffixes registry to be used for such Structured 82 Syntax Suffixes. 84 A variety of Structured Syntax Suffixes have already been used in 85 some media type registrations, in particular "+json", "+der", 86 "+fastinfoset" and "+wbxml". This document defines and registers 87 these Structured Syntax Suffixes in the Structured Syntax Suffix 88 registry, along with "+ber" and "+zip". In addition, this document 89 updates [RFC3023] to formally register the "+xml" Structured Syntax 90 Suffix according to procedure defined in 91 [I-D.ietf-appsawg-media-type-regs]. 93 Discussion of this document should occur in the Apps Area Working 94 Group (apps-discuss@ietf.org). [RFC Editor note: remove this 95 paragraph.] 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. When to Use these Structured Syntax Suffixes 103 Each of the Structured Syntax Suffixes defined in this document is 104 appropriate for use when the media type identifies the semantics of 105 the protocol payload. That is, knowing the semantics of the specific 106 media type provides for more specific processing of the content than 107 that afforded by generic processing of the underlying representation. 109 At the same time, using the suffix allows receivers of the media 110 types to do generic processing of the underlying representation in 111 cases where 113 they do not need to perform special handling of the particular 114 semantics of the exact media type, and, 116 there is no special knowledge needed by such a generic processor 117 in order to parse that underlying representation other than what 118 would be needed to parse any example of that underlying 119 representation. 121 3. Initial Structured Syntax Suffix Definitions 123 3.1. The +json Structured Syntax Suffix 125 [RFC4627] defines the "application/json" media type. The suffix 126 "+json" MAY be used with any media type whose representation follows 127 that established for "application/json". The Message Type Structured 128 Syntax Suffix registration form follows. See 129 [I-D.ietf-appsawg-media-type-regs] for definitions of each of the 130 registration form headings. 132 Name: JavaScript Object Notation (JSON) 134 +suffix: +json 136 References: [RFC4627] 138 Encoding considerations: Per [RFC4627], JSON is allowed to be 139 represented using UTF-8, UTF-16, or UTF-32. When 140 JSON is written in UTF-8, JSON is 8bit compatible 141 ([RFC2045]). When JSON is written in UTF-16 or 142 UTF-32, JSON is binary ([RFC2045]). 144 Fragment identifier considerations: 146 The syntax and semantics of fragment 147 identifiers specified for +json SHOULD be as 148 specified for "application/json". (At 149 publication of this document, there is no 150 fragment identification syntax defined for 151 "application/json".) 153 The syntax and semantics for fragment 154 identifiers for a specific "xxx/yyy+json" 155 SHOULD be processed as follows: 157 For cases defined in +json, where the 158 fragment identifier resolves per the +json 159 rules, then as specified in +json. 161 For cases defined in +json, where the 162 fragment identifier does not resolve per 163 the +json rules, then as specified in "xxx/ 164 yyy+json". 166 For cases not defined in +json, then as 167 specified in "xxx/yyy+json". 169 Interoperability considerations: n/a 171 Security considerations: See [RFC4627] 173 Contact: Apps Area Working Group (apps-discuss@ietf.org) 175 Author/Change controller: The Apps Area Working Group. IESG has 176 change control over this registration. 178 3.2. The +ber Structured Syntax Suffixes 180 The ITU defined the Basic Encoding Rules (BER) message transfer 181 syntax in [ITU.X690.2008]. The suffix "+ber" MAY be used with any 182 media type whose representation follows the BER message transfer 183 syntax. (The expert reviewer for Message Type Structured Syntax 184 Suffix registrations ought to be aware of the relationship between 185 BER and DER to aid in selecting the proper suffix.) The Message Type 186 Structured Syntax Suffix registration form for +ber follows: 188 Name: Basic Encoding Rules (BER) message transfer 189 syntax 191 +suffix: +ber 193 References: [ITU.X690.2008] 195 Encoding considerations: BER is a binary encoding. 197 Fragment identifier considerations: 199 At publication of this document, there is no 200 fragment identification syntax defined for 201 +ber. 203 The syntax and semantics for fragment 204 identifiers for a specific "xxx/yyy+ber" 205 SHOULD be processed as follows: 207 For cases defined in +ber, where the 208 fragment identifier resolves per the +ber 209 rules, then as specified in +ber. 211 For cases defined in +ber, where the 212 fragment identifier does not resolve per 213 the +ber rules, then as specified in "xxx/ 214 yyy+ber". 216 For cases not defined in +ber, then as 217 specified in "xxx/yyy+ber". 219 Interoperability considerations: n/a 221 Security considerations: Each individual media type registered with 222 a +ber suffix can have additional security 223 considerations. 225 BER has a type-length-value structure, and it is 226 easy to construct malicious content with invalid 227 length fields that can cause buffer overrun 228 conditions. 230 BER allows for arbitrary levels of nesting, which 231 may make it possible to construct malicious 232 content that will cause a stack overflow. 234 Interpreters of the BER structures should be 235 aware of these issues and should take appropriate 236 measures to guard against buffer overflows and 237 stack overruns in particular and malicious 238 content in general. 240 Contact: Apps Area Working Group (apps-discuss@ietf.org) 242 Author/Change controller: The Apps Area Working Group. IESG has 243 change control over this registration. 245 3.3. The +der Structured Syntax Suffixes 247 The ITU defined the Distinguished Encoding Rules (DER) message 248 transfer syntax in [ITU.X690.2008]. The suffix "+der" MAY be used 249 with any media type whose representation follows the DER message 250 transfer syntax. (The expert reviewer for Message Type Structured 251 Syntax Suffix registrations ought to be aware of the relationship 252 between BER and DER to aid in selecting the proper suffix.) The 253 Message Type Structured Syntax Suffix registration form for +der 254 follows: 256 Name: Distinguished Encoding Rules (DER) message 257 transfer syntax 259 +suffix: +der 261 References: [ITU.X690.2008] 263 Encoding considerations: DER is a binary encoding. 265 Fragment identifier considerations: 267 At publication of this document, there is no 268 fragment identification syntax defined for 269 +der. 271 The syntax and semantics for fragment 272 identifiers for a specific "xxx/yyy+der" 273 SHOULD be processed as follows: 275 For cases defined in +der, where the 276 fragment identifier resolves per the +der 277 rules, then as specified in +der. 279 For cases defined in +der, where the 280 fragment identifier does not resolve per 281 the +der rules, then as specified in "xxx/ 282 yyy+der". 284 For cases not defined in +der, then as 285 specified in "xxx/yyy+der". 287 Interoperability considerations: n/a 289 Security considerations: Each individual media type registered with 290 a +der suffix can have additional security 291 considerations. 293 DER has a type-length-value structure, and it is 294 easy to construct malicious content with invalid 295 length fields that can cause buffer overrun 296 conditions. 298 DER allows for arbitrary levels of nesting, which 299 may make it possible to construct malicious 300 content that will cause a stack overflow. 302 Interpreters of the DER structures should be 303 aware of these issues and should take appropriate 304 measures to guard against buffer overflows and 305 stack overruns in particular and malicious 306 content in general. 308 Contact: Apps Area Working Group (apps-discuss@ietf.org) 310 Author/Change controller: The Apps Area Working Group. IESG has 311 change control over this registration. 313 3.4. The +fastinfoset Structured Syntax Suffix 315 The ITU defined the Fast Infoset document format as a binary 316 representation of the XML Information Set in [ITU.X891.2005]. These 317 documents further define the "application/fastinfoset" media type. 318 The suffix "+fastinfoset" MAY be used with any media type whose 319 representation follows that established for "application/ 320 fastinfoset". The Message Type Structured Syntax Suffix registration 321 form follows: 323 Name: Fast Infoset document format 325 +suffix: +fastinfoset 327 References: [ITU.X891.2005] 329 Encoding considerations: Fast Infoset is a binary encoding. The 330 binary, quoted-printable and base64 content- 331 transfer-encodings are suitable for use with Fast 332 Infoset. 334 Fragment identifier considerations: 336 The syntax and semantics of fragment 337 identifiers specified for +fastinfoset SHOULD 338 be as specified for "application/fastinfoset". 339 (At publication of this document, there is no 340 fragment identification syntax defined for 341 "application/fastinfoset".) 343 The syntax and semantics for fragment 344 identifiers for a specific "xxx/ 345 yyy+fastinfoset" SHOULD be processed as 346 follows: 348 For cases defined in +fastinfoset, where 349 the fragment identifier resolves per the 350 +fastinfoset rules, then as specified in 351 +fastinfoset. 353 For cases defined in +fastinfoset, where 354 the fragment identifier does not resolve 355 per the +fastinfoset rules, then as 356 specified in "xxx/yyy+fastinfoset". 358 For cases not defined in +fastinfoset, then 359 as specified in "xxx/yyy+fastinfoset". 361 Interoperability considerations: n/a 363 Security considerations: There are no security considerations 364 inherent in Fast Infoset. Each individual media 365 type registered with a +fastinfoset suffix can 366 have additional security considerations. 368 Contact: Apps Area Working Group (apps-discuss@ietf.org) 370 Author/Change controller: The Apps Area Working Group. IESG has 371 change control over this registration. 373 3.5. The +wbxml Structured Syntax Suffix 375 The WAP Forum has defined the WAP Binary XML (WBXML) document format 376 as a binary representation of XML in [WBXML]. This document further 377 defines the "application/vnd.wap.wbxml" media type. The suffix 378 "+wbxml" MAY be used with any media type whose representation follows 379 that established for "application/vnd.wap.wbxml". The Message Type 380 Structured Syntax Suffix registration form follows: 382 Name: WAP Binary XML (WBXML) document format 384 +suffix: +wbxml 386 References: [WBXML] 388 Encoding considerations: WBXML is a binary encoding. 390 Fragment identifier considerations: 392 The syntax and semantics of fragment 393 identifiers specified for +wbxml SHOULD be as 394 specified for "application/vnd.wap.wbxml". 395 (At publication of this document, there is no 396 fragment identification syntax defined for 397 "application/vnd.wap.wbxml".) 399 The syntax and semantics for fragment 400 identifiers for a specific "xxx/yyy+wbxml" 401 SHOULD be processed as follows: 403 For cases defined in +wbxml, where the 404 fragment identifier resolves per the +wbxml 405 rules, then as specified in +wbxml. 407 For cases defined in +wbxml, where the 408 fragment identifier does not resolve per 409 the +wbxml rules, then as specified in 410 "xxx/yyy+wbxml". 412 For cases not defined in +wbxml, then as 413 specified in "xxx/yyy+wbxml". 415 Interoperability considerations: n/a 417 Security considerations: There are no security considerations 418 inherent in WBXML. Each individual media type 419 registered with a +wbxml suffix can have 420 additional security considerations. 422 Contact: Apps Area Working Group (apps-discuss@ietf.org) 424 Author/Change controller: The Apps Area Working Group. IESG has 425 change control over this registration. 427 3.6. The +zip Structured Syntax Suffix 429 The ZIP format is a public domain, cross-platform, interoperable file 430 storage and transfer format, originally defined by PKWARE, Inc.; it 431 supports compression and encryption and is used as the underlying 432 representation by a variety of file formats. The media type 433 "application/zip" has been registered for such files. The suffix 434 "+zip" MAY be used with any media type whose representation follows 435 that established for "application/zip". The Message Type Structured 436 Syntax Suffix registration form follows: 438 Name: ZIP file storage and transfer format 440 +suffix: +zip 441 References: [ZIP] 443 Encoding considerations: ZIP is a binary encoding. 445 Fragment identifier considerations: 447 The syntax and semantics of fragment 448 identifiers specified for +zip SHOULD be as 449 specified for "application/zip". (At 450 publication of this document, there is no 451 fragment identification syntax defined for 452 "application/zip".) 454 The syntax and semantics for fragment 455 identifiers for a specific "xxx/yyy+zip" 456 SHOULD be processed as follows: 458 For cases defined in +zip, where the 459 fragment identifier resolves per the +zip 460 rules, then as specified in +zip. 462 For cases defined in +zip, where the 463 fragment identifier does not resolve per 464 the +zip rules, then as specified in "xxx/ 465 yyy+zip". 467 For cases not defined in +zip, then as 468 specified in "xxx/yyy+zip". 470 Interoperability considerations: n/a 472 Security considerations: ZIP files support two forms of encryption: 473 Strong Encryption and AES 128-bit, 192-bit and 474 256-bit encryption; see the specification for 475 further details. Each individual media type 476 registered with a +zip suffix can have additional 477 security considerations. 479 Contact: Apps Area Working Group (apps-discuss@ietf.org) 481 Author/Change controller: The Apps Area Working Group. IESG has 482 change control over this registration. 484 4. IANA Considerations 486 See the Message Type Structured Syntax Suffix registration forms in 487 Section 3.1 - Section 3.6. 489 The following Structured Syntax Suffix registration for "+xml" shall 490 be used to reflect the information found in [RFC3023], with the 491 addition of fragment identifier considerations: 493 Name: Extensible Markup Language (XML) 495 +suffix: +xml 497 References: [RFC3023] 499 Encoding considerations: Per [RFC3023], XML is allowed to be 500 represented using both 7-bit and 8-bit encodings. 501 When XML is written in UTF-8, XML is 8bit 502 compatible ([RFC2045]). When XML is written in 503 UTF-16 or UTF-32, XML is binary ([RFC2045]). 505 Fragment identifier considerations: 507 The syntax and semantics of fragment 508 identifiers specified for +xml SHOULD be as 509 specified for "application/xml". (At 510 publication of this document, the fragment 511 identification syntax considerations for 512 "application/xml" are defined in [RFC3023], 513 sections 5 and 7.) 515 The syntax and semantics for fragment 516 identifiers for a specific "xxx/yyy+xml" 517 SHOULD be processed as follows: 519 For cases defined in +xml, where the 520 fragment identifier resolves per the +xml 521 rules, then as specified in +xml. 523 For cases defined in +xml, where the 524 fragment identifier does not resolve per 525 the +xml rules, then as specified in "xxx/ 526 yyy+xml". 528 For cases not defined in +xml, then as 529 specified in "xxx/yyy+xml". 531 Interoperability considerations: See [RFC3023]. 533 Security considerations: See [RFC3023] 534 Contact: Apps Area Working Group (apps-discuss@ietf.org) 536 Author/Change controller: The Apps Area Working Group. IESG has 537 change control over this registration. 539 5. Security Considerations 541 See the Security considerations sections found in the Message Type 542 Structured Syntax Suffix registration forms from Section 3.1 - 543 Section 3.5. 545 When updating a + registration, care should be taken to 546 review all previously-registered xxx/yyy+ media types as to 547 whether they might be affected by the updated + registration. 548 Because the generic fragment identifier processing rules take 549 precedence over media-type-specific rules, introducing new or 550 changing existing definitions may break the existing registrations of 551 specific media types, as well as particular implementations of 552 applications that process affected media types. Such changes can 553 introduce interoperability and security issues. 555 When updating the fragment identifier processing rules for a specific 556 xxx/yyy+ media type, care should be taken to review the 557 generic fragment identifier processing rules for the + 558 registration and not introduce any conflicts. Because the generic 559 fragment identifier processing rules take precedence over media-type- 560 specific rules, such conflicting processing requirements should be 561 ignored by an implementation, but such conflicts can introduce 562 interoperability and security issues. 564 Note that [FRAGID-BP] provides additional advice to designers of 565 fragment identifier rules for media type suffixes and specific media 566 types. 568 6. References 570 6.1. Normative References 572 [RFC4627] Crockford, D., "The application/json Media Type for 573 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 575 [ITU.X690.2008] 576 International Telecommunications Union, "Recommendation 577 ITU-T X.690 | ISO/IEC 8825-1 (2008), ASN.1 encoding rules: 578 Specification of basic encoding Rules (BER), Canonical 579 encoding rules (CER) and Distinguished encoding rules 580 (DER)", ITU-T Recommendation X.690, November 2008. 582 [ITU.X891.2005] 583 International Telecommunications Union, "Recommendation 584 ITU-T X.891 | ISO/IEC 24824-1 (2007), Generic applications 585 of ASN.1: Fast infoset", ITU-T Recommendation X.891, 586 May 2005. 588 [WBXML] Open Mobile Alliance, "Binary XML Content Format 589 Specification", OMA Wireless Access Protocol WAP-192- 590 WBXML-20010725-a, July 2001. 592 [ZIP] PKWARE, Inc., "APPNOTE.TXT - .ZIP File Format 593 Specification", PKWARE .ZIP File Format Specification - 594 Version 6.3.2, September 2007. 596 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 597 Extensions (MIME) Part One: Format of Internet Message 598 Bodies", RFC 2045, November 1996. 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 604 Types", RFC 3023, January 2001. 606 6.2. Informative References 608 [I-D.ietf-appsawg-media-type-regs] 609 Freed, N., Klensin, J., and T. Hansen, "Media Type 610 Specifications and Registration Procedures", 611 draft-ietf-appsawg-media-type-regs-14 (work in progress), 612 June 2012. 614 [FRAGID-BP] 615 Tennison, J., "Best Practices for Fragment Identifiers and 616 Media Type Definitions", July 2012, 617 . 619 Appendix A. Change History 621 This section is to be removed before publication. 623 draft-ietf-appsawg-media-type-suffix-regs-07 Added information based 624 on IANA and GEN-ART reviews. 626 draft-ietf-appsawg-media-type-suffix-regs-06 Clarified why this 627 document updates RFC 3023. 629 draft-ietf-appsawg-media-type-suffix-regs-05 Added an Informative 630 reference to 631 http://www.w3.org/TR/fragid-best-practices/. 632 Minor editorial changes. 634 draft-ietf-appsawg-media-type-suffix-regs-03 Added generic fragment 635 idenfier rules to +ber/+der to make them 636 consistant with other registrations. 637 Added some warning about how adding/changing 638 fragment identifier rules for a +suffix can 639 affect fragment identifier processing rules for 640 previously registered xxx/yyy+suffix media types. 642 draft-ietf-appsawg-media-type-suffix-regs-02 Added BER/DER security 643 considerations. 644 Reworked fragment identifier wording some more. 646 draft-ietf-appsawg-media-type-suffix-regs-01 Reordered the sections. 647 Cleaned up some MUSTard. 648 Fixed some references. 649 Added encoding considerations. 650 Reworked fragment identifier wording. 652 draft-ietf-appsawg-media-type-suffix-regs-00 Added the fragment 653 identifier consideration sections. 654 Added a note about +xml fragment identifier 655 considerations. 657 draft-hansen-media-type-suffix-regs-02 Added +zip. 658 Fixed up the ISO document references. 659 Minor changes. 661 draft-hansen-media-type-suffix-regs-01 Added +ber. 662 Minor changes. 664 Authors' Addresses 666 Tony Hansen 667 AT&T Laboratories 668 200 Laurel Ave. South 669 Middletown, NJ 07748 670 USA 672 Email: tony+sss@maillennium.att.com 674 Alexey Melnikov 675 Isode Ltd 676 5 Castle Business Village 677 36 Station Road 678 Hampton, Middlesex TW12 2BX 679 UK 681 Email: Alexey.Melnikov@isode.com