getElementsByName doesn't work on FireFox in some cases.

B

briggs

<html>
<head>
<script>
/* AddChild */
function ac()
{
var c;
var p = document.getElementById("p");
for (var i = 0; i < 5; i++) {
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
}
}

/* CountChildren */
function cc()
{
// The number of children is the number of elements whose name is
'ch'
var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);
}
</script>
</head>
<body onload="ac();">
<div id="p">parents:</div>
<input type="button" value="How many children 'parents' has?"
onclick="cc();">
</body>
</html>
 
R

RobG

briggs wrote:

Please post plain text only.

[...]
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
[...]

var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements. If you check the
elements, they have a 'name' attribute but it is not recognised by
getElementsByName.

Insert elements that can have a name (say INPUTs) and it works.

[...]
 
B

briggs

Thanks, Rob

'name' is not a valid attribute for div elements.
But, the following code works well in Firefox.

<html>
<head>
<script>
/* CountChildren */
function cc()
{
// The number of children is the number of elements whose name is
'ch'
var c = document.getElementsByName('ch');

// Both IE and Firefox reports 5.
alert(c.length);
}

</script>
</head>
<body>
<div id="p">parents:
<div name="ch">child 0</div>
<div name="ch">child 1</div>
<div name="ch">child 2</div>
<div name="ch">child 3</div>
<div name="ch">child 4</div>
<input type="button" value="How many children 'parents' has?"
onclick="cc();">
</body>
</html>

I think...
if the above code works, the codes in my first post should work too.
 
T

Thomas 'PointedEars' Lahn

RobG said:
briggs wrote:

Please post plain text only.

He/she did:

| Content-Type: text/plain; charset="euc-kr"
[...]
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
[...]

var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements.
True.

If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null
but it is not recognised by getElementsByName.

Which is the reason of this.
Insert elements that can have a name (say INPUTs) and it works.

True.


PointedEars
 
T

Thomas 'PointedEars' Lahn

briggs said:
'name' is not a valid attribute for div elements.
But, the following code works well in Firefox.

If that works, it is due to you triggering Quirks Mode or simply a bug.
Whatever is the cause, it is nothing you should rely on.

The DOCTYPE declaration is missing, which triggers Quirks Mode.
<head>
<script>

Should be


I think...
if the above code works, the codes in my first post should work too.

Not necessarily.


PointedEars
 
R

RobG

Thomas said:
RobG wrote:




He/she did:

| Content-Type: text/plain; charset="euc-kr"

Yeah, sorry to the OP, the different encoding threw me.

[...]

c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
c.innerHTML = "child " + i;
p.insertBefore(c, null); // Add 'div' element as child.
[...]


var c = document.getElementsByName('ch');

// IE6 reports 5, but Firefox reports 0. why?
// getElementsByName doesn't work on FireFox?
alert(c.length);

'name' is not a valid attribute for div elements.

True.


If you check the elements, they have a 'name' attribute


False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>

<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
</html>


I got:

hasAttribute name in x x.name
Firefox false true fred
Safari false true fred
Opera false true fred


However, add the name attribute in the HTML and not in the script:

<div id="steve" name="fred">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>


and you get the opposite (almost):

hasAttribute name in x x.name
Firefox true false undefined
Safari true false fred
Opera true false undefined


I think we can agree that using non-standard attributes causes unreliable
results. :)
 
T

Thomas 'PointedEars' Lahn

RobG said:
Thomas said:
RobG said:
briggs wrote:
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...] [...]
If you check the elements, they have a 'name' attribute
False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<title></title>

| said:
<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
</html>

(I reply only to clear up a misunderstanding. In case you did not notice
yet, usually I do not read postings of yours with a non-existing sender
address since I killfiled .auau in From headers as being a disregarding of
Netiquette [RFC1855] and a violation of USENET/Internet (quasi-)standards,
particularly RFC1036 and RFC[2]822.)

I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.

As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.
I think we can agree that using non-standard attributes causes
unreliable results. :)

We can, even in an ambiguous sense.


PointedEars
 
R

RobG

Thomas said:
RobG wrote:

Thomas said:
RobG wrote:

