- 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>
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