OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri-editors] further thinking on mustUnderstand


So, wading in here, are you saying Dave that we shouldn't use a
MustUnderstand attribute, or that we should specify where it is appropriate
to use?

=Drummond 

-----Original Message-----
From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] 
Sent: Friday, February 04, 2005 12:00 PM
To: Peter C Davis
Cc: xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] further thinking on mustUnderstand

This is why MustUnderstand is so dangerous and so easy to misuse.
Imagine that I'm resolving =Peter in order to discover your public key.
I ask = for Peter and get back something like this:

<XRIDescriptors>
	<XRIDescriptor>
		<Auhthority>...</Authority>
		<Token MustUnderstand=true>...</Token>
		<ds:KeyInfo>...</ds:KeyInfo>
	</XRIDescriptor>
<XRIDescriptors>

I have no interest in contacting the next resolution authority and I
have no use for the security token. All I want to do is process the
ds:KeyInfo element. But if I don't understand the Token element, I'm not
allowed to consume ds:KeyInfo. Using Token and MustUnderstand in this
way breaks the entire XRID.

What we really want is something like this:

<XRIDescriptors>
	<XRIDescriptor>
		<Auhthority>
		...
			<Token MustUnderstand=true>...</Token>
		</Authority>
		<ds:KeyInfo>...</ds:KeyInfo>
	</XRIDescriptor>
<XRIDescriptors>

I can imagine use cases where MustUnderstand might be useful, but every
suggestion put forward by supporters has been a misuse of the attribute.
I think at a minimum we should consider it very dangerous.

Dave

-----Original Message-----
From: Peter C Davis [mailto:peter.davis@neustar.biz] 
Sent: Friday, February 04, 2005 9:53 PM
To: Dave McAlpin
Cc: xri-editors@lists.oasis-open.org
Subject: Re: [xri-editors] further thinking on mustUnderstand

well... they MAY be, or they may be XRI bound (that is, they are
specific 
tokens for a resolver to use to resolve a specific authority-part
subsegment 
with a specific authority).

--- peterd

On Friday 04 February 2005 02:43 pm, Dave McAlpin wrote:
> I don't think so. Tokens, in your example, apply to authorities.
They'd
> be placed in XRIDescriptors/XRIDescriptor/Authority/Token.
> MustUnderstand would be relative to the Authority, not the XRID.
>
> -----Original Message-----
> From: Peter C Davis [mailto:peter.davis@neustar.biz]
> Sent: Friday, February 04, 2005 9:40 PM
> To: Dave McAlpin
> Cc: xri-editors@lists.oasis-open.org
> Subject: Re: [xri-editors] further thinking on mustUnderstand
>
> On Friday 04 February 2005 02:19 pm, Dave McAlpin wrote:
> > Both of these cases seem to argue for MustUnderstand semantics on an
> > Authority element, not on the XRID which can describe multiple
> > authorities. In the second case especially, a client shouldn't be
> > precluded from processing Service elements just because he doesn't
> > understand how to pass proper credentials to some resolution
>
> authority.
>
> > Is that correct?
>
> i suppose that depends on where the token extension points are
placed...
> token
> placement is likely to be XRIDescriptors/XRIDescriptor/Token, since
> these are
> (potentially) unique for each authority, and required for processing
> 'next-level' resolution.... in this use case.
>
> SO the processing would require (a) resolver to process the XRID,
> extract the
> Token, and add that to the HTTP header for the next resolution step.
> that
> seems to require modifications to the XRID.
>
> --- peterd

-- 
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.302 / Virus Database: 265.8.5 - Release Date: 2/3/2005
 

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/xri-editors/members/leave_workg
roup.php.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]