Just a short quick question, relation to text of 1.1.3 in 2396bis about URL ref? (re-posted; 2nd attempt)

Re: updating RFC 2718 (Guidelines for new URL schemes)

At 16:48 04/08/29 -0700, Larry Masinter wrote:

>* Syntactic compatibility
>
>I think the sentiments in this section are good; I'm uneasy
>about the lengthy 'motivation for syntactic compatibility',
>since it's really not just a motivation, but also an explanation
>for what is meant by 'syntactic compatibility'. I think
>some of the Motivations are confused (e.g., the discussion
>about fragment syntax, but URI schemes don't define
>fragment syntax!)
>
>So I think this section can be reduced to asking that
>URI schemes use RFC2396bis generic syntax, because of
>compatibility with relative references.

I think this has two aspects:
- We have to clearly state that every URI scheme syntax has
   to follow the (generic) URI syntax in that it cannot allow
   URIs that don't fit into the URI syntax. As a very simple
   example, if a foo: scheme would allow "#" as part of the
   URI syntax, it would be out. Similar for misusing "%", and
   a few other things.
- We also should recommend that any components of the generic
   syntax (e.g. // for top level, / for hierarchy,...) are used
   with the semantics defined in RFC 2396bis.

>* 2.2 Is the scheme well defined?
>
>This should be turned into a guideline rather than
>a question, with the suggestion that there are
>resource locator schemes and non-locator schemes.
>I think it's useful if schemes are clear about whether
>(or under what circumstance) the 'resource' might be
>something that returns a (body/entity/...?) which has
>a Media Type, and can be used with fragment identifiers
>in their conventional definition.
>
>* 2.2.5 Character encodings
>
>I think this turns into a requirement for compatibility
>with IRI guidelines.

"IRI guidelines" or the IRI spec?

>Maybe there is a place here to
>note that there is only one namespace, a "URI scheme"
>is also an "IRI scheme".

Yes. The considerations that Stuart Williams brought into
IRIs, and that are listed as issue  <at>  <at>  <at> ,
[]
Some of this will probably end up in the IRI spec, but
it actually belongs here.

There are quite a few points that came up in my recent review
of the xxmp

>2.3 Demonstrated utility
>
>I'd like to suggest that we require something stronger: that new
>URI schemes have demonstratable, new, long-lived
>utility:
>
>   Because URI schemes are a single, global namespace, the
>   unrestricted registration of many new URI schemes can
>   clutter implementation space, and possibly lead to
>   contention for "short names". For this reason, new
>   URI schemes should have a clear utility to the broad
>   Internet community, and provide some means of identifying
>   resources that is not already available with previously
>   registered URI schemes.
>
>Perhaps this is controversial :)

It seems to go into the opposite direction of what was discussed
at the BOF, namely to relax the rules. But I guess this could
work out by saying that the above is desirable, and there should
be potential for it, rather than having it as a hard-and-fast rule.

Regards,    Martin.

RE: updating RFC 2718 (Guidelines for new URL schemes)

Hi:

I had a few questions - see ' <at>  <at>  <at> '

> - We have to clearly state that every URI scheme syntax has
>    to follow the (generic) URI syntax in that it cannot allow
>    URIs that don't fit into the URI syntax. As a very simple
>    example, if a foo: scheme would allow "#" as part of the
>    URI syntax, it would be out. Similar for misusing "%", and
>    a few other things.

 <at>  <at>  <at>  Not clear that I understand why "#" would not be allowed. According to
2396bis it is a legal URI character introducing a fragment component which
is an optional component of a generic URI.

