Rainer, OK, that sounds reasonable. The examples you give are a good ones and probably should be included in the RFC text.
Glen -----Original Message----- From: Rainer Gerhards [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 03:30 To: Marshall Glen; [EMAIL PROTECTED] Subject: RE: HOSTNAME Field > Chris, > > I conceptually agree with the proposed change. > > At the same time, at the risk of duplicating prior comments, > I see this allows for the HOSTNAME to reference a logical > entity which may be a subset or superset of a physical > entity. For example, foo.bar.com may easily refer to a web > server process, a load-balancing switch for several e-mail > servers, or a vanilla-flavor physical host machine of > arbitrary use. This suggests that HOSTNAME does not and > cannot unambiguously (or authentically) identify the source > of the message. Is this a problem? I don't think so - the current RFC3164 hostname has the same problem. Also, if you think about the front-ended web servers, the text does not require that you put the public name (e.g. www.example.net) into the hostname field - it could also be www-head.example.net, www1.example.net and www2.example.net if these are the three servers making up the farm. In fact, I would expect the later in, as these are what I think the real hostnames of the devices. I think the change Chris proposes makes life much easier - and is also already seen in many implementations. I need to re-read the RFC in regard to relays. In my view, we should allow a relay to reformat a hostname (any kind) in case it knows better about the real name. I am picking up on Andrew Ross' sample of many devices sending with a hostname of 10.0.0.1. A local relay could then be configured to rewrite the name to a more meaningful one before forwarding it to the central relay. Rainer > -----Original Message----- > From: Christopher Lonvick > > --vvv--- Proposed change to Section 2.2 ---vvv--- > > The HOSTNAME field will contain an indication of the originator of > the message in one of four formats: only the hostname, > the hostname > and domainname, the IPv4 address, or the IPv6 address. > The preferred > value is the hostname and domainname in the format specified in > STD-13 [RFC 1034 and 1035]. This format will be referred > to in this > document as HOSTNAME-STD13. If only the hostname is used, the > HOSTNAME field MUST contain the hostname only of the device as > specified in STD-13 [4]. This format is discouraged but > provides for > legacy compatability with the format described in RFC 3164. This > format will be referred to in this document as HOSTNAME-3164. In > this format, the Domain Name MUST NOT be included in the HOSTNAME > field. If the IPv4 address is used, it MUST be shown as the dotted > decimal notation as used in STD-13 [5], and will be referred to as > HOSTNAME-IPV4. If an IPv6 address is used, any valid > representation > used in RFC-2373 [6] MAY be used and will be referred to as > HOSTNAME-IPV6. A single space character MUST also follow the > HOSTNAME field. > > Messages containing Signature Blocks and Certificate Blocks as > described in this document MUST use the HOSTNAME-STD13 format in > the HOSTNAME field. > > ---^^^--- Proposed change to Section 2.2 ---^^^--- ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions Health Services Corporation and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you
