Subject: RE: [Enum] enumservice names

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 23 May 2002 11:05:16 -0600

Lawrence wrote:

> So there may be some post filtering AFTER the re-write has
> constructed a URI (or URIs).

This does seem to be the crux of the dispute. I agree with Lawrence here. And I assert that not only will there be post-filtering on the *protocol* side of the URI, but some uses may even look for capability "hints" in the URI *path* and other parameters. If so, then the use of the enumservice field should be one that is not fundamentally representable by the URI path itself.

In selection of a schema for the enumservice field, what strikes me as fundamentally not represented in the URI is the intent of the parties involved. This is why service resolution is different from call completion even though both may occur via the same basic URI. And this is why classes of communication like 'talk' vs. 'tty' or 'texttalk' make sense.

Moreover, if I have a means of invoking transcription services for an arbitrary number of protocols, I can't use the enumservice to derive at this question of intent when I don't know my protocol capabilities in advance. For instance, if a new protocol appeared under an entry the 'talk' enumservice, I could attempt to invoke a transcription service knowing that the class of communication for the call was compatible with talking (as opposed to typing, for instance). Of course, there may be ways to transcribe between the two, but if my list of possibilities has no such hint regarding the basic intent (or model or interface, whatever), then the enumservice field will be only marginally useful.

--Andy Zmolek 
    Technology & Standards Engineer 
      CTO Standards 
        Avaya Inc. 

            [email-masked] 
              +1 720 444 4001 
                sip:[email-masked]

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 23 May 2002 22:14:19 +0200

--On 2002-05-23 11.05 -0600 "Zmolek, Andrew (Andrew)" <[email-masked]>
wrote:

> If so, then the use of the enumservice field should be one that is not
> fundamentally representable by the URI path itself.

It depends. In some cases you need to do a lookup of NAPTR RRs several
times and apply the rewrite rule to get the full URI, so, I would like to
say that an enumservicefield is to give hints which are enough so a client
resolving the E2U NAPTR chains doesn't have to do too much unnessecary work.

This is _exactly_ why I suggested separate documents which specify each one
of the enumservices. In those documents it can be written exactly what the
client can expect given a specific enumservicefield. Regardless of if it is
"sip" or "voice".

   paf