W3C home > Mailing lists > Public > www-tag@w3.org > April 2015

Fwd: WG Action: Formed Domain Boundaries (dbound)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 28 Apr 2015 16:52:11 +1000
To: "www-tag@w3.org List" <www-tag@w3.org>
Message-Id: <EE5105D5-B512-4892-92FB-D770656D8AC8@mnot.net>
FYI - this seems potentially relevant to folks here. In a nutshell, it's "What's after the Public Suffix List?"

Cheers,


> Begin forwarded message:
> 
> From: The IESG <iesg-secretary@ietf.org>
> Subject: WG Action: Formed Domain Boundaries (dbound)
> Date: 11 April 2015 2:26:32 am AEST
> To: "IETF-Announce" <ietf-announce@ietf.org>
> Cc: dbound WG <dbound@ietf.org>
> Reply-To: ietf@ietf.org
> Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-announce/0Fk6DhobDBZW58yRSciM44F3pqA>
> 
> A new IETF working group has been formed in the Applications Area. For
> additional information please contact the Area Directors or the WG
> Chairs.
> 
> Domain Boundaries (dbound)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Chairs:
>  Pete Resnick <presnick@qti.qualcomm.com>
>  Murray Kucherawy <superuser@gmail.com>
> 
> Assigned Area Director:
>  Barry Leiba <barryleiba@computer.org>
> 
> Mailing list
>  Address: dbound@ietf.org
>  To Subscribe: http://www.ietf.org/mailman/listinfo/dbound
>  Archive: http://www.ietf.org/mail-archive/web/dbound
> 
> Charter:
> 
> Various Internet protocols and applications require some mechanism for
> determining whether two domain names are related. The meaning of
> "related" in this context is not a unitary concept. The DBOUND working
> group will develop one or more solutions to this family of problems,
> and will clarify the types of relations relevant.
> 
> For example, it is often necessary or useful to determine whether
> example.com and foo.example.com, or even example.net, are subject to
> the same administrative control. To humans, the answer to this may be
> obvious. However, the Domain Name System (DNS), which is the service
> that handles domain name queries, does not provide the ability to mark
> these sorts of relationships. This makes it impossible to discern
> relationships algorithmically. The right answer is not always "compare
> the rightmost two labels".
> 
> Applications and organizations impose policies and procedures that
> create additional structure in their use of domain names. This creates
> many possible relationships that are not evident in the names
> themselves or in the operational, public representation of the names.
> 
> Prior solutions for identifying relationships between domain names have
> sought to use the DNS namespace and protocol to extract that information
> when it isn't actually there.  See the "Additional Background
> Information" section of the working group wiki for more details:
> https://trac.tools.ietf.org/wg/dbound/trac/wiki/AdditionalBackgroundInformation
> 
> For the purpose of this work, "domain names" are identifiers used by
> organizations and services, independent of underlying protocols or
> mechanisms, and an "organizational domain" is defined as a name that
> is at the top of an administrative hierarchy, defining transition from 
> one "outside" administrative authority to another that is "inside" the
> organization.
> 
> The current way most of this is handled is via a list published at
> publicsuffix.org (commonly known as the "Public Suffix List" or "PSL"),
> and the general goal is to accommodate anything people are
> using that for today.  However, there are broadly speaking two use
> patterns. The first is a "top ancestor organization" case. In this case,
> the goal is to find a single superordinate name in the DNS tree that can
> properly make assertions about the policies and procedures of 
> subordinate names. The second is to determine, given two different 
> names, whether they are governed by the same administrative authority. 
> The goal of the DBOUND working group is to develop a unified solution, 
> if possible, for determining organizational domain boundaries. However, 
> the working group may discover that the use cases require different 
> solutions. Should that happen, the working group will develop those 
> different solutions, using as many common pieces as it can.
> 
> Solutions will not involve the proposal of any changes to the DNS
> protocol.  They might involve the creation of new resource record types.
> 
> This working group will not seek to amend the consuming protocols
> themselves (standards for any web, email, or other such protocols) under
> this charter.  If such work is desirable, it will be assigned to another
> appropriate working group or defined as a work item in an updated 
> charter. Rechartering will only be considered after completion of the 
> base work.
> 
> The working group has a pre-IETF draft to consider as a possible
> starting point: draft-sullivan-dbound-problem-statement
> 
> Milestones:
> 
> TBD
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 28 April 2015 06:52:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:11 UTC