Subject: [Sipping] RE: Comments on draft-moran-sipping-filter-arch-00

From: [email-masked]
Date: Fri, 7 Jun 2002 19:43:31 -0500

Eric,

Appreciate your comments. I will update based on yours and any others received in the next week or two. I am looking for indication as to which language to use for specifying the rules. Is XML good enough? Once a language is selected, then I can see a more assertive effort in specifying the protocol (e.g. a DTD). Another question  I have is whether DTD is good enough. Are there strong opinions for Schema vs DTD for this application  - technical or religious?

Regards,

Tim M.

> -----Original Message-----
> From: ext Eric Burger [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 8:12 AM
> To: Moran Tim (NET/Dallas)
> Cc: Sipping
> Subject: Comments on draft-moran-sipping-filter-arch-00
> 
> 
> In general, even I can endorse the draft :-)

Apparently you do not endorse many submissions ???  Appreciate your endorsement nonetheless.

> 
> The concept of a standard set of methods to set parameters in the
> notification server is rather useful.  This draft exemplifies 
> the value of
> object-oriented methods.  You might want to mention that in the draft.

Will do.

> 
> I have some comments and some editorial nits.  First the comments.
> 
> 3.1.1 Current time
> Is it meaningful to have millisecond accuracy for something 
> that can easily
> take 500ms of one-way transit time?
> In the 3G case, the endpoint does have a pretty good sense of 
> network time.
> For that matter, 2G handsets have a good sense of network 
> time.  However,
> can we rely on this in the general case?  More importantly, 
> is there a use
> case for a current time parameter?

Other (e.g. non-wireless and/or non-presence) event packages may be able to make use of it either now or in the future. For those that don't need ms granularity  - or even the higher order(s) I suggest the use of default values. For example, time zone is required but no default. Year, month, and day is required with no default. Hours, minutes, seconds, milliseconds is defaulted to 0. To specifically address your comment could be done by defaulting the ms to 0 and requiring everything else with no defaults. Thus, those who don't need it do not have to do anything while those that do can utilize it.

> 
> 3.3 Operators
> Do all servers have to support all operators?  If they don't, 
> and I don't
> see how one could require them to, then do we need to 
> differentiate between
> "I recognize that operator but I don't support it" versus "I 
> don't get what
> you are trying to say."?

The Error reporting in section 3.1.4 identifies the cases of do not understand or cannot honor. I think this covers your case. We realized that there will probably be a finite set of canned error codes and responses required to be supported. We wanted to leave that to the next phase - but we can address now. Some initial thinking is:
1. Illegal Syntax. 
2. Feature not supported - could be an operation, or just that the statment is too complex for the application (filtering engine)
3. Illegal Value or maybe Parameter out of Range or Value Not Supported - the application can not support the requested operation due to implementation limitations. For example, the server can only provide notifications every 2 seconds as opposed to a requested value of every 100 ms.
4. Package not supported - this could also be covered by 2. The intent is to capture the case that the subscription was sent to the wrong application server.
5. Others?

> 
> 3.3.2 Comparison and Logical Operators
> For Has-changed-by, I would propose the default units are 
> specified by the
> package.  In the appendix, this corresponds to the 
> "location-radius-meters"
> attribute.  Otherwise, I would suggest passing the value and 
> units as opaque
> strings.

The application is in control in any of the cases cited above and below. In the example we used the application explicitely defined the units in the element tag. Perhaps that is a bad application design. As far as this draft is concerned - the application element is carried opaquely so it should work for well structured (human readable) package design as well as the ones that are rather grating. Perhaps we should improve upon the examples to follow current trends/wisdom. I prefer the VoiceXML example where the units are in the value. The application knows how to decode the structure of the value including multipart values as in "1h3m2s" or "[email-masked]" or "972-374-1369". However, another application may wish to enforce strict validation and specify the units in a separate element which is an enumerated type or even fixe - but this is off on a tangent.

> 
> One option is to link the tag to a value, such as
> '<interval>900s</interval>'.  This has the benefit of saying 
> what you mean.
> It has the drawback of being long.
> 
> Another options is to specify the value in the VoiceXML way, such as
> '<interval value="900s"/>'
> 
> '<interval seconds="900"/>' is rather grating and makes for a 
> big DTD if you
> wanted to also allow <interval minutes="15"/>, <interval 
> days=".01041667"/>.
> 

Again, these are package design issues. The rule protocol merely transports them to the filteirng engine application which has to know how to interpret the values - and the id of the value.

> 
> 3.3.3 Time-based Logical Operators
> I would suggest that it would be more understandable to say 
> that "Every X"
> means repeat the notification every X period until we hit the 
> Expires time
> of the original subscription, while "Every X 0" means report 
> once.  This
> follows the meaning found for the Expires header, as well as 
> making sense as
> you read it.  That is, when I say, "Please check my e-mail 
> every 5 minutes"
> I expect the system to check my e-mail every 5 minutes until 
> I say stop.  I
> don't expect the system to check my email 5 minutes from now 
> and then stop.
> 

