Subject: AW: AW: [Enum] enumservices in new version of 2916bis

From: Brandner Rudolf <[email-masked]>
Date: Fri, 28 Jun 2002 18:09:37 +0200

Hi all,

> -----Ursprüngliche Nachricht-----
> Von: Richard Shockey [mailto:[email-masked]]
> Gesendet: Freitag, 28. Juni 2002 04:42
> An: Stastny Richard; Peterson, Jon; [email-masked]; 
> [email-masked]
> Betreff: Re: AW: [Enum] enumservices in new version of 2916bis
>
-----[snipp]----- 
> 
> or in the Walter convention ..."E2U+sip:srs"  ?? IMHO there 
> is much to 
> recommend in his approach....  Rudolf? Larry?  are we close here?
> 

So the discussion led to the following regarding the enumservice field:

E2U
That's a given and not controversial.

URIscheme
.. as a neccessity and being requested being mandatory.

service
.. being optional.

Lawrence proposed
     servicefield = "E2U" ("-" <uri-scheme>) [*("+" <enumservice>)]
for parsing reasons, which I support. If regexp is considered expensive, parsing is also. Thus having distinct delimiters is an advantage. Along the lines that a CATEGORY is a group of SERVICEs and therefore within the same space (but not redundant), I'd like to be able to put in the service field a category. So the <enumservice> might be voice or fax or email or talk or msg.
In addition, Richard Stastny proposed an optional addinfo, which I'd think would be best delimited by a '*' (see cost of parsing). Usage of addinfo needs to be defined, yet.

So we would have:
     servicefield = "E2U" ("-" <uri-scheme>) [*("+" <enumservice/category>)] ["*" addinfo]

Some examples: 

A non-terminal with no optional fields:
     "E2U-"
There's a sip URI coming with no more information revealed (as requested)
     "E2U-sip"
A tel: URI for a phone with a lot of features and an addinfo
     "E2U-tel+voice+msg*do not call me at night"
which is equivalent to (well, vmail not defined yet)
     "E2U-tel+voice+fax+sms+mms+vmail*do not call me at night"

OK, I can live with this and I accept
     servicefield = "E2U" ("-" <uri-scheme>) [*("+" <enumservice/category>)] ["*" addinfo]
I think we are there. The SIP community requirements are met, end systems requirements are met, regexp and parsing cost considered, gateways can deal with this. Anything more?

Rudi

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

---

From: Michael Mealling <[email-masked]>
Date: Fri, 28 Jun 2002 12:21:39 -0400

On Fri, Jun 28, 2002 at 06:09:37PM +0200, Brandner Rudolf wrote:
> for parsing reasons, which I support. If regexp is considered 
> expensive, parsing is also. Thus having distinct delimiters is an 
> advantage. Along the lines that a CATEGORY is a group of SERVICEs and 
> therefore within the same space (but not redundant), I'd like to be 
> able to put in the service field a category. So the <enumservice> might 
> be voice or fax or email or talk or msg.
> In addition, Richard Stastny proposed an optional addinfo, which I'd 
> think would be best delimited by a '*' (see cost of parsing). Usage of 
> addinfo needs to be defined, yet.
> 
> So we would have:

Umm... I'd really like to change that from uri-scheme to protocol. It is
_very_ common for protocols to be able to handle more than one URI scheme.
URI scheme does _not_ equate to an actual protocol and vice versa.
In the above grammar it is impossible to specify that a mailto URI can be
used for something that isn't using SMTP.

> I think we are there. The SIP community requirements are met, end 
> systems requirements are met, regexp and parsing cost considered, 
> gateways can deal with this. Anything more?

I think the SIP community has communicated that they're happy with
something more than just 'SIP' as long as they can gaurantee that
they can make the decision to only ever deal with SIP. So I think
you may be intepreting their requirements more tightly than they are.

I think it is _very_ important to seperate the URI scheme from the
protocol found in the Service field. You can specify valid mappings in
the definition of the protocol value in the Service field but don't actually
_put_ the URI scheme there as though it were the only thing needed.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net