> - We also should recommend that any components of the generic
>    syntax (e.g. // for top level, / for hierarchy,...) are used
>    with the semantics defined in RFC 2396bis.

 <at>  <at>  <at>  I am also not sure that 2396bis goes so far as to actually require "/"
to be a hierarchical delimiter for a given scheme, but it rather says that
URI schemes that do not want to remain opaque must support hierarchical
processing. (I presume the "data" URI scheme would also support hierarchical
processing.:)

> >I think it's useful if schemes are clear about whether
> >(or under what circumstance) the 'resource' might be
> >something that returns a (body/entity/...?) which has
> >a Media Type, and can be used with fragment identifiers
> >in their conventional definition.

 <at>  <at>  <at>  What is the media type of a non-dereferenceable URI, as might be minted
in a typical RDF application? This all seems very metaphysical to me. Or
does the media type only come into play if a URI is dereferenced?

> >2.3 Demonstrated utility
> >
> >I'd like to suggest that we require something stronger: that new URI 
> >schemes have demonstratable, new, long-lived
> >utility:
> >
> >   Because URI schemes are a single, global namespace, the
> >   unrestricted registration of many new URI schemes can
> >   clutter implementation space, and possibly lead to
> >   contention for "short names". For this reason, new
> >   URI schemes should have a clear utility to the broad
> >   Internet community, and provide some means of identifying
> >   resources that is not already available with previously
> >   registered URI schemes.
> >
> >Perhaps this is controversial :)
> 
> It seems to go into the opposite direction of what was 
> discussed at the BOF, namely to relax the rules. But I guess 
> this could work out by saying that the above is desirable, 
> and there should be potential for it, rather than having it 
> as a hard-and-fast rule.

 <at>  <at>  <at>  Would have to agree with this last comment. I see no problem with
cluttering of implementation space. An implementation should be able to
detect a string being used within a URI context, parse it out to see that it
conforms to the generic URI syntax, and then discover whether it has any
rules to dereference such a URI. Of course, most implementations do not
recognize generic URIs but only specific schemes which are hard coded into
them. I am not a little sceptical of there being some kind of gold rush on
URI scheme names.

Tony

Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK 

tel:+44-20-7843-4659
mailto:t.hammond <at> nature.com

********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended
recipient. If you have received this e-mail in error please inform the sender and delete it from your
mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents
accept liability for any statements made which are clearly the sender's own and not expressly made on
behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan
Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in
this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any).
No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail
communication. Macmillan Publishers Limited Registered in England and Wales with
  registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Off/On topic - Brick VS Head. URI(URL/File) eg of previous posts...

Re: Off/On topic - Brick VS Head. URI(URL/File) eg of previous posts...

At 10:00 AM +0000 9/2/04, Kitchen Pages wrote:
>Content-Description: filename="text1.html"
>Content-Type: text/html
>
>In relation to the URL of File and its difference to that of Win9x 
>32 - aka URI of file.
>
>I have noticed several things for a while which seem to work 
>opposite of clearly defined standards and I was wondering why this 
>practice is continued without any note - Ie: a reference to what 
>does where, how it does it?!?, or even the result of a URI on 
>various systems, etc.. (as part of relative-URI as I understood it; 
>which may of been 'incorrect')
>
>To explain just one very small example, and as perhaps my other 
>posts can not be understood :( from my lack of understanding these 
>ideals fully.
>
>Step A, created a folder on <../../../../../>C:\ named FOLDER.IE5
>Step B, created a file named 'FILE' in the folder above without an extension
>
>Test 1, <file:///C/FOLDER.IE5/FILE>file://C/FOLDER.IE5/DATA results 
>in a File Not Found which I think is wrong.
>Test 2, C:\FOLDER.IE5\DATA results in FILE being found, *.

Your 'Test 1' is not the orthodox transcription of your 'Test 2.'

If Test 2 succeeds, then Test 1 SHOULD fail for two defects.

1) the path segment for the drive letter should be /C:/ not /C/. 
Your file: URI is looking for
a non-existent branch in the path tree.

2) you need a host.  Even if you want to minimize typing, you may use 
a zero-length ""
host field as short for 'localhost' the pseudo-host that means 
"here."  But you have to
at least delimit the null 'host' string with yet another '/' character.

Fixing those two transliteration bugs, you come up with

