Subject: RE: Character encoding for Netconf messages?

From: "Kent Watsen" <[email-masked]>
Date: Wed, 9 Aug 2006 15:18:05 -0700

Should the WG decide which approach NetConf uses?

Seem like its going to be one of:

	1. Only UTF-8 (no XML declaration not needed per message)
	2. At least UTF-8 (XML declaration needed per message)

Either way, the spec needs to be updated to document the decision

Thanks!
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of McDonald, Ira
Sent: Saturday, July 29, 2006 11:02 AM
To: 'Andy Bierman'; Randy Presuhn
Cc: [email-masked]
Subject: RE: Character encoding for Netconf messages?

Hi,

The IESG policy on charsets has been stable for years,
since publication of BCP 18/RFC 2277 (January 1998).
Verbatim from section 3.1 'What charset to use':

  "All protocols MUST identify, for all character data, which charset is
   in use.

   Protocols MUST be able to use the UTF-8 charset, which consists of
   the ISO 10646 coded character set combined with the UTF-8 character
   encoding scheme, as defined in [10646] Annex R (published in
   Amendment 2), for all text.

   Protocols MAY specify, in addition, how to use other charsets or
   other character encoding schemes for ISO 10646, such as UTF-16, but
   lack of an ability to use UTF-8 is a violation of this policy; such a
   violation would need a variance procedure ([BCP9] section 9) with
   clear and solid justification in the protocol specification document
   before being entered into or advanced upon the standards track."

So, either an IETF standards-track protocol MUST only support
UTF-8 (so that tagging is irrelevant over the wire) or it MUST
always tag the charset in use in every over-the-wire message.

If Netconf permits the use of UTF-16 over the wire without an
'encoding' attribute in the XML declaration, then Netconf needs
a variance - not easy to get.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Andy Bierman
> Sent: Wednesday, July 26, 2006 6:56 PM
> To: Randy Presuhn
> Cc: [email-masked]
> Subject: Re: Character encoding for Netconf messages?
> 
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> > If we specify a mandatory-to-implement encoding, I'd 
> strongly suggest
> > that it be UTF-8.
> > 
> 
> Excellent topic for a VERY TBD WG work item!!!  :-)
> 
> (I agree with you, but I'm coding for internationalization.)
> 
> That's not an easy decision, or one that should be made
> as part of some ad-hoc design process.
> 
> 
> > Randy
> 
> Andy
> 
> 
> > 
> > ----- Original Message ----- 
> > From: "Kent Watsen" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Tuesday, July 25, 2006 7:46 PM
> > Subject: Character encoding for Netconf messages?
> > 
> > 
> > 
> > 
> > The Netconf spec does not require XML declarations (i.e. <?xml
> > version="1.0" encoding="UTF-8" ?>).  However, both the SSH and SOAP
> > mapping specs show the use of XML declarations; though the 
> BEEP mapping
> > spec does not...  
> > 
> >  
> > 
> > Should NetConf specify a mandatory encoding (e.g. USASCII) 
> or leave it
> > up to implementations to decide?   If it is up to the 
> implementations to
> > decide, then would that require the client to defer sending 
> its <hello>
> > until after receiving the server's <hello> in order to determine the
> > encoding to use?
> > 
> >  
> > 
> > Would it make sense for the <hello> to be USASCII and to list all
> > supported encodings as capabilities? - this seems flexible 
> but then the
> > NetConf spec would need to require an XML declaration on 
> every message
> > 
> >  
> > 
> > Thanks!
> > 
> > Kent
> > 
> >  
> > 
> > --
> > 
> > Kent Watsen
> > 
> > Software Architect
> > 
> > Juniper Networks
> > 
> >  
> > 
> > 
> > 
> > 
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://ops.ietf.org/lists/netconf/>
> > 
> > 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.5/403 - Release Date:
7/28/2006

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Aug 2006 15:43:01 -0700

Hi -

> To: "McDonald, Ira" <[email-masked]>; "Andy Bierman" <[email-masked]>; "Randy Presuhn"
<[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, August 09, 2006 3:18 PM
...
> 2. At least UTF-8 (XML declaration needed per message)
...

I think (1) makes sense.  I haven't heard any convincing
arguments that (2) would be worth the hassle.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Aug 2006 15:56:56 -0700

> Either way, the spec needs to be updated to document the decision

I disagree.
Why does the NETCONF protocol have to specify the XML encoding scheme?
That is part of the "XML header" or the "data model framework",
but not really something that should be mandated right now
in the protocol WG.

Doesn't this depend on the data models and features of the agent?

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 9 Aug 2006 17:27:42 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Kent Watsen" <[email-masked]>
> Cc: "McDonald, Ira" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, August 09, 2006 3:56 PM
...
...

BCP 18 (RFC 2277) clause 3.1:

| 3.1.  What charset to use
|
|   All protocols MUST identify, for all character data, which charset is
|   in use.

Seems rather clear.  Are you proposing that we ask the IESG for
an exception?

BCP 18 continues:

|   Protocols MUST be able to use the UTF-8 charset, which consists of
|   the ISO 10646 coded character set combined with the UTF-8 character
|   encoding scheme, as defined in [10646] Annex R (published in
|   Amendment 2), for all text.

This also seems rather clear.

What's the rationale for not addressing these requirements?

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Aug 2006 17:41:38 -0700

> What's the rationale for not addressing these requirements?

none I guess.
Since the requirements are so clear, there isn't
anything to discuss, and the documentation requirement
is just another CLR -- NETCONF uses the UTF-8 charset.

Andy