briggs wrote:

c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...]

[...]

If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following: [...]
<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
[...]

I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.

I was highlighting differences in outcomes depending on how it is
attempted for the purpose of discussion, not contradiction.

As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?


==Some further discussion==

In Firefox, attributes can be added to an element:

1. in the HTML source,
2. using the element's setAttribute method, and
3. using JavaScript dot notation.

The first two methods will add the attribute to the HTML element's
attribute object, making them available to other methods such as
getElementById or getElementsByName.

Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same name
defined in the relevant DTD.

This means that an ID can be added to a DIV's attributes object using:

divRef.id = 'divId';
divRef.hasAttribute('id') // returns true


But since name is not an attribute defined in the HTML 4 DTD, a name
attribute isn't added to divRef's attributes object if dot notation is used:

divRef.name = 'divName';
divRef.hasAttribute('name') // returns false


But a name attribute can be added to the attributes object using
setAttribute:

divRef.setAttribute('name','divName');
divRef.hasAttribute('name') // returns true

Now hasAttribute('name') will return true, getElementsByName will find
the div and innerHTML reveals a name attribute in the HTML.

The results from IE 6 are quite different, it does not allow the 'name'
attribute to be added to a DIV element's attributes object by any of the
above methods.

We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine.

I explained that different results are obtained using exactly the same
code in different browsers and that how the attribute is attached can
affect the outcome in ways that are not obvious or might not be expected.

Do you have a different reason for saying so?.


1. Ignoring innerHTML, innerText and other proprietary approaches.
 
T

Thomas 'PointedEars' Lahn

RobG said:
Thomas said:
RobG said:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
briggs wrote:
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...]
[...]
If you check the elements, they have a 'name' attribute
False. The element object created is added a `name' property.

c.getAttribute("name") // null
Consider the following: [...]
<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script>
[...]
I was talking about creating element objects through DOM scripting and
what happens when they are added a property that does not have a Valid
corresponding attribute.

You are talking about referring to existing elements in _markup_ via
element objects and what happens when that element objects are added
a property that does not have a Valid corresponding attribute.

I was highlighting differences in outcomes depending on how it is
attempted for the purpose of discussion, not contradiction.
Pardon?
As for the code of the OP,

c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?

Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that
name to the respective element at all. I assumed that to be clear already.
==Some further discussion==

In Firefox, attributes can be added to an element:

1. in the HTML source,
2. using the element's setAttribute method, and
3. using JavaScript dot notation.

The first two methods will add the attribute to the HTML element's
attribute object, making them available to other methods such as
getElementById or getElementsByName.

Where I consider it to be a Gecko DOM bug that setAttribute() is
successful even though the resulting element (would) contradict(s)
the DTD.
Using dot notation will only add an attribute to the element's
attributes object if the element has an attribute with the same
name defined in the relevant DTD.

See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.
[...]
We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.

I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)


Regards,
PointedEars
 
R

RobG

Thomas said:
RobG wrote:

Thomas said:
RobG wrote:

Thomas 'PointedEars' Lahn wrote:

RobG wrote:

briggs wrote:

c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...]

[...]

If you check the elements, they have a 'name' attribute

False. The element object created is added a `name' property.

c.getAttribute("name") // null

Consider the following:
[...]

<div id="steve">name is fred, id is steve</div>
<script type="text/javascript">
var x = document.getElementById('steve');
x.name = 'fred';
alert(
'hasAttribute name? ' + (x.hasAttribute('name'))
+ '\nname in x? ' + ('name' in x)
+ '\nValue of x.name? ' + x.name
);
</script> [...]
c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.

'correct' on what basis? Can you explain why 'false' is the correct
response?


Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that ^^^^^^
name to the respective element at all. I assumed that to be clear already.

Not to me.

It seems that there is no way of determining via script what attributes
are OK and what aren't - hasAttribute only tells you those that have
been set, not whether the attribute is valid for that element.

There is nothing in the DOM spec that says using setAttribute to attach
an attribute that isn't in the DTD should do anything in particular
(hence your use of 'should' rather than 'must' and I agree with that).

Where I consider it to be a Gecko DOM bug that setAttribute() is
successful even though the resulting element (would) contradict(s)
the DTD.

