headers
Lisa Dusseault | 1 Oct 19:33
Favicon

Re: Dates for architecture workshop


On Sep 27, 2007, at 9:32 PM, Dave Crocker wrote:

>
> Lisa Dusseault wrote:
>>  - The topic is intended to be Apps area common architecture (some  
>> such pieces which already exist include SASL, LDAP, URLs, MIME  
>> types).  Any topic should relate to more than one application.
>>  - We would like this to be a working meeting. We may break people  
>> out forcibly into twos or threes to actually write stuff (email,  
>> proposals, I-D text,  etc) but we'll also have some discussion as  
>> a big group.
>
>
> Lisa,
>
> I've re-read your note a few times and while I think I understand  
> the concept of "common architecture" I am not understanding what  
> you mean by "position papers".
>
> Can you clarify what sorts of architectural problems are motivating  
> the event, what sorts of issues you are looking to have addressed,  
> what sorts of follow-on actions you are seeking, etc.?

I'm hoping for community input on what sort of issues need to be  
addressed, rather than drive the agenda myself and end up with nobody  
doing the actual work :)

This may be obvious, but I think the reason for a special venue and  
the topic of *common* architecture is to get people talking who
(Continue reading)

Permalink | Reply | 0 comments |
headers
tom.petch | 1 Oct 13:01

Re: Dates for architecture workshop

----- Original Message ----- 
From: "Lisa Dusseault" <lisa <at> osafoundation.org>
To: "John C Klensin" <john-ietf <at> jck.com>
Cc: "Apps Discuss" <discuss <at> apps.ietf.org>
Sent: Thursday, September 27, 2007 6:41 PM
Subject: Re: Dates for architecture workshop

> I think that conflict is livable, and since the dates work well for  
> CalConnect people and for me and Chris, I'd like to nail those dates  
> down.  Please put Feb 11/12 on your calendar if you're interested in  
> participating.
> 
> We haven't nailed down all the details yet, but here's the rough idea:
> 
>   - The topic is intended to be Apps area common architecture (some  
> such pieces which already exist include SASL, LDAP, URLs, MIME  
> types).  Any topic should relate to more than one application.

Like

 - XML as a protocol definition language
 - XML as a data definition (/information /model) language

Tom Petch

>   - We would like this to be a working meeting. We may break people  
> out forcibly into twos or threes to actually write stuff (email,  
> proposals, I-D text,  etc) but we'll also have some discussion as a  
> big group.
>   - We would like participation to be open to people who aren't
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 4 Oct 23:10

draft-klensin-net-utf8 and draft-klensin-unicode-escapes

Hi.

After a long delay, I'm in the process or updating both of these
documents.  Very high-level summary of changes:

  ------
draft-klensin-unicode-escapes
  -04 has been posted.   It has been reorganized to make it
easier to follow and to respond to comments from several people
on and off the list.  It now recommends either \u'NNNN..' or the
XML form and recommends against the others (and explains why).
I think (hope?) that is consistent with general consensus.  The
alternative is to make no recommendation at all, which rather
misses the point, I think (and some others seem to think so as
well).

Chris Newman suggested one additional change, which was to move
the syntax for the not-recommended options into an appendix so
as to further discourage their use.  I think that is reasonable,
but it didn't make -04.   -05 will be posted, presumably within
the next 24 hours if the online tool works this time, but that
is the only substantive change from -04.

 -------

draft-klensin-net-utf8
  This document has been considerably reworked, with some
requirements lowered to SHOULD and others promoted to MUST per
online discussions.  Most of the former introductory material
and explanations of Net-ASCII have been moved to appendices and
(Continue reading)

Permalink | Reply | 7 comments |
headers
Stephane Bortzmeyer | 5 Oct 16:24
Picon

Encoding of small characters in draft-klensin-unicode-escapes-04

On Thu, Oct 04, 2007 at 05:10:43PM -0400,
 John C Klensin <john-ietf <at> jck.com> wrote 
 a message of 49 lines which said:

> It now recommends either \u'NNNN..' 

[Small syntax detail, do not spend too much time on it.]

Section 5.1 describes the content of the "Backslash-U with Delimiters"
form as "4*6HEXDIG". Why not "2*6HEXDIG"? It would be more compact for
the first characters and would be more consistent with the other forms
such as the "XML and HTML" one.

My personal taste is that \u'20' is better than \u'0020'.

Section 6.2 contains a note which seems related (the risk that small
numbers are thought to represent octets, in the current locale) but I
do not think it is a serious risk since section 2 clearly states that
we encode Unicode code points, not octets.
Permalink | Reply | 1 comment |
headers
Stephane Bortzmeyer | 5 Oct 17:07
Picon

Re: I-D Action:draft-klensin-net-utf8-04.txt

On Fri, Oct 05, 2007 at 01:40:02AM -0400,
 Internet-Drafts <at> ietf.org <Internet-Drafts <at> ietf.org> wrote 
 a message of 91 lines which said:

> 	Title           : Unicode Format for Network Interchange
> 	Author(s)       : J. Klensin, M. Padlipsky
> 	Filename        : draft-klensin-net-utf8-04.txt

I have read and studied this I-D and I find it basically OK, suitable
for approval and very useful for the Internet, where
internationalization is an important issue.

I have some reservations, which are mostly details:

> Section 1.1 [...] preferred to the double-byte encoding of "extended
> ASCII" [RFC0698]

This reference to a very obsolete system does not bring useful
information. Delete it or move it to the interesting "History and
Context" appendix.

> Section 2.1 [...] None of those uses is inappropriate for streams of
> plain text.

Isn't it a typo? It should be "appropriate".

> Section 3 [...] Recognition of the fact that some applications
> implementations may rely on operating system libraries over which
> they have little control and adherence to the robustness principle
> suggests that receivers of such strings should be prepared to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stephane Bortzmeyer | 5 Oct 17:12
Picon

