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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: RE: [xri] Yettanuther Syntax Proposal


Victor,

Unfortunately, "\" is not a URI or IRI reserved character, so we can't make
it an XRI syntax character.

Too bad, because I agree with you, it might be a nice solution to the
email-address-lookalike problem. (On principle, however, I think we should
keep mechanism and policy separate. Keep the syntax simple and clean and
deal with social vulnerability issues via policy.)

=Drummond 

-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Friday, May 11, 2007 11:15 AM
To: xri@lists.oasis-open.org
Subject: Re: [xri] Yettanuther Syntax Proposal

I like this a lot. Not the least of my reasons for liking it is that  
I was able to understand it the first time through.
One small suggestion (which admittedly may be completely off the wall  
due to my limited grokking of XRI syntax) - could we use the "\"  
character to introduce a rooted literal? As in =steve\@microsoft.com  
- "\" is not a legal local name character in RFC2822, so it should  
make an illegal email address out of it.
=vg

Schleiff, Marty wrote:
> After three weeks of trying, I suggest we abandon efforts to contrive
> meaningful grammar to match the rich syntax of direct concatenation.
> It's not been completely fruitless, because we've learned that  
> there is
> no obvious difference in the meaning of direct concatenated global ref
> vs. a local ref with parens enveloping a globally-rooted XRI. So,
> instead of focussing on coming up with richer ways to express concepts
> for which we have no use cases, I suggest we focus on simpler ways to
> express very flexible concepts. As a starting point for  
> consideration, I
> suggest the following:
>
> 1.	There are only three types of values that can be in a
> subsegment; a local value, a rooted value (one beginning with a  
> GCS), or
> a parenthetical cross reference.
> a.	example        // Example of a local literal
> b.	@example     // Example of a rooted literal:
> c.	(@example*stuff)   // Example of a parenthetical cross
> reference.
>
> 2.	A parenthetical cross reference is required in two cases:
> a.	An XRI with more than one subsegment or segment is to be taken
> into the context of another XRI.
> b.	An IRI is to be taken into the context of an XRI.
> c.	Note - If a single subsegment XRI is enveloped in parens when
> taken into the context of another XRI, the parens are unnecessary.
> Normalization rules may be necessary.
>
> 3.	There are three global namespaces in which a rooted literal can
> be rooted; @, =, $.
>
> 4.	There are only three subsegment delimiters; star, bang, and
> plus. Subsegments of a segment are ALWAYS delimited by either a star,
> bang, or plus.
> a.	@example*stuff                      // "stuff" is a local
> literal
> b.	@example!stuff                       // "stuff" is a persistent
> local literal
> c.	@example+stuff                      // "stuff" is a tag with the
> meaning of the tag determined by @example
> d.	=steve*@microsoft.com                    // "@microsoft.com" is
> a rooted literal. I hope this helps address steve's social  
> vulnerability
> issue, even though my word processor still considers this an email
> address, even with the @ preceded by *.
> e.	=steve!@microsoft.com          // "@microsoft.com" is a rooted
> literal, and "=steve" claims that it is persistent (although I'm not
> sure it makes sense for =steve to make such a claim).
> f.	=marty*(@example*stuff)       // "(@example*stuff) is a
> parenthetical cross reference referencing a particular resource. When
> taken into the context of "=marty" as a parenthetical cross reference,
> it means the same resource with associated attributes and/or service
> points provided by =marty.
> g.	=marty!(@example*stuff)       // same as before, but =marty
> claims the whole cross reference is persistent.
>
> 5.	A plus can only be followed by a local literal.
> a.	 @example+stuff                      // "stuff" is a tag with
> the meaning of the tag determined by @example
>
> 6.	Star and bang can be followed by any of the three types of
> subsegments (local literal, rooted literal, parenthetical cross
> reference)
>
> 7.	The grammatical difference between the three subsegment
> delimiters is as follows:
> a.	!     // this means the following subsegment is persistent
> b.	*    // this means the following subsegment may be reassignable.
> When a star preceeds a local literal, it means that the local literal
> conveys no meaning to a relying party - it's just the name of a
> namespace or resource in a namespace.
> c.	+    // this means the following local literal is a tag,
> intended to convey a particular meaning. The meaning is decreed by the
> "context" in which the tag appears (i.e., by the combined preceding
> subsegments). Parties/communities that use tags will benefit by  
> having a
> common decree about the meaning of the tag values used in the  
> community.
>
> 8.	Each subsegment is in the context of everything to its left (as
> represented in the abstract model - i.e., to the left on the same
> level).
> a.	@example*stuff             // "stuff" is a local literal in the
> context of @example.
> b.	@example*stuff*morestuff       // "morestuff" is a local literal
> in the context of "@example*stuff".
> c.	@example*half-full*=marty      // "=marty" in the context of
> "@example*half-full", which might consider =marty's reputation to be
> "excellent on even numbered days".
> d.	@example*half-empty*=marty      // "=marty" in the context of
> "@example*half-empty", which might consider =marty's reputation to be
> "lousy on odd numbered days".
> e.	@example*=marty*stuff                   // "stuff" is in the
> context of "@example=marty"; not in the context of "=marty".
> f.	@example*(=marty*stuff)                 // "stuff" is a
> subsegment of "=marty*stuff". "stuff" is not a "top level"  
> subsegment of
> "@example*(=marty*stuff)".
> g.	=drummond+home+phone               // "+phone" is in the context
> of "=drummond+home".
>
> 9.	I still haven't figured out what to do about <gcs>!<literal>,
> and I need some help with it. I think it would be easier if ! were  
> not a
> delimiter, but just a claim of persistence, but I don't think you guys
> will agree with that.
> a.	@!123.234.345    // because ! is a delimiter, this whole thing
> can't be termed a rooted literal. I need help with this.
>
> 10.	If people don't like * in front of a rooted literal subsegment,
> I suppose we could decide to leave it off syntactically, but still
> include it in spirit (i.e., even though you don't see it, it's still
> there). However, that would get rid of any benefit the "*" provides
> against social vulnerability (see example 3.d.).
>
> I'm not hard-set on any of this, but I think it incorporates a lot of
> the ideas we've discussed over the past weeks. These ideas represent
> simpler syntax, simpler grammar, and I still think they address all  
> the
> use cases that have been suggested. I think it provides a nice  
> solution
> for the most common desire for direct concatenation (i.e., + tags  
> as in
> 6.f.). And it also clears up my grief about "+" not being a global
> namespace.
>
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Computing Security Infrastructure
> (206) 679-5933




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