Which suggests that for setAttribute to be useful, it should return a
value to say whether attaching/modifying the attribute was successful -
otherwise dot notation may as well be used.

A hack can be to use dot notation to set the property then test it with
hasAttribute - but IE doesn't support hasAttribute.

IE isn't much better - it won't find the element using
getElementsByName, but it will add the name attribute to the HTML and
attribute object using any of the mentioned methods.

See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.

It doesn't matter HTML or createElement are used to create the element,
it's how the attribute is attached that matters.

Adding the attribute in the HTML behaves exactly as does setAttribute,
and setAttribute behaves the same whether the element is created in HTML
or DOM. Adding the attribute as a property of the DOM object is where
the difference lies (to which I suppose you could respond with "Yeah,
like I said in the beginning").

I did quite a bit of further testing to prove it this, hopefully that
will make the lesson stick. This discussion has been useful, at least
to me.

I'd call it a Gecko flaw, bug indicates a programming error. This seems
to be a 'works as designed' thing - but that's just opinion.

[...]
I think we can agree that using non-standard attributes causes
unreliable results. :)

We can, even in an ambiguous sense.

'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.


I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)

And I don't disagree with that! :)
 
T

Thomas 'PointedEars' Lahn

RobG said:
Thomas said:
RobG said:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
Thomas 'PointedEars' Lahn wrote:
RobG wrote:
briggs wrote:
c = document.createElement("DIV"); // Create 'div' element.
c.id = "ch";
c.name = "ch";
[...]
[...]
[...]
c.hasAttribute("name")

