Frank Ellermann | 3 Dec 01:15 2004
Picon
Picon

Re: I-D ACTION:draft-hoffman-news-nntp-uri-03.txt


Paul Hoffman wrote:

> http://www.ietf.org/internet-drafts/draft-hoffman-news-nntp-uri-03.txt

Thanks.  Four minor points, you still say:

| Because that document has been moved to Historic status,
| this document copies the news and nntp URI schemes from
| it to allow that material to remain on standards track.

That's IMO backwards, you don't do it because RfC 1738 is
historic, but because you want RfC 1738 to be historic, as
stated in the abstract.  Your drafts are hens, not eggs ;-)

| <id-left> and <id-right> are defined in Section 3.6.4 of
| RFC 2822 [RFC2822].

You have this in section 2.1 about the <newsgroup-name>,
but you need it either in 2.3 about the <message-id> or in
the 2. intro with the ABNF.

Third minor point, your ABNF doesn't cover two simple cases:

<news://news.spamcop.net/≥
<news://news.spamcop.net>

My UA handles this like <news://news.spamcop.net/*> - that
is of course no argument and only an observation.  If you
want to sanction this behaviour (because it's the same idea
(Continue reading)

Frank Ellermann | 3 Dec 01:42 2004
Picon
Picon

Re: I-D ACTION:draft-hoffman-ftp-uri-03.txt


P. Hoffman wrote draft-hoffman-ftp-uri-03.txt :

| ALUN'S CONCERN
|
| email addresses can be harvested

That's true, but I'd prefer a complete sentence, how about:

  The e-mail address conventionally sent as password for
  anonymous access (2.1) could be harvested, user agents
  should not sielently use addresses configured for other
  purposes.

| <cwd1> through <cwdN> and <name> are (possibly encoded)
| strings

Is that really all you want to say about percent-encoding ?
It took me some hours to find the problem with %FF for an
ordinary command line client, it's hidden in RfC 1123 3.2.6:

| a Telnet escape character (known as IAC, with the value
| 255) to be sent as data MUST be doubled.

Who's supposed to know this, the publisher of the ftp-URI,
or the user agent ?  Certainly not the user.  Bye, Frank

Picon

Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs

>>>>> On Fri, 19 Nov 2004 19:03:51 -0800, 
>>>>> "Roy T. Fielding" <fielding <at> gbiv.com> said:

> I don't think that they are actively used for significant operations.
> Yes, they are implemented (inconsistently) on multiple platforms
> (some allow names to occur after the '%", while others assume that
> the zone ID will be a small integer),

(a minor note) draft-ietf-ipv6-scoping-arch-02.txt specifies integers
as the minimum set of scope zone IDs that all implementations must
support.  All compliant specifications must accept decimal integers,
and *BSDs should behave so, although it prints attached interface name
by default.

> There is nothing we can do in the specifications to change the
> fact that using a % as a zone ID separator in URIs will result in
> interoperability failures.  Those applications are already deployed.
> It would be easier to change all of the deployed operating systems
> that contain IPv6 to allow an additional delimiter character if
> cut-and-paste is really important.

I don't buy this argument.  We can also say that system libraries with
'%' '%' as the delimiter and applications using the libraries are
already deployed.  As others already said, BSDs have been using for
several years, which is also merged into MacOS X.  In addition, as far
as I know recent versions of Windows and Linux implementations adopt
this specification.  I would say that saying "these are not actively
used for significant operations." is misleading.  First of all, what
"significant operations" mean is really not clear.  Additionally, why
can we be so sure that they are not actively used without knowing how
(Continue reading)

Picon

Re: An Internet-Draft on literal scoped addresses with accompanying zone IDs in URIs

>>>>> On Fri, 19 Nov 2004 15:57:06 -0500, 
>>>>> Bill Fenner <fenner <at> research.att.com> said:

>> My dump question (that exposes my lack of knowledge about URIs/etc.) is 
>> since the literal IPv6 address are enclosed in "[" "]" to allow for the ":" 
>> in the literal IPv6 address, why can't the "%" be used in the same 
>> way?  For example:
>> 
>> http://[fe80::20d:60ff:fe2f:8df5%4]
>> 
>> Please excuse my ignorance on this, but it would be good to explain this 
>> (and include this information in the draft).

(snip)

> The basic issue is how special % is in URLs, because of
> percent-encoding.  Section 2.4 of draft-fielding-uri-rfc2396bis
> (the full Standard URI spec, currently in the RFC-Editor's queue)
> says:

>    Because the percent ("%") character serves as the indicator for
>    percent-encoded octets, it must be percent-encoded as "%25" in order
>    for that octet to be used as data within a URI.

> The newer IRI spec (in IESG Evaluation; draft-duerst-iri-10.txt)
> specifies an encoding of URIs to IRIs that assumes that any percent
> anywhere in the URI begins a percent-encoded octet.  Allowing a
> bare "%" would complicate these rules quite a bit.  There would be
> no way to know without parsing the URI further whether the % began
> a %-encoded octet or not.
(Continue reading)

Bruce Lilly | 5 Dec 20:07 2004
Picon

draft-fielding-uri-rfc2396bis-07 ABNF


The subject draft states:

   The ABNF for URI and URI-reference has been redesigned to make them
   more friendly to LALR parsers and reduce complexity.

However, attempting to use that ABNF with an LALR parser yielded
literally hundreds of shift/reduce and (more importantly)
reduce/reduce conflicts.  A GLR parser was fare any better with the
ABNF.

Are there any implementations using the ABNF as specified in the draft?

Bruce Lilly | 5 Dec 22:00 2004
Picon

Re: draft-fielding-uri-rfc2396bis-07 ABNF


On Sun December 5 2004 14:07, Bruce Lilly wrote:
> A GLR parser was fare any better with the

"unable to" should appear before "fare".

Graham Klyne | 6 Dec 18:00 2004

Re: draft-fielding-uri-rfc2396bis-07 ABNF


At 14:07 05/12/04 -0500, Bruce Lilly wrote:

>The subject draft states:
>
>    The ABNF for URI and URI-reference has been redesigned to make them
>    more friendly to LALR parsers and reduce complexity.
>
>However, attempting to use that ABNF with an LALR parser yielded
>literally hundreds of shift/reduce and (more importantly)
>reduce/reduce conflicts.  A GLR parser was fare any better with the
>ABNF.
>
>Are there any implementations using the ABNF as specified in the draft?

My Haskell implementation [1] is hand-coded, but attempts to follow the 
given syntax very closely.  But my approach is top-down, not LALR, so that 
probably doesn't answer your question.

#g
--

[1] http://www.ninebynine.org/Software/HaskellUtils/Network/URI.hs
     http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/network/Network/URI.hs

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

(Continue reading)

Bruce Lilly | 6 Dec 19:34 2004
Picon

Re: draft-fielding-uri-rfc2396bis-07 ABNF


On Mon December 6 2004 12:00, Graham Klyne wrote:

> >Are there any implementations using the ABNF as specified in the draft?
> 
> My Haskell implementation [1] is hand-coded, but attempts to follow the 
> given syntax very closely.  But my approach is top-down, not LALR, so that 
> probably doesn't answer your question.

Thanks for the pointers, but you're right that it doesn't answer
my question.  My concern is with the specification of the
grammar, which I believe to be incomplete (and therefore
unimplementable as an LALR parser in a manner which
guarantees interoperability) as there is no specified set of
precedence relationships necessary to resolve the existing
conflicts (ideally, there are no conflicts in a well-designed
grammar).

Alun Jones | 7 Dec 01:35 2004
Picon

RE: I-D ACTION:draft-hoffman-ftp-uri-03.txt


I think it'd be more appropriate to simply note the potential for
address harvesting _if_ the recommendation to use an email address as
the password is followed, and allow implementors to determine whether
that's a privacy risk for their application, and how best to handle it.
You do have to wonder who would be downloading from an FTP site whose
owners were not trustworthy enough to leave an email address alone!

On the topic of encoding, it would seem obvious that the URI should
contain encoded characters for those characters that a) are best encoded
(non-printables, for instance), or b) require encoding (any of
"%/;<CR><LF><NUL>").  The URI should be parsable into elements by
splitting at slashes and the semi-colon, after which time the individual
components can be percent-decoded.  The FTP client implementation is
knowledgeable about the fact that FTP uses the Telnet protocol
underneath, and so should be responsible for the encoding ( FF doubling,
for instance, or adding <NUL> after <CR>).  The URI itself shouldn't
contain a doubled FF - that's putting too much of a requirement on the
users who craft URIs to objects.

