On September 1, 2005 at 23:05, Douglas Otis wrote:
* I need some clarification of the use of "bit-fields". When
using the term "bit-fields" there is direct implication that
the field has 16 distinct values based on 0-15 bits of the
16 bit integer. For example:
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 | 0 |
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Actually the IETF has a practice of defining the MSB as bit 0. This
can be confusing when describing bit settings. Rather than
specifying the bit ordering, the settings were defined by value. A
bit with a value of 1 would be bit 15 per IETF big endian
conventions, and bit 0 per common little endian architectures.
Even with network-byte ordering, bit numbering usually (from what
I've seen) goes right-to-left to match the exponent. I have no real
experience with IETF's view on this since the RFCs I'm most familiar
with do not deal with bits.
Bit
values of 1, 2, or 4 was an attempt to avoid this ambiguity.
Then this nomenclature should be explicitly defined to avoid confusion
(at least I was; maybe I am not representive of the intended audience).
I'm trying to understand if the unsigned integer (16 bits) is
being used to represent mulitple properties (a reason to describe
settings as bits) or a single property (settings should be described
as a single number).
Contains two distinct values versus the single integer value of 6.
There are two tables where one indicates the resulting combined values.
The "Summed Values" table seems to imply that the Weight field
is to represent a single property versus a set of properties.
For example, if 2^0 and 2^1 bits are set, the "Bit Values" table
implies conflicting interpretations while the "Summed Values" table
does not.
* Should "walking" even be allowed? This seems to increase the cost
of failure and one has to deal with what really constitutes a
top-level domain. For example, what about country-based roots:
com.au, or tx.us? Does one consider the root domain to always be
the first domain (right-most) of a full domain name?
Is it reasonable to require a sender to explicitly define SRV
records
for each EHLO name they will use, therefore avoiding any "walking"?
Dave Crocker and John Levine were proponents of this approach which
has been replicated to a fashion within the SSP draft. The SSP draft
requires upward walking.
If I can guess on the rationale, there is a desire to explicitly
indicate when a domain defines SRV records for their SMTP clients
versus a domain that is not doing CSV. This way, if someone attempts
to spoof a domain by using names with no SRV records, the SMTP server
can determine if the domain specified explicitly does CSV or not,
and if it does, it can reject the mail.
I am correct on this or are there other reasons?
--ewh
_______________________________________________
ietf-clear mailing list
ietf-clear(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-clear