Form feed in Net-UTF8? (Was: FWD: Re: Comments on Unicode Format for Network Interchange

Doug Ewell said:

> > I recommend that the control code FF (form feed, U+000C) be
> > likewise permitted.  The form feed function is well known and well
> > defined in almost all printing functions, and all RFCs issued in
> > modern times use FF to separate pages.  It would ironic indeed for
> > the Internet-Draft to retain the requirement that form feeds
> > "SHOULD NOT be used unless required by exceptional circumstances"
> > while advancing toward publication as an RFC, complete with form
> > feeds!

And I did not see anywhere a discussion of this specific point. I
notice that draft-klensin-net-utf8-04 still disallows (actually, it is
a SHOULD NOT in section 2.1) form feeds and I'm not sure of the
rationale. Why end-of-lines and not end-of-pages?
Permalink | Reply | 8 comments |
headers
John C Klensin | 5 Oct 17:30

Re: Encoding of small characters in draft-klensin-unicode-escapes-04


--On Friday, 05 October, 2007 16:24 +0200 Stephane Bortzmeyer
<bortzmeyer <at> nic.fr> wrote:

> On Thu, Oct 04, 2007 at 05:10:43PM -0400,
>  John C Klensin <john-ietf <at> jck.com> wrote 
>  a message of 49 lines which said:
> 
>> It now recommends either \u'NNNN..' 
> 
> [Small syntax detail, do not spend too much time on it.]
> 
> Section 5.1 describes the content of the "Backslash-U with
> Delimiters" form as "4*6HEXDIG". Why not "2*6HEXDIG"? It would
> be more compact for the first characters and would be more
> consistent with the other forms such as the "XML and HTML" one.
> 
> My personal taste is that \u'20' is better than \u'0020'.

First, I want to be clear that I don't feel strongly about any
of this and will do what the community wants.   However...

One could use the two-digit form, but I think it is trouble.
The Unicode folks,
whose guidance I'm trying to follow except when it seems to
violate good Internet or applications sense, never use less than
four hex digits.  And we have the problem with Perl (noted in
that section now) that two-digit values are sometimes
interpreted as ASCII and sometimes as "local one-octet character
encoding, whatever that is".  So the four-digit form helps
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 5 Oct 17:54

Re: I-D Action:draft-klensin-net-utf8-04.txt


--On Friday, 05 October, 2007 17:07 +0200 Stephane Bortzmeyer
<bortzmeyer <at> nic.fr> wrote:

> On Fri, Oct 05, 2007 at 01:40:02AM -0400,
>  Internet-Drafts <at> ietf.org <Internet-Drafts <at> ietf.org> wrote 
>  a message of 91 lines which said:
> 
>> 	Title           : Unicode Format for Network Interchange
>> 	Author(s)       : J. Klensin, M. Padlipsky
>> 	Filename        : draft-klensin-net-utf8-04.txt
> 
> I have read and studied this I-D and I find it basically OK,
> suitable for approval and very useful for the Internet, where
> internationalization is an important issue.
> 
> I have some reservations, which are mostly details:
> 
>> Section 1.1 [...] preferred to the double-byte encoding of
>> "extended ASCII" [RFC0698]
> 
> This reference to a very obsolete system does not bring useful
> information. Delete it or move it to the interesting "History
> and Context" appendix.

Officially, RFC698 is not obsolete and applies specifically to
NVT-like streams, which is why it seemed worth singling out. The
spec should have listed "obsoletes RFC 698", which means that
this can't be in a section that is purely informative.  I'll try
to figure out a better way to handle it, but am going to leave
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 5 Oct 17:57

Re: Form feed in Net-UTF8? (Was: FWD: Re: Comments on Unicode Format for Network Interchange


--On Friday, 05 October, 2007 17:12 +0200 Stephane Bortzmeyer
<bortzmeyer <at> nic.fr> wrote:

> Doug Ewell said:
> 
>> > I recommend that the control code FF (form feed, U+000C) be
>> > likewise permitted.  The form feed function is well known
>> > and well defined in almost all printing functions, and all
>> > RFCs issued in modern times use FF to separate pages.  It
>> > would ironic indeed for the Internet-Draft to retain the
>> > requirement that form feeds "SHOULD NOT be used unless
>> > required by exceptional circumstances" while advancing
>> > toward publication as an RFC, complete with form feeds!
> 
> And I did not see anywhere a discussion of this specific
> point. I notice that draft-klensin-net-utf8-04 still disallows
> (actually, it is a SHOULD NOT in section 2.1) form feeds and
> I'm not sure of the rationale. Why end-of-lines and not
> end-of-pages?

Because line breaks are required even for unformatted streams.
FormFeeds are not.  

But I find the above arguments reasonably persuasive and will
put FF back in unless others feel strongly about this.

    john
(Continue reading)

Permalink | Reply | 6 comments |
headers
Clive D.W. Feather | 5 Oct 18:20

Re: draft-klensin-net-utf8 and draft-klensin-unicode-escapes

John C Klensin said:
> draft-klensin-unicode-escapes
>   -04 has been posted.   It has been reorganized to make it
> easier to follow and to respond to comments from several people
> on and off the list.

First thing I spotted: the syntax in 5.1 is missing the trailing quote mark.

Section 4 is missing the references to ISO-C and Java.

> draft-klensin-net-utf8

Section 2.1 item 3: "control characters" needs to be properly defined,
since it's a SHOULD. Unicode.org is currently offline, but at the least
you either need to make it explicit ranges (say U+0000 to U+001F and U+007F
to U+009F), or base it on a Unicode character class.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |
Permalink | Reply | 4 comments |

Gmane