ignore this message.
<wet noodle time>
Never post messages close to 2 am.
</wet noodle time>
sigh
Tony Hansen
[EMAIL PROTECTED]
Tony Hansen wrote:
> um, erm, ahem
>
> ss 4.1 para 3 is supposed to be talking about the use of the s= selector
> value to choose which signature key is being used.
>
> But Jim mistook the paragraph to be talking about the s= service type
> value that can be found *within* a signature key.
>
> This indicates to me that our text led Jim astray.
>
> Tony Hansen
> [EMAIL PROTECTED]
>
> Dave Crocker wrote:
>> Jim Fenton wrote:
>>> Section 4.1 paragraph 3 talks about the service type (s=) constraint
>>> in key records, and goes on to say that it is helpful when delegating
>>> signing authority. s= was included to provide expansion capability
>>> should, at some point, some service other than email decide to use
>>> DKIM. If and when some other service does use DKIM, the ability to
>>> constrain a key to signing email only would help delegation. In the
>>> meanwhile, there isn't any benefit to delegation as a result of s=.
>>>
>>> I suggest that the paragraph be deleted.
>>
>>
>> You suggest having the DKIM Overview make no comment on the s= parameter?
>>
>> The signing specification's explanatory text for s= is:
>>
>> "This tag is intended to constrain the use of keys for other
>> purposes".
>>
>> If there is something inaccurate in the Overview text, what is it?
>>
>> As for "included to provide expansion capability", I don't understand
>> what this means. The signing spec text says it was included for a
>> different purpose, but that it *includes* an expansion capability, to
>> list other services.
>>
>> You further seem to indicate that s= is not currently useful but would
>> be if it listed other services. (I well might be misunderstanding
>> this part of your text.) In any event, either the capability has
>> currently utility, or it was a mistake to put it in the spec. Which
>> are you saying?
>>
>> d/
>>
>>
>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
