RE: [xri-editors] Proposed text for 2.2.5

["Drummond Reed" <drummond.reed@onename.com>]

Nat, after looking at this closely with Dave this afternoon, we both
agreed that since a space is not technically legal in IRI (it is an
excluded character), we should follow the same policy as IRI. We also
felt we should include roughly the same text they did about saying that
although spaces could be used in input and display, this should be
avoided if in that context they may be misinterpreted or incorrectly
transcribed.

I can imagine contexts where that is not a problem, and therefore where
displaying the space char should be fine. But I can also imagine other
contexts where it could be a major problem, which is why I support
including the warning, and sticking with the same technical policy as
IRI.

=Drummond 

-----Original Message-----
From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
Sent: Thursday, November 06, 2003 7:57 PM
To: Sakimura, Nat; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] Proposed text for 2.2.5

After Drummond and I looked more closely at the IRI draft, it doesn't
appear
that an IRI with a space is a technically legal either. They don't say
so
explicitly, but it doesn't seem to be allowed by the ABNF. We were
trying to
follow the example they set out. How strongly do you feel about this?

> -----Original Message-----
> From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> Sent: Thursday, November 06, 2003 6:42 PM
> To: Dave McAlpin; xri-editors@lists.oasis-open.org
> Subject: RE: [xri-editors] Proposed text for 2.2.5
>
>
> Sorry that I had to miss the call.
>
> Looks generally OK. I have a bit of problem with
> "is not technically a legal XRI" part, however.
>
> To me, the intent is more like
> "is technically a legal XRI, but is strongly discouraged."
>
> Nat
>
> > -----Original Message-----
> > From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
> > Sent: Friday, November 07, 2003 11:13 AM
> > To: xri-editors@lists.oasis-open.org
> > Subject: [xri-editors] Proposed text for 2.2.5
> >
> > In today's editor's call, I volunteered to draft some text
> > that normatively allows spaces in input and presentation,
> > disallows them in the BNF and generally discouraging their
> > use. This is the same approach taken by IRI in section 3.1
> > and 6.1. Here's the proposed text.
> >
> > Infrastructure accepting or presenting XRIs MAY deal with
> > printable characters in the "excluded" set above, escaping
> > them on input and/or unescaping them prior to presentation. A
> > string that contains these characters in an unescaped form,
> > however, is not technically a legal XRI.
> >
> > Note that presenting the "space" character in unescaped form
> > is especially risky for several reasons. First, it is
> > difficult to visually determine the number of spaces in a
> > string. An identifier that contains a run of several
> > unescaped spaces would be very prone to misinterpretation and
> > transcription errors. Second, the space character is often
> > used to delimit an XRI, so including unescaped spaces in a
> > string makes it difficult, and sometimes impossible, to
> > determine where the identifier ends. Finally, unescaped
> > spaces can be used to maliciously construct subtly different
> > identifiers intended to mislead the reader. For these
> > reasons, unescaped spaces SHOULD be avoided in presentation.
> >
> >
> >
> > 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/membe
> > rs/leave_workgroup.php.
> >
> >
> >
>
> 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_w
orkg
roup.php.




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_w
orkgroup.php.