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
