[dconn] Re: do we really need warnPhishing?

[Pawel Kowalik <[e-mail]>]

Hi Peter,

On 19.03.26 14:09, Peter Thomassen wrote:
> Hi,
>
> (as a participant)
>
> On 3/16/26 00:28, Pawel Kowalik wrote:
>> Changing it to 2 state is a good simplification. I am wondering if 
>> making it explicit by leaving warnPhishing flag and saying either 
>> warnPhishing or syncPubKeyDomain or syncBlock MUST be set.
>>
>> This way providers who rely today on warnPhishing will keep working 
>> same way,
>
> I'm not sure what the alternative is ("will not keep working"?). Is it 
> the case that existing implementations might break if warnPhishing is 
> dropped, or misbehave in some unpredictable manner?
That's correct. The implementations which only show warning based on the 
flag would stop doing that.
>
> If so, it may be preferable to make things fail more cleanly, and 
> provide a working path for legacy implementations. Perhaps this could 
> be achieved by adding a specification version tag in a way that is 
> unacceptable to implementations that don't know the new version. (If 
> haven't checked whether that is possible.)
>
> If that's an option, legacy templates could follow the existing 
> (non-IETF) specification, without a "specversion" tag and including 
> warnPhishing etc. New templates would follow the IETF spec including 
> the "specversion" tag. If a legacy implementation inadvertently 
> processes a new-style template, it would fail (rather than misbehave). 
> I suppose a service provider may offer both in parallel for continuity 
> as long as they wish. 

"specversion" is likely a good facility as such - for the future. It 
won't solve this particular problem, because "legacy" implementations 
would not know to look at this flag and will interpret the templates the 
old way looking after warnPhishing flag. Unless we do something to break 
the template (like renaming one of required properties), which I think 
will cause more problems than it solves.

Kind Regards,
Pawel