Test 1a, file://localhost/C:/FOLDER.IE5/DATA
Test 1b, file:///C:/FOLDER.IE5/DATA

What happens if you try those?

Al

Re: Off/On topic - Brick VS Head. URI(URL/File) eg of previous posts...

Hello Al,
thankyou for your time and efforts in supply of resolve with a reply to 
my request and plea's for help.

The two URI examples you provided worked a lot better then my examples 
had been performing.  I had assumed that I should adopt the Win NetBios 
domain path when using File:// and there in started my dramas in u
nderstanding this whole thing and the results I was getting (which I had 
done for a few years).  

Windows then altered the URI in the address bar to suit a known path if 
it found one by displaying a 'page can not be displayed' message – where 
I could then press Go and see the rendered data while some older browsers 
just showed errors of all descriptions; with Mozilla showing a 
non-existant empty path from time to time as you also kind of described.  
I have noted that the localhost is dropped by Iexplorer upon rendering as 
you suggested with "" as the host. (another part of the voodoo I kept 
encountering).

Many thanks again for your kind assistance in resolve of my major issue 
for an understanding about File://.
My kindest regards and many thanks again for your prompt kind reply,
Jason

:)

Message-Id: <p06110409bd5bcb77c41d <at> [10.0.1.2]>
References: <20040902.10005898 <at> home.kitchenpages.net>
--------------------------------------------------------------
At 10:00 AM +0000 9/2/04, Kitchen Pages wrote:
>Content-Description: filename="text1.html"
>Content-Type: text/html
>
>In relation to the URL of File and its difference to that of Win9x 
>32 - aka URI of file.
>
>I have noticed several things for a while which seem to work 
>opposite of clearly defined standards and I was wondering why this 
>practice is continued without any note - Ie: a reference to what 
>does where, how it does it?!?, or even the result of a URI on 
>various systems, etc.. (as part of relative-URI as I understood it; 
>which may of been 'incorrect')
>
>To explain just one very small example, and as perhaps my other 
>posts can not be understood :( from my lack of understanding these 
>ideals fully.
>
>Step A, created a folder on <../../../../../>C:\ named FOLDER.IE5
>Step B, created a file named 'FILE' in the folder above without an 
extension
>
>Test 1, <file:///C/FOLDER.IE5/FILE>file://C/FOLDER.IE5/DATA results 
>in a File Not Found which I think is wrong.
>Test 2, C:\FOLDER.IE5\DATA results in FILE being found, *.

Your 'Test 1' is not the orthodox transcription of your 'Test 2.'

If Test 2 succeeds, then Test 1 SHOULD fail for two defects.

1) the path segment for the drive letter should be /C:/ not /C/. 
Your file: URI is looking for
a non-existent branch in the path tree.

2) you need a host.  Even if you want to minimize typing, you may use 
a zero-length ""
host field as short for 'localhost' the pseudo-host that means 
"here."  But you have to
at least delimit the null 'host' string with yet another '/' character.

Fixing those two transliteration bugs, you come up with

Test 1a, file://localhost/C:/FOLDER.IE5/DATA
Test 1b, file:///C:/FOLDER.IE5/DATA

What happens if you try those?

Al 

Re: Just a short quick question, relation to text of 1.1.3 in 2396bis about URL ref? (re-posted; 2nd attempt)

Kitchen Pages wrote:
> Just a short quickie question

I see various question marks in your message, but no actual questions, at 
least none that I can follow well enough to provide an answer for. I suspect 
others on the list haven't responded because they feel the same. What is your
quickie question?

> The text below is from one of my books on how to use/programme for BCB 
> c++ (Borland Builder) published in 1998 which states:

At the risk of sounding like Roy Fielding, whatever (mis-)understandings you 
have picked up from that book, or from anywhere other than the RFCs 
themselves, are irrelevant. A book about some programming language can say 
what it wants about anything. I tend to assume that the actual specs are going 
to be more accurate and precise than the executive summary you get in a book, 
especially if the topic is peripheral to the main topic of the book.

