headers
Frank Ellermann | 1 Dec 2006 17:51
Picon
Picon

Re: snews 4395-review

Hi, 

I've replaced the "URI scheme semantics" section using
proposals by Ken Murchinson and Chris Newman (thanks!):

-  Like "news", but using NNTP over TLS with default
-  port 563 (no STARTTLS), registered as "nntps"

+  Syntactically equivalent to 'news', but using NNTP
+  over SSL/TLS (SSL/TLS with security layer is
+  negotiated immediately after establishing the TCP
+  connection) with a default port of 563, registered
+  as "nntps"

Frank
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 5 Dec 2006 17:23
Picon
Picon

draft-ellermann-news-nntp-uri-04


Discussion on this series of drafts so far has concentrated mainly on  
matters related to snews, registration of schemes, and so on. There has  
not been much said on the actual facilities to be accessed by the two  
schemes, or with the way they are described (and that has been largely  
because I have just not found the time to do it). Time to rectify that now.

So firstly, to deal with the facilities.

The chief change since your draft-00 is that you now admit wildmats in the  
news scheme (which is good, though not quite good enough) and the chief  
change you have *not* made is the introduction of ranges in the nntp  
scheme; what you say is

[RFC1738] has no <range> for the "nntp" 'nntp' URI scheme, and this memo
       isn't the place to invent new tricks for a rarely used scheme.

Let me make a general overall statement first:

Both these schemes are intended to provide access to resources available  
 from NNTP servers, usually using port 119. ISTM that when inventing a URI  
to interface to some particular protocol, you should aim to provide the  
maximum access to that protocol that can reasonably be defined. So if  
there is some feature of the protocol that cannot be accessed by that URI,  
then it is reasonable to ask "Why Not?"

So first consider using the news URI to gain access to particular  
newsgroups.

news:/comp.lang.c
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Ellermann | 5 Dec 2006 22:21
Picon
Picon

Re: draft-ellermann-news-nntp-uri-04


Charles Lindsey wrote:

> There has not been much said on the actual facilities to be accessed
> by the two schemes, or with the way they are described

It was clear that I'm not interested to make up new features, and want
to describe the schemes as they are used today, in many existing servers
and many existing clients.  It's still based on Paul's original idea,
and that deprecated the nntp scheme.

RFC 1738 and the Gilman draft also stated more or less clearly that the
nntp-scheme might be a bad idea.  So that's not the time to add ranges,
for starters I couldn't test it, none of my clients support this scheme.

While it's not more deprecated in the last drafts it's still discouraged
indirectly.  Rearranging the quotes:

> Again, you have a format for a whole group:

> nntp://server.example/comp/lang.c

> which was not actually allowed in RFC 1738, but might be useful even
> though it means the same as

> news://server.example/comp/lang.c

Oddly RFC 1738 allows the server + group syntax only for the
nntp-scheme.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 8 Dec 2006 15:36
Picon
Picon

Fwd: [EAI] Re: draft-ellermann-news-nntp-uri-04


On Tue, 05 Dec 2006 21:21:57 -0000, Frank Ellermann
<nobody <at> xyzzy.claranet.de> wrote:

> Charles Lindsey wrote:

>> Again, you have a format for a whole group:
>
>> nntp://server.example/comp/lang.c
>
>> which was not actually allowed in RFC 1738, but might be useful even
>> though it means the same as
>
>> news://server.example/comp/lang.c
>
> Oddly RFC 1738 allows the server + group syntax only for the
> nntp-scheme.

Yes, but the point I was trying to make is that you were introducing a new
feature not present in RFC 1738, which does not permit
"nntp://server.example/comp.lang.c" or
"nntp://server.example/comp.lang.c/" at all. Not that I object to that
(since I want to go further by adding <range>s), but you did not point out
that you were introducing an extension.

> It's frustrating for users if some URLs don't work for them.  It's also
> bad for the support stuff if they'd have to answer question why some
> fancy style of URLs for a protocol they've never before heard of (their
> own NNTP server) doesn't work.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frans Englich | 19 Dec 2006 10:23

Empty URI & URI references


Hello all,

Is an empty string a valid URI, URI reference, or both?

In my particular case I have a C++ class for representing URIs that for long 
has flagged empty strings as invalid, but when using it to implement 
specifications I am confronted with that some consider it wrong.

When one googles around on this topic one finds lots of confusion, and 
according to my reading, a slight leaning towards treating empty strings as 
valid:

* http://www.stylusstudio.com/xmldev/200404/post30160.html
* http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#URI_reference
* http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4478501
* RFC 2396, C.2. Abnormal Examples
* RFC 2396, 4.2. Same-document References

If I'm going to take a shot, I'd say that empty URIs are invalid, but empty 
URI references are valid.

