Comments on protocol-04

Mark Davis mark.davis at icu-project.org
Mon Mar 3 20:00:18 CET 2008


Comments on Protocol-04

 The main issue is that I think the split between Rationale and
 Protocol is as yet incomplete. The Rationale should be all the
 background, history, and reason for changes, but not be normatively
referenced or
 required by the Protocol, Bidi, or Tables documents.


 Other comments below.


 >    those who have worked with Unicode or other character set standards
 >    and the DNS, appears in [IDNA200X-Rationale].  Terminology that is an
 >    integral, normative, part of the IDNA definition, including the
 >    definitions of "ACE", appears in that document as well.  Familiarity
 >    with the terminology materials in that document is assumed for
 >    reading this one.

 I think the documents would be much more accessible if the Rationale
 document was confined to reasons for why we are doing IDN200x,
 background, etc., and *not* be required for interpreting the protocol
 document. That is, the normative definitions of a few items like
 A-Label, U-Label, etc, should be moved here.

 ..


 >  4.3.1.  Rejection of Characters that are not Permitted
 >
 >    The Unicode string is examined to prohibit characters that IDNA does
 >    not permit in input.  Those characters are identified in the

 The wording is better in 5.4 ("checked to verify ...."), and should be
 used here.


 >    "DISALLOWED" and "UNASSIGNED" lists that are discussed in
 >    [IDNA200X-Rationale].  The normative rules for producing that list
 >    and the initial version of it are specified in [IDNA200X-Tables].
 >    Characters that are either DISALLOWED or UNASSIGNED MUST NOT be part
 >    of labels being processed for registration in the DNS.
 >
 >  4.3.2.  Label Validation
 >
 >    The proposed label is then examined, performing tests that require
 >    examination of more than one character.
 >
 >  4.3.2.1.  Leading Combining Marks
 >
 >    The first character of the string is examined to verify that it is
 >    not a combining mark.  If it is a combining mark, the string MUST NOT
 >    be registered.
 >
 >  4.3.2.2.  Contextual Rules
 >
 >    Each code point is checked for its identification as characters for
 >    registration (the list of characters appears as the combination of
 >    CONTEXTJ and CONTEXTO in [IDNA200X-Tables]).  If that indication
 >    appears, the table of contextual rules is checked for a rule for that
 >    character.  If no rule is found, the proposed label is rejected and
 >    MUST NOT be installed in a zone file.  If one is found, it is applied
 >    (typically as a test on the entire label or on adjacent characters).
 >    If the application of the rule does not conclude that the character
 >    is valid in context, the proposed label MUST BE rejected.  (See the
 >    IANA Considerations: IDNA Context Registry section of
 >    [IDNA200X-Rationale].)

 The table should not be described in the Rationale document. It should be here.



 >
 >  4.3.2.3.  Labels Containing Characters Written Right to Left
 >
 >    Additional special tests for right-to-left strings are applied (See
 >    [IDNA200X-BIDI].  Strings that contain right to left characters that
 >    do not conform to the rule identified there MUST NOT be inserted in
 >    zone files.
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                 [Page 7]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >  4.3.3.  Registration Validation Summary
 >
 >    Strings that have been produced by the steps above, and whose
 >    contents pass the above tests, are U-labels.
 >
 >    To summarize, tests are made here for invalid characters, invalid
 >    combinations of characters, and for labels that are invalid even if
 >    the characters they contain are valid individually.  For example,
 >    labels containing invisible ("zero-width") characters may be
 >    permitted in context with characters whose presentation forms are
 >    significantly changed by the presence or absence of the zero-width
 >    characters, while other labels in which zero-width characters appear
 >    may be rejected.
 >
 >  4.4.  Registry Restrictions
 >
 >    Registries at all levels of the DNS, not just the top level, are
 >    expected to establish policies about the labels that may be
 >    registered, and for the processes associated with that action.  While
 >    exact policies are not specified as part of IDNA200X and it is
 >    expected that different registries may specify different policies,
 >    there SHOULD be policies.  These per-registry policies and
 >    restrictions are an essential element of the IDNA registration
 >    protocol even for registries (and corresponding zone files) deep in
 >    the DNS hierarchy.  As discussed in [IDNA200X-Rationale], such
 >    restrictions have always existed in the DNS.
 >
 >    The string produced by the above steps is checked and processed as
 >    appropriate to local registry restrictions.  Application of those
 >    registry restrictions may result in the rejection of some labels or
 >    the application of special restrictions to others.
 >
 >  4.5.  Punycode Conversion
 >
 >    The resulting U-label is converted to an A-label (i.e., the encoding
 >    of that label according to the Punycode algorithm [RFC3492] with the
 >    prefix included, i.e., the "xn--..." form).
 >
 >  4.6.  Insertion in the Zone
 >
 >    The A-label is registered in the DNS by insertion into a zone.
 >
 >
 >  5.  Domain Name Resolution (Lookup) Protocol
 >
 >    Resolution is conceptually different from registration and different
 >    tests are applied on the client.  Although some validity checks are
 >    necessary to avoid serious problems with the protocol (see
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                 [Page 8]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    Section 5.4 ff.), the resolution-side tests are more permissive and
 >    rely heavily on the assumption that names that are present in the DNS
 >    are valid.  Among other things, this distinction, applied carefully,
 >    facilitates expansion of the permitted character lists to include new
 >    scripts and accommodate new versions of Unicode without introducing
 >    ambiguity into domain name processing.
 >
 >  5.1.  Label String Input
 >
 >    The user supplies a string in the local character set, typically by
 >    typing it or clicking on, or copying and pasting, a resource
 >    identifier, e.g., a URI [RFC3986] or IRI [RFC3987] from which the
 >    domain name is extracted.  Or some process not directly involving the
 >    user may read the string from a file or obtain it in some other way.
 >    Processing in this step and the next two are local matters, to be
 >    accomplished prior to actual invocation of IDNA, but at least this
 >    one and the next one must be accomplished in some way.
 >
 >  5.2.  Conversion to Unicode
 >
 >    The local character set, character coding conventions, and, as
 >    necessary, display and presentation conventions, are converted to
 >    Unicode (without surrogates), paralleling the process described above

 People are going to find this confusing. It is quite common to use
 UTF-16 as the internal form of Unicode for processing -- probably more
 common than UTF-8. UTF-16 does *and must* use surrogate code units in
 order to represent supplementary code points. So remove "(without
 surrogates)". It is not necessary, since isolated surrogate code
 points are detected and disallowed by the Tables document.


 >    in Section 4.2.
 >
 >  5.3.  Character Changes in Preprocessing or the User Interface
 >
 >    The Unicode string MAY then be processed, in a way specific to the
 >    local environment, to make the result of the IDNA processing match
 >    user expectations.  For instance, at this step, it would be
 >    reasonable to convert all upper case characters to lower case, if
 >    this makes sense in the user's environment.
 >
 >    Other examples of processing for localization that might be applied,
 >    if appropriate, at this point (but even further outside the scope of
 >    this specification) include interpreting the KANA MIDDLE DOT as

 Bad example. Since the Middle dot is allowed currently, it cannot be
 treated as a separator.


 >    separating domain name components from each other, mapping different
 >    "width" forms of the same character into the one form permitted in
 >    labels, or giving special treatment to characters whose presentation
 >    forms are dependent only on placement in the label.
 >
 >    Recommendations for preprocessing for global contexts (i.e., when
 >    local considerations do not apply or cannot be used) and for maximum
 >    interoperability with labels that might have been specified under
 >    liberal readings of IDNA2003 are given in [IDNA200X-Rationale].

 Customized preprocessing is very bad idea for interoperability, as
 discussed elsewhere. We should not be encouraging it here or in


