Subject: RE: [Simple] Clarification on XCAP path seperator ~~

From: "Fridy Sharon-Fridman" <[email-masked]>
Date: Thu, 25 Aug 2005 22:21:51 +0300

At 4:49 PM +0300 8/25/05, Fridy Sharon-Fridman wrote:
>Hi Ted,
>
>It helps as it clarifies one can use percent-encoded and get
translation
>that will lead correctly to the XCAP resource. It was an issue of
>interoperability between XDMS (OMA XCAP Servers) and clients vendors,
in
>latest OMA Fest 9.5.
>
>Would you consider, at this RFC queue stage of XCAP, clarifying this
>within XCAP I/D, explicitly? (now it appears as a possible consequence
>from chapter 13 security discussion, and here in your E-Mail...)
>
>Thanks,
>--Fridy / Followap

Clarifying text can be added during AUTH48 if it implies no normative
change.  Do you have suggested text?
			regards,
				Ted Hardie

[Fridy] :-) Yes. Please see below local text as option 1. It may require
a global text - See option 2. The 3rd option seems unnecessary but more
"aligned" with section 6 overview.

(1)

6.  URI Construction

   In order to manipulate an XCAP resource, the data must be represented
   by an HTTP URI.  XCAP defines a specific naming convention for
   constructing these URIs.  The URI is constructed by concatenating the
   XCAP root with the document selector with the path separator with a
   escape coded form of the node selector.  This is followed by an
   optional query component that defines namespace bindings used in
   evaluating the URI.  The XCAP root is the enclosing context in which
   all XCAP resources live.  The document selector is a path that
   identifies a document within the XCAP root.  The path separator is a
   path segment with a value of double tilde ("~~")

<<Start of new Text>>
   , and MAY be percent encoded as defined in [RFC3986].
<<End of new text>>

   It is piece of
   syntactic sugar that separates the document selector from the node
   selector.  The node selector is an expression that identifies an XML
   element within a document.

BTW RFC 2396 is referenced (and then the term is called "escape") but
not the newer RFC 3986. It may be needed to replace the reference above
or add a reference, and update [RFC3986] above to the relevant number.

(2)

6.  URI Construction

   In order to manipulate an XCAP resource, the data must be represented
   by an HTTP URI.  XCAP defines a specific naming convention for
   constructing these URIs.  The URI is constructed by concatenating the
   XCAP root with the document selector with the path separator with a
   escape coded form of the node selector.  This is followed by an
   optional query component that defines namespace bindings used in
   evaluating the URI.  The XCAP root is the enclosing context in which
   all XCAP resources live.  The document selector is a path that
   identifies a document within the XCAP root.  The path separator is a
   path segment with a value of double tilde ("~~").  It is piece of
   syntactic sugar that separates the document selector from the node
   selector.  The node selector is an expression that identifies an XML
   element within a document.

<<Start of new Text>>
   The HTTP URI MAY be percent encoded as defined in [RFC3986].
<<End of new text>>

   The sections below describe these components in more detail.

(3)

Add a section between 6.2 and 6.3 (and change numbers and toc)

	"6.2"		Path Separator

	The path separator is a path segment with a value of double
tilde 	("~~"), and MAY be percent encoded as defined in [RFC3986].  
	It is piece of syntactic sugar that separates the document
selector 	from the node selector.  

And 

<<Remove from 6 this "It is piece of syntactic sugar that separates the
document selector from the node selector.">>

Cheers,
--Fridy / Followap

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Aug 2005 14:31:06 -0700

>   element within a document.

Actually, rereading 3986, Section 2.3, I find this (note that ~ is an
unreserved character):

   URIs that differ in the replacement of an unreserved character with
   its corresponding percent-encoded US-ASCII octet are equivalent: they
   identify the same resource.  However, URI comparison implementations
   do not always perform normalization prior to comparison (see Section
   6).  For consistency, percent-encoded octets in the ranges of ALPHA
   (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
   underscore (%5F), or tilde (%7E) should not be created by URI
   producers and, when found in a URI, should be decoded to their
   corresponding unreserved characters by URI normalizers.

So it looks like the advice should be "SHOULD NOT be percent-encoded,
as advised in Section 2.3 of RFC 3986.  URIs containing %7E%7E should
be normalized to ~~ for comparison; they are equivalent.".

Haris's original mail referenced 2396 which might be ambiguous.  I believe 3986
is pretty clear here, though, and updating the reference to 3986 and adding
this clarification looks like it removes any ambiguity.

Does this make sense, or am I missing something here?
			regards,
				Ted Hardie