I'd say that URI is more of an abstract concept, and that URI references is 
what we deal with. The latter being the shadow image of the perfect figure we 
cannot touch or see.

So, for a class that 'parses "URIs"', I'd say that accepting the empty string 
is the right thing to do.

Disentanglement, clarification would be highly appreciated.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Julian Reschke | 19 Dec 2006 15:42
Picon
Picon

Re: Empty URI & URI references


Frans Englich schrieb:
> Hello all,
> 
> Is an empty string a valid URI, URI reference, or both?
> 
> In my particular case I have a C++ class for representing URIs that for long 
> has flagged empty strings as invalid, but when using it to implement 
> specifications I am confronted with that some consider it wrong.
> 
> When one googles around on this topic one finds lots of confusion, and 
> according to my reading, a slight leaning towards treating empty strings as 
> valid:
> 
> * http://www.stylusstudio.com/xmldev/200404/post30160.html
> * http://en.wikipedia.org/wiki/Uniform_Resource_Identifier#URI_reference
> * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4478501
> * RFC 2396, C.2. Abnormal Examples
> * RFC 2396, 4.2. Same-document References

Well. I'd recommend to look at what's normative.

"URI" is defined in RFC3986, Section 3 
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3>), and 
obviously can not be empty.

"relative-ref" is defined in RFC3986, Section 4.2 
(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.4.2>), and 
can be empty.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Cowan | 19 Dec 2006 16:08

Re: Empty URI & URI references


Frans Englich scripsit:

> * RFC 2396, C.2. Abnormal Examples
> * RFC 2396, 4.2. Same-document References

Your difficulty is that you are working with RFC 2396 instead of its
replacement RFC 3986.  In 2396, there is no syntactic definition of
what a URI is; in 3986, there is (roughly an absolute URI with or
without a fragment identifier).

> If I'm going to take a shot, I'd say that empty URIs are invalid,
> but empty URI references are valid.

Exactly so.

--

-- 
What has four pairs of pants, lives             John Cowan
in Philadelphia, and it never rains             http://www.ccil.org/~cowan
but it pours?                                   cowan <at> ccil.org
        --Rufus T. Firefly
Permalink | Reply | 2 comments |
headers
Ted Hardie | 19 Dec 2006 20:59

Re: msrp and msrps URI scheme review

Reading through the definition, I am particularly concerned that we get
comments on the drafts' discussions of escaping.  As it stands now, the
draft says:

>
> If a userinfo component exists, it
>   MUST be constructed only from "unreserved" characters, to avoid a
>   need for escape processing.  Escaping MUST NOT be used in an MSRP
>   URI.  Furthermore, a userinfo part MUST NOT contain password
>   information.
>
>      The limitation of userinfo to unreserved characters is an
>      additional restriction to the userinfo definition in RFC3986.
>      That version allows reserved characters.  The additional
>      restriction is to avoid the need for escaping.
>
>   The following is an example of a typical MSRP URI:
>
>      msrp://host.example.com:8493/asfd34;tcp
>

RFC 3986 changed most instances of "escaped" to percent-encoded,
so it is probably better to use that language.    There are also a couple
of questions which come up.  RFC 3986 allows percent-encoding to be
used in reg-name,  so that it can be used to represent a host using
characters outside of the ASCII range:

  host        = IP-literal / IPv4address / reg-name
 reg-name    = *( unreserved / pct-encoded / sub-delims )
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frank Ellermann | 19 Dec 2006 23:03
Picon
Picon

Re: Empty URI & URI references


John Cowan wrote:

>> If I'm going to take a shot, I'd say that empty URIs are invalid,
>> but empty URI references are valid.

> Exactly so.

My browser doesn't grok href="", but gets the idea for href="#".
In the STD 66 syntax it's the <path-empty> case in chapter 4.2.

Frank
Permalink | Reply | 0 comments |
headers
Frans Englich | 20 Dec 2006 09:34

Re: Empty URI & URI references


On Tuesday 19 December 2006 16:08, John Cowan wrote:
> Frans Englich scripsit:
> > * RFC 2396, C.2. Abnormal Examples
> > * RFC 2396, 4.2. Same-document References
>
> Your difficulty is that you are working with RFC 2396 instead of its
> replacement RFC 3986.

It indeed is, but as long as the specific code in question stays with RFC 
2396, I have as well :|

> > In 2396, there is no syntactic definition of  
> what a URI is; in 3986, there is (roughly an absolute URI with or
> without a fragment identifier).
>
> > If I'm going to take a shot, I'd say that empty URIs are invalid,
> > but empty URI references are valid.

Which further makes me conclude that allowing the empty string for the class 
in question would be the right thing since it's dealing with URI references 
rather than URIs, because it for example accept relative URIs and performs 
resolution between URI references.

Cheers,

		Frans
Permalink | Reply | 0 comments |

Gmane