Subject: Comments on draft-ietf-msgtrk-mtqp-03.txt

From: Gregory Neil Shapiro <[email-masked]>
Date: Sat, 4 Aug 2001 01:47:34 -0700

2.  Basic Operation

The second paragraph describes how to determine tracking host to contact.
How about a host like this:

gshapiro.net	IN	SRV	mtqp tracking.gshapiro.net
		IN	MX 10	smtp.gshapiro.net
		IN	MX 20	smtp.sendmail.com

In other words, a dedicated tracking server for gshapiro.net and two MX
records.  When an SMTP message is sent, smtp.gshapiro.net happens to be
unavailable so the message goes to smtp.sendmail.com.  If an MTQP client
then tries to track the message, it will use tracking.gshapiro.net (due to
the SRV record).  However, tracking.gshapiro.net doesn't know about the
message yet (still in smtp.sendmail.com's queue).  The lookup fails.

Also, it's not clear from the paragraph that if SRV records do not exist,
do you only use the first MX returned or all of them in MX preference
order?

If I may suggest the following change:

     When an MTQP client wishes to make use of the message tracking
     service, it establishes a TCP connection with the server host.  To
     find the server host, the MTQP client first does an MX lookup for the
     server host using DNS MX records, as specified in [RFC-DNS] and
     revised by [RFC-HOSTS].  If no MX records are found, the MTQP client
     then does an A record lookup for the server host.  If MX records are
     found, for each MX record (in MX preference order -- lowest to
     highest), an SRV lookup on the MX host name using DNS SRV records,
     with a service name of "mtqp".  (See the "Usage rules" section in
     [RFC-SRV] for details.)  If a SRV host is found, the MTQP client uses
     that host for tracking.  Otherwise, it uses the MX host name for
     tracking.  Finally, the host either the SRV host (if found) or the MX
     host is contacted using MTQP.  This process is repeated for each of
     the MX records until an MTQP lookup succeeds (i.e., tracking status is
     returned).

With this new text, the DNS records might look something like:

gshapiro.net		IN	MX 10	smtp.gshapiro.net
			IN	MX 20	smtp.sendmail.com

smtp.gshapiro.net	IN	A	10.254.153.10

smtp.sendmail.com	IN	A	192.168.10.43
			IN	SRV	mtqp tracking.sendmail.com

tracking.sendmail.com	IN	A	192.168.10.45

In which case, a message sent to [email-masked] would be tracked by
first contacting smtp.gshapiro.net with MTQP and if no tracking information
is available at that host (or it can not be contacted), then continue by
contacting tracking.sendmail.com with MTQP.

An example, such as the one I have given should be added to the draft.

---

3.  Initialization and Option Response

Example 5 should probably use "VND." as Option2 and Option3 are not valid
(only STARTTLS is).  A suggested replacement:

     Example #5 (options available):
     S: +OK+/MTQP MTQP server ready
     S: starttls
     S: Vnd.vendor.Option2 with parameters
     S: Vnd.vendor.Option3 with a very long
     S:  list of parameters
     S: .

---

10.  IANA Considerations

Vendor-specific options MUST be registered with IANA?  I thought the whole
point of vendor options was like that of 'X' ESMTP extensions:

RFC 2821             Simple Mail Transfer Protocol            April 2001
2.2.2 Definition and Registration of Extensions

   In addition, any EHLO keyword value starting with an upper or lower
   case "X" refers to a local SMTP service extension used exclusively
   through bilateral agreement.  Keywords beginning with "X" MUST NOT be
   used in a registered service extension.  Conversely, keyword values
   presented in the EHLO response that do not begin with "X" MUST
   correspond to a standard, standards-track, or IESG-approved
   experimental SMTP service extension registered with IANA.  A
   conforming server MUST NOT offer non-"X"-prefixed keyword values that
   are not described in a registered extension.

If that is the case, then they should not be registered with IANA.  Perhaps
we want to steal some of the above text for this document.

---

12.  Protocol Syntax

Move opt-text up as it is used by comment-command first (before
temp-response).

The response-info ABNF is incorrect.  The parens are not balanced.

---

Spelling fixes:

@@ -197 +197 @@
-parseable, case-insensitive response information giving more data about
+parsable, case-insensitive response information giving more data about
@@ -249 +249 @@
-Which option is picked is an adminstrative decision and is not further
+Which option is picked is an administrative decision and is not further
@@ -667 +667 @@
-     System port number XXXX - TBA by IANA
+     System port number XXXX - TBD by IANA
@@ -693 +693 @@
-begin with "vnd."  MUST be registered with IANA on a Firt Come First
+begin with "vnd."  MUST be registered with IANA on a First Come First
@@ -721 +721 @@
-     Both the STMP client and server must check the result of the TLS
+     Both the SMTP client and server must check the result of the TLS
@@ -725 +725 @@
-was achieved is made locally, is implementation-dependant, and is beyond
+was achieved is made locally, is implementation-dependent, and is beyond
@@ -825 +825 @@
-13.  Acknowledgements
+13.  Acknowledgments
@@ -925 +925 @@
-assist in its implmentation may be prepared, copied, published and dis-
+assist in its implementation may be prepared, copied, published and dis-
@@ -930 +930 @@
-references to the Internet Society or other Internet organisations,
+references to the Internet Society or other Internet organizations,

---

From: Tony Hansen <[email-masked]>
Date: Sat, 04 Aug 2001 14:07:05 -0400

See comments below.

	Tony

> An example, such as the one I have given should be added to the draft.

I don't know how common this usage of MX records is, but it is valid.
I'm okay with this change. Anyone else?

>      S: Vnd.vendor.Option3 with a very long

sure

> we want to steal some of the above text for this document.

I meant to say that the vendor name must be registered, as is done with
MIME content types.

Another option is to go the java route and use a reversed domain name:

	vnd.com.example.option1

This avoids the IANA registration issue entirely, under the assumption
that only the owners of a domain would use their domain.

> The response-info ABNF is incorrect.  The parens are not balanced.

ok

> Spelling fixes:

ok

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Aug 2001 09:32:39 -0400

At today's mini-BOF, we did not discuss this issue. I'm leaning towards
the reversed domain name solution.

	Tony

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 06 Aug 2001 09:06:15 -0600

> the reversed domain name solution.

Domain names aren't stickky enough for this. We (Esys, no Simeon,
no Execmail. Wait, make that Messagingdirect, er I _really_ meant
ACI) are ample proof of this :-(

Would we need to (IANA) register each item, or just reserve a vendor prefix
in the namespace?

--lyndon

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Aug 2001 14:01:27 -0400

I also noticed these RFCs:

2806	telephone call URL	vnd.company.option
2848	PINT			vnd.acme.com
3028	Sieve			vnd.vendor.product

	Tony

Tony Hansen wrote:
> 
> I was trying to emulate MIME vendor content-types, where this hasn't
> been a problem. After a company is renamed, it could continue to use the
> existing name, or register another name -- it's their choice.
> 
> The way MIME content-types are done, vendor company prefixes are
> registered:
> 
>    Registrations in the vendor tree will be distinguished by the leading
>    facet "vnd.".  That may be followed, at the discretion of the
>    registration, by either a media type name from a well-known producer
>    (e.g., "vnd.mudpie") or by an IANA-approved designation of the
>    producer's name which is then followed by a media type or product
>    designation (e.g., vnd.bigcompany.funnypictures).
> 
> I would just expect the vendor prefix in the namespace to be registered.
> It would be even better if we could bounce off another, existing
> registry.
> 
> IANA's vendor content-types aren't all that regular, because of the
> muddying of the namespace waters (letting media names be at the 2nd
> level, as in vnd.mudpie vs. vnd.bigcompany.funnypictures). So it would
> be difficult to bounce off that registry. That's why dns names would be
> better.
> 
> How quickly do dns names get reused after a company gets renamed? When a
> company renames itself, how quickly do they usually relinquish their old
> domain names, and how quickly after that do they get picked up by other
> companies?
> 
> Another alternative would be to create a vendor namespace registry
> that's divorced from mtqp, and bounce off of that registry. How useful
> would that be?
> 
>         Tony
> 
> Lyndon Nerenberg wrote:
> >

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Aug 2001 13:54:59 -0400

Tony

---

From: [email-masked]
Date: Tue, 07 Aug 2001 00:45:10 -0700 (PDT)

>    designation (e.g., vnd.bigcompany.funnypictures).

Note, however, that this registers vnd.bigcompany.funnypictures, not
vnd.bigcompany or bigcompany. So it isn't strictly correct to say that company
prefixes are registered.

The media type reviewer (currently me) does check for inappropriate producer
name use, however, this isn't as much of check as you might think since due to
inaction on the part of various producers we have had little choice but to
allow other people to register their types for them. (The process does give the
actual producer the right to claim the registration later if they want to.) The
check ends up being along the lines of "is this really a media type associated
with this producer".

> It would be even better if we could bounce off another, existing

This is treading dangerously close to the domain name situation. We don't want
to go there.

> be difficult to bounce off that registry. That's why dns names would be

Piggybacking off of domain names could work. It is certainly better than having
a separate registry.

> domain names, and how quickly after that do they get picked up by other

There's a huge amount of variability in all this in practice.

> that's divorced from mtqp, and bounce off of that registry. How useful

Bad Idea IMO.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Tue, 07 Aug 2001 05:12:04 -0400

Ned, care to make a specific recommendation?

I see these options:

    o	punt -- don't specify a registry at all. This is the same
	thing that RFCs 2806 (tel URL), 2848 (PINT) and 3028 (sieve)
	do. They all specify the same type of vendor trees, but do NOT
	specify any registry for the list.

    o	go with reverse domain names

    o	have IANA do a generic registry of vendor names, usable by
	mtqp, 2806, 2848, 3028, future RFCs, etc.

    o	have IANA do a special registry for mtqp vendor options

If I don't hear some specific recommendations, I plan on going with the
punt option.

	Tony

---

From: [email-masked]
Date: Tue, 07 Aug 2001 03:01:27 -0700 (PDT)

>     o	go with reverse domain names

I guess I slightly prefer punting, but either one of these seems fine to me.

				Ned

---

From: Eric Allman <[email-masked]>
Date: Tue, 07 Aug 2001 05:32:13 -0700

This doesn't look like a strong enough argument to punt this idea, at
least to me.  For example, suppose that several incarnations ago you
had a vendor extension -- let's call it

	vnd.esys.XXX

The "esys" part is registered with IANA if we choose the "register"
option, or is just grabbed by you if we choose the "punt" option.

In any case, once you've distributed software that uses this vnd tag,
you're pretty much locked in to maintaining it -- you can't really
ask client software to look for vnd.esys, vnd.simeon, vnd.execmail,
vnd.messagingdirect, and vnd.aci -- treating them all as aliases.

By the way, I notice that you still have esys.ca registered.  It
seems that if a vendor has software that uses an extension of this
type, it isn't all that hard for them to maintain the old domain name
in order to keep the namespace registered, just as you have.

I'm leaning toward reversed domain names rather than register or punt.
Register seems like it's an unneeded extra level of work, and why
punt if we can come up with a reasonable way to do this now?

Of course, one advantage of registration is that these don't
arbitrarily expire -- so if a company (for example) goes out of
business but their software is still deployed, the namespace isn't
subject to re-use.

eric

============= In Reply To: ===========================================
: From:  Lyndon Nerenberg <[email-masked]>
: Subject:  Re: Comments on draft-ietf-msgtrk-mtqp-03.txt 
: Date:  Mon, 06 Aug 2001 09:06:15 -0600

: 
: > At today's mini-BOF, we did not discuss this issue. I'm leaning towards
: > the reversed domain name solution.
: 
: Domain names aren't stickky enough for this. We (Esys, no Simeon,
: no Execmail. Wait, make that Messagingdirect, er I _really_ meant
: ACI) are ample proof of this :-(
: 
: Would we need to (IANA) register each item, or just reserve a vendor prefix
: in the namespace?
: 
: --lyndon

---

From: Eric Allman <[email-masked]>
Date: Tue, 07 Aug 2001 05:35:49 -0700

: From:  [email-masked]
: > The way MIME content-types are done, vendor company prefixes are
: > registered:
: 
: >    Registrations in the vendor tree will be distinguished by the leading
: >    facet "vnd.".  That may be followed, at the discretion of the
: >    registration, by either a media type name from a well-known producer
: >    (e.g., "vnd.mudpie") or by an IANA-approved designation of the
: >    producer's name which is then followed by a media type or product
: >    designation (e.g., vnd.bigcompany.funnypictures).
: 
: Note, however, that this registers vnd.bigcompany.funnypictures, not
: vnd.bigcompany or bigcompany. So it isn't strictly correct to say that company
: prefixes are registered.

Ned, I read this differently -- "IANA-approved designation" modifies
"producer's name" -- which is "then followed" by a non-IANA-approved
media type or product designation.  Am I totally off?

eric

---

From: Tony Hansen <[email-masked]>
Date: Tue, 07 Aug 2001 11:34:52 -0400

From what I remember in the MIME discussions while working on vnd.,
Eric's interpretation was the intent. You were supposed to be able to
register vnd.bigcompany.* as well as vnd.bigcompany.xyz and
vnd.bigcompany.abc.

However, Ned's interpretation appears to be what was actually
implemented. If you look in the IANA registry, you'll find things like
vnd.bigcompany.funnypictures registered, rather than vnd.bigcompany.* or
just vnd.bigcompany.

	Tony

---

From: [email-masked]
Date: Fri, 10 Aug 2001 01:54:18 -0700 (PDT)

> media type or product designation.  Am I totally off?

IMO yes you are. You're equating designation with registration. The
designations implied by the various facets are checked as part of the process,
but only the entire media type is registered.

And FWIW, my recollection of the design of this scheme doesn't agree with
Tony's. I don't believe vendor or product registrations were ever considered as
part of this process. And given recent history in the domain name space as well
the recent image/tiff flap in the FAX WG (where a not-insigificant component is
perceived ownership  of a media type name), had IANA actually elected to
implement such a registry I believe we would have a hell of a mess on our hands
by now.

				Ned