Rationale.

 >
 >    Because these transformations are local, it is important that domain
 >    names that might be passed between systems (e.g., in IRIs) be
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                 [Page 9]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    U-labels or A-labels and not forms that might be accepted locally as
 >    a consequence of this step.  This step is not standardized as part of
 >    IDNA, and is not further specified here.
 >
 >  5.4.  Validation and Character List Testing
 >
 >    In parallel with the registration procedure, the Unicode string is
 >    checked to verify that all characters that appear in it are valid for
 >    IDNA resolution input.  As discussed in [IDNA200X-Rationale], the
 >    resolution check is more liberal than that of the registration one.
 >    Putative labels with any of the following characteristics MUST BE
 >    rejected prior to DNS lookup:
 >
 >    o  Labels containing code points that are unassigned in the version
 >       of Unicode being used by the application, i.e., in the
 >       "Unassigned" Unicode category or the UNASSIGNED category of
 >       [IDNA200X-Tables].
 >
 >    o  Labels that are not in NFC form.
 >
 >    o  Labels containing prohibited code points, i.e., those that are
 >       assigned to the "DISALLOWED" category in the permitted character
 >       table [IDNA200X-Tables].
 >
 >    o  Labels containing code points that are shown in the permitted
 >       character table as requiring a contextual rule and that are
 >       flagged as requiring exceptional special processing on lookup
 >       ("CONTEXTJ" in the Tables) MUST conform to the rule, which MUST be
 >       present.
 >
 >    o  Labels containing other code points that are shown in the
 >       permitted character table as requiring a contextual rule
 >       ("CONTEXTO" in the tables), but for which no such rule appears in
 >       the table of rules.  With the exception in the rule immediately
 >       above, applications resolving DNS names or carrying out equivalent
 >       operations are not required to test contextual rules, only to
 >       verify that a rule exists.
 >
 >    o  Labels whose first character is a combining mark. [[anchor15: Note
 >       in Draft: this definition may need to be further tightened.]]
 >
 >    In addition, the application SHOULD apply the following test.  The
 >    test may be omitted in special circumstances, such as when the
 >    resolver application knows that the conditions are enforced
 >    elsewhere, because an attempt to resolve such strings will almost
 >    certainly lead to a DNS lookup failure.  However, applying the test
 >    is likely to give much better information about the reason for a
 >    lookup failure -- information that may be usefully passed to the user
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 10]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    when that is feasible -- then DNS resolution failure alone.
 >
 >    o  Verification that the string is compliant with the requirements
 >       for right to left characters, specified in [IDNA200X-BIDI].

 This is the only remaining SHOULD test. Given that the test is now
 relatively straightforward -- and helps avoid visual ambiguity
 problems on the front end, I think this should be a MUST.



 >
 >    For all other strings, the resolver MUST rely on the presence or
 >    absence of labels in the DNS to determine the validity of those
 >    labels and the validity of the characters they contain.  If they are
 >    registered, they are presumed to be valid; if they are not, their
 >    possible validity is not relevant.  A resolver that declines to look
 >    up a string that conforms to the above rules is not in conformance
 >    with this protocol.
 >
 >  5.5.  Punycode Conversion
 >
 >    The validated string, a U-label, is converted to an A-label using the
 >    punycode algorithm.
 >
 >  5.6.  DNS Name Resolution
 >
 >    The A-label is looked up in the DNS, using normal DNS procedures.
 >
 >
 >  6.  Name server Considerations
 >
 >  6.1.  Processing Non-ASCII Strings
 >
 >    Existing DNS servers do not know the IDNA rules for handling non-
 >    ASCII forms of IDNs, and therefore need to be shielded from them.
 >    All existing channels through which names can enter a DNS server
 >    database (for example, master files (as described in RFC 1034) and
 >    DNS update messages [RFC2136]) are IDN-unaware because they predate
 >    IDNA.  Other sections of this document provide the needed shielding
 >    by ensuring that internationalized domain names entering DNS server
 >    databases through such channels have already been converted to their
 >    equivalent ASCII A-label forms.
 >
 >    Because of the design of the algorithms in Section 4 and Section 5 (a
 >    domain name containing only ASCII codepoints can not be converted to
 >    an A-label), there can not be more than one label for each domain
 >    name.
 >
 >    The current definition of the DNS protocol [RFC2181] explicitly
 >    allows domain labels to contain octets beyond the ASCII range
 >    (0000..007F), and this document does not change that.  Note, however,
 >    that there is no defined interpretation of octets 0080..00FF as
 >    characters.  If labels containing these octets are returned to
 >    applications, unpredictable behavior could result.  The A-label form,
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 11]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    which cannot contain those characters, is the only standard
 >    representation for internationalized labels in the current DNS
 >    protocol.
 >
 >  6.2.  DNSSEC Authentication of IDN Domain Names
 >
 >    DNS Security [RFC2535] is a method for supplying cryptographic
 >    verification information along with DNS messages.  Public Key
 >    Cryptography is used in conjunction with digital signatures to
 >    provide a means for a requester of domain information to authenticate
 >    the source of the data.  This ensures that it can be traced back to a
 >    trusted source, either directly or via a chain of trust linking the
 >    source of the information to the top of the DNS hierarchy.
 >
 >    IDNA specifies that all internationalized domain names served by DNS
 >    servers that cannot be represented directly in ASCII must use the
 >    A-label form.  Conversion to A-labels must be performed prior to a
 >    zone being signed by the private key for that zone.  Because of this
 >    ordering, it is important to recognize that DNSSEC authenticates a
 >    domain name containing A-labels or conventional LDH-labels, not
 >    U-labels.  In the presence of DNSSEC, no form of a zone file or query
 >    response that contains a U-label may be signed or validated against.
 >
 >    One consequence of this for sites deploying IDNA in the presence of
 >    DNSSEC is that any special purpose proxies or forwarders used to
 >    transform user input into IDNs must be earlier in the resolution flow
 >    than DNSSEC authenticating nameservers for DNSSEC to work.
 >
 >  6.3.  Root Server Considerations
 >
 >    IDNs are likely to be somewhat longer than current domain names, so
 >    the bandwidth needed by the root servers is likely to go up by a
 >    small amount.  Also, queries and responses for IDNs will probably be
 >    somewhat longer than typical queries today, so more queries and
 >    responses may be forced to go to TCP instead of UDP.
 >
 >
 >  7.  Security Considerations
 >
 >    The general security principles and issues for IDNA appear in
 >    [IDNA200X-Rationale].  The comments below are specific to this pair
 >    of protocols, but should be read in the context of that material and
 >    the definitions and specifications, identified there, on which this
 >    one depends.
 >
 >    This memo describes procedures for registering and looking up labels
 >    that are not valid according to the base DNS specifications (STD13
 >    [RFC1034] [RFC1035] and Host Requirements [RFC1123]) because they
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 12]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    contain non-ASCII characters.  Those procedures depends on the use of
 >    a special ACE encoded form, with the encoding specified in [RFC3492],
 >    that contains only characters permitted in host names by those
 >    specifications.  No security issues such as string length increases
 >    or new allowed values are introduced by the encoding process or the
 >    use of these encoded values, apart from those introduced by the ACE
 >    encoding itself.
 >
 >    Domain names (or portions of them) are sometimes compared against a
 >    set of privileged or anti-privileged domains.  In such situations it
 >    is especially important that the comparisons be done properly, as
 >    specified in requirement 2 of Section 3.1.  For labels already in
 >    ASCII form (i.e., are LDH-labels or A-labels), the proper comparison
 >    reduces to the same case-insensitive ASCII comparison that has always
 >    been used for ASCII labels.
 >
 >    The introduction of IDNA means that any existing labels that start
 >    with the ACE prefix would be construed as U-labels, at least until
 >    they failed one of the relevant tests, whether or not that was the
 >    intent of the zone administrator or registrant.  There is no evidence
 >    that this has caused any practical problems since RFC 3490 was
 >    adopted, but the risk still exists in principle.
 >
 >
 >  8.  IANA Considerations
 >
 >    IANA actions for this version of IDNA are specified in
 >    [IDNA200X-Rationale].
 >
 >
 >  9.  Change Log
 >
 >    [[anchor22: RFC Editor: Please remove this section.]]
 >
 >  9.1.  Version -00
 >
 >    Version -00 of this draft was produced in November 2007 by moving
 >    text from draft-klensin-idnabis-issues and by copy considerable text
 >    from RFC 3490.  The result was then extensively edited.
 >
 >  9.2.  Versions -01 and -02
 >
 >    These versions reflected a number of editorial changes, some of them
 >    significant, and alignment of terminology with
 >    draft-faltstrom-idnabis-tables.
 >
 >
 >
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 13]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >  9.3.  Version -03
 >
 >    o  Abstract rewritten to bring its length within RFC Editor
 >       guidelines.
 >
 >    o  Corrections and revisions in response to extensive comments by
 >       Mark Davis and others.
 >
 >    o  Small modifications to several operations, including moving the
 >       Normalization steps to a different place in the sequence.
 >
 >    o  Many editorial changes.
 >
 >  9.4.  Version -04
 >
 >    o  Revised terminology and removed the MAYBE category as a
 >       consequence of design discussions on 30 January 2003 and followup
 >       conversations.  Also restructed the various operations to treat
 >       CONTEXTUAL RULE REQUIRED as a validation step (paralleling bidi),
 >       rather than a category.  Those changes required changes elsewhere
 >       in the document for consistency.
 >
 >    o  Changed the requirements for normalization, making this a
 >       requirement on the calling application rather than an action of
 >       this protocol.  This is consistent with the general "mappings
 >       belong somewhere else" principle.
 >
 >    o  Updated references.
 >
 >    o  More editorial work, some independent of the changes, described
 >       immediately above.
 >
 >
 >  10.  Contributors
 >
 >    While the listed editor held the pen, this document represents the
 >    joint work and conclusions of an ad hoc design team consisting of the
 >    editor and, in alphabetic order, Harald Alvestrand, Tina Dam, Patrik
 >    Faltstrom, and Cary Karp.  This document draws significantly on the
 >    original version of IDNA [RFC3490] both conceptually and for specific
 >    text.  This second-generation version would not have been possible
 >    without the work that went into that first version and its authors,
 >    Patrik Faltstrom, Paul Hoffman, and Adam Costello.  While Faltstrom
 >    was actively involved in the creation of this version, Hoffman and
 >    Costello were not and should not be held responsible for any errors
 >    or omissions.
 >
 >
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 14]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >  11.  Acknowledgements
 >
 >    This revision to IDNA would have been impossible without the
 >    accumulated experience since RFC 3490 was published and resulting
 >    comments and complaints of many people in the IETF, ICANN, and other
 >    communities, too many people to list here.  Nor would it have been
 >    possible without RFC 3490 itself and the efforts of the Working Group
 >    that defined it.  Those people whose contributions are acknowledged
 >    in RFC 3490, [RFC4690], and [IDNA200X-Rationale] were particularly
 >    important.
 >
 >
 >  12.  References
 >
 >  12.1.  Normative References
 >
 >    [IDNA200X-BIDI]
 >               Alvestrand, H. and C. Karp, "An updated IDNA criterion for
 >               right-to-left scripts", January 2008, <http://
 >               www.ietf.org/internet-drafts/
 >               draft-alvestrand-idna-bidi-03.txt>.
 >
 >    [IDNA200X-Rationale]
 >               Klensin, J., Ed., "Internationalizing Domain Names for
 >               Applications (IDNA): Issues, Explanation, and Rationale",
 >               February 2008, <http://www.ietf.org/internet-drafts/
 >               draft-klensin-idnabis-issues-06.txt>.
 >
 >    [IDNA200X-Tables]
 >               Faltstrom, P., "The Unicode Codepoints and IDN",
 >               February 2008, <http://stupid.domain.name/idnabis/
 >               draft-faltstrom-idnabis-tables-04.txt>.
 >
 >               A version of this document, is available in HTML format at
 >               http://stupid.domain.name/idnabis/
 >               draft-faltstrom-idnabis-tables-04.html
 >
 >    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
 >               STD 13, RFC 1034, November 1987.
 >
 >    [RFC1035]  Mockapetris, P., "Domain names - implementation and
 >               specification", STD 13, RFC 1035, November 1987.
 >
 >    [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
 >               and Support", STD 3, RFC 1123, October 1989.
 >
 >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 >               Requirement Levels", BCP 14, RFC 2119, March 1997.
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 15]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >    [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
 >               for Internationalized Domain Names in Applications
 >               (IDNA)", RFC 3492, March 2003.
 >
 >    [Unicode-UAX15]
 >               The Unicode Consortium, "Unicode Standard Annex #15:
 >               Unicode Normalization Forms", 2006,
 >               <http://www.unicode.org/reports/tr15/>.
 >
 >  12.2.  Informative References
 >
 >    [ASCII]    American National Standards Institute (formerly United
 >               States of America Standards Institute), "USA Code for
 >               Information Interchange", ANSI X3.4-1968, 1968.
 >
 >               ANSI X3.4-1968 has been replaced by newer versions with
 >               slight modifications, but the 1968 version remains
 >               definitive for the Internet.
 >
 >    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
 >               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
 >               RFC 2136, April 1997.
 >
 >    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
 >               Specification", RFC 2181, July 1997.
 >
 >    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
 >               RFC 2535, March 1999.
 >
 >    [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
 >               "Internationalizing Domain Names in Applications (IDNA)",
 >               RFC 3490, March 2003.
 >
 >    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
 >               Resource Identifier (URI): Generic Syntax", STD 66,
 >               RFC 3986, January 2005.
 >
 >    [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
 >               Identifiers (IRIs)", RFC 3987, January 2005.
 >
 >    [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
 >               Recommendations for Internationalized Domain Names
 >               (IDNs)", RFC 4690, September 2006.
 >
 >    [RFC4952]  Klensin, J. and Y. Ko, "Overview and Framework for
 >               Internationalized Email", RFC 4952, July 2007.
 >
 >    [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 16]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >               5.0", 2007.
 >
 >               Boston, MA, USA: Addison-Wesley.  ISBN 0-321-48091-0
 >
 >
 >  Author's Address
 >
 >    John C Klensin (editor)
 >    1770 Massachusetts Ave, Ste 322
 >    Cambridge, MA  02140
 >    USA
 >
 >    Phone: +1 617 245 1457
 >    Fax:
 >    Email: john+ietf at jck.com
 >    URI:
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 17]
 >
 >  Internet-Draft              IDNA200X Protocol              February 2008
 >
 >
 >  Full Copyright Statement
 >
 >    Copyright (C) The IETF Trust (2008).
 >
 >    This document is subject to the rights, licenses and restrictions
 >    contained in BCP 78, and except as set forth therein, the authors
 >    retain all their rights.
 >
 >    This document and the information contained herein are provided on an
 >    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 >    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 >    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 >    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 >    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 >    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 >
 >
 >  Intellectual Property
 >
 >    The IETF takes no position regarding the validity or scope of any
 >    Intellectual Property Rights or other rights that might be claimed to
 >    pertain to the implementation or use of the technology described in
 >    this document or the extent to which any license under such rights
 >    might or might not be available; nor does it represent that it has
 >    made any independent effort to identify any such rights.  Information
 >    on the procedures with respect to rights in RFC documents can be
 >    found in BCP 78 and BCP 79.
 >
 >    Copies of IPR disclosures made to the IETF Secretariat and any
 >    assurances of licenses to be made available, or the result of an
 >    attempt made to obtain a general license or permission for the use of
 >    such proprietary rights by implementers or users of this
 >    specification can be obtained from the IETF on-line IPR repository at
 >    http://www.ietf.org/ipr.
 >
 >    The IETF invites any interested party to bring to its attention any
 >    copyrights, patents or patent applications, or other proprietary
 >    rights that may cover technology that may be required to implement
 >    this standard.  Please address the information to the IETF at
 >    ietf-ipr at ietf.org.
 >
 >
 >  Acknowledgment
 >
 >    Funding for the RFC Editor function is provided by the IETF
 >    Administrative Support Activity (IASA).
 >
 >
 >
 >
 >
 >  Klensin                  Expires August 9, 2008                [Page 18]
 >
 >
 >
 >
 >  --
 >  Mark
 >



 --
 Mark



-- 
Mark


More information about the Idna-update mailing list