Greetings,
Is there a specific reason, that maximum length of subjects for tickets
are 200 character? Wouldn’t it be better if the number of character is
higher or unlimited?
Michael Peer
I&CT
EURAC research
Viale Druso/Drususallee 1
39100 Bolzano/Bozen
Italy
Email: michael.peer@eurac.edu mailto:.michael.peer@eurac.edu
Website: www.eurac.edu http://www.eurac.edu/
Greetings,
=20
Is there a specific reason, that maximum length of subjects for tickets
are 200 character? Wouldn’t it be better if the number of character is
higher or unlimited?
Unlimited is what the body is for. The whole point of a subject
(in email, rt, or a general headline in a newspaper) is
“microcontent”, a very concise summary that you can show
in a list and read at a glance.
bobg
Greetings,
=20
Is there a specific reason, that maximum length of subjects for tickets
are 200 character? Wouldn’t it be better if the number of character is
higher or unlimited?
Unlimited is what the body is for. The whole point of a subject
(in email, rt, or a general headline in a newspaper) is
“microcontent”, a very concise summary that you can show
in a list and read at a glance.
But nothing bad will happen if you change the field definition in RT and
in the database.
Thanks for the respons.
Another thing. I updated my database from rt-2.0.4 to rt-3.4.5. I see,
that the update-scrips don’t not change the type of the column data in
the table transactions from character varying(100) to character
varying(255). Now I become the followig error:
value too long for type character varying(100) (/opt/rt3/lib/RT.pm:287)
Dec 4 10:56:09 xxxxxxx RT: RT::Handle=HASH(0xae0afa4) couldn’t execute
the query 'INSERT INTO Transactions
It would be grate, if you could insert this in the database
update-scripts.
Thanks
Michael PeerFrom: rt-devel-bounces@lists.bestpractical.com
[mailto:rt-devel-bounces@lists.bestpractical.com] On Behalf Of Jesse
Vincent
Sent: Wednesday, 06 December, 2006 21:52
To: Bob Goldstein
Cc: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] Subject length
Greetings,
=20
Is there a specific reason, that maximum length of subjects for
tickets are 200 character? Wouldn’t it be better if the number of
character is higher or unlimited?
Unlimited is what the body is for. The whole point of a subject
(in email, rt, or a general headline in a newspaper) is
“microcontent”, a very concise summary that you can show
in a list and read at a glance.
But nothing bad will happen if you change the field definition in RT and
in the database.
bobg
=20
=20
Michael Peer
I&CT
EURAC research
Viale Druso/Drususallee 1
39100 Bolzano/Bozen
Italy
Email: michael.peer@eurac.edu mailto:.michael.peer@eurac.edu=20
Website: www.eurac.edu http://www.eurac.edu/=20
=20
------_=_NextPart_001_01C71972.1F271BCF
Content-Type: text/html;
charset=“us-ascii”
Content-Transfer-Encoding: quoted-printable
Greetings,
Is there a=20 specific reason, that maximum length of
subjects for tickets are = 200=20 character? Wouldn't it be
better if the number of character is higher or =
unlimited?
<?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" =
/>
Michael=20
Peer
I&CT
_______________________
EURAC =
research
Viale=20 Druso/Drususallee 1
39100
Bolzano/Bozen
<?xml:namespace prefix =3D =
st1 ns =3D=20
"urn:schemas-microsoft-com:office:smarttags" /><st1:country-region=20
w:st=3D"on"><st1:place=20
w:st=3D"on">Italy</st1:place></st1:country-region>
Email:=20
<FONT face=3D"Trebuchet MS" size=3D2><SPAN lang=3DDE=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: ‘Trebuchet MS’“><A=20
title=3Dmailto:—.—@eurac.edu =
href=3D"mailto:.michael.peer@eurac.edu”><FONT=20
title=3Dmailto:—.—@eurac.edu color=3Dblack><SPAN =
title=3Dmailto:—.—@eurac.edu=20
style=3D"COLOR: =
black">michael.peer@eurac.edu<FONT=20
face=3D"Trebuchet MS" size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: ‘Trebuchet
MS’">
Website:=20 <A title=3Dhttp://www.eurac.edu/ =
href=3D"http://www.eurac.edu/“><FONT=20
title=3Dhttp://www.eurac.edu/ face=3D"Trebuchet MS” color=3Dblack =
size=3D2><SPAN=20 title=3Dhttp://www.eurac.edu/=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: ‘Trebuchet =
MS’">www.eurac.edu<o:p></o:p>
------_=_NextPart_001_01C71972.1F271BCF–
–===============1857492103==
Content-Type: text/plain; charset=“us-ascii”
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
List info:
The rt-devel Archives
–===============1857492103==–
List info:
The rt-devel Archives
List info:
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
But nothing bad will happen if you change the field definition in RT and
in the database.
Something bad might happen in email. RFC 2822 says this:
There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
A
Andrew Sullivan | ajs@crankycanuck.ca
Information security isn’t a technological problem. It’s an economics
problem.
–Bruce Schneier
But nothing bad will happen if you change the field definition in RT and
in the database.
Something bad might happen in email. RFC 2822 says this:
There are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
But that’s “perl line” and not “per header”, so if we’re foldking
headers, we should be ok, right?
But that’s “perl line” and not “per header”, so if we’re foldking
headers, we should be ok, right?
Correct. The subject header, according to 2822, is of possibly
indeterminate length, as long as you’re folding. (Which is why I
said “might”: I didn’t know if you were folding.)
A
Andrew Sullivan | ajs@crankycanuck.ca
If they don’t do anything, we don’t need their acronym.
–Josh Hamilton, on the US FEMA