Re: [xdi] Agenda: XDI TC Telecon Friday 09:00 - 10:30AM PT 2015-03-27

[Joseph Boyle <planetwork@josephboyle.net>]

Instead of the symbols Drummond proposed for local identifiers, I think we should just partition the existing identifier space which would also fix some atypical features of XDI identifiers as currently defined.

Currently XDI identifiers can contain the characters A-Z a-z 0-9 (and the Letter and Number character classes of Unicode - we need to discuss and confirm that too) and four special characters:

- . _ ~

These have been carried forward without change from either:   (I’ve only ever seen tilde at the beginning to indicate a following Unix account name)

https://www.ietf.org/rfc/rfc3986.txt (which does not allow non-ASCII at all):

 unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

or from:

https://www.ietf.org/rfc/rfc3987.txt (which uses more generic criteria for Unicode non-ASCII characters):

   iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar

   ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
                  / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
                  / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
                  / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
                  / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
                  / %xD0000-DFFFD / %xE1000-EFFFD

   iprivate       = %xE000-F8FF / %xF0000-FFFFD / %x100000-10FFFD

RFC 3987 excludes only:

1. 32 unassigned code points just after ASCII
2. http://en.wikipedia.org/wiki/Private_Use_Area_(Unicode_block) (including emoji unless they’ve been moved) 
3. 32 unassigned code points in http://en.wikipedia.org/wiki/Arabic_Presentation_Forms-A 
4. http://en.wikipedia.org/wiki/Specials_(Unicode_block) 
5. two unassigned code points at the end of each Supplementary Plane whose lower 16 bits look like Byte Order Mark

So XDI currently can have arcs like: 

+-identifier  +.identifier  +_identifier  +~identifier    =-1   +.1   =_1   =~1

While underscore is universally categorized with letters and used as a spacer in identifiers, the other three are not; in fact tilde is almost always an operator.

Also note that usually decimal point, minus, and plus are considered parts of a number if they are followed by digits.

Proposal 1:  Make tilde the local context symbol; don’t allow tilde in identifiers.

identifier-char   =   ALPHA / DIGIT / "-" / "." / "_"
global-identifier =       1*id-char
local-identifier  =   “~” 1*id-char



Proposal 2:  Make identifiers starting with special characters local, and identifiers starting with alphanumeric global.

identifier-char   =   ALPHA / DIGIT / “-“ / “.” / “_” / “~"    
global-identifier =   (ALPHA / DIGIT)         1*id-char
local-identifier  =   (“-“ / “.” / “-“ / “~”) 1*id-char


Proposal 3+:  ????

identifier-char   =   ALPHA / DIGIT / “-“ / “.” / “_” / “~"    
global-identifier =   (????)         1*id-char
local-identifier  =   (????) 1*id-char

On Mar 26, 2015, at 11:12 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:

Parentheses and the Local Identifier Syntax Question

Joseph has voiced the concern that the current proposed ABNF syntax “overloads” parentheses syntax with several meanings. After the StarShift, which removed nested XDI addresses, the following table summarizes the current uses of parentheses syntax:

Usage	Syntax	Example
peer root	(_)	(=example)
URI peer root	(scheme:_)	(http://foo.example.com/)
inner root	(_/_)	(=example/#friend)
URI ID	x(scheme:_)	=(http://foo.example.com/foo/)
local ID	x(_)	=(foo)

Joseph has suggested that at least one of these could be replaced by another syntax to reduce the overloading of parentheses. Drummond feels strongly that root syntax should stay consistent, and further that the URI ID syntax is consistent with that. That leaves only local ID as a candidate for using a different syntax.

One option would be to introduce a “local symbol” with usage similar to the immutability symbol “!”, i.e., it would appended after the context symbol (and the optional immutability symbol) to indicate that the identifier scope was local and not global.

Here are examples of the primary options for a local symbol character with examples so you can see how they “read” (the parentheses syntax is included on the last row for comparison):

Local Symbol	= Example	+ Example	# Example	* Example
;	=;foo	+;foo	#;foo	*;foo
,	=,foo	+,foo	#,foo	*,foo
^	=^foo	+^foo	#^foo	*^foo
.	=.foo	+.foo	#.foo	*.foo
x( )	=(foo)	+(foo)	#(foo)	*(foo)

Immutable + Local Symbol	= Example	+ Example	# Example	* Example
!;	=!;foo	+!;foo	#!;foo	*!;foo
!,	=!,foo	+!,foo	#!,foo	*!,foo
!^	=!^foo	+!^foo	#!^foo	*!^foo
!.	=!.foo	+!.foo	#!.foo	*!.foo
x!( )	=!(foo)	+!(foo)	#!(foo)	*!(foo)

We will review and make a final decision about local identifier syntax. Note that if you are not able to make tomorrow’s TC call, please indicate your view in a response on the list.

XDI Messaging Spec

Markus will give a status report of his work on XDI Messaging 1.0 WD03:

http://xdi.org/xdi-spec-docbook/xdi/xdi-messaging-1.0/xdi-messaging-1.0-wd03.xml

https://wiki.oasis-open.org/xdi/XdiMessagePatterns

$push Instead of $copy?

In recent discussions on the XDI2 open source project call, it was suggested that $push might be a better dollar word than $copy for the XDI data synchronization operation.

Websocket Binding, Publish/Subscribe, $copy Link Contracts

If there is time, Markus can show a proof-of-concept of a Websocket binding. There are several topics to discuss:

• Is there agreement that we should publish a Websocket binding? In which spec?
• Will this require defining more about the $copy operation? In which spec?
• What will push (pub/sub) connections require in terms of additional link contract semantics?

NEXT CALL

The next call is next week at the regular time.