That said, the concepts that the URI generic syntax embodies have been refined 
over time, influenced by the nuances of HTTP and the kind of situation 
described in the Borland book you quoted. Resource has been decoupled from 
representation, and identification has been decoupled from retrieval. 
Consequently, a clear distinction between a "locator" and a "name" is not 
necessary to maintain at either the syntactic level or the semantic level, for 
the purposes of resource identification.

Location may be important in the definition of a scheme, for implementation, 
but even in the case of the http scheme, location is only relevant in a URI's 
authority component when one is using a resolver that uses that component in 
the usual manner, dissecting it into a host, port, and userinfo, and talking 
over a network -- it could just as easily use a catalog instead, effectively 
treating the http URI as an opaque identifier rather than having any location
semantics implicit in the URI at all.

> In a nutshell as I am - I was wondering ? that perhaps the URL
> references used in the draft text could be stated; like an RFC number
> as the "Informative References" seem to have multiple choices which may
> not be a bad thing but it is somewhat confusing considering the
> reference to REC2141 for URN (or should I use that?).

I can't figure out what you're referring to ("the URL references"?), what 
you're asking for ("stated"? "use RFC 2141 for URN"?), or what your complaint
is, exactly, with the current draft.

If you have an editorial suggestion for improving the Informative References 
section, then my advice would be to please try to state it clearly, for better 
results: "RFC 2396bis draft 06 currently says..., which is confusing 
because..., and here's what (or the kind of thing) it could say that would 
mitigate that confusion..." ...then prepare to be roasted by Roy. :)

-Mike

Re: Comments on draft-saintandre-xmpp-uri-04.txt

Hi Martin,

My apologies for the delayed reply. I have attempted to incorporate all 
of your feedback and have prepared an interim version of the document, 
which is available here:

http://www.jabber.org/~stpeter/ietf/draft-saintandre-xmpp-uri-05-pre1.txt

I would appreciate it if you or others would take a look at this document
and let me know if I have misinterpreted any of the feedback received.

Several further questions and observations below...

On Tue, Aug 24, 2004 at 09:55:12AM +0900, Martin Duerst wrote:
> 
> >> >   While the "?" character is allowed in the resource identifier portion
> >> >   of an XMPP address (according to [XMPP-CORE]), that character can be
> >> >   used as a delimiter between the jid and the query parts of an xmpp:
> >> >   URI; therefore, any instances of the "?" character in the resource
> >> >   identifier portion of an XMPP address that is generated or processed
> >> >   as an xmpp: URI MUST be escaped as "%3F" (as described in Section
> >> >   2.2.5 of [URL-GUIDE]).
> >>
> >> That's a good example of a case that should be expressed in the syntax
> >> rules. The syntax has to express the exact form of the URI as it is
> >> allowed to appear, not some intention about the parts that go into the
> >> URI. So as an example, if the syntax for the resource identifier in
> >> xmpp were something simple like
> >>      resource = *( 'a' / 'b' / 'c' / '?' )
> >> then the syntax for the resource component in the xmpp scheme syntax
> >> would have to read:
> >>      resource = *( 'a' / 'b' / 'c' / '%3F' / '%3f' )
> >> or so.

On re-reading rfc2396bis, it seems to me that this is handled by the rule 
contained in Section 2.2:

   If data for a URI component would conflict with a reserved 
   character's purpose as a delimiter, then the conflicting data 
   must be percent-encoded before forming the URI.

So rather than describing specifically how to handle the "?" character,
it seems best to include this general rule (since it might also apply
to any other character that might conflict with a reserved character).
Does this seem right?

