On 4/2/2015 8:14 AM, John R Levine wrote:
>>> On the signing side, the signer has the new option of adding a
>>> conditional
>>> signature, but all of the old options still work.
>>
>> Protocols are defined by bits over the wire, not APIs.
>
> They're defined by both.
Sorry, no.
Or rather, while it is common to link them together, that's not required.
Just as the same API can be satisfied by many different protocols, the
same protocol can be accessed through many different APIs.
Historically the IETF has tried to focus only on protocols (bits over
the wire), in order to stay away from API wars and the differences
needed by different platforms. In recent years, this has been relaxed
somewhat, mostly serving to add to the confusion about the difference
between APIs and protocols (IMO).
I haven't done a careful audit, but the IETF typically does not put API
specs on standards track, though I note that the Kerberos GSS-API comes
close. Except that it is specified as... a protocol.
> The main reason we published RFC 5672 was to
> clarify that the API returns the value of the d= tag, not the i= tag,
> even though the bits on the wire didn't change.
That's not why I initially raised the issue that led to the creation of
the update. I cast it in terms of overhead vs. payload, the same as I'm
distinguishing here and alas, the same as I was taught, 40 years ago.
"DomainKeys Identified Mail (DKIM) ... permit[s] a signing domain
to claim responsibility for the introduction of a message into the
mail stream. "
That is, the 'payload' of DKIM is the delivery of a validated domain
name. In the original specification, we failed to properly specify
which of the two delivered identifiers (d= and s=) was that promised
payload.
In the Update, here too we see the confusion caused by having the
document even reference the construct of an API. Frankly I conceded the
reference in that document as a means of trying to get past people's
confusion about the difference between the parts of a protocol that are
overhead, versus that part that is payload, delivered outside of the
protocol. Given this exchange now, I regret that concession.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
