That's true, while we won't have the PSL in the algorithm, we will still be talking about PSDs, so the term will remain defined. OK, that makes sense, Scott; thanks.
Barry On Mon, Jun 27, 2022 at 9:46 AM Scott Kitterman <skl...@kitterman.com> wrote: > > If we use a different term, we'll need to define it. Fundamentally, I think > changing the name only adds a level of indirection (and thus complexity). > > Current: > > PSD (which is defined in the document) yes or no or use tree walk. > > Proposed: > > Role (needs a definition) PSD (defined), Org (defined as not a PSD), and > Subdomain (which isn't defined and is technically wrong - all three might be > subdomains). > > Whether you directly use psd as the tag or not, the question is still is it a > PSD or not. The suggested change doesn't do anything towards getting away > from PSD as a concept or a defined term. > > I think that by hiding it in the definitions, it will be more confusing, not > less. > > Scott K > > On June 27, 2022 1:27:37 PM UTC, Barry Leiba <barryle...@computer.org> wrote: > >I have to say, as a participant, that I have more than a little > >sympathy for this suggestion or some derivative of it. Using "psd" as > >the tag name is rooted in history that will be lost as we move away > >from using a public suffix list. > > > >Barry > > > >On Mon, Jun 27, 2022 at 6:20 AM Alessandro Vesely <ves...@tana.it> wrote: > >> > >> On Sun 26/Jun/2022 18:05:44 +0200 Barry Leiba wrote: > >> > > >> > Please comment in this thread about whether you agree with making the > >> > registration now, or whether you do not agree and why. > >> > >> > >> I'd like to make a last appeal to use more intuitive symbols to be used > >> instead > >> of the current ones: > >> > >> instead of | use | to mean > >> -----------+----------+----------------------------------------------------- > >> psd=u | role=sub | the default subdomain role (never needed) > >> psd=n | role=org | the org domain (only needed with non compliant > >> PSDs) > >> psd=y | role=psd | a PSD (needed if PSD published DMARC record.) > >> > >> > >> The reason to use cryptic symbols seems to be to discourage their usage, > >> which > >> I can hardly understand. I'd be OK with the current symbols if the WG can > >> explain somewhat better, possibly as part of the spec itself, the > >> rationale of > >> using counter-intuitive yes/ no/ undefined to express that three-valued > >> value. > >> > >> > >> Best > >> Ale > >> -- > >> > >> > >> > >> > >> > >> _______________________________________________ > >> dmarc mailing list > >> dmarc@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmarc > > > >_______________________________________________ > >dmarc mailing list > >dmarc@ietf.org > >https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
