I'd like to approach this from a non-conventional point of view.
The role of Q&A is to find what's not behaving regarding to what was required. That implies to me that a Q&A analyst must be aware of the requirements as much as the developer or even more.
One of the key aspects of the requirements is how a software must behave under the boundaries. If this is not defined, it's not the role of the Q&A to define it, but to seek clarifications from the Domain Experts (if this is a domain boundary) or Technical Experts (if this is a technical boundary) on how the software is expected to behave in these cases, and help the team to understand what's going on and to build a better product.
It's not the role of the Q&A to find an allegedly bug, report it and, let's say, forget it ("I did my job, I found the bug, I feel fine with myself, damn you developers do your work well!").
You're part of a team. You're helping building a product, and more often than not you're the last man standing between a release and a user. Understanding how your product must behave is just part of your job. The other part of your job is helping everyone on the team understand that too.
About your concrete case: What's the kind of information is expected in that field ? Is that a comment ? A question ? A BASE64 string to be used as a RSA Public Key ?
Depending upon the type of information you should have there, you may define that it's a bug (for a RSA Public Key, that would not allow you to copy it back) or not (if it's a comment field for English speakers only, it's not reasonable to think it as a bug). But either way, you should push people around to add the definition of the behavior to the formal requirements.