Another item I noted is section 2.1, "If no user name or password is
supplied, and one is requested by the FTP server,..."  FTP never
requests a user name or password.  It greets you with a 220, and it
refuses you access with a 530 error if you try to do an action that is
prohibited because you are not logged on.  The FTP client should always
send the anonymous user name and password if no user name (and you
should be disallowed from sending a password with no username) has been
supplied.

Note also that 2396bis says that userinfo containing a password is
(Continue reading)

Graham Klyne | 7 Dec 12:14 2004

Re: draft-fielding-uri-rfc2396bis-07 ABNF


Bruce,

I think you need to be careful about conflating a grammar as a 
specification of correct sentences (and correspo0nding parse trees) with a 
grammar as guiding a particular parser implementation.  The importance of 
grammars satisfying certain properties for LL(1) or LALR parser generation 
is that they permit creation of the parse tree without backtracking.

In this case, I think it's sufficient that the grammar satisfies the former 
purpose;  implementation is a matter for the, er, implementer.

#g
--

At 13:34 06/12/04 -0500, Bruce Lilly wrote:

>On Mon December 6 2004 12:00, Graham Klyne wrote:
>
> > >Are there any implementations using the ABNF as specified in the draft?
> >
> > My Haskell implementation [1] is hand-coded, but attempts to follow the
> > given syntax very closely.  But my approach is top-down, not LALR, so that
> > probably doesn't answer your question.
>
>Thanks for the pointers, but you're right that it doesn't answer
>my question.  My concern is with the specification of the
>grammar, which I believe to be incomplete (and therefore
>unimplementable as an LALR parser in a manner which
>guarantees interoperability) as there is no specified set of
(Continue reading)


Gmane