> >> >2.3  Generation of XMPP URIs
> >> >
> >> >
> >> >   When generating an XMPP URI, the generating application SHOULD follow
> >> >   these steps:
> >>
> >> I'm probably repeating myself, but having these steps is in clear
> >> conflict with the
> >>     "xmpp:" jid [ "?" query ]
> >> syntax rule above. Either there is an actual jid in there, or it's
> >> something else that is the result of some processing. No shortcuts
> >> allowed .
> >
> >That text was discussed on the XMPP WG list in order to assist
> >implementers. But I don't understand your comment; the intent is that,
> >yes, there is an "actual JID" in there. Are you saying that Step 1
> >("Obtain XMPP address (JID).") is not right because a real JID would
> >already have passed Steps 2 and 3?
> 
> No. What I'm saying is that section 2.3 is basically right, but that
> the syntax of the xmpp URI has to be changed to include percent-encoding,
> in order to correctly reflect the result of the process described in 2.3.

I've attempted to do so in the preview release referred to at the 
beginning of this message, but in trying to do justice to rfc2396bis 
I may have strayed further from the text of the previous version, so 
corrections are welcome.

> >> >   2.  Perform [IDNA] translation against the JID (in the form of a
> >> >       UTF-8 string).
> >>
> >> What IDNA translation?
> >
> >I think that people on the XMPP WG list meant "conversion" rather than
> >"translation".
> 
> Way not clear enough. IDNA describes various 'conversions' or 
> 'translations',
> or whatever you call it, in different directions, and these also have
> some flags that affect what actually happens.

In fact it seems to me that IDNA conversion would refer only to the 
internationalized domain labels that make up an internationalized domain
name. Certainly it would not apply to the JID as a whole, and the flags
defined for IDNA are not appropriate for an XMPP node identifier or an
XMPP resource identifier. So I am not sure that any reference to the 
ToASCII conversion operation is appropriate here, or that it is truly
necessary to define how the UTF-8-to-ASCII conversion occurs. However,
if it *is* necessary, then we *could* define the conversion by means of
the ToASCII operation (though we would need to describe how the various
parts of a JID can be understood as labels in the IDNA sense), or we
could define the conversion by other means. How have other URI scheme
specifications dealt with this matter?

Thanks again.

Peter

--

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php

non-authoritative syntaxes for fragment identifiers

RE: non-authoritative syntaxes for fragment identifiers

I figured out that by 'AWWW', you meant http://www.w3.org/TR/webarch/,
which says:

# Parties that draw conclusions about the interpretation of a
# fragment identifier based solely on a syntactic analysis of
# all or part of a URI do so at their own risk; such interpretations
# are not authoritative because they are not licensed by specification.

AWWW has chosen to note that those who use something
non-standard do so 'at their own risk'. In this case,
the 'something non-standard' is 'interpretation of
a fragment identifier based solely on a syntactic
analysis of all or part of a URI'.  But in general,
those who use something non-standard do so 'at their
own risk'.

I think the wording in RFC 2396bis is fine, and that the
problem is with AWWW's wording. "at their own risk" is
short for "using non-standard behavior, standards don't
say what should happen, etc".

> although in some cases Internet media types owners may not
>  need/want to define a syntax, content owners may want to address
>  fragments of content, and have to define non-authoritative syntaxes.

But this isn't up to content owners. URIs are used for
communication from a reference sender ("hey, I want
you to look at URI blah blah fragment blah blah") 
to a reference receiver ("thanks, got it, I'll get that URI and
look up the fragment").
The reference sender needs to rely on a standard interpretation
of URIs and fragments to have any assurance that the reference
receiver will know what is meant. Having some private convention
that some receivers know and others don't just means that you're
relying on some out-of-band information, and the identifier isn't
really "U", you just have some other kind of Resource Identifier.

# in the future, it may be beneficial to establish common conventions 
# for addressing fragments consistently across multiple representations
# of a content.

Such proposals then should be reviewed as Proposed Standards
to update RFC2396bis.

# Indeed at the moment, very few Internet media types have defined a
# syntax for fragment identifiers.

It's certainly feasible to update media type registrations to
include this information (e.g., RFC3778 added fragment syntax
when updating a registered media type).

Larry
--

-- 
http://larry.masinter.net