In the spirit of expressions it needs to state the logical value returned. Remember this rule may be combined (and'ed) with another expression that would not result in sending a notification. While I like the way you put it - it might cause others to think that it overrides all other components of the overall expression. Not specifying repeat-n is the same as repeat-n=0 which by reading the current description would send only once. 

> 
> The following are typographical errors.
> 
> 3.1.4 Error
> s/Code, and String/Code and String/

> 
> 3.3.1, 3.3.2, 3.3.4, 5.2, 9 [7], 9 [8], Annex A, Elsewhere
> There seem to be non-7-bit ASCII characters throughout the 
> document.  I
> think you have some em dashes and curly single & double quotes.
> 

> 4.1 Normal
> s/are used. If no, filtering rules/are used. If no filtering rules/
> 
> 10 Author's Addresses
> This section should be "Authors' Addresses".  Also, your 
> e-mail is much more
> important than your (missing) telephone number :-)

USA 972.374.1369
Thanks again - good comments.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 21 Jun 2002 16:22:11 -0400

My problem with XML is the usual one: I like lisp; I like matching
parenthesis; I hate angle-brackets--slashes that don't match :-(

XML is as bad as anything else.  It's hot, so no one will complain (even if
no one can use it).

My understanding is that XML Schema is the "current" schema definition
format, while DTD is legacy.  E.g., schema is definitely the way to go.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 07, 2002 8:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Comments on draft-moran-sipping-filter-arch-00

Eric,

Appreciate your comments. I will update based on yours and any others
received in the next week or two. I am looking for indication as to which
language to use for specifying the rules. Is XML good enough? Once a
language is selected, then I can see a more assertive effort in specifying
the protocol (e.g. a DTD). Another question  I have is whether DTD is good
enough. Are there strong opinions for Schema vs DTD for this application  -
technical or religious?

Regards,

Tim M.

> In general, even I can endorse the draft :-)

Apparently you do not endorse many submissions ???  Appreciate your
endorsement nonetheless.

Will do.

> case for a current time parameter?

Other (e.g. non-wireless and/or non-presence) event packages may be able to
make use of it either now or in the future. For those that don't need ms
granularity  - or even the higher order(s) I suggest the use of default
values. For example, time zone is required but no default. Year, month, and
day is required with no default. Hours, minutes, seconds, milliseconds is
defaulted to 0. To specifically address your comment could be done by
defaulting the ms to 0 and requiring everything else with no defaults. Thus,
those who don't need it do not have to do anything while those that do can
utilize it.

> "I recognize that operator but I don't support it" versus "I

The Error reporting in section 3.1.4 identifies the cases of do not
understand or cannot honor. I think this covers your case. We realized that
there will probably be a finite set of canned error codes and responses
required to be supported. We wanted to leave that to the next phase - but we
can address now. Some initial thinking is:
1. Illegal Syntax.
2. Feature not supported - could be an operation, or just that the statment
is too complex for the application (filtering engine)
3. Illegal Value or maybe Parameter out of Range or Value Not Supported -
the application can not support the requested operation due to
implementation limitations. For example, the server can only provide
notifications every 2 seconds as opposed to a requested value of every 100
ms.
4. Package not supported - this could also be covered by 2. The intent is to
capture the case that the subscription was sent to the wrong application
server.
5. Others?

> attribute.  Otherwise, I would suggest passing the value and

The application is in control in any of the cases cited above and below. In
the example we used the application explicitely defined the units in the
element tag. Perhaps that is a bad application design. As far as this draft
is concerned - the application element is carried opaquely so it should work
for well structured (human readable) package design as well as the ones that
are rather grating. Perhaps we should improve upon the examples to follow
current trends/wisdom. I prefer the VoiceXML example where the units are in
the value. The application knows how to decode the structure of the value
including multipart values as in "1h3m2s" or "[email-masked]" or
"972-374-1369". However, another application may wish to enforce strict
validation and specify the units in a separate element which is an
enumerated type or even fixe - but this is off on a tangent.

> wanted to also allow <interval minutes="15"/>, <interval

Again, these are package design issues. The rule protocol merely transports
them to the filteirng engine application which has to know how to interpret
the values - and the id of the value.

> don't expect the system to check my email 5 minutes from now

In the spirit of expressions it needs to state the logical value returned.
Remember this rule may be combined (and'ed) with another expression that
would not result in sending a notification. While I like the way you put
it - it might cause others to think that it overrides all other components
of the overall expression. Not specifying repeat-n is the same as repeat-n=0
which by reading the current description would send only once.

USA 972.374.1369