correctly yields `false' in Firefox 1.5 if called afterwards.
'correct' on what basis? Can you explain why 'false' is the correct
response?
Because adding a property to an element object that has no corresponding
declared attribute name should not result in adding an attribute of that ^^^^^^
name to the respective element at all. I assumed that to be clear
already.

Not to me.

It seems that there is no way of determining via script what attributes
are OK and what aren't - hasAttribute only tells you those that have
been set, not whether the attribute is valid for that element.

Unfortunately, yes.
There is nothing in the DOM spec that says using setAttribute to attach
an attribute that isn't in the DTD should do anything in particular
(hence your use of 'should' rather than 'must' and I agree with that).

<URL:http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288>

Unfortunately, this particular recommendation regarding attribute values
should not be followed in practice due to buggy implementations.
[...]
Which suggests that for setAttribute to be useful, it should return a
value to say whether attaching/modifying the attribute was successful -

It should throw an exception, could be an INVALID_CHARACTER_ERR exception,
in that case. DOM methods should not allow for creating elements that
contradict the document type they are declared for.

[...]
See above. It appears that whether the attribute is added or not using
that, depends on how the element object was created, unfortunately. I
consider that to be a Gecko DOM bug as well.

It doesn't matter HTML or createElement are used to create the element,
it's how the attribute is attached that matters.

No, if HTMLDocument::createElement is used, the created but not included
element is not added a new attribute using the property accessor, but the
element object is added a new property. Hence the return values of
HTMLElement::getAttribute() and HTMLElement::hasAttribute() for that
element object as the calling object.
[...]
I think we can agree that using non-standard attributes causes
unreliable results. :)
We can, even in an ambiguous sense.
'Ambiguous' infers that you think it is unreliable for a reason
different to mine. [...]
Do you have a different reason for saying so?.
I have. Non-existing e-mail addresses in From headers are a non-standard
attribute, too, and the unreliable result it produces is a smaller number
of competent people that will read and reply to your postings :) (SCNR)

And I don't disagree with that! :)

I see.

$ host -t MX iinet.net.au
iinet.net.au mail is handled by 10 filter.iinet.net.au.

$ telnet filter.iinet.net.au smtp
| Trying 203.0.178.192...
| Connected to filter.iinet.net.au.
| Escape character is '^]'.
| 554 iinet-mail.icp-qv1-irony4.iinet.net.au
| Connection closed by foreign host.

Probably you want to read the Acceptable Use Policy of your service
provider, SingTel Optus Pty Ltd., again, especially Appendix H, section 7.

[Word]
<URL:http://optus.net.au/dafiles/OCA/Abo...ry/SharedStaticFiles/SharedDocuments/AppH.doc>


Score adjusted

PointedEars
 
T

Thomas 'PointedEars' Lahn

Randy said:
Thomas 'PointedEars' Lahn said the following on 1/16/2006 10:38 AM:

That is utter non-sense.

No, it is not.
Non-existing e-mail addresses are a "non-standard attribute"?

They are.
Did you read that before you posted it?

I did.
Your implication is that the fact the email address is non-existent makes
the attribute non-standard but that a valid address all of a sudden makes
it a standard attribute?

Yes, it does.
And I don't disagree with that! :)


I see.

$ host -t MX iinet.net.au
iinet.net.au mail is handled by 10 filter.iinet.net.au.

$ telnet filter.iinet.net.au smtp
| Trying 203.0.178.192...
| Connected to filter.iinet.net.au.
| Escape character is '^]'.
| 554 iinet-mail.icp-qv1-irony4.iinet.net.au
| Connection closed by foreign host.

Probably you want to read the Acceptable Use Policy of your service
provider, SingTel Optus Pty Ltd., again, especially Appendix H, section
7.

Mine is a "valid existing email address"

If what you write here applies, it is not:
but it is as useless as any other non-existing email address as you can't
send it email.

| Network Working Group M. Horton
| Request for Comments: 1036 AT&T Bell Laboratories
| Obsoletes: RFC-850 R. Adams
| Center for Seismic Studies
| December 1987
|
|
| Standard for Interchange of USENET Messages
| [...]
| 2.1. Required Header lines
|
| 2.1.1. From
|
| The "From" line contains the electronic mailing address of the
| person who sent the message, in the Internet syntax. [...]


| Network Working Group P. Resnick, Editor
| Request for Comments: 2822 QUALCOMM Incorporated
| Obsoletes: 822 April 2001
| Category: Standards Track
|
|
| Internet Message Format
| [...]
| 3.4. Address Specification
|
| Addresses occur in several message header fields to indicate senders
| and recipients of messages. An address may either be an individual
| mailbox, or a group of mailboxes.
| [...]
| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^


HTH

PointedEars
 
R

Randy Webb

Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:
Randy Webb wrote:

Yes, it does.

I have read some crazy things from you but that tops most of them.

If what you write here applies, it is not:

Read carefully what I wrote. The wording makes a difference. "You can't
send it email". Consider carefully the phrase I used versus "It doesn't
receive email". The email address I use in Usenet does indeed receive
mail. In fact almost 100 emails a day.

| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^

And as I said, that email address receives mail. Daily.

Your useless pedantics are getting old and serve no useful purpose.

I could just as well change my email address I post in Usenet to
(e-mail address removed) and neither is of any more use to you
than the other.
 
T

Thomas 'PointedEars' Lahn

Randy said:
Thomas 'PointedEars' Lahn said the following on 1/16/2006 5:41 PM:

Read carefully what I wrote. The wording makes a difference.

Indeed it does. If what you say above is true, you used the wrong wording.
"You can't send it email". Consider carefully the phrase I used versus "It
doesn't receive email".

An e-mail address must specify an existing mailbox; anything that does not,
is no e-mail address (RFC[2]822, Address Specification). Electronic mail
that cannot be received by a mailbox is never delivered by either the
sending or the receiving MTA; after some tries it results in a bounce, an
"undeliverable mail" message, to the sender and is removed from the MTA's
queue.
The email address I use in Usenet does indeed receive mail. In fact almost
100 emails a day.


<snip useless quote that is irrelevant to me>

Irrelevant to you, but not to the discussion and many service providers.
| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^

And as I said, that email address receives mail.

What counts is that the _mailbox_ receives.

If we assume that you identify e-mail address with mailbox, your statement
above that you cannot send mail there is not true, and your sender address
would not pose any problem. However, it would violate Internet Standard 11
(RFC[2]822) otherwise.


PointedEars
 
R

Randy Webb

Thomas 'PointedEars' Lahn said the following on 1/17/2006 7:35 AM:
Randy Webb wrote:




Indeed it does. If what you say above is true, you used the wrong wording.

I did not use the wrong wording to say what I wanted to say. It says
exactly what I wanted to say and it said in the way I wanted it said.
That does not make it the "wrong wording".
"You can't send it email". Consider carefully the phrase I used versus "It
doesn't receive email".


An e-mail address must specify an existing mailbox; anything that does not,
is no e-mail address (RFC[2]822, Address Specification).

Mine does.

Electronic mail that cannot be received by a mailbox is never
delivered by either the
sending or the receiving MTA;

The email address I use points at a mailbox that does indeed get mail
delivered to it - daily.

after some tries it results in a bounce, an
"undeliverable mail" message, to the sender and is removed from the MTA's
queue.

If you attempt to send an email to the address I give, you should get an
undeliverable mail message. Probably get a declined message though.
Irrelevant to you, but not to the discussion and many service providers.

For it to be relevant to a discussion between you and myself, it has to
be relevant to both of us and I don't give one iota what that reference
says.

As for my service provider, I don't think you would succeed in doing
anything more than giving them a good laugh if you notified them that I
was using an email address that you can't send email to. Especially
considering that Comcast explicitly suggests you do just that (use a
fake address) to cut down on spam.
| A mailbox receives mail. [...]
^^^^^^^^^^^^^^^^^^^^^^^^

And as I said, that email address receives mail.


What counts is that the _mailbox_ receives.

And it does. What counts to *ME* is that YOU can not send it mail. And
that makes my email address just as useless to you as a non-existent
one. Other than a non-existent one has a little more use to you because
you get to be pedantic about whether that is proper or not when nobody
in this group (except you) gives a crap about it.
If we assume that you identify e-mail address with mailbox, your statement
above that you cannot send mail there is not true,

Send me an email then. See if it gets delivered. And then I will forward
one, with all headers intact, to you so that you can see that it
actually *does* receive email. Just not from anybody that I don't
explicitly allow to email it.
and your sender address would not pose any problem.

Fake sender addresses do not cause any problem. Well, other than to you.
However, it would violate Internet Standard 11 (RFC[2]822) otherwise.

Then sue me and complain to Comcast.
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Mon, 16 Jan
2006 17:28:56 remote, seen in Randy Webb
There are only two reasons people would want to have a valid email
address in Usenet Postings:
Untrue.

1) So that they can circumenvent the "Ask in Usenet, get answered in
Usenet" convention.

2) Collect email addresses for Spamming.

3) So that off-topic communication can occur, without off-topic news-
posting.

YSCIB.
 
L

Lasse Reichstein Nielsen

Thomas 'PointedEars' Lahn said:
An e-mail address must specify an existing mailbox;

What is a mailbox? If we use the rather loose definition of RFC2822,
the paragraph that you quote, a mailbox is said to both receive mail
and normally be comprised of two strings (optional display name and
e-mail address enclosed in < and >). That's ambiguous already. A
string does not receive mail.

What they appear to mean, and uses correctly later, is that the string
is a "mailbox specification". I.e., an identifier of something that
receive mails.

What "receives" means is still unspecified, since RFC2822 doesn't
cover exchange protocols like NNTP and SMPT. Piping to /dev/null
should be sufficient.

A more precise definition is in RFC2821 (2.3.10 Mailbox and Address).
It still just says that a mailbox is a place where mail is deposited.
Again "deposited" is not formalized.

I can assure you that I have mailboxes that delete some incoming mails
without me ever seeing them. Is that a mailbox? Would it be if it
deleted all of them?


/L
 
T

Thomas 'PointedEars' Lahn

Lasse said:
Thomas 'PointedEars' Lahn said:
An e-mail address must specify an existing mailbox;

What is a mailbox? [...]

| 3.4. Address Specification
|
| Addresses occur in several message header fields to indicate senders
| and recipients of messages. An address may either be an individual
| mailbox, or a group of mailboxes.
| [...]
| A mailbox receives mail. It is a conceptual entity which
| does not necessarily pertain to file storage. [...]

What a mailbox is, could not be more clear: A mailbox is a conceptual
entity that receives (e-)mail